We like patterns. Patterns are cool. Patterns apply to people, and groups, and organizations, and…everything, actually. (L: I could talk about patterns for hours, but I won’t. You’re welcome.)
As we’ve each mentored people into technical leadership and tried to understand how people grow as their leadership role and ability grows, we noticed a pattern with several distinct steps. Because patterns are cool, and because we learn by writing and talking, we put words to the pattern we were seeing.
Before we get too far in, let’s define technical leadership:
Technical leadership is providing knowledge, guidance, support, and strategy to developers, systems, and especially the intersection of the two.
To be clear, it is not project management (although sometimes that’s included) or people/HR management (although sometimes those roles are combined too).
We’re going to break down what we’ve seen with some diagrams and then some explanation of what each stage looks like. We’ll split the explanation into two posts, because there’s a lot to talk about. This was the reasonable-length version, we promise.
The Progression – the Diagrams
As people gain knowledge in Technical Things, that knowledge tends to reflect these levels – self (as in, “my tasks”), single team and system, multi-team/multi-system, and finally, the enterprise/company as a whole.
People also tend to move from awareness of something – for instance, awareness that their team could use their help on something outside of their usual duties – to ownership of it – like, deciding in their soul places to help their team be awesome.
However, fun fact, the basic pattern we noticed was that people move across these at the same time. So really, it looks a little bit like this, assuming they start at the bottom and hop up the levels as they go:
People move from self-awareness to self-ownership, and then they become aware of their team. Eventually they move toward accepting ownership of their team, etc (don’t worry, we’re going to explain these in detail!). However, this diagram is super complicated, so…
TADA! As people progress through technical leadership, they do…well, this. ☝ Self-awareness to enterprise ownership.
The Progression – the Stages
Self -> Awareness
Ever worked with a baby programmer, or remember when you were a baby programmer? Someone brand new, out of school, who hasn’t quite figured out how to like… understand things and also talk to people? Or, cooperate on a professional team? Yeah. Mastering the basics is vital to all that comes after it. Also to adulting well, which is another skill baby programmers usually need to learn.
Self -> Ownership
The true first step to being a technical leader is to build a reputation for being reliable in the eyes of your team – and that means executing your development tasks well. A wise person once told Josh, “be good where you are.” Get things done on time, ask amazing questions, and learn to love and understand the system you’re wrangling.
If there’s success here, more challenging and complicated work will be offered. Also, interesting to note, most technical leaders never get entirely away from this step or the next. Solid technical skill (and troubleshooting, spoiler alert) always help a technical leader.
Single Team & System -> Awareness
This stage starts at troubleshooter – building a track record for solving tricky problems. This means taking on more frustrating and painful tasks than you strictly have to, and getting good at different kinds of problems.
Basically, this is getting really good at understanding the neuroses of a system, learning how to debug and fix it efficiently and effectively. It also requires a massive dose of stubbornly not quitting.
The better someone is at troubleshooting, the more likely that they’ll become the Help, I am Stuck and You Know Stuff person – dedicating resources to helping other people. This shift means all kinds of patience – with technology, and with people. A lot of great technical people draw the line here, mostly because…well, they don’t enjoy people very much. That’s fine, people are a lot of work.
This step is where people typically stop doing as much of their own implementation – and that can be really frustrating for people who go into IT to write code. Instead of finding joy in implementation, though, they learn to find joy in other people’s successes. Again, a lot of people draw the line here because they love implementing technical solutions, so please stop talking to them and let them code stuff.
Next up…
In part 2, we’ll talk about growing into taking ownership of the team’s success, and move on to awareness and ownership of multiple teams.