Building your team as CTO

In the latest blog of the Pragmatic CTO series, I thought it would be worth sharing my thoughts about strategies for building a successful tech team. Some of the principes I live/work by are outlined below but first I think its important to know what type of CTO you are, and where your strengths and weaknesses lie.

So you’re a CTO - what team are you on? Are you on the C-suite management team, with your fellow CEOs, CFOs… Or are you on your engineering team , with software developers, site-reliability engineers and testers?

This question comes back from the discussion about the role of inward and outward looking CTO from my previous post. Some CTOs tend to feel more at home with the techies, some feel more comfortable with their management colleagues.

To be a good pragmatic CTO, you need to play for both teams. In other words, everyone is on your team. Such a wide team can mean a lot of different things to different people - so having the right way to build and manage the team around you is of critical importance.

Find the right people - not the right tech skills

Hiring is hard in any business sector - I’m yet to meet anyone who disagrees with that statement. In the tech world that CTOs operate in, the challenge is particularly acute. Software development and engineering skills are in huge demand - making it a candidate's market. This has been the case since I started a career in technology almost two decades ago, and with the importance and growth of tech in all spheres of life, it will continue to do so. The supply of engineering CVs is reasonably healthy, however, finding the right candidate is difficult and time consuming.

Ideally, a CTO can build a core team of highly skilled and experienced engineers, who can work productively to produce quality tech products in an efficient manner. However this is easier said than done. The demand for the best senior candidates is huge, and they demand a premium package and conditions to join the right team. Even if there is a budget large enough, being able to identify the best candidate from an interview process is not easy. In a startup world, however, the budget constraints are real, and more often than not we have to compromise by finding the candidates that are maybe less experienced or think of other ways to attract or compensate them.

This doesn’t have to be a compromise at all - it is much harder to find the right personality and attitude, than it is to learn new skills. The right people, possibly more junior to begin with, have a much higher chance to become key employees in the future. As the saying goes, ‘recruit for attitude, train for skill’ - and see your team grow and succeed with you.

Mentoring - Do as I do

I mention hands-on and demonstrable traits a number of times - this is because I strongly believe that the best and most effective way to mentor and improve people around you is by leading by example - less talking, more doing. This applies both to technical and engineering skills, as well as softer communication and collaboration skills within a team. Show what’s possible, keep the right attitude and more often than not, you’ll see the similar response from those around you.

As a CTO I work with a lot of talented developers, many of them better engineers than I am. Most of them didn’t join my team with that level of skills and experience - but have learned and developed over time, to become the startup developers that they are today.

As probably many of you are, I enjoy getting my hands dirty and getting to code as often as I can - which isn’t as much as I’d like, but that’s a story for another day.

In order for my hands-on work to be as useful as possible for the team, I leave the most interesting tasks and projects to my team - that’s why they joined the company. Instead, I’ll make sure to be available for pair programming sessions when things get difficult, or take on the boring or legacy code - like a resource of last resort, someone my team can rely on when required.

This serves two purposes - shows that I’m around and not afraid to dig into any problem, hopefully demonstrating the right attitude to challenges to the rest of the team. At the same time, by taking the challenging or less-interesting tasks, I’m trying to work together with the team on reducing the stress levels and ensuring work is engaging and not too repetitive. I also enjoy any opportunity to do a bit of coding, whatever it is, so there is a bit of that too ;)

But that’s just my way - whatever process you use, just make sure to help everyone in the team grow to their full potential!

Communication - We are all in this together

Sometimes a CTO will develop two personalities when communicating to their colleagues: one moment diving deep into tech with the engineering team, evaluating key technical design; the next moment there is a detailed discussion about investment strategy and funding.

In my opinion, we should try to avoid this. Separating these conversations leads to silos, where it’s easy to miss out updating your development team about latest investment decisions, leaving them isolated. You want your engineers on this journey, and for that you need to make sure to promote openness and discussion within the team.

The same goes the other way around - if technology is the key to your business success, your CEOs and investors need to understand it, not be protected from it. Being open about technology, including the CEO knowing about cloud architecture will benefit a tech business.

Being open about challenges and bugs with your CEO and your customers, will promote trust, and help build a collaborative environment, with everyone, from tech team, investors and customers becoming part of the journey towards the best possible tech product.

Maintaining consistent communication across the team, so that everyone is fully informed, and feeling part of a single unit working towards a common goal and sense of product ownership, is vital to grow into a great company.

Continuous improvement - feedback and learning

Staff turnover, and especially software engineers, is one the major reasons for slow product progress, low morale and decreased productivity. One of the often cited reasons for engineers leaving their role I’ve seen is the lack of feedback and opportunity for improvements. It stands to reason that addressing this common concern would reduce the staff turnover in your team.

Regular feedback session with key team members, setting the goals and evaluating results should be part of your armoury as a CTO. And I’ll emphasise regularly here - it’s very easy to forget to have regular reviews or 1-on-1 sessions with your key team members. Make sure to include these in the diary from early on, show your commitment and do not allow other meetings and temporary priorities override this - ensuring your team members receive regular feedback and have a chance to voice their thoughts directly to you is big part of your job as a tech leader.

In addition, understanding what’s important to your team, investing within these elements and making time for training and development helps to build a good team spirit and retention.

Don’t let personal development and learning become an ad-hoc activity, or you'll fall into a trap of never doing it or indefinitely postponing for something momentarily ‘more important’.

Some of the ways to make engaging and useful learning activities include regular and dedicated R&D time (½ a day a week for example), allocated budget for events and tech conferences. In the current times, when in-person activities are somewhat harder to organize or attend, a paid subscription to online training library would be a good way for your team to find and explore new technologies to learn about

Ethical Approach - Between Loyalty and Fairness

As business and technology leaders, we should always remember that our professional focus is not the center of the universe, with life happening at the time, with all it's ups and downs.

Empathy and personal touch are important for building relationships, and cohesion and loyalty within the team. Trust and loyalty are consistently mentioned as one of the key traits of successful leaders and teams in the long run, and I would agree with that. Knowing that your leaders trust you and always have your back, gives teams confidence to excel, take the right risks, and handle success and failure in a healthy manner, always learning and improving, whatever the outcomes of individual projects and activities.

Loyalty is a two way street - one cannot demand loyalty without giving it in the first place, and it’s a leader's job to take the first step and demonstrate first hand to the team.

I came across leaders in my career who didn’t get that balance right - boasting about the successes they were responsible for, while at the same time justifying failures by individual mistakes by their team members. Or forgetting about the human side of their colleagues, demanding results and assigning blame, at times when some empathy and patience would give better results. Being a member or observer of such teams, I can tell you all of them failed. Make sure your team succeeds by not repeating the same mistakes as the CTO.

Next steps...

I’ve covered some of the key aspects of my approach to building a successful tech team. There is a lot more to be said about building tech teams than what I included in this post - I’ll be coming back to this topic again, given it’s importance for a CTO role.

What are your thoughts and experiences that made the team successful or reasons not-so-successful teams could have been better?