“He who travels alone travels fastest, but in the company of friends you go further.”

Breyten Breytenbach

If I were to rank the four quadrants of the Well-Rounded Technical Lead, this would come out top. There is little more important than building and fuelling a team.

As an engineer, your job is to get stuff done. But leading a team: you can’t, and shouldn’t, do everything on your own. You are working with people to scale up the best of what you do. To leverage your skills and experience, to do what you can’t do alone. You’ll need to think strategically, set direction, share, and help the group become and stay a team.

The upsides of working with a team are hopefully obvious. A group with wide ranging skills and mixed perspectives, collaborating to solve problems and deliver valuable software quicker than one individual; building a fit-for-purpose codebase and a rich enough architecture along the way.

Downsides are more subtle. Though hugely rewarding, there can be little glory in running a team. It’s your job to adjust to what the team needs. You’ll need to give away some of the most important and interesting jobs, whilst still ensuring that they get solved. You get the dirty job of setting the bar, filling the gaps, and allowing the team to share in the ownership without being sloppy.

Your aims as a Tech Lead

Your aim is to build a team that works effectively together. Help them to use the resources at their disposal and their collective skills to solve problems, delivering valuable software.

Teams aren’t magic, they’re craft; and graft. You’ll need to be balancing sharing your experience and letting people find out for themselves. Be the safety net and let them step into new challenges. Know where your folks are at: and if they are at risk of rust-out or burn-out. If you are lucky sometimes you can point them in the right direction, and get out of their way.

Ensure your team has good focus and key information that will enable good choices. Are they communicating what’s important, and are learning from the reality of the system you are building?

Walking around my key practices

Safety, first

Psychological Safety is the most important thing you can do. There is massive value in placing your people in a space where they can accelerate their growth. If you do nothing else on this list, ensure that your team works in an environment that is safe to fail, and safe to not-know.

People like to have adventures, but not be fearful. When someone feels safe enough, they stretch and take measured risks. They question and learn; share and trust. Building trust leads to a resilient team that can deal with complexity and setbacks.

When individuals feel too much pressure, fear or exhaustion, they shut down. Often regressing to more basic skills, refusing ownership and becoming limited in communication. Look for these patterns and catch them early. Find out what’s not working and make changes. 

Create an environment that gives people room to take managed risks. Encourage questioning, discovery and learning without judgement. Lead by example: show them it’s ok to fail and not know by working in the open and being open to be fallible. Give them confidence: demonstrate clearly that you are part of the safety net that allows them to fail.

Safety is not just about how the team interacts and supports each other. There is much you can do as an engineer to build better safety to experiment. Ensure you have good tools and practices that provide your team with space to experiment with lower risk. Developer sandboxes, test automation, monitoring, CI/CD are tools and practices that allow the team to own the risk management at the code level.

Go together

Software development is a social activity. If a team isn’t communicating well, then it’s likely that what they are building isn’t shared or clear. It will generate silos and misunderstandings that will act as future roadblocks to progress. 

Every team needs direction. It’s important that a team has a shared mission that they undertake together. It energises and brings focus. Removing individual silos allows the team’s strengths to be combined and focused on removing the biggest obstacles.

Your job is to ensure that any conflicting priorities are resolved and there is a clear goal ahead. Help the team gain clarity on direction and how they will get there. Help them plan, learn and adjust. Depending on the team, you might provide a plan and structure, or a framework to help them solve it themselves.

Once settled, you need to ensure that the team has what it needs to reach that goal. You can do this by asking but it’s likely you will learn far more by being in the work. You will have distractions and other commitments, but make a key commitment to go with the team too.

Facilitate collaboration

A good way to create team ownership is through sharing the creation process. Ensure that important team decisions are made in environments where everyone gets to be heard. Facilitate creative sessions to find decisions that move the team forward together.

Don’t always be the centre. Bring facilitation tools and help them find the right collaboration points. Demonstrate the ability to discuss and listen when solving the hardest challenges, then step back and let the team run with it, providing support and feedback if needed. 

Strong collaboration is more than meetings, workshops and whiteboard conversations. Keep watch on what happens day to day, are folks hitting blockers or are running on a problem for a long while? Demonstrate what you want to see by bringing the team into your space when you hit a blocker.

Grow your people

You cannot do everything that needs doing. Not even the important stuff. Good news: 99% of engineers are in the job to learn, grow and progress, they will thrive when they do.

Although you are in the position of Tech Lead so that you can scale what you do, it’s not a one-sided deal. You are there to help your team grow and meet the challenges presented to them. Know your people and what they want. Align and connect the work to their goals. Watch them fly.

How can you do this? Put simply: Know what makes your folks tick; find the right size challenge and ask them to own it; then be the Safety net. We shouldn’t be just handing over problems to people. We need to provide them with support, and catch a mistake before it becomes a problem

“Delegation” and “Skills Development” are skills to be honed –  super valuable, but hard work. You want to avoid creating overload, failure or burnout. It’s well worth gaining a good understanding of the basics of these key skills. Look for folk in your org that can help you or take a look at the further reading below.

Set good standards

Quality is important. Poor choices and sloppy code can come back to bite in many a way. As a Tech Lead you can be expected to be responsible for the quality of what the team produces. Without controlling what others do, how can we do that?

Some teams set their own great standards. Other teams need guiding towards the good enough. How can you find out? Get into the code, make some changes, explore. Get your team talking about the quality level they should set themselves (and why). This also encourages the team to be articulate about what we do, to call out what’s not working, and find better ways to do things. 

Sometimes standards slip, that’s ok. Again, when it happens, start the conversation to discover why and what needs to change. Do we need automation, adjustments, new agreements?

There’s also a standard to be set in how we interact and work with each other. It’s important that any leader is aware our choices of behaviour can affect and influence others. If you are respected and do a good job, folk will copy what you do. Reflect and ensure that you behave as you want others to. Be the good example that others need to see.

Simplify onboarding

Churn happens. People like a varied life. Let this be a positive. Identify and remove silos that would stop an engineer joining and working well on your codebases.

What can we do now to help the future engineers who join your team? Lower the learning friction, by making things clear, consistent and without surprise

1. Make your spaces welcoming and clear. Automate or sign-post the fiddly bits. 
2. Document key decisions taken (and why) and practise clear commits
3. Hold consistent repos and code (style, patterns, libraries, technologies)
4. Automate local machine set up 

It’s easy to put this off. Don’t. What simplifies someone joining your team also often enables the current team and lowers the demand to know and remember all the things.

Further reading

Growing teams towards stronger and further delegation is an important skill, but one too big to cover in a single blog post. Max Landsberg’s Skill Will Matrix from the Tao of Coaching provides a good starting model.

Peopleware is a classic book about putting people in the heart of the Software delivery process, it’s written from long experience in delivering software and working with teams. Managing Humans is a more recent book that covers the skills of leading technical people from a silicon valley perspective, and offers some great anecdotes and advice.

If you are interested in how group facilitation can help you guide a team I’ve found the Facilitator’s PocketBook an interesting insight into the world of useful collaborative  meetings