How do you recruit a manager?

300hFor a bit more than half a year ago I decided to leave the corporate world. I moved to Ocado Technology which was starting a new office in Wroclaw at that time. I guess I forgot to boast about it.

This post won’t be about how great Ocado is or anything like that (however if you ask me, it is). I just wanted to share one thing that we did in Wroclaw, which for me was pretty awesome and quite unique when you look at other companies.

I want to share, how we hire managers.

Meet your new boss

Wherever I worked before, when the company was going to hire a manager, they just did it. Some uber managers held the interviews and finally, after time of gossips and keeping stuff super secret, the uber manager’s representative was meeting the team to share a fantastic, game-changing, long-awaited news.

‘You have new boss. Listen to him. Work with him. Finally, like him. We say he’s good.’

I have heard it more than a few times in my life – sometimes it worked, sometimes it didn’t. Sometimes the manager was actually good and we liked him, sometimes he sucked and after 3 months ‘decided to follow his career outside the organisation’, as the uber manager said.

The biggest problem of this approach is that managers don’t work with other managers only. They work mostly with people they are responsible for. However, during the recruitment phase no one asks the people about anything. Often they don’t even see the candidate before he is hired and has his day one. How can you then be surprised when the people don’t simply like the new guy?

I don’t know if uber managers (never been one, so I can just make a guess) think they are so senior, experienced, skilled and strong leaders that everyone will follow without any questions just basing on their word. That they know what is the best for everyone. Isn’t it a bit conceited?

Meet the candidate for your new boss

homer-job-interviewWhen in Ocado the time came to hire a manager, we decided to do it differently. The first stage of the process was interview with the team. The candidate was put in front of all people in the office, which was quite easy as there were less than 20 of us,  and asked to give a really short presentation. Afterwards we had a simple chat together to see if there is the chemistry between us. If the team wasn’t happy about the candidate, we thanked him for his time.

Stopping the entire office for 1.5 hour may seem like a waste, but for me it’s an investment. When I remind myself the corporate world, I can only guess how much time was wasted during pointless discussions or solving conflicts with managers? Far more. How was the team’s motivation and performance affected by making a wrong recruitment decision?

If the people don’t fell like they want to work with a given candidate, does it make any difference that the guy is experienced or skilled? Even if later he passes all the other stages, you have to convince the team that they should trust recruiters instead of themselves. If the candidate makes a great impression on the team, when he actually joins the organisation, he’s not a stranger. It’s their guy, they hired him. Saying ‘yes we want to work with this guy’ builds a commitment.

Of course one can say ‘people don’t know what they want’, but if you really think so this post, even this blog is not exactly for you. I believe that people exactly know what they want, especially in IT.

Short summary

Should the team have an interview with a candidate for their manager? Yes. It’s not easy, but doable. The question is, if your organisation is happier with long-term value or short-term profit. If you want to have great people, who will do a great job, you have to invest your time and effort in recruitment process. There is no other way.


What are estimates for?

Estimates are all about time. During one of last retrospective I realized that for some people estimates, and their role, are not that well understood. If not perceived well they can create pressure. Because what happens when we estimated the amount of work needed wrong? What happens when what we declared is significantly different than what we actually needed to fulfill our task?

Estimates are provided by developers and mean the most probable time when a given task will be finished. The most probable, not exact. Exact time can never be provided, at least not in software development.  This is something that both managers and developers need to remember.

Sometimes due to various reasons developers are afraid that breaking the estimate will cause troubles. When during the work some unplanned task shows up a question arises – should I take more time and work on the proper solution or do the task using duct tape and deliver my code on time? For me the answer is obvious, but as I lately learned not for all. Take all the time you need to rethink and redesign the solution, and implement it in the proper way. Ask yourself a simple question – what will satisfy your product owner or client – desired functionality that is working as expected or piece of crap delivered on time?

If your manager will be mad explain what is happening and why you have a delay. If you care about transparency and visibility of your work you manager will trust that you do all you can to deliver the code. If not, well then I’m sorry but the company should change the manager… Otherwise sooner or later the team will simply leave.

If you are a manger please remember what estimates are. If you create pressure on the team, the estimates will quickly become surprisingly high. People will start to add significant safety buffers just to be sure that in the worst case they will still manage to meet the deadline. In 95% of cases they will actually finish before time, but remain silent – wasting your time and money. Of course this will be the less professional part of the team – the more professional will be already working for some other company where the word ‘estimate’ is well-understood.