Le Carnet
Pour la gloire de Dieu et le salut du monde.

Hiring Like The Life Of Your Team Depends On It (2/5)

Published on .
by Hubert Behaghel

What underpins this value is that slowing down is not an option and moving faster is a core responsibility of a team.

Not Growing is a Risk

Death by Inflexibility

People resign, and that should be okay. That requires having a margin in the headcount and a decently shared knowledge.

Our internal OSS model also demands this margin. Take the engineering teams you admire. Let’s be honest, it’s not due to the amount of cash they produce, or the quality of the customer experience they deliver. Not even their uptime. No, what impresses you is that their entire reputation, is built on their tooling. The tooling we equip ourselves with judges us. A bit harshly at Sky at the minute if I am honest. That’s why we have initiated the disco-core project, to create a space where we can collaborate to solve few problems for good, makes us move faster and become overall stronger for it.

Why have we chosen to get there via an underresourced team and the so-called internall OSS approach? Because it’s not a top-down initiative. We want strong buy-in from the teams. To keep enough control and ownership on the teams to benefit from it, we promote this other value of ours Don’t build for, build with, as one team. Effectively, we have designed our strategic initiatives purposedly so that they fail if the teams don’t get involved. But that supposes you build the right flexibility in the way your team’s work. That applies to MAP, to the soon to be launched SIGs, to all that we do in the DevOps space. Fail for a good reason, not because you couldn’t sort out the easy challenge of time management.1

Death by Inflation

Year over year, the same degree of engineering competency is worth less. Technical obsolescence is harsh in our field. A year ago, I was hands-on building sky.com. In 6 months at best, I’ll have to remove any trace of front-end expertise from my CV. I’ll be irrelevant to any serious team in search of a talented front-end engineer. The array of practices and techniques a team must master keeps growing and evolving (hello data science!). It is critical that we raise the bar constantly. So much so that at Amazon, Bar Raiser is a responsibility anyone can apply for. It takes a minimum of two years of training and shadowing. It’s a highly respected function in charge of hiring and promoting. It facilitates both processes and has veto power on both. Let me stress, it’s a responsibility not a dedicated role. It can lead to funny situations like a mid-level software engineer who happens to be bar raiser blocking the hiring decision of a Senior VP. How about your team? Is the bar raising? Do you have a bar raising process?

Hiring is arguably the biggest driver for bar raising. It comes down to putting this one question at the centre of your discernment:

Is this candidate better than 50% of the other people in the same role in the department?

Have a consensual yes and you’re likely making a great hiring decision. That sounds easy right? Well, it kind of is. Define better. Have a constructive process to facilitate and answer this question. And Bob is your uncle.

Tick-Tock, the Crocodile is Near

You need to acknowledge a clock is ticking. Because someone will move on. Because of obsolescence. But also because the business will ask you to move faster. Think about it: if you do a great job as a team, you’ll become the path of least resistance for the business and more work will come your way. If you do a poor job, you’ll accumulate technical debt. This is subject to the same compound effect as real debts. You’ll need extra-efforts to keep up. In both case, it’s more work for you and your team.

Finally, the reason the clock is ticking is because hiring is a skill and demands practice. How long since your last hiring decision (offer or reject alike)? When did you last on-board a newjoiner?

You should have now come to the following conclusions:

Remember, we don’t mind risks. It’s all about controlling them. We will see how in the next post.


  1. Factoring that flexibility in our estimates and in our roadmap commitments and job done. [return]