It's all about "The Team" - CTO's discuss
I had the pleasure to be invited to a recent Codemotion CTO Meeting. I get invited to many industry events but this particular one I had great interest in. The focus was to be “The Team”, which I fully believe is at the core of my role as a CTO. It’s something I as an individual and we as a team at Utilus deal with everyday - making our team bigger, stronger and faster. Codemotion asked me to write up my thoughts on the meeting and here’s the article that has been published by Codemotion this month (link at the bottom). Enjoy!
By Miguel Ferreira
Last week I was at a CTO Meeting organized by Codemotion in Amsterdam.
The meeting itself was organized around a theme – The Team – introduced by the meeting moderator Marco Casario (Chief of International Business Development, Codemotion), and a panel of three CTOs to kickstart the discussions:
Marco Casario structured the theme into three related topics that roughly cover the lifecycle of a team:
1. The perpetual quest for talent
2. Keeping the team motivated
3. Saying goodbye to team members.
1. Finding talent
Most CTOs seem to make use of recruiters to help them with their recruitment pipelines, noting that finding the right recruiter for you and your company is a challenge in itself, but when done right is also very rewarding. Panellists Geert Vos and Sebastian Lagemann mentioned participation in tech events/Meetups/workshops as a good opportunity to get to know more potential new hires who share a common interest. Being the CTO of a company with a broader spectrum of activity, one that tackles building and running systems at large, I find this approach a bit difficult, since I would have to cover a large range of topics.
However, while I was thinking about how many Meetups I would have to cover to find that one person, Raluca Mihu dropped the first eye-opener of the evening for me. She said the first thing to do is clearly define what are you looking for in terms of the person’s characteristics, so you can then define what are you offering in order to attract those people.
The discussion dived into the scary abyss of failure, when to fail, how to fail. Embracing failure gets much traction these days. But, as Raluca reminds us, it was not always so. It would have been unthinkable 10 or 20 years ago for a developer to admit not knowing how to do their job and having to go figure it out while on the job. This would have been a sackable offence back then, but today it’s just another day at the office.
“Setting up an organisation that allows for and embraces people falling often and failing fast does not reduce the quality of the systems it builds and runs.”
It’s actually the opposite.
Letting the team take responsibility for fixing it in the production environment, and then backtrack to their day-to-day in order to fix the underlying cause, will be your best option for fixing things structurally and preventing regressions. Another interesting perspective on the value of failure is the realization that failing mostly comes from stepping out of your comfort zone, from doing things differently. In other words, it comes from innovation. If innovation is what a company looks for, “asking people to fail frequently” can be a way to achieve that. Recruitment is rarely discussed without mentioning gender disparity.
In Raluca’s opinion, women will try to match as perfectly as they can with a job ad before they apply. In many cases, these job ads list way too many technologies and that makes it easier for women to think they are not a good match for the job because, in their experience, they do not have enough of an overlap with what is required for the job. Keeping job ads short and more focused on the problems to solve, can increase the chance of having more women applying. Also, with respect to the gender gap, people mentioned that they had successfully addressed women applicants by realizing that the applicant selection methods were biased towards men. By taking a different approach, they were able to grow their teams with great developers, of which the majority are women. But what are these selection method biases and how to address them?
There is not a clear-cut answer to that, but the one that really caught my attention was the observation that the professional trajectories are very different from gender to gender. Since I’m a male, I have no intrinsic knowledge of that trajectory of a female colleague to land in the same position that I’m in. Sebastian approached this blindspot problem by inviting candidates for group assessments. In this process, they create hypothesis about the applicants. They test their hypothesis by switching certain applicants from one team to another in the middle of the assessment, to see how they behave with different team-mates. However, group assessments require a very significant investment in preparing the assignments, in closely observing the teams and testing assumptions.
Recruitment is a two-way street. When hiring someone, I need to be convinced I really want to work with them, just the same as that person should consider if they want to work with me. When interviewing, Raluca recommends the STAR method. The applicant describes a Situation where they had a Task to perform, and explains their Actions and the corresponding Results.
Regarding salary, if you base your offer on the applicant’s current salary and add some more money to it, that is a very safe bet. Who doesn’t want to make a bit more than they currently do? However, knowing that there is a significant gap in the salaries payed to different genders, by taking this approach you will be perpetuating this gap. Ouch! That’s probably not what you meant to do, right? On the other hand, if you ask people how much do they need or want, applicants might (and often do) perceive this as a trick question. Ouch again! That wasn’t the intention either!
According to Geert, problems will likely arise when team members exchange salary information between themselves and you might be asked to justify differences. I very much agree with Raluca’s remark that, in the end, you cannot make everyone happy and pay everyone exactly what they deserve, but you should strive for sleeping well at night, knowing you are doing the best you can to be fair to your team.
Cultural fit was also another topic of debate. Geert immediately expressed the question I was left with the previous evening at a Meetup about diversity in tech: What is culture fit anyway? The discussion moved on to examine what is meant by culture fit. Geert highlighted that it is desirable that companies evolve, and having a crystalized culture to fit people against will hurt the evolution of the company, and its culture.
“A company’s culture can change with every new hire. What is desirable is that is changes for the better.”
Raluca explained she uses metaphors to judge culture. She asks applicants to choose three toys (or something else) that represent their past, present and future. Then she gets them to talk about their life through the metaphors with the toys. According to her, this brings applicants out of the tech world and into the people’s world. On company culture, Raluca’s experience is that it helps to have a culture strategy that you use to guide the process of searching for applicants and to better prepare for interviews.
The leaking bucket problem of having a higher industry dropout rate of women also came up.
“It’s not just about hiring more, it’s also about keeping the people that get hired.”
Personally, whenever I hear the words cultural fit I get the impression that “here comes an excuse not to hire someone” – to justify personal choices disguised as company choices.
2. Motivating the team
So you’ve built the team – now how to keep them motivated?
Geert was quick to draw an answer to the question: “You make people feel like the company is also theirs.” As the CTO, it’s your job to create a company where people want to work and stay for a long time. Okay, but how do you do that?
Geert said it’s about making people responsible for their work and the performance of their team, and for that they need more information than just “this is the job you need to do.” They need to understand how the company operates and what are the drivers for its financial success.
Another interesting response was to influence the team on what they want instead of what they do. For example, if you feel like the code the team produces could be better, instead of influencing them to produce the quality level that you expect you can try and influence the team to also want the same quality level.
You should be patient with the team if you really want to influence what they want as opposed to what they do. The outcome is a much more lasting effect and a happier team.
3. Letting someone go
Letting someone go is probably the most delicate thing a CTO needs to do.
Sebastian leans on his team to make the decision of letting someone go. He generally tries to get a feeling for how things are working or not working, whether there is a path forward that does not involve letting someone go, or if otherwise, if there is an element in the team that needs to be removed.
For Geert, the process starts with signals he picks up from each individual team member and from the team as whole. When it comes to make the actual decision, Geert leans on his colleagues from the management team to help him. Raluca is quite pragmatic and calls the decision quite quickly. She believes in the power of intuition and her experience thus far has shown her that she is better off following her intuition than fighting it.
All in all, most people in the room have always terminated an employment relationship with a team member by mutual agreement, as opposed to legal action.