The Well-Rounded Technical Lead (A Model for Technical Leadership)

"One does not 'manage' people.  The task is to lead people.  And the goal is to make productive the specific strengths and knowledge of each individual."
Peter Drucker

Technical Lead butterfly diagram

The job of a Technical Lead is a broad one. What she does varies from team to team, project to project. I built this model to guide myself. It's found further use in mentoring, personal development and training. Here I talk through the role at high level. 

What I mean by 'Technical Lead'

A Technical Lead takes responsibility for the technical delivery of a project. She's not alone though. Her job is to share the responsibility with a group of practitioners. The team's job is likely to be solving a business problem through technologies and building software. The lead may guide, lead or facilitate the direction for the group; sharing the responsibility and ownership out, in balance with the group's needs and capabilities. It's still in a 'doing' role - remaining great at being able to get stuff done and helping others do the same.

Being an ace technician is not enough, the needs of most teams are wider that that.  Depending on the situation and ability of the team the lead may be removing impediments, mentoring or coaching.  She's likely to be coding, though not as much as she'd like to be – often it’s not her main job any more.  What she will be doing, is helping the team explore the solution though code, design, metaphor and automation.

There will be an need for working beyond the team - sharing equal responsibility for the wider goals of the project with her peers.  In this new situation there's often a need to explore less developed skills and to grow in directions previously not stretched as a developer.

"Funny, I don't call them that."

Some people talk about Technical Team Leaders, others Lead Programmers and I see these as similar or the same role, I'm okay if you call them something different, if you'll forgive me for my naming in return.  In the mix are sometimes Technical Architects and Iteration / Delivery Managers.  I see these roles as separate to that of a Technical Lead though sometimes the Lead and their team do play some or all of these roles. Often the roles become more separate in larger organisations and groups, with the need for increased co-ordination.

I don’t use the word manage or manager much, with some reason: Peter Drucker has written a lot about Knowledge Workers, which really resonates with me and what I see in technical teams. He makes the point that the people we find in software delivery teams – knowledge workers – aren’t looking to be managed or to be governed by process, they are looking to keep on learning and progressing.

Having a definition can be important

I wrote in my post about Growth and Feedback: ‘Its valuable to know what good looks like if you want to be good.’ I think that having a rich definition is valuable to progression and learning; to use to challenge, direct and measure yourself against.

Experiences are far more valuable than introspection so a model is a check and balance to your own experiences. But whilst you are on your way, or if you've hit a blocker, some structure and other people's experiences can help build new directions to go.

A caveat: It doesn't have to be mine

This is just a model - a slice through the continuum that is leadership. Don’t stress if it doesn’t match yours – that’s where it starts to get interesting and where some of the best conversations start. Every leader comes from different roots and has a different focus and style.

A caveat: You don't have to do it all at once

This is an ideal and aspirational model - not every role is going to require all these skills and insights, and not every person needs all these skills right now: it would depend on the people, and to job to be done. It's likely as their role progresses that they probably should be working in each of the quadrants.

A brief walk around the Model

My model has four ‘wings’ which talk to the following:

• Engaging with Business: Looking outwards from the team and talking with the wider business - your peers as well as the people who sell and support the product.

• Engaging with the team: focusing inwards towards the team - building and nurturing them as well as ensuring they are focused on the task at hand. You're a role model now.

• Architecture and Infrastructure: Working with your team, building something good enough; focusing on the technical dimensions.

• Delivery and risk: Working to manage the technical risks and debt, and helping build a delivery plan.

These areas are deliberately broad, it should be easy to look into each area and specify some of the current and future expectations. I do have some suggestions of what activities might in each quadrant - I'll be working though more details of each in the coming weeks. To start with I want to highlight four activities, that sit across the quadrants, that highlight the value of being well-rounded.

The value of being well-rounded

Diagram showing the strength in working across the quadrants

Many people focus on one or two of the quadrants, developing skill and strength in them. But to grow fully into the role, I feel you need to look wider. In the diagram, I've indicated the invaluable jobs you can do well when you work across the quadrants.

• To set the technical vision you should engage with both the wider business functions around you, as well as with your team. You will need to help the team understand the needs of the business as well as let let the business know how you can help.

• Architectural Forces are the expectations and limits on your system. What it should and shouldn't do as a whole, and as it grows. These drive the design and the coding that you do, as well as tests you put around the system. Working with the team to define the Architectural Forces allows the whole team to grow the codebase and create valid shared metaphors.
  The team should own the design, but its your experience and feel that will guide it. Your experience will help the team focus on the Cross Functional Requirements (CFRs) at the right time

• As a Technical Lead you are likely to be responsible for the technical parts of the delivery - managing the compromises and risks as they appear and as you learn more. You are often best situated to make the calls on manoeuvring through the choices and risks. Assuring the delivery is a bridge between the choices you've made in the emerging design of the system and the needs for the delivery - what you choose to do when and managing what has not been done.

• Finally, based on the risks and information you have, you are ideally placed to challenge the solution with the Stakeholders or Product Owner on what the solution to their problem looks like, what can and can't be done and how risky it might be, not only at the start, but as the project continues and you learn more about the right choices. This feeds back into what you make a priority to build and find out.

Growing your focus: How I've used the model

If you are looking to grow your Tech Lead skills, take a look at the model, and what you do. If you can see some gap, that are useful to you and your business  pick whats most important right now and look to see if you can grow to meet those needs.

In the next blog post in the series I’ve gathered some perspectives about how to develop your well-roundedness, in becoming a great Technical Lead.

How to be well rounded

I've detailed the practices that I've found valuable, and what's at the heart of a Well Rounded Technical Lead