Am I technically Dangerous?
The average career path of a technical person while varied for everyone, of course, can more than likely be summed up by the following;
Be perceived good at current role-> Be offered a perceived more advanced role -> Be perceived good at current role… etc
Now while that is far too general for many in the trials and tribulations of modern-day companies, that is generally how I have seen progression happen in the gigs I have had and also from my own personal experience of progression.
So when I have the opportunity to coach someone on how they can reach a perceived advanced role within a technical team I always come back to the same underlying strategy; be technically dangerous.
A career progression path for a software developer could be like this;
Graduate/Junior Software Developer > Software Developer Software Developer > Senior Software Developer Technical Team Lead (Tech) or Team Lead (Humans) Engineering Manager The word ‘progression’ assumes that the above path is moving in a forward direction most of the time. That is not always the case. What isn’t well known to most is that the jump from individual contributor to a manager is in many ways of the job a step backwards.
Which means the one thing that you were perceived to be good at, the code, begins to take a slight backseat as you need to learn about all these messy human things that now take up your day.
Want to learn React? Then this appraisal might not get done?
That pull request needs someone to check it? If you don’t get this offer out you might lose the candidate?
Azure Functions look cool? They do, but you need to budget Q4 estimates with your capacity plan to make sure you deliver on time?
So at this point, if you are doing your job right, you’ve delegated those things to folks better suited and it’s their actual job to do. You’ve made sure that the team is getting what they need from you, which is more than likely a lot more important than shipping code right?
Well, yes… but how do you stay relevant to be able to help your team since you are still an assumed technical lead?
You are a Senior Android developer who has just received a promotion to Team Lead which consists of 9 reports. As you report to the Engineering Manager you path looks pretty clear, but you want to sit as a Team Lead for some time to soak up what it’s like.
Tech stack is what you know and are perceived good at (Java, APIs and some SQL) Number of reports is manageable for regular 1–1s and general harmony of the group You can still dabble and commit code on a regular basis If you have a problem, you can pull in your Engineering Manager In this situation go deep.
It’s your stack… learn as much as you can, set you up for greater success in the future. Your team will appreciate your additional duties as a manager but will also know that you can still cut code just as good as they can.
It’s around this point you learn what bits of being a manager you like and dislike. Being involved in capacity planning, strategy meetings, large architecture decisions and coaching junior members of the team mean the rewards are great while you keep your technical chops with you.
You’re going to need those chops because…
You’re perceived to be a more than capable Team Lead (well done you), so how about the Engineering Manager role? You report straight to the CTO and you know have 6 reports. Awesome right? Sure… but each of those 6 has around 6–15 folk underneath them. Did I mention each individual is a Team Lead of a different stack or discipline?
One of the tech stacks is your deep one (Android), but now you have Web (React, C#, .NET, EF), BI (Tableu and PowerBI), Automated Testing, iOS (Swift) and Architecture to deal with Your 6 folk want to talk about their folk as well as themselves; that’s a lot of folk You want to commit code? Erm… don’t think you will have the time for that. Sure you can ask your boss for help, but at this level you’re expected to know what you’re doing In this situation go wide.
Going wide on these new technologies means that you are unlikely to be able to go deep on them. It means that you need to model yourself as a T-Shaped Person.
Valve Employee Handbook As a T-Shaped Person, you collect information about all of these technologies so that when something doesn’t smell right, you can act. When someone brings a proposal to your desk, you can ask just enough qualifying questions to know whether it’s a good one or a bad one. You still have that one deep area of expertise but as days go by you add more strings to your bow.
You know that at any given moment have to be technically dangerous in any given stack because you are going to be asked topics and it’s up to you, the Engineering Manager, to set the overall direction of the team.
You are the North Star.
In a world where technology is moving so fast, being a T-Shaped-Technically-Dangerous human is not the easiest career choice in the current market.
However, if you hire a team which is smart, empathetic, hardworking and enthusiastic about your cause then maybe one Thursday evening you can fix that production SQL issue with your new found wide technical knowledge… or maybe that’s just dangerous?