How to Engage with your team (be a Well Rounded Technical Lead, part 1)

If I were to rank the four quadrants of the Well Rounded Technical Lead, this is the one that would come out top. There is little more important in the role than guiding the delivery team.

As a developer, your job was to get stuff done. However, when taking on leading a team, there is an inbuilt assumption that you can't and shouldn't do everything on your own. You are working with a team to scale up what you do, leveraging your skills and experience, to help do what you can't do alone. You'll need to think strategically, set direction, share, and help the group become or stay a team.

The upsides of working with a team are hopefully obvious: a group of skilled people that can quickly deliver software into production, build a fit-for-purpose codebase and a rich enough architecture. Delivery of working code should be fast and a group of people collaborating can offer a mix of perspectives and skills to get things done well.

The downfalls of having a team are a little more subtile. Though hugely rewarding, there's little glory, as its your job to adjust to what the team needs to get the job done, as well as challenge them to be great. You'll need to start to give away some of the most important jobs and share out the challenges, whilst still ensuring that they get solved. You get the sometimes dirty job of setting the bar, so people share in the ownership and aren't sloppy or slipshod.

Your aims as a team lead

As the lead of a team your aims are to ensure that the team are working effectively as a group, and that they use the resources at their disposal and the skills of the team so that they can keep delivering high quality working software. To do this you'll need to ensure that you and they are communicating what's important, the group is learning and experiencing the reality of the system you are building.

You'll be looking to balance sharing your experience and letting people find out for themselves. You may be helping them step up to new challenges and recognising what the group and individuals need to do well and grow, and when they are tired and need a break. Sometimes its enough to point them in the right direction and get out of their way, freeing you up to code a little.

Walking around the practices

Ensuring safety / Safety, First

There is massive value in placing your people in a space where they can learn to excel. I look to create an environment that gives people room to take managed risks, as well as encouraging progression and learning.

Generally speaking, people want to have adventures, but not be fearful. When someone feels safe enough, they stretch and look to take measured risks. They question and learn; share and trust. When they feel too much pressure, fear or exhaustion they shut down - regressing to more basic skills, refusing ownership and becoming limited in communication.

Developer sandboxes, tests, automation, monitoring , continuous integration and delivery are tools and practises that allow the team to own the risk management at the code level. At the human level you may need to set the scene and help the team to work at the right level of safety for them. A big slice of that loops back to sharing, empathy, clear communication and trust. Building that can take time, but it's one of the most powerful things you can do.

Facilitating technical discussion

With safety in place, people are more able to collaborate and learn. You should ensure your team is communicating about what's important. Practices, architecture, design, problems, better solutions, new ways of working. Not just talking, but listening and collaborating.

These days 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. There are likely to be silos and misunderstandings that will act as future roadblocks to progress. It's not that teams need to be talking all the time, but they need to clearly communicating enough to get a great job done. I'll come back to what they could be talking about in the section on architecture.

Leading and building people

It's your job to set the direction for the team; and to then ask them what they need to do it well. Teams often need a clear goal and direction to allow them to move together and solve problems as a group. Depending on the maturity of the team, they can benefit from some structure and an initial approach to allow them to make a start in solving the problems. I've found that leading and facilitating focused group discussions can go a long way in contributing to this goal.

Don't be a lone wolf — rather than working in a vacuum, you need to keep listen to your team and respond to them. A team should be able to communicate what is needed, giving you the feedback to tune your approach. Part of being a leader is sometimes accepting the message how it comes. That feedback can require a thick skin, and effort to hear what is being said, but the value of understanding your people is worth it.

The conversation works both ways — you should be discovering what each wants to do and be good at. Finding alignment between the group's and the individual's goals is a sweet spot that can really energise a team.

from: http://thingsweforget.blogspot.co.uk/2012/09/932-boos-vs-leader.html

Delegation and chorus

A key skill of a great team lead is to be delegating the right level of challenge to each member of the team. This isn't just about coding, it can cover many of the aspects of the jobs the team needs to get done. You really don't want to be in charge of everything for both your and the team's sanity.

Luckily common traits of software developers are that they want influence on what they are building and they want to be challenged, which makes it easier to delegate work. Stay involved though — you shouldn't be just handing over problems to people. You should be discussing and sharing the initial approach as well as circling around, helping to steer and to guide the managing of the risks involved.

The other side of the coin is managing knowledge and essential skills - avoiding siloing and ensuring that the team doesn't generate its own bottlenecks or disfunction An atmosphere of sharing and collaboration can help here, where the team has opportunities to talk through learning and choices, as well promiscuous collaboration and rotation of people around the jobs.

Define and demonstrate good

You can't keep an eye on everything, yet you are responsible for what is produced by the team. Putting it another way: You need to set the standard so that high quality code is produced when you aren't writing it. The team will treat your behaviour as a guide. As humans, our most core learnings come from watching and repeating others actions. Sometimes the best way to get someone to do something is to do it first.

One of the best coaches I know teaches people by clearly performing what he wishes to be learnt. He has great skill in demonstrating something that is accurate, but simple enough to be duplicated. Demonstrating by doing sets the bar for team behaviour, discipline and quality. Without loosing integrity, I like to clearly act out the behaviours I wish to see.

With experienced teams I like to get the team to share the quality levels they set themselves, and sometimes treat them as a contract we can keep ourselves to. This also encourages the team to be articulate about what we do, and to call out what's not working, and better ways to do things. Its another way of delegating without loosing touch, and keeps me from being a bossy boots.

On boarding

Churn happens on any team, if the project runs for long enough. When people join your team, its important they can get up to speed and start adding value as soon as is reasonable. Though you may not be doing this directly, you'll need to be ensuring that on boarding happens well. Shadowing, pairing can be great ways to exchange knowledge, certainly you'll want an experienced team member sitting close by to help with gotchas and questions.

The amount of on boarding needed can be in indicator of the complexity of the project and the delivery processes surrounding it. As well as improving the introductory materials a new team member can highlight Groupthink and accepted complexity.

Further Reading

How scaling up a team effects delivery is of critical importance. If you haven't yet, its well worth reading Fred Brooks' essay The Mythical Man Month which clearly lays out the effect of adding additional people to software projects, or pick up his book that covers that and other essays.

Growing teams towards stronger and further delegation is an important skill, but one too big to cover here. 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, its written from long experience in delivering software and working with teams. Managing Humans is 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 Pocket Book an interesting insight into the world of useful group meetings

Summary

The essential thing to remember that you are not the team's boss, you are their leader, guiding them towards the goal of useful, suitable software, and that's where we go next, looking at the activities to produce the well crafted code and architecture you need.