Category: Leadership

Tech Lead Delegation – Baby Steps into Leadership

Tech Lead Delegation – Baby Steps into Leadership

One of the first steps a technical leader takes is taking over as a team lead. In IT, this is often called a Dev Lead, Tech Lead, or Architect, depending on a company’s teams and title structure, or it can be more understood than titled.

This type of technical leader might not have direct reports, but accepting ownership of the team’s technical success is leadership, and it’s one of the first big responsibility changes and perspective shifts in the process of becoming a technical leader.

Technical leadership means taking on ownership of a team’s technical success.

In the two-part series Technical Leadership Progression, we defined “technical leadership” differently – if you’ve read that one, here we’re using it to mean specifically the Single Team Ownership phase.

Read More Read More

Awesome Permission

Awesome Permission

One of the things we’ve noticed while mentoring is that some people suddenly take off like a rocket – they accept responsibility for more than they previously took on, and then they seek out more. They also handle this increase in responsibility very well, and they impress people who previously were at best neutral – along with people who were previously disappointed.

We’ve seen it happen, and we’ve been trying to figure out how to describe what the pieces are, because if a cool thing happens, you should explain how to reproduce it.

So, we began to think of it in terms of the process, the ingredients, and the result.

If a cool thing happens, you should try to figure out how to reproduce it.

Read More Read More

Technical Leadership Progression, part 2

Technical Leadership Progression, part 2

In Technical Leadership, part 1,  we talked about how someone grows into a technical leader aware of their team. In this post, we’ll continue on to describing a Tech Lead who takes ownership of their teams’ success, and then moves into the higher levels.

Read More Read More

Technical Leadership Progression, part 1

Technical Leadership Progression, part 1

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 alertalways 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.