This is the last blog post in the series about technical strategy in practice. The first post, I’ve detailed what is technical strategy and why is important. In the second one, I’ve described how a technical strategy should look for a specific product. In this article, I am going to share more about who creates the technical strategies.

Even if I’m an experienced CTO, it’s time for the consultant answer: it depends. I’ve encountered two models in my career that I can share. These are obviously not the only possibilities, but for now, let’s discuss these two: ad-hoc or defined role(s) (usually CTO, Software Architect, or Technical Lead).

Ad-hoc

Let’s say you have an idea for a product, but know nothing about programming. You search for a technical co-founder and find someone who seems like the best fit. She’s a Ruby developer, so she starts developing in Ruby. You’ve just made your first technical, strategic decision without realizing it!

You then manage to raise some money, hire more developers. They start bringing their ideas to the table and decide to use a microservices architecture for some reasons you don’t fully understand. They just made another technical, strategic decision!

Like any model, this one has advantages and disadvantages.

Advantages

• The technology fits your developer’s skill set and interests, potentially increasing motivation.
• Developers are in charge! They like that, and will advertise it to their friends, communities, etc., potentially enlarging your hiring pool.

Disadvantages

• Not all developers have the experience and communication skills to think through and clearly express such decisions.
• Developers who feel their voice is not heard might leave the company.
• Without good facilitation, the decisions are made based on who knows how to argue better, and not necessarily on the best interest of the business.

Caveats

This model works reasonably well with small development teams consisting of very good developers who understand not only the short-term needs but also the medium-term requirements. In other words, it works well with very good developers who also have strategic planning skills.

From the outside, it looks like a very chaotic approach – but this is not necessarily a bad thing. As long as the results are great, the model works. The big issue is what to do when suddenly development slows down, bugs appear, or customers complain. Many businesses in this situation decide to hire a manager, who then starts introducing structures and tools that typically result in the best developers leaving the company. Instead, patience, root-cause analysis, facilitation, and consulting can help fix the root cause of problems while preserving the culture.

CTO, Software Architect, Technical Lead

In this model, one or more people are responsible for the technical strategy. There’s a triad of roles, with similar responsibilities but on various levels:

• CTO – makes decisions on the practices, tools, technologies used in the whole company
• Software architect – decides on practices, tools, technologies used in a certain product or product suite
• Technical Lead – decides on practices, tools, technologies used in a team

It’s easy to think about this model as a top-down, hierarchical approach. It doesn’t have to be that way. People who have good strategic planning skills know that one of the most important sources of information for decisions is feedback from people doing the actual work. In fact, a good CTO, software architect or technical lead finds time to sit down and pair with developers.

Let me repeat that, because it is very important. Making a strategic decision in a vacuum or by taking into account only the business needs doesn’t lead to good results. The only way to understand what is going on in development is to sometimes sit down with developers and write some code.

Advantages

• Skill match: people who have good strategic decision skills make the strategic decisions
• Potential for more clarity, given that the strategy is communicated well
• More time for developers to focus on what they like: writing code

Disadvantages

• Human nature: it’s easy for people in leadership positions to start thinking they are always right and wield their power
• Trust erosion: in time, the triad might lose developers’ trust, leading to rebellion (in the form of “yeah, yeah, we’ll do what we think is right instead of what you say”)
• Single point of failure: so much responsibility on one person can lead to stress that can lead to bad decisions.

Caveats

This model works fine when the triad has the right skills, knows how to gain and maintain the trust of developers, communicates effectively and knows how to involve developers in the decision-making process. Although this seems a bit unnatural for startups, it can work very well; defining responsibilities from the beginning allows the people involved to learn the job when it’s easiest, with few people and less code. Identifying strategic thinking skills are key in this case.

Larger companies use this model to a certain extent, although my experiences have been mixed. The decision to appoint someone as “software architect” is based on their results as a programmer, rather than on their strategic thinking, communication, and collaboration skills. Yet the latter are much more important for a software architect than for a senior developer.

Conclusion

You have a technical strategy today, whether you know or not. It’s a set of decisions that someone made in the past, and which affect most of your developers for a long period of time. The strategy could be very explicit, or it could live in the minds of the developers. As long as you don’t have it explicitly formulated, it is difficult to analyze and improve it. The simplest one is “do whatever, and throw money at the problem later”.

More complex strategies involve one or more of code quality, configuration management, architecture or testing. We will be tackling this subject in the next articles.

Are you planning to develop a technical strategy or you would like to improve the existing one? We can help you out. Our coaches have successfully helped many teams to build their strategy. Contact us for more information.

Photo source

Check below the other 2 articles from this series:

Product strategy: technical strategy in practice (I) – what it is technical strategy and why is it important 

Product strategy: technical strategy in practice (II) – what a technical strategy should contain for a specific product