I recently gave a talk at Staff Plus in New York on "Unbecoming the Bottleneck: Growing Others as an IC". Afterwards, someone wrote to me with the following question, and I've written up a response as a blog post:
Question: I’ve been stuck at senior for several years. With several other seniors on the team and a relatively new tech lead hired into the team, it’s hard to get visibility, especially when many rooms are gated by title.
Here are few thoughts!
Technical mastery is crucial, but only part of the equation. And yet, you still want to become the person that people come to with thorny technical questions, or the person of last resort during a tricky incident. Ideally, you are coming up with approaches to ship features or improve your systems that others haven’t thought of, and are appreciably better on some metric (like time to implement, cloud cost, query latency, etc). If there is another person or two on the team occupying that role, you may need to counter position yourself by staking out expertise on something that’s not important yet, but may be in the future (perhaps a new homegrown tool that your organization is rolling out, or how to integrate well with some wider company initiative). You want to be shipping high-quality, high impact work with relatively few surprises in production. If there is a long tenured trusted engineer on the team, you might go to them and ask “What’s something that’s been bugging you but you haven’t gotten around to dealing with? Can I help?”.
Early in my time at Spotify, for instance, I spent a month or so optimizing a bunch of SQL queries in services that had been paging us because of increased latency. Sometimes this was as simple as adding the right index, but occasionally I had to rewrite a query so that it would actually hit an index. But in each case, I made sure to document the improvement and share it with the team. This was a relatively small accomplishment in the grand scheme of my tenure, but it established me early as someone who could make order-of-magnitude improvements on small pieces of the system. Other engineers were happy to not be getting paged as much, and our leadership felt less existential angst that certain core services were just going to fall over under increased load.
Assuming you've gained a reputation for technical mastery (which to be clear is a hard thing to do!), you also need to excel in the "soft skills" of communication, project management, and relationship building. The most important relationships are probably with your leadership chain. Ethan Evans’ magic loop is a great formula here. Basically, you’re trying to address or help address whatever top-line worries your leadership has. Is there a project going off the rails? Maybe you can step in to provide some guidance to get it back on track. Is there a nagging production issue that another org has escalated? Maybe you can quickly get to the bottom of the issue. You'll want to look for opportunities to write RFCs or other technical design docs, work on projects where you're leading a key piece of the work (ideally directing the implementation work of others too). You'll also want to be building good relationships with other teammates and engineers from other teams.
But let's finally address the environment. All of this is much easier when you're in a setting where there's plenty of high-impact work to go around. Ideally you want to be in a situation where there's an abundance of high-impact work, but a shortage of people skilled enough to lead key streams of work. If you're not in that kind of environment, you'll realistically have to either out perform others to get access to key projects, or wait until those "above you" make space (either by leaving or getting promoted). Sometimes you may need to leave the team or the company, but I'd generally recommend resisting that impulse at first, so long as you're still learning at a decent rate and have a decent work environment. If you're choosing a new team, looking for a team with a lot of high-impact, difficult technical work is a key thing to look for. In the short-term, an absence of strong technical leadership on a team could make it appealing (a great chance for you to demonstrate leadership!), but in the long-run you'll want to put yourself in frequent situations where you're not the most tenured or experienced person in the room. Ultimately you'll learn the most if you're around other engineers who are better than you, so soak up those opportunities when granted. In the long-run, it's probably better, even if in the short-run it does make advancement trickier.
And one last word on "rooms gated by title." It's enormously frustrating to be gated from a room because you don't have the title. Sometimes this does inhibit impact. But what I've discovered since gaining the title is that though the title does confer access to more rooms, many of these rooms are not places where high-impact work happens. And if you're doing high-impact work relevant to one of those rooms, you'll often find yourself invited as a guest. I guess the key takeaway is that in general, "access to the right room" is probably not the key blocker on your growth, as exasperating as the exclusion feels.
Top comments (0)