Becoming a CTO

It’s funny how the new financial year brings new opportunities, new challenges and at the same time, a period of reflection. In the past week alone, I’ve had a several friends and people I’ve worked with in the past, reach out to discuss “what makes a great CTO”. Now, for some, they are already in a CTO role, for others, it’s a role they are hoping to move into in the coming weeks. After handing out my humble opinion, one simply said “you know if you had posted about this, I wouldn’t have had to take pester you.” A fair point. So, I thought it was time that I shared my thoughts on what makes a great CTO, thoughts based on working with some pretty inspirational CTOs in the past, and I hope, valuable insight from my own experiences over the past 8-10 years as a CTO.

The definition

There are lots of different views on what a CTO is, their duties, areas they should focus on, even what they should be strong at. This is pretty clear when you put a group of us in a room at the same time, some are uber technical, still coding daily and are really part of the low-level engineering effort, others are far more business managerial and simply aren’t technical at all. For me, a great CTO must have come from a technical background, they have to have been on that journey of being a software engineer, someone who has worked on making their code efficient, secure, robust and re-usable. They have to been responsible for identifying the right technologies to use, the right infrastructure, understand how to architect out enterprise-wide scalable solutions while at the same time, enforce software development patterns and lifecycles that work well. But here is the rub, many engineers who are great at these things, simply do not want to take on the other challenges that you need to have experienced to make a great CTO. Many technical roles can be solitary roles, and there is nothing wrong with that, however, a CTO isn’t one of those types of roles. For me, you have to then go on that journey of learning how to lead a team, how to structure engineering team efforts, create and cultivate a great agile engineering culture. Then we have the business side of things, you have to gain experience of the business, almost become or have that ability to be a sort of Product Owner or old school BA. Once you have done these roles, you’ve gained the experience and foundation of what makes a great CTO.

You see, a CTO for me is the one who is at the sharp end of technological innovation and product development within an organisation, even more so if the organisation is a technical company or has a technology platform at its core. The CTO is responsible, scratch that, accountable for creating a solid engineering environment and team mentality, they are responsible for ensuring engineering follows the 3 fundamentals and they are the ones responsible ultimately for building a great technical product. They will help shape technical strategy to the point of forming actual strategy for the organisation itself, something that many “business” focussed individuals will disagree with. But, remember, almost every business in the world now has its success governed by its technical prowess, its IT capabilities and strategy…It’s a fact.

In addition to all of these areas, a great CTO must also be an inspirational leader, great public speaker and in many cases, quite entrepreneurial.

Building a team around you

This challenge is very different from organisation to organisation. Some of you will be required to build a team from scratch, others will inherit a fully functioning engineering department and senior team. So the challenge in execution can be varied, however, the objective and outcome is the same.

A great CTO will look to get the right talent around them straight away. For small teams this maybe a strong engineer who can double up as an agile type coach / scrum master, for larger teams, it maybe to identify those with some leadership qualities. I personally like to get a structure of a small number of people who are uber talented around me. I look to have senior architects who form a “guild” to ensure strong alignment amongst the people who really structure the product from a technical point of view. For scale, or when you need to scale teams, I believe you need to start looking at “Heads of engineering” across the areas of real challenge. The key then is not to enforce an engineering culture or structure, rather to collaborate with those senior people you’ve now got around you to get something you all like in place.

I’m a strong believer in a good clear agile engineering culture with autonomous teams, but here you need to view leadership about alignment, not dictating or bossing people about, nor looking over their shoulders. Working in this way has many many undisputed benefits, however, it can be challenging depending on your organisation’s expectations in terms of reporting or their own mindset / culture. The benefits outweigh the challenges every time though, IMHO. Setting a culture of autonomous teams empowers your engineers, keeps them challenged and motivated while at the same time, instils pride in what they do.

As I said, I am a strong believer in “guilds” and “charters”, having groups of people coming together to help move engineering efforts forward. I also believe that having group meetings every other week, almost like a sprint planning session, works well with your senior team. In the past, I’ve been set against people having things on paper in these meetings, however, in recent months I’ve found that its beneficial to all collaborate around a “One Note” document, or a tool like Monday.com Though, if you can keep the mentality to a “stand-up” I believe it keeps your meetings down to around 20-30 minutes, and lets face it, for an update and alignment session that’s on a regular basis, this should be enough.

Setting the culture

Engineering culture is something that isn’t set in stone, a great CTO should always be looking to see how it can be improved, how to iteratively get more from the structure and culture that is in place. You should be asking yourself, what could be changed to make life easier, or more productive for my teams. As Churchill once said, “To improve is to change; to be perfect is to change often”, and that’s how we should think about engineering culture.

IMHO you have to follow an agile engineering culture, deliver as much empowerment as possible to your engineers and their teams, help “coach them” rather than dictate and help them remain focussed on engineering tasks, and not administration. I used to promote the use of Scrum masters, however, in recent years, I’ve moved more away from a specific agile practice, and adopted a more agile principled approach, meaning that I recognise that each team is unique, and therefore each teams way of working can be different. This is true agile for me, ensure agile principles are valued more so than any specific agile practice, and to do this, I believe you need to leverage agile coaches as opposed to a scrum master.

The right culture will keep your teams motivated, keep your engineers engaged and ensure they take pride in their work. All these things ultimately lead to better quality code, better execution of product deliverables, shorter deliverable cycles and ultimately happier customers. I’ve been painfully aware of this for sometime and it’s the single greatest reason why I promote things like an innovation day, or two days across the entire engineering department. An innovation day is all about letting teams form themselves, letting them innovate and build simply whatever they wish. It taps into the same drivers that lead us to see engineers working hours on end for open-source projects for free, it taps into something I call “Mastery”. I say this, because engineers love to master their trade, they want to get better at it and they ultimately enjoy that. If engineers become stale in the workloads that they have, and let’s be honest and open here, lots of work can be repetitive and un-challenging for engineers at time, then they won’t take as much pride in the work they deliver or will simply look for challenges outside of your organisation. So, by having a day or two set aside to pure innovation each month, gets those creative juices flowing, promotes teamwork, collaboration, and engineering mastery. Though this may seem like a waste of money on the company’s time, its actually highly productive, and in most cases, teams will build something that really should end up on your product roadmap.

Oh, a beer afterwards (virtual from home or face to face) could also help the culture.

The product

No matter the business, the type of organisation, view everything as a product, and never ever ever let anyone start talking about a project. I know this could be seen simply as language, however, from language comes a certain way of thinking. If we think product, we think of re-usable solutions, off the shelf and at most a bit of configuration before it can be re-used, and the business enjoy revenues from it. If we think of a project, we focus purely on what is needed for this particular requirement or customer. As soon as you do that, you have killed any benefits of the work you are undertaking outside of that specific customer need. In addition, a project should have a clear start and end date, that feels very waterfall to me. In contrast, a product needs to be maintained and can be iteratively improved over time, ensuring customers continue to use that product, and more importantly, new customers are drawn to it and start to use it too.

The big challenge for any CTO is getting those business requirements into the engineering teams accurately. There has been so many ways of how to do this over the years, but I would simply say it’s largely down to having the right talented people in seat, as opposed to following any specific description of a job role. Feel free to use a BA, or a Product Owner, but ultimately there are two things you need your teams to remember:

  1. Understand the customer problem statement, their need their pain.
  2. Do not blindly follow customer recommendations, challenge their thinking and ask why they recommend this.

I believe in design-based thinking, with the customer at the centre of everything we do. However, you have to understand the pain and think of a clean new solution, rather than get caught in improving what they have. This is tough to explain, but Henry Ford once said (though this maybe more legend than fact), “If I had asked people what they wanted, they would have said faster horses”.  I’ve spent many years around tech solutions which essentially take what the customer has, and makes it a bit faster, or a bit simpler. How many times do we find workflows in systems that mirror good old-fashioned manual processes, work is now just in my digital in-tray as opposed to my physical paper based one on my desk. This is technology being used in the wrong way, yes it sorts of solved the problem, but it didn’t innovate, and didn’t deliver as it should have.

As a CTO, you have to inspire around this area, and you have to get the people in those positions who can think outside of the box. I often like to get people involved who are not part of engineering nor even part of the business. Rather their experience is in other areas, you soon see different methods of thinking and potentially very different solutions. As a CTO in this area, I believe you have to be quite disruptive in your thinking, challenge the proposed solutions and try and ensure the people around you think out of the box. You have to be almost an entrepreneur…

Technology strategy

IT Strategy is one of those things that is interpreted in a different way with almost every exec team I have ever worked with. Some like to see a pure strategy, as in let’s see the strategic based decisions on the technologies and platforms that will be used, what strategic benefits the business and IT should get from these decisions. That’s what I call strategy. However, some want to see specific plans on execution, as in plans, timelines, what challenges could be expected etc etc. For me, this is far too much detail for a strategy, and really, that’s a separate piece of work on implementation.

The best generic advice I feel I can give on the basis of forming your IT strategy is this:

  1. Know how you want to operate your platforms and what support staff you think you will need to maintain what you deliver
  2. Know when to Buy, Partner or Build
  3. Asses the chances of an innovation dead-end and clearly avoid that

Most of your strategy will be based off of these 3 main points. First off, how do you want to operate and what support staff do you want. This really does make you start to think of the types of solutions, scalability, performance and ongoing support. A great example is looking at Cloud vs on-prem and if you are opting for cloud, then PaaS / SaaS vs IaaS. Once you make strategic decisions here, it starts to ensure you make better decisions later on. Take point two, knowing when to buy, partner or build. Well dependent on your strategic decision for point one, this will have a massive bearing on your decisions on point 2. One thing I must add, is when you are considering when to buy, partner or build, think of two things:

  1. Where do I want to spend my IT budget, or “dev dollars” as I often am quoted to say. What will give me the best bang for my bucks
  2. Do I see this as core to our proposition, or in some way just causing dilution / lack of focus

I think if it is core to your proposition, as in you can make an impact on customer outcomes and add value to the valuation of the company, then yes, you’ve got to build. However, if it doesn’t, and there is nothing really unique to it, then purchase. When partnering, you’re looking at something that add’s value to your own proposition, but is something that is either not cost effective for you to build and maintain, or you simply need to take advantage of some form of aggregation / specialist skills that the partner brings to the relationship.

A great CTO is an entrepreneur, they need to be if they are to set IT strategy that will continuously work for the business and add value to it.

The product roadmap

These are powerful things, however, don’t get hung up on dates, don’t predict the future. Far too many CTOs try to predict the future in terms of timelines, I’ve fallen into that trap a number of times myself, either by my own doing or by accepting the ask from others. If you have to think dates, think of very wide barn doors, because until you have teams actually scoping out the real detail of the work, you don’t have much more than a “hunch” to go on in terms of effort and delivery timescales. A good product roadmap should form what you want the product to do, it should meet the demands of the businesses strategic approach, effectively defining product that will help the business meet its strategic objectives.

A great CTO will take the time to understand the difference between a strategy, or strategic direction of the company, and the fact that product isn’t strategy, rather product (and it’s roadmap) is geared around meeting that specific strategy. Now, strategy isn’t something that typically sits with a CTO, however, I believe if you are a CTO of a company that’s product is its technology, then you need to have a strategic input. See Porters strategic triangle to understand the three main areas of macro strategy that your product will fall within. Take time to think about your product roadmap and how it drives the business to meet its strategic aims and objects.

Capturing data and analytics

Data and analytics are the tools that enable CTOs to ensure their teams refine and improve solutions and the way in which they work. For example, if you can’t monitor how your teams are performing, if you don’t have transparency of delivery of product, then if all feels a little “blind”. Transparency into progress helps you drive forward, and the best way to have transparency is to ensure you have a culture of continuous delivery. Now this isn’t always possible, but if you can see what’s in the release pipeline at all times, and the various stages, then comfort is there that as a team, as an engineering department, as a business you are “delivering”. Real delivery is far more valuable than trying to predict the future, trying to predict the delivery of something.

Delivery focussed data and analytics can help you identify the teams that deliver product faster, or product that is more robust than say another teams. It allows your teams to get more accurate at predicting when products will be released because you have a history to work from.

Data and analytics can also serve you in two massively valuable ways,

  1. Monitoring your systems – allowing you to identify potential performance issues before they happen
  2. Diagnose issues and fix them
  3. Provide additional MI that could open additional revenue streams

Now the first 2 have in recent years caused me personal problems, not having sufficient monitoring or diagnostic capabilities meant at times you feel like you’re flying by the seat of your pants. There is a real temptation as CTO to ensure your teams push forward and solve real problems quickly – sometimes at the expense of sufficient monitoring tools and dashboards. Take it from me, ensure you get great monitoring and diagnostic tools into everything you do, even as part of your minimum minimum viable product, because if you don’t, not only is it hard to identify potential issues or to solve them, its painful having to take time out of busy engineering schedules to retro fit these capabilities.

The third point, well that comes down to the entrepreneur inside of you…

Alignment and efficient meetings

Efficient meetings for me are short, sharp, to the point and are called because you need to solve a specific problem within that meeting. It must have an outcome, one that is tangible, if not, the meeting wasn’t needed, or it is needed but required a lot more work to be done and brought to the meeting. Unless you are solving a real problem, something complex as a team, I would recommend daily stand-ups, check-ins as and when you need and keep everything on your actual feet. Sure there are times you need a committee style of meeting, lengthy meetings to ensure alignment across a wide variety of issues, but these should be run based on a strict agenda and only cover things that people don’t already know. Don’t fall into the trap of going through things as a tick box exercise, or just to pay lip service, or to “share knowledge”. If you are doing these things, they can be done informally or formally but via shorter more focussed meetings.

I’ve always tried to keep any meeting I am running under an hour and a half, and that includes Charter and Guild meetings where we are trying to solve large challenges. You’ve got to keep moving the discussion forward, oh and if you have notes, make sure someone takes them accurately. Again, I prefer a shared One Note, but appreciate that many will want more formal looking minutes.

In order to get alignment right across the floor, I really like a CTO to stand-up and give an update to the entire department. The update can be on whatever, but it needs to be enjoyable and something people want to listen to. It’s a great time to share the bigger picture, but also the perfect way in which to ensure there is clear alignment right across the floor. After all, that’s one voice that everyone is listening too.  Try to be inspirational, and not boring though 😉

Public Speaking

I think many technology focussed individuals struggle with this, and it maybe one of those key reasons why there are so many CTOs or people at an executive level that look after IT, that haven’t been through an IT based career fully. In certain studies, it has been shown that some individuals (and this isn’t limited to IT) are more fearful of public speaking than of death itself. I know, may sound nuts to those of you who are comfortable with public speaking, but it’s a real fact.

I personally don’t mind public speaking. I’ve had to do a hell of a lot of it in the workplace and externally for probably close to 15 years now. I’m not saying I’m great at it, rather I am comfortable with it. So what do I have to share around this area, well, try and do the following:

  1. Only agree to speak on subjects you are passionate about
  2. Never ever put too much content into a presentation in word format. Use illustrations – sweeping graphics and rely only on a few bullets on the slide
  3. Look to get engagement from your audience right away – pose a question or start with something thought provoking.
  4. Avoid lecturing or listing points together, it gets really boring listening to “we do this, and we do that, and we do this better because of….”
  5. Try to provide something personal to you about the subject matter, make it relatable to yourself and the audience
  6. It’s an old saying, but “fail to prepare, prepare to fail…”

The fist and the last points are by far and away the most important, even more so if you are nervous of public speaking.

On the preparation front, I will share with you some of the habits I have, which to be fair I was given by my wife who used to be a stage performer. The first part is the structure of your presentation / talk. Make sure you structure it around “hero” type points you want to make. So, list the points out, then get them into some sort of order that makes sense, you can have the support messages under your hero points there, but don’t make too much of a big deal about them. You will end up speaking about them, but don’t clutter your presentation or your mind for that matter. Look to tell a story from hero message to hero message, with the story or narrative largely including sub messaging you want to get across. In your head the story should be from getting from hero message to hero message – and will help you be able to talk without reading slides.

I use imagery a lot, simply because I want the audience to look at the slide, digest its content pretty quickly at a high-level and then have them listen to what I have to say about the content. Having a story in your head here massively helps, because you don’t have to remember word for word what you want to say, rather the narrative you want to get across and the key hero messages.

Once you have all of this together, practice it. I practice larger presentations a few times, especially memorising my hero messages or the odd link between them. The story should be in my head fully formed, so I rely on slides for imagery, graphics, quick ways of showing content to the audience, hero messages and memory pointers.

Forming relationships and taking feedback

A CTO has a hard life in terms of the variety of relationships they need to form. You have to be able to form great relationships with engineers, and this is the most important one. If you come from a technical background you will find this quite easy. If you haven’t been on that journey, then this will be really really tough to do, especially if you want to understand your team’s personalities and characters. A CTO also has to act as someone who can inspire engineers, command their technical respect while at the same time not come across as a CTO who is telling people what to do, dictating how things should be done. That goes against the autonomous team culture you want to set up, so it’s a balancing act.

As CTO, you also have to be able to form relationships with other business departments, the heads of, other executive and the board. It’s wider reaching than this though, because you will no doubt have to be able to work well with client coverage and sales teams, and that then means forming relationships with your peers and other execs from external companies. The variety of the departments and type of people within these departments makes it hard for a CTO to really form strong relationships, but it’s something you have to do and do it in a way that shows you are authoritative in your own space, while at the same time, very mindful of others and their needs. Unfortunately, there is a lot of “ego” in and around tech, and as a CTO you have to be strong minded, confident but not arrogant or judgemental of others, and be ready for the odd “idiot” being polite there, who will want some form of “tech-off” with you….But just see that for what it is, remain focussed on your messaging, what you want to achieve and listen.

I also believe, that a great CTO identifies possible relationships with other companies. They identify their strengths and are able to put together the jigsaw of how these companies can help enrich your own product set or company profile. This is becoming increasingly more important as pretty much every business that operates successfully today relies on its technology.

This all leads into the area of taking Feedback, and how you take that feedback, especially if its negative or highly critical. I personally look to try and take all feedback onboard, trying to understand the other persons perspective of where they are coming from. I also try to understand exactly what the outcomes could be if I do take that feedback onboard or if I don’t. Though I think being a CTO can be quite a lonely job at times, one thing that a CTO is never short of, is people’s feedback and opinion. Let’s face it, everyone has an opinion on IT or technology. I think only marketing has the same problem if I’m being honest. While this means you’re never short of an opinion on your performance, it does also mean you find yourself with a lot of feedback that is, well at best contradictory, at worse highly ill-informed. So, the key is understanding exactly what feedback you need to embrace wholeheartedly, is understanding the micro-points that lead to that feedback, where it is coming from and the knowledge of the people providing that feedback. It’s only at this level of detail that you can really asses if the feedback is something you want to take on-board.

As CTO, relationships and feedback is a real tight-rope, there simply is so much poor feedback based on frankly a lack of understanding. But, forming good relationships can be one of the more rewarding aspects of the role.

Keeping calm and dealing with crises

My final point of this post is to say this, every system fails, every system goes wrong and at times you will be in crises mode, fighting fires and feeling very stressed. You can handle this in two distinct fashions,

  1. Get into the micro-level of detail, getting involved and really become a micro-manger / engineer at the same time
  2. Trust your team, empower them, and be there to provide them with the support they need

I know many who fall into option 1 here without knowing it. I have met many who also think this is exactly what a CTO should be doing. I’m here to say you are wrong. If you find yourself in option 1, then you are looking at career burn out and probably a highly limited personal, social and family life. That level of stress has an impact on the people around you, without you knowing it. So, I am here to say that managing crisis is more about team than any other aspect of your business.

You have to have a team, and when I say team here I mean a team made up of individuals but not specific individuals. You need a supporting cast, you need the bench, you need bench rotation etc etc. You cannot have the same players on the pitch for every single game in any sport, and managing crisis and being on call means exactly the same in the workplace.

Individuals go on holiday, they suffer with illness, personal issues, they have other commitments outside of work and so you cannot rely nor should you be able to call upon specific individuals in crises. The same is true of the CTO. You have to have a team of people that can respond and resolve the issues. Your role as CTO, is to ensure you have that team in place and that you have processes around managing crisis. You are the supporting act here, if you cannot empower your team to investigate and resolve issues, then you have failed. If you are dependent on specific individuals, including yourself, then you have failed. If you don’t have structure around handling crises (which keeps people calm and able to focus on the right things) then you’ve failed.

The CTO role is to enable and empower autonomous teams and make sure the support structure and processes are right. Apart from that, get out of the way and only be involved if teams ask for your input / call upon you. Remember you must stay calm, encourage and support and always have your focus on the bigger picture, not get pulled into the weeds.

Conclusion

A CTO role is tough, it’s a balancing act and most CTOs will struggle with some aspects of the job, be that public speaking, being inspirational, being entrepreneurial, being able to effectively communicate technical issues with non-technical people, or being able to form the right type of IT strategy. Who knows, my point is, if you are thinking of being a CTO – just know that all of us who have been, or are acting CTOs, struggle with some aspect of the job. Look to get better in the areas in which you struggle and don’t be afraid of them. Always be trying to learn how to do things better, educate yourself across all aspects and lean on your peers. Us CTO’s need to stick together…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s