Cal Henderson is the co-founder and CTO of Slack. He oversees Slack's world-class engineering team and sets the technical vision for the company. An experienced technology leader and a popular speaker on engineering scalability, he joined FirstMark Guilds to share his top tips, habits, and tactics.
How does Slack use Slack? What habits have you set up that have given you leverage?
The first thing I’ll say is that the way I use Slack is *very* different than how an individual contributor uses Slack. On how Slack uses Slack, I’d note a few things, the first of which is that I’m in a lot of channels. Since we have a high number of channels, we also have quite a bit of automation related to their creation and use cases. As an example, we have a whole hiring flow whereby each person we’re interviewing is added to their own channel and the entire hiring/offer process flow is handled on Slack. Another example is that we have a new channel stood up (and subsequently closed) for every internal incident.
Tip : I love using Slack’s Channel Section feature, where you can drag and drop certain channels into groups. Since I have so many channels in Slack, I rely heavily on our Search functionality to find relevant threads and previous discussions.
What does your team look like today, and along what dimensions are teams organized?
I have eight direct reports. Four VP-level folks who run the bulk of my Engineering org as well as a Chief of Staff, executive assistant, and a few principal engineers. The four VP-level leaders run: Infrastructure, Product Engineering, Developer Platform, Security.
Can you elaborate a bit on the role and focus of your principal engineers (PEs)?
Both PEs have been at the company since the original days. One is backend, one frontend. Both are jack-of-all-trades types and can dive into any team at any point. They’re very heavy output and can bring people along for the ride. Outside of the two that I work most closely with, we have 8 principals at the company of all archetypes of a pool of 800-900 engineers, so roughly 1%. We use them as strategic talent that can be moved to the most important thing at a moment’s notice versus having them go deep in an area for a long time.
How do you approach hiring in the Zoom era? How many interviews throughout a full process, what style of coding interview?
We haven’t made any substantial changes to our hiring process since COVID began because we’ve had strong infrastructure around remote interviewing for quite some time.
Step 1: Candidate completes initial application
Step 2: One hiring manager screen
Step 3: Most positions go through 4-interview slots
Step 4: For Director-level and up, we typically add an extra round that consists of a 45m presentation + 45m Q&A on any topic; very useful filter for assessing communication skills.
Step 5: By end of day, we almost always know if we can give you an offer and close you thatvsame day. Speed is absolutely key.
How do you assess engineers in a realistic & scalable way?
We used to use “take homes” for a long time. It provided a great signal, but we saw a bigdrop off in people not completing it. So we had to ask ourselves: “Are we willing to lose highquality candidates in this process?” The answer was resoundingly no. Now—and instead of take homes—we do live debugging pair programming. It’s more work on our side, but has a few benefits: 1) very strong signal, 2) if hired, there’s a strong sense ofvhaving gone through something communal, and 3) we don’t have the take-home dropoff issue we had before.
How do you handle annual planning?
Early on, we held weekly team meetings every Monday with everyone in Engineering -- everyone shared what they were doing. Honestly, we probably did that for too long (all the way up to 50 engineers) but it was very effective in minimizing other time-consuming coordination while keeping everyone on the same page. Now, we have two distinct planning frequencies: every fiscal year (when we focus on financial plans) and every quarter (when we focus on resource allocation). Often, it feels like we’re always planning. We also do 3-year planning, which is much higher level and focused on long-term strategic priorities.
How do you make prioritization decisions?
I’m a firm believer that you ship your org chart. An example of that, Slack Connect is a bundle of features that used to be joint run by a number of different teams. Onboarding belonged to Growth, Core belonged to Messaging, Compliance belonged to the Enterprise team and so
on. Point of the story? There was no one owner despite the fact that it’s a very strategic part of Slack. So we decided to break that out as a new org. We moved teams into that central department, and now we have a Slack Connect team. On a yearly basis, we also ask ourselves “what are our broad areas of investment?” because that’s how we should go shape our organization. The easiest things to build are ones that don’t cross organizational boundaries.
We have a few key sources for prioritization:
1. Our product vision & strategy
2. Feedback from our smallest customers
a. Focus : how do we make more of them successful & drive growth?
3. Feedback from our largest customers
a. Focus : All about winning deals & keeping customers happy
4. Infrastructure considerations
a. For example, what can we put in place now so we build faster next time?
i. E.g. evolution from Javascript to Typescript
b. Cleaning up our backlog and handling constant tech transitions that are always overlapping migrations
Book recommendation: An Elegant Puzzle by Will Larson | LINK
How do you think about the evergreen conundrum of measuring engineering throughput?
The most important role of a CTO is to understand the good, the bad, and the things you’re doing that truly move the needle. We have a group called Dev Productivity (Dev Prod) where we made a fairly large investment (overinvested early on) to focus on building internal tools for engineers. (10-15% of our engineers are in the Dev Prod group—reached 20% early on at one point).
In terms of engineering metrics, I prefer to look at the team level vs. the individual:
1. PRs per team - weirdly works because effort goes into shipping a PR into production.
2. Review time - how quickly does this team give feedback on another’s code?
a. ( When a team is healthy, team’s velocity here is high.)
3. Defect escape rate - Bugs in vs. bugs out + incidents
Tip: Each engineering manager & her team gets a dashboard on these metrics and their change over time, but more importantly, how they benchmark against other teams. Adds a sense of comradery and competition that’s been very healthy within the org.
Bonus: Lines of code are useless (too gamifiable)
Any new tools or infrastructure that’ve made a big difference?
We focus on tooling that’s based around how we transition office work online.
1. Donut - much more now than ever since we’re exclusively remote
2. Icebreaker - super lightweight, easy to use & fun
3. Loom - for moving previously synchronous events like team meetings or all-hands to asynchronous so that the content is more flexible for parents, custom hours, time zones, etc.
4. Healthy diet of Google Docs & Sheets (only increased during COVID)
Bonus : Some things are still better live. (e.g. collaborative whiteboarding).
How’re you boosting Diversity of your team?
We've done quite a bit, but the number one thing that has really helped us to attract talent is to make sure there are diverse senior-level managers and ICs. It all starts with hiring. Early on we intentionally made sure that we hired the first few women engineers really early so that it set the right tone for our team. We also want to make sure that people of all backgrounds can look around Slack and say: “I see people like me in senior manager and senior IC roles.”