Like some companies, Intercom's progression track for Engineers splits in two after Senior Engineer. Unlike some companies, Intercom provides tailored on-boarding, training and 1:1 support for Engineers who are interested in branching out into Management. Unlike almost all companies Intercom facilitates what some call the engineer manager pendulum - or a switch back to the IC track after some time as a Manager.
Why?
We believe in matching people to roles that play to their strengths and interests and also believe that that after - say - 2 years growing into and working as an Engineering Manager our Intercomrades will become good engineering managers AND better engineers.
So if it turns out after 2 years the role that now aligns with their strengths and interests is that of an Engineer, why wouldn’t we offer a path back?
Especially since they’re better Engineers than when they left for Management.
So what makes us so confident that they are better?
Leverage.
There’s a limit to what you can do with one keyboard and one brain and 24 hours. Even for the best in the world accelerated progress comes from increasing the amount you can get done per unit time. Even with the most expertise, smartest working process, sharpest IQ and fanciest energy drinks your ability to graft through, scale yourself and create something great alone is likely lower than you think it is.
Think of the key people in your favourite open source project - say Rails. How would @DHH make time to talk smack on twitter or go off the grid for 3 months if he was the sole developer on Rails? He wouldn’t. In reality Rails wouldn’t exist, or if it did it wouldn’t be wired into the fabric of so many successful companies on the world stage.
One of the oldest and most scalable ways of increasing your output per unit time is through people. Becoming an Engineering Manager offers you that gift of leverage from day 1.
It’s not uncommon to get to Senior Engineer level and never have need to flex properly into working through people. The median project in the median company isn’t that challenging and companies design org structures and processes geared towards keeping things this way because, much like predictable revenue, it’s great for business.
As an Engineering Manager it’s your job to work through people. You might think that you’d be terrible at that, and you might be right to start - but it’s unambiguously true that if you work at it (and you’ll have no choice as an EM) you’ll get better at it over time. 2 years later, if you decide you fancy a change - you’ll go back to an IC role with a new found ability to get leverage by working through people. This is a solid platform from which to plot your journey to staff or principal engineer and beyond.
Harder Problems. Bigger Projects.
The simplest distinction between an IC and a Manager is this …
A Manager works on the system, ICs work in the system
If you move from Senior Engineer in a team to Manager of a team it’s quite likely that you’ve just assumed ownership of the most complex system of your career. Your job is to take the components of that system - the people, tools and the environment, the culture - and create something that’s better than the sum of its individual parts.
This can be ridiculously hard in a way that is non-intuitive to beginners and hard to explain. To give a sense of what I mean, here are some of the questions that keep Managers awake at night.
- What is the ideal headcount for this team?
- Did this team succeed because of my influence, or in spite of it?
- What should my team be working on in the next 3 months? 6 months?
- Is this Engineer overworked? Is this Engineer cruising?
- In what situations are cruising or overwork acceptable? Desirable even?
- At what size and shape of meeting does group psychology dominate individual psychology?
- How can I give sufficient autonomy AND stay close enough to ensure fair, unbiased recognition?
- What are the plausible 2nd and 3rd order effects of moving somebody to a different team?
- How can something like a project estimate be both bullshit and necessary at the same time?
- How can I judge if this Engineer has better technical judgement than I have?
It’s incredibly difficult to come up with a simple and effective answer for these that applies in practice, and even harder to come up with an answer that generalizes to all teams at all times. There are certainly no easy answers to any of these questions. Or at least, the easy answers - the ones that look great on paper - are the ones that look silly in action and the ones that quickly get you in trouble. These questions represent hard problems - harder than most Engineering projects, in most teams of most companies.
The projects that you’ll drive to solve these problems as an Engineering Manager are also bigger than most Engineering projects at most companies. It takes time to see the effects of action you take on your team, probably a lot longer than your average scrum sprint. They’ll also be bigger in terms of impact. Making a change to a team of 5 people that lifts those 5 people for the longer term is multiples of what you might be capable of achieving by working as an IC directly on projects.
And if you decide you miss working in the system and not on the system and go back to Engineering, it’s likely your experience working on these hard big problems and your newly developed ability to herd cats will leave you in great shape to tackle harder and bigger Engineering projects.
New Perspectives
One of the refrains I often hear from folks who are considering some time in Management is a fear for rusting technical skills, technical knowledge and ability to execute. Remember, as a Manager, you’ll work on the system, not in the system - that is at least one zoom level removed from the codebase. On a Manager's schedule, you’ll find yourself in meetings a lot more than before. You’ll also find yourself spread across many different concerns, at different zoom levels possibly in the same day. It is, therefore, pretty certain that your raw execution skills will rust and that high fidelity feel for a stack or technology will get ever duller. At first, you won’t believe your advisors when they tell you, but this is the right sacrifice to make.
To effectively operate on the system - and to start thinking about good answers to the questions above, and to stay in touch with reality, your people and the business - you’ll need to develop an ability to step back from the front-line to gain perspective. You’ll need to partner that with an ability to go both broad and then deep when required. This doesn’t mean just broad and deep in terms of the technology stack, or the organisation - you’ll need to understand things you didn’t understand well before. Not just machines, but people who operate the machines. Not just the results, but the strategy that underpins the results. Not just the how but the why. You’ll need to scan over a broader range of things in general. You’ll need to develop a nose for when things look like they need deeper attention. This is hard because your picture will be pixellated and lossy right where you'd like it not to be and because you haven’t the time you had before. Many things might look fine but feel off and you'll only have time to pick one or two to pay attention to.
Then, when the need arises, you’ll need to be able to go deep. Deep into the details of the feasibility of a technical plan, the rationale of a long-range technical decision, or the motivations of your star performers. To do this effectively, you’ll need to develop not only expertise - but the ability to be an expert in not being an expert. The ability to lean on other disciplines, experts and perspectives and to synthesize your learnings into understanding and then action. To manage your time effectively you’ll need to figure out how deep is too deep, and what the right zoom level is, and this will take practice!
So while your raw execution skills in the codebase might be rusting as a Manager, your general ability to scatter-gather across different concerns and different domains - especially ones you’re a beginner in - at different zoom levels then synthesize new perspectives for yourself and others a becomes a key tool to your effectiveness.
Unsurprisingly, this is also an effective skill to master as an Engineer grows out of Senior and into Staff and Principal levels of Engineering Organisations.
Conclusion
If you’re a Senior Engineer, or indeed an Engineer at any level - spend some time in Management. Enough time that it gets hard and you get to fail big, feel some pain, recover and learn. At the very worst you’ll come back to Engineering a better Engineer with a deep understanding of how to scale yourself through people, how to take on bigger and harder projects and a new found ability to gain perspective by going broad and deep at different zoom levels across many different disciplines and concerns. At the very best, you’ll develop a love for a different, potentially deeply satisfying way of building new things at a new level of scale.
Why not take your next swing at Management with Intercom in Dublin?
This blog post borrows heavily from ideas shared by Charity Majors, Will Larson and Paul Graham. You should check out their blogs.