{"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

Ad-hoc<\/h1>\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

Advantages<\/h4>\n