It’s no secret that building and empowering high-performing teams helps produce excellent results. It sounds simple enough, but how do you truly build this type of dream team? It all hinges on learning.
As software engineers our job revolves around rapidly absorbing and utilising new and unfamiliar technologies, libraries, frameworks, systems and codebases. Learning is the largest day-to-day time sink for engineers.
Learning takes time
This learning takes up many forms. Off the top of my head, here’s some common ways I learn every day in my job:
- programming languages and their features
- libraries and package ecosystems
- underlying technical concepts
- codebases – where everything lives and what it all does
- best practices – for technologies, libraries and codebases
- general engineering principles
- how to go about working on code to produce the desired results
- non-functional domain knowledge
It’s a lot.
Traditional learning and development approaches like conferences and courses can struggle to cover this kind of learning. In my experience they tend to be geared towards learning one large topic in depth, rather than many small topics quickly. While these are important for traditional learning and development activities, such as enhancing careers or expanding your knowledge, they aren’t aligned to the complex business of on-project and team-focused learning.
Software engineering can be (surprisingly) quick and easy when we know what we need to do AND exactly how to do it. But that’s where the challenge is – how do we truly optimise a team for this type of learning on the job?
It’s time to buddy up!
One fantastic method is paired programming. Now, some think that pairing/grouping up engineers is less efficient because fewer tickets can be completed simultaneously – for example in a 6 person team working in pairs, only 3 tickets get worked on at once. But pairing or grouping is hugely efficient for learning. Even though you’re doubling up team members, you’re halving the time spent collectively learning so there’s still huge value there.
Collaboratively working on day-to-day problems with others helps you learn multiple things at once. For example, if you’re pairing with another engineer – you’re learning about the language being used, the codebase they’re working on, how they go about engineering and implementing the feature. By working with others, we can understand the things we didn’t know we needed to learn!
By having engineers actively teaching one another and frequently repeating knowledge while linked together in context we maximise the retention of that information. This also invokes the protégé effect, which tells us the best way to learn (or cement your previous learning) about a topic is to teach it to others.
Paired programming has a long list of benefits to a team. It reduces problem solving time, catches more mistakes early, helps people build mentor/mentee relationships and generally stops us from all getting too lonely. I strongly recommend pairing, but I also strongly caution imposing it on an otherwise confident and happy team. Not all activities (i.e. those where the problem AND solution are well understood) require pairing and it can become draining if used constantly.
Modern software delivery is a team sport
Next up is building a resilient mesh of overlapping knowledge within a team. In this mesh there’s a shared “core” of knowledge that everyone in the team should know – this is normally for common bits that need to be used frequently.
T-shaped skills graphs describe something very similar, with the idea being that in a team of generalist engineers, there’s a shared core of basic knowledge that allows anyone to theoretically work on anything. It also protects the team from disasters, such as when a key team member holding a silo of knowledge leaves the company.
It’s important to realise that optimal for the individual is not always optimal for the team. Modern software delivery is fundamentally a team sport. As an individual member of the team, you need to check your ego at the door. Be prepared to support your colleagues by pairing or answering their questions over churning out your own workload.
Don’t forget culture
However, silos and knowledge specialisms naturally develop in a sufficiently complex project. Of course people grow more knowledgeable about specific technologies and areas of the codebase through interacting with them. In a knowledge mesh, it’d be inefficient (and impossible) to make sure everyone knows everything about everything. Instead, members of a high-performing team should get comfortable with the idea of asking “dumb” questions and interrupting team members with questions to unblock work.
Remember: there are no dumb questions. It’s much more efficient to ask a quick question even if it distracts someone for a few minutes than to remain blocked on your tasks while you go away and figure it out on your own! Crucial to this approach is having a strong team-culture and good psychological safety. After all, people can feel vulnerable when admitting they don’t know things.
In teams with weaker cultures or poor psychological safety, engineers may feel pressure to compare themselves against their peers and take on difficult tickets individually to validate their abilities. Knowledge silos also tend to appear, as team members don’t feel confident showing vulnerability by working in an area they’re less familiar with.
To prevent this, instead of evaluating team productivity as the sum total of contributions by individuals, we should evaluate it as the collective output of the entire team. By switching a team to use systems such as four key metrics, we can work to improve the output of our teams without worrying about unimportant details like how many tickets/features/story points each person completed.
We’re always learning
Learning is the major time sink for engineers delivering software. But by optimising our teams for learning we’re able to better support collaborative working and regular questions between team members – which is crucial to building high-performing teams.
As engineers, we’re always learning. If after reading this you have any feedback, further suggestions or just want something clarified – please get in touch!
If you’d like to read more about software engineering, subscribe to our Made Tech Insights newsletter to get new blog posts straight to your inbox.
About the Author
Tom Vaughan
Senior Software Engineer at Made Tech
