How to build a tech team, three by three!

In the 20 years that I’ve been lucky enough to be leading teams in the technology space, I’ve had numerous opportunities to try different methods of building and maintaining them. Not all of them have been successful, in fact it’s fair to say that I’ve ‘pivoted’ my approach on more than a few occasions and in the future, I’m sure I’ll do it again. What follows is a distillation of what I’ve learn’t about motivating a modern tech delivery team.
Environment
Over the years I’ve watched as companies have moved away from the enclosed spaces of old to modern open plan layouts, this has it’s good and bad points, but I try to keep the following in mind.

1. Maintain proximity
Flexible working is something that I firmly believe we should all embrace and certainly promote, however in programming, nothing beats having coders near each other on a day to day basis. Pair programming and just being able to turn around and get assistance from a colleague is vital to high performing teams. Preferably I would have coders sitting back to back, so that they can just pivot around for ad-hoc discussion and sharing.
2. Temperature and Sound
It goes without saying that programming requires intense concentration so distractions like poorly controlled office temperature and high levels of background noise can really impact focus and should be minimised as much as possible. Ideally I’d have teams in their own rooms for really concentrated bursts (this might be full time or temporary in nature).
3. Equipment
Always ensure they have the right tools for the job, even if this means buying kit that may at first seem overly expensive. It pays in the long run and is a real motivator for team members to know that you are willing to invest in the equipment they use.
Leadership Style
A very personal one here: I’ve changed a great deal in the years I’ve been a manager and a leader. In essence I’d boil my approach these days into three expectations that I have for myself and those that work for me.

1. Communication
In pretty much every thing I’ve read, heard about or been taught, communication is always the primary subject and for good reason, without constant focus and attention to how we communicate, relationships will wither and die. I try to make sure that I allow plenty of time in any given day for both formal communication (follow up summaries of meetings) and importantly informal communication ( quick chat with a colleague about their weekend before a meeting, instead of checking my phone).
2. Collaboration
Coding is often perceived as a solitary occupation, performed by geeks focused on a screen, headphones clamped firmly to their heads. Although there are certainly times when this is the case, for the the majority of time, good code comes out of the discussions and collaborations with other colleagues both in the immediate team and the wider department. Learning to get past our own egos to share ideas and show our work to others is one of the key skills of a good software engineer and a good leader.
3. Accountability
Much is made of how effective it is these days to have autonomous teams that jointly define how they are going to work together to achieve a desired outcome. In my experience this is indeed the most effective approach to motivating individuals and achieving high performance. However, if individuals are not willing to really be accountable for their own actions within the team, then this quickly falls apart. It is key that each member understands their role and signs up at a personal level.
Delivery approach
As a manager/leader, a key expectation will always be for me to facilitate the delivery of a particular project to time, quality and cost. Obviously this needs to translate directly to the teams that fall in my particular area. In days gone by, the expected approach might have been to drive the most ‘time on task’ I could get from those I directed but, as many have found, this really isn’t the way to get the most out of teams or individuals so my approach these days is very different.

1. Work/Life balance
A slightly over used term perhaps but critically important to getting the best of everyone. Some years back I learnt that if I stopped watching the clock on those that worked for me, they generally settled into a natural rhythm that suited them and actually still got the job done. They were happier, more motivated and much more likely to go the extra mile if occasionally needed. Modern families where both parents work really benefit from a flexible approach to when and how work is done and now I wouldn’t work any other way.
2. Project task alignment
It’s certainly the case that building software is a complicated/detailed business and there are many moving parts and factors to think about. When dividing up projects it can be tempting to split everything into the smallest component so that it can be distributed to any resource at any point. However, I’ve found that this approach can be incredibly demotivating to engineers that love to see their work released into the wild. Far better to focus individuals on working through the components that make up a fully fledged piece of functionality than only working on a small bit of it before moving to something else.
3. Autonomous teams
Twenty years ago, we used to build software the way we build bridges or buildings and the same project methodology was used to tightly control the allocation of resources and materials in what was known as the ‘Waterfall’ approach to project delivery. Then some very bright engineers invented a more modern approach: broadly this was known as ‘Agile’ and what followed were various approaches to implementing a more flexible delivery methodology, largely based around iterative methods. In both cases, there was a fairly prescriptive approach of carefully laid out rules and regulations to be followed by managers in order to implement the project. In more recent years, we have started to realise that although the ‘Agile ‘ approach is better suited to software delivery, it is also far better that the team itself, agrees the exact implementation and flavour to suit what they are being asked to build and the make up of the team. I’ve witnessed first hand that this is by far and away the most motivational approach and indeed the most performing teams I’ve known have been organised this way.
These are obviously my own thoughts and in no way represent the views of the company I work for now or those in my past, but I continue to learn. Great to hear your thoughts/comments on the subject.

