{"id":12203,"date":"2016-09-23T14:57:51","date_gmt":"2016-09-23T11:57:51","guid":{"rendered":"https:\/\/mozaicworks.com\/?p=9629"},"modified":"2016-09-23T14:57:51","modified_gmt":"2016-09-23T11:57:51","slug":"product-strategy-technical-strategy-practice-iii","status":"publish","type":"post","link":"https:\/\/mozaicworks.com\/blog\/product-strategy-technical-strategy-practice-iii","title":{"rendered":"Product strategy: technical strategy in practice (III)"},"content":{"rendered":"
This is the last blog post in the series about technical strategy in practice. The first post<\/a>, I’ve detailed what is technical strategy and why is important. In the second<\/a> 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.<\/p>\n Even if I’m an experienced CTO, it\u2019s time for the consultant answer: it depends. I\u2019ve 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).<\/p>\n Let\u2019s 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\u2019s a Ruby developer, so she starts developing in Ruby. You\u2019ve just made your first technical, strategic decision without realizing it!<\/p>\n 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\u2019t fully understand. They just made another technical, strategic decision!<\/p>\n Like any model, this one has advantages and disadvantages.<\/p>\n This model works reasonably well with\u00a0small development teams<\/b>\u00a0consisting of very good developers\u00a0who understand not only the short-term needs but also the medium-term requirements.\u00a0<\/b>In other words, it works well with very good developers who also have strategic planning skills.<\/p>\n From the outside, it looks like a very chaotic approach \u2013 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.<\/p>\n In this model, one or more people are responsible for the technical strategy. There\u2019s a triad of roles, with similar responsibilities but on various levels:<\/p>\n It\u2019s easy to think about this model as a top-down, hierarchical approach. It doesn\u2019t 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,\u00a0a good CTO, software architect or technical lead finds time to sit down and pair with developers<\/b>.<\/p>\n 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\u2019t 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.<\/p>\n 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\u00a0developers 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\u2019s easiest, with few people and less code. Identifying strategic thinking skills are key in this case.<\/p>\n Larger companies use this model to a certain extent, although my experiences have been mixed. The decision to appoint someone as \u201csoftware architect\u201d 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.<\/p>\n You have a technical strategy today, whether you know or not. It\u2019s 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\u2019t have it explicitly formulated, it is difficult to analyze and improve it. The simplest one is \u201cdo whatever, and throw money at the problem later\u201d.<\/p>\n 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.<\/p>\n 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<\/a>\u00a0for more information.<\/em><\/p>\n Photo source<\/p>\n Check below the other 2 articles from this series:<\/p>\nAd-hoc<\/h1>\n
Advantages<\/h4>\n
\n
Disadvantages<\/h4>\n
\n
Caveats<\/h4>\n
CTO, Software Architect, Technical Lead<\/h1>\n
\n
Advantages<\/h4>\n
\n
Disadvantages<\/h4>\n
\n
Caveats<\/h4>\n
Conclusion<\/h2>\n