.webp)
All great leaders bring urgency into everything they do. They don’t set people up for failure (all of their goals are ambitious but achievable) but they want the benefits from the initiative so much they can’t wait to get it and they want it now -
Rorie Devine The CTO | CIO Bible
How do you build a successful technical strategy? Executive leadership means being kept up at night by worry. There are several things that will keep you awake as an executive technical leader. This includes:
The list is endless. What keeps you up at night fluctuates with time and circumstance. How can you keep up the momentum of your project, the technology behind it, and your technical team, whilst bringing things in on time and on budget? Your strategy will keep these concerns at bay which you can build using the four pillars of executive leadership:
These Four Pillars are how you build a successful technical strategy. For each of these pillars you will need strategies (long-term goals and how you plan to achieve them) and tactics (short-term goals with concrete steps and success metrics) that are in-line with the key strategic and commercial objectives of the company. You will need to communicate the strategies and the tactics throughout your organisation and drill them into your team, so their actions align with your goals. Their goals should be your goals and your goals should reflect the overall goals of the organisation and the vision of the CEO. Using these four pillars will keep the company goals aligned. You will progress the product, the technology, and the team towards the goals while keeping control of the budget. At Webio we use a 6x6x6 approach to communicate objectives in the next six weeks (tactics), six months (strategies), and six years (overall outcomes). This is a great strategic framework to build these four pillars in.
My goal in the next couple of pages is not to provide anything new or revelatory, but to collect several disparate ideas and best practices into a coherent structure. I use the term ‘executive tech leadership’ in this article. Most often this will be a CTO or maybe a CIO, but this could also be the CEO of a tech company, a lead architect, or a development team lead in a company without other technical leadership, a Product Manager, or a Technical Product Manager.
Your product is or should be, at the core of everything you do. Every decision you make is ultimately in support of the product and the product roadmap. Executive Leadership will involve a large degree of sales, sales support, client/customer management, and marketing. All of this is how you, as a strategic technical leader, help support and progress the product. Ideally, you should be working very closely with the product leadership which could be a CEO (usually in the case of a small company or start-up), a Product Manager, or the collective vision of the executive team.
When thinking about a product, the ‘burger analogy’ helps. A Big Mac is a product. It is a whole thing that comes as a package and is sold as a unit. It can be customised a little bit - you can ask them to ‘hold the pickles’ or maybe the lettuce - but the product is the product and if you ask McDonalds to sell you 1000 Big Mac buns and nothing else, they will likely just say no!
Software products can take a few forms, including:
Irrespective of your package and price model, your job as an executive tech leader is to make sure that the product is always progressing. That can mean developing new features, refactoring existing features, and finding new and ideally cheaper ways to scale and support the product.
Your first port of call when it comes to progressing the product is to ensure there is a solid, well-communicated Product Roadmap that details where the product is and where it is going. On the 6x6x6 model, this will mean having something that clearly states what is expected in the next six weeks, what is planned for the next six months, and where it will be in the next six years (the 6x6x6 model). Ideally, this will be communicated throughout the organisation but as a tech leader, you need to at least ensure that the technical team is deeply entrenched in the product roadmap and understand what they are building and how it is being used.
Once you have defined what the product roadmap is, you will need some way of tracking the progress of the product to make sure that there is a balanced approach and, more importantly, to make sure that the product as a whole is progressing. Do not underestimate how easy it is to have a team of developers doing a lot of busy and very important work but never actually moving forward. The bigger the team, the greater the risk is that this will happen. In the 6x6x6 model, the 6-week goals are very important to make sure that the product keeps progressing.
Keeping track of the budget of the product is almost important as part of product progression, but that will be discussed in our final pillar.
As well as progressing the product, the technology itself must constantly move forward. The average lifespan of a piece of code is something like 10 years. In these ten years, much will change in terms of processing powers, methodologies, tools, and even languages. The minute you stop progressing the technology is the minute you start accumulating technical debt. Reviewing the technology means reviewing everything from methodologies to server setup to programming languages. Keeping up means of being very careful to focus on the winners that will improve the product, progress the team and provide the value that will control the budget.
The biggest part of progressing the technology is to have a solid technical roadmap that maps out where you want to be over the next six weeks, six months, and six years. The six-week roadmap should be fixed and immutable, the six-year very flexible with your six-month plan being somewhere in between. This technical roadmap needs to be thorough but flexible, detailing where you want to be and how you plan to get there but able to pivot with new technology and opportunities.
Some of the tools to help progress technology include:
A big part of progressing the tech means that you and your teams all need to keep up with industry trends. I found a combination of Wired Magazine (for long-term industry trends), Meetups and Conferences, and encouraging the people I manage to tell me about new trends they are seeing is a great way to keep abreast of what is going on. Brown Bag sessions –lunchtime talks on a given subject for anyone in the company who is interested-- is a great way of encouraging learning and helping your team progress (more or that next point).
Progressing the technology is really managing innovation. As a tech leader, you need to be constantly scanning the new horizon for what is new, but also have a knack for finding the innovations that will bring you value rather than getting carried away by the Gartner Hype Cycle at every wave. Part of this is also encouraging the team to learn and get excited about innovation while staying focused on the other pillars (product, team, and budget).
Team balancing and diversity are key elements to progressing technology, which we will discuss next.
You cannot progress the product or the technology without progressing the team as well. This means progressing the skillset within your team and having mechanisms to ensure that each member is being utilised in a way that brings value to them and the business. You need to ensure all the managers know what their team balance is, which skills and personality traits are in abundance and which are lacking and know the direction individual team members want to take. A great deal of this leadership is finding who the leaders are on the technical team and moulding them into the managers, the technical leads, and the architects they can be. It is important to recognise here that great engineers do not necessarily make great leaders and indeed sometimes the best managers are only mediocre engineers. It is also important to note that not all engineers want to manage or even progress. A good part of progressing the team is hiring the right people in the first place. Skills can be taught, but the right fit for a team means finding a balance in skills and backgrounds.
With a younger team, the challenge is usually too much ambition and people wanting to progress quicker than their ability. In an older team the problem is the opposite, where seasoned developers are comfortable in their position and have no desire to move forward. In my experience, the latter is a bigger problem than the former, but a well-balanced team will circumvent a lot of this on both ends of the scale, with younger team members challenging more established engineers and more established engineers showing the less experienced how much they need to learn. From a strategic perspective, the key here is to ensure that the team does not stagnate. Stagnation is death in technology.
A common method of balancing team technical skills is to send out surveys to technical staff where they can self-identify their skills. This certainly has a time and place but beware of the “Dunning–Kruger effect” where some of your best engineers will give themselves the lowest scores and some of your lower-performing engineers the highest! Recently, I did a technical survey where I asked people to rate themselves on a scale of:
which the engineers I asked said they found this system helpful because it was more specific than a number between one and ten.
A good ‘engineer lifecycle management’ policy can also help. Sometimes this includes discussions and offering progression in the organisation, but sometimes this also means being open to people leaving for pastures new to learn and grow safe the knowledge that, should a position be available, they will always be welcomed back. If the progress of the team is being managed well, there is a good chance some of the engineers will want to come back. This also means deciding who should/can be a manager or team lead, who can be a ‘10x engineer’ (an engineer so highly skilled they can do the work of 10 with the right training and structure), who works well on a team, who is better left alone, and who has skill and competency supporting sales and meeting clients. Having paths open to non-people management skills that are still management can help. This can include Product Owner and Product Manager, Sales, Account Management, Project Management, and Technical Architect.
Another important part of team balancing is dealing with scalable team sizes. The Spotify Squad Model seems like a very sensible way of organising teams (despite its shortcoming it is still being used a number of places outside of Spotify), although I am accustomed to the Jeff Bezos “Pizza Size Model” where you break teams down into functional units with each unit being no larger than can be fed with two large pizzas (Jeff Bezos popularised this model). It is worth noting that this rule includes management teams as well!
Progressing and balancing a team also means doing more than paying lip service to diversity and inclusion. Diversity and inclusion are a big topic and covers a lot of different elements:
It is also important not to exclude people with your diversity policy. For example, be mindful that trying to specifically attract women (for example) may lead to BAME engineers feel like they are not being valued. Diversity and inclusions are not only important for their own sake, but they also bring an important value to the balance of the team, your product, and to innovation. Innovation and progressing the technology is very difficult with a staff of like-minded people who all think alike!
As an executive tech leader, you need to make sure that the teams you manage are evolving, moving forwards, and maintaining a balance of skills, personalities, and outlook.
While the product is at the core of everything we do, we are doing it for money. Even if our product has a Massive Transformative Purpose (MTP) that will change and enhance the world, without an economic basis it will not succeed. If the product is not creating value for your customers, the company is not creating value for the shareholders and your executive leadership will soon end!
Controlling the budget means ensuring that the whole technical team is creating value, both individually and collectively. In a mature company, each engineer should be earning the company at least three times their salary (and they generally cost 1.5 times their salary). In software, this can be very difficult to gauge but like all budgeting, most of the battle is in the tracking. An executive technical leader should know the cost of everything in their domain, including an idea of the cost of a Sprint (if you are working in Agile), the cost of a feature, the cost of your hosting and every other technical cost such as software, hardware, and connectivity. Each of these costs should be tracked and monitored regularly. Poor tracking of hosting (often the most expensive cost after salaries) on cloud services such as AWS can quickly lead to spiralling costs (more about this below).
Controlling the budget means recognising where the false economies are. Cheapest is not always the best option, and neither is most expensive. Every cost and every spend needs to be looked at with the cold light of ‘value’. If it is not creating value, then it is not worth the spend. Sometimes the value is obvious: spending so much on a new Integrated Development Environment (IDE) will help with productivity and sometimes they are less hard to track (training budgets are a good example!), but every spending decision you make needs to be tracked and evaluated.
Most software companies will spend the lion’s share of their budget on tech salaries, followed by hosting or hardware costs (depending on business model). If you host on cloud services like AWS, the possibility of costs spiralling out of control is high as mentioned above. With good technical architecture and smart use of technology, hosting costs can drop from millions a month to hundreds of thousands a month. AWS (and I imagine others as well) will often work closely with you to help reduce costs if you ask them to.
If you are progressing the product, progressing the technology, progressing the team, and using a well-defined methodology for development like Agile, you should not need to directly monitor the output of your team through cumbersome time tracking technologies. However, a “CTO Master Plan” spreadsheet which includes the overall cost of the tech team (or team member if there is only one team), what they are doing, and for how long is a good way to monitor costs.
Along with the four pillars, there are a few notes worth considering. As with any leadership, an executive technical leader will need to manage the CEO, Board of Directors, and/or shareholders. They will need to manage their own managers and teams. They will need to manage across to other executives and managers, to be the voice and, most importantly, the champion of the technical team across the organisation. This falls broadly into “progress the team” but deserves special mention because the team you are managing is not your team, but the company-team as a whole!
Being a leader means holding yourself to a higher standard, which means being ruthlessly honest with yourself, fearless and forthright even when it scares you. You will need to progress yourself! If you are not at least occasionally feeling like you are going to throw up because you are doing something that scares you, you may need to ask yourself if you have become complacent and too comfortable! Imposter syndrome (where you doubt your own ability) is real and across most positions. Being in a leadership role means accepting your self-doubt and not compensating through arrogance or pride, but rather accepting who you are, building on your strengths. It means being honest with yourself and humble enough to know when you need to ask for help! This help can come from the people you manage (hopefully your balanced team includes plenty of people that are much better at certain elements of your job than you are!) from mentors and from literature.
More importantly, Imposter Syndrome makes people feel scared and stops them from communicating. None of the pillars will stand without communication and indeed good communication is vital to all four columns. You cannot control the budget without knowing the figures, you cannot progress the team without knowing them, you cannot progress the technology without having a continuing dialogue about what is new on the horizon and you can’t progress the product if you don’t know what it is!
Being an executive technical leader means that you are responsible for something greater than you can control yourself. It means being part of a team, but also influencing that team more than anyone else. There are many challenges, and the reward is that you get agency over the strategical technical direction of your company, and if you take care of the four pillars, you will:
This combined with solid communication, good strategy, and tactics (using the 6x6x6 model) and holding yourself to a high but realistic standard will give you a solid foundation to build on. Good luck.
Resources
If you need to improve your customer engagement, talk to us and we'll show you how AI automation via digital messaging apps works. You will love the Webio experience. We promise.
Talk to us about Conversational AI
