“We only hire seniors” and other anti-patterns
“We only hire senior engineers” and other anti-patterns
Spend enough time on the ‘orange site’, and you will see similar platitudes about hiring over and over again. Maybe you’ll read about “hiring only the top 1% of developers”, or perhaps “we only hire senior engineers”. I imagine this is a dog whistle to suggest that only software elite work at a given workplace, so don’t bother to apply. I wonder though, is applying these kind of elite filters the best (albeit expensive) way to build a high performing team, or are there other kinder, nicer ways?
Depending on who you ask this question, you may get many difference answers. I’m always fond of data, as are Google, and their ‘HR’ team asked this very question.
“Over two years we conducted 200+ interviews with Googlers (our employees) and looked at more than 250 attributes of 180+ active Google teams. We were pretty confident that we’d find the perfect mix of individual traits and skills necessary for a stellar team — take one Rhodes Scholar, two extroverts, one engineer who rocks at AngularJS, and a PhD. Voila. Dream team assembled, right?
We were dead wrong. Who is on a team matters less than how the team members interact, structure their work, and view their contributions.”
The Google team learned there were five key dynamics that made teams more successful than others. Psychological Safety, Dependability, Structure and Clarity, Meaning of work, and Impact of work.
Psychological safety: Can we take risks on this team without feeling insecure or embarrassed?
Psychological Safety was by far the most important dynamic. But what do we mean, when we talk about Psychological Safety?
Taking a risk around your team members seems simple. But remember the last time you were working on a project. Did you feel like you could ask what the goal was without the risk of sounding like you’re the only one out of the loop? Or did you opt for continuing without clarifying anything, in order to avoid being perceived as someone who is unaware?
How do you create this safety? Trust. And trust has to be earned. This requires understanding of the team, team dynamics, interpersonal dynamics and individual needs and wants.
Like any relationship worth its salt, this requires effort and authenticity. My favoured way to establish a relationship with a report is through regular 1:1s, but please — be genuine. Learn about your team. Find out their background, their families, their interests. These are all signposts to helping you find their passion at work. Understanding their motivation will help you structure work and team to get the best outcomes.
Dependability: Can we count on each other to do high quality work on time?
This trust extends to each other, and brings us to the second point on Google’s understanding of high performing teams. Your team have to trust each other, and they have to gain the same understanding of each other that you, as a leader, need to develop. In a previous life, we might have tried ‘team building’, escape rooms or even axe-throwing as ways to develop this trust. These thigns are lots of fun, but I’ve found a simpler way to build this trust — and get work done.
Pairing is awesome. Many hands make light work, and this is very true of paired programming. Two sets of eyes and brains keep the code honest. Write that spec. Refactor that method. Document that edge case. You will end up with better code, reduce your bus factor a little, and build the trust and rapport necessary to build that feeling of trust and dependability.
Structure & clarity: Are goals, roles, and execution plans on our team clear?
As a leader, you can never over-communicate. Engineering teams often work in cycles, and establish ‘work to be done’ over that period. But is that enough?
It’s easy to become focused on busywork and the dopamine hit of smashing through another ticket, but leaders must always ask — am I making an impact? If the sum of the work doesn’t result in measurable impact, why bother? Goals are not the sum of the tickets you complete. Goals are measurable outcomes.
If you’ve ever watched young children play soccer, you will know first-hand what happens when a team performs without roles and plans. They all chase the ball, at the same time, and often collide with each other. Sometimes they’ll score a goal, but that’s either the result of one of them looking up and driving towards the goal, or a happy accident.
Your team needs roles and responsibilities, and this encompasses more than just functional roles. If we’re focused on outcomes, the work will pass through many hands before a customer can use it, and so an owner is needed. Create one.
Lastly, you always need a plan. It will change but the act of thinking increases chances of success drastically. A one-pager is sufficient for all but the gnarliest of problems, and literally will get your team on the same page!
Meaning of work: Are we working on something that is personally important for each of us?
Surprisingly, for one of the higher paying professions, software engineers place much less value on salary, versus other factors. This means that their motivation is much more intrinsic, and the reward comes from the work itself.
You may have a brilliant, innovative product, in which case you can easily attract engineering talent by virtue of the product itself. If you’re working on something less shiny you may have to find other ways to motivate your team.
There’s a number of ways to achieve this, all well beyond the scope of this article, from adopting shinier technology, using older technology in innovative ways, or even just allowing the team to second to other functions or teams within the same business. The key is to understand the individuals career motivations and allow them to realise them within your business.
Impact of work: Do we fundamentally believe that the work we’re doing matters?
This can be a tough one for startups. If you’re building Uber for Cats, you’d better hope you can find a team that loves cats and transport.
Failing that, align the work to the teams own values. Are they passionate about accessibility? Let them lead an initiative within the team to enable your app for accessibility. Bring the team on the journey too, so they can learn and understand more about both the subject, and their team-mate. Even if your product sits within a particular niche, building for social values is a great way to both improve your product and allow the team to breathe their values through it.
What else?
There’s plenty of ways to improve your team, through internships to build leadership and mentoring skills, to diversity which reduces group-think and exclusive designs. I’d love to know ways that you’ve introduced to improve the performance of your team, please let me know.