The Modern Leader
As you transition from IC to management, your shift focuses from projects to people - I’m sure you’ve heard this at least 20 times from me alone. In some organizations you’ll keep coding to some degree, but many are much more focused on you managing your team vs. writing code against pre-planned deliverables. (I haven’t written a line of production code since I joined Spot AI over a year ago, but I have enough on my plate to take my time up to where I really shouldn’t be spending my time coding.)
If you spend any time on Twitter or even LinkedIn for that matter in the developer ecosystem, there are constantly conversations around new technologies, cool things people are building, or the casual argument about why Tailwind needs to disappear forever. (Before anyone comes after me, this is not my opinion!) If you’ve been managing folks for a while, it can feel like you’re watching these conversations happen from the sidelines. You’re spending more time focused on making sure your team is producing quality work, so you’re likely less focused on making sure you’re keeping up with the latest technologies. The longer you’re at least one level removed from the side, the slower your technical growth becomes – this is expected.
This means you have a new muscle you need to build: leveraging your team’s technical capabilities, combined with your increased business context, to product your team’s best work.
Your job as a manager is not to have all the answers; it’s to help guide your team to the best answer by leveraging your business context and their technical know-how.
As you spend more time in management, you must get comfortable with no longer knowing everything (though it’s highly debatable if you knew everything to begin with, sorry to break this news to you in a 5 minute email). Be okay with asking clarifying questions. They’re not dumb questions! You need the context to make better decisions, and you wouldn’t want your boss or peers making a decision when they don’t have the full context. Keep asking questions until you understand.
I’ve been so far removed from the technical implementation at this stage that while my technical knowledge can carry me through complex conversations, at the end of the day my engineers are much better suited to discussing our options than I am. It’s my job to make sure they’re thinking broadly enough and considering other options as well as the long-term impact of their work, which means I need to ask many clarifying questions to understand the impact from a technical capacity if it’s not my area of expertise.
If this scares you, that’s fine. It’s a mindset shift. But if you find yourself missing being in the code and having time to dig into new technologies, there’s nothing keeping you in management forever. In fact, a lot of people have asked me if it’s okay to go from management back to being an individual contributor, and the answer is a resounding yes. I highly recommend this article from Charity Majors where she discusses the engineer/manager pendulum and why it’s so beneficial. You’re in good company, I promise!