In my first years of working as a developer, I dreaded a few words like \u201cmarketing\u201d, \u201cexciting\u201d, and \u201cstrategy\u201d. And for good reasons: most times they were void of meaning.<\/p>\n
A few years later, as a technical lead, and later as a technical coach, I learned that the lack of meaning in the words \u201ctechnical strategy\u201d hides a deeper truth. If there is a technical strategy, it\u2019s often not clear to developers. If there isn\u2019t one, I can tell in the first 42\u2032 of conversation.<\/p>\n
In a series of three articles, I will share more about what I think technical strategy is, why it\u2019s useful, how to start building one and who is responsible for creating it. In this part, I\u2019m tackling the first two subjects: what is technical strategy and why it is important.<\/p>\n
There are many definitions for strategy, but I like to explain it in simple words. The simplest explanation I found is:<\/p>\n
A strategy is a set of decisions that influence more people over a longer period of time and that are typically very difficult to overturn.<\/p><\/blockquote>\n
Let me give you an example from programming. How you decide to implement a private function today might affect you and a few other people. Moreover, any of your colleagues can change it. The decision to use _your favorite technology here_ affects all the developers for the lifetime of the product and requires considerable effort to change. The first is a tactical decision, while the second is strategic.<\/p>\n
There is a gray area between strategy and tactics<\/b>, as you can see from the explanation. It\u2019s ambiguous what \u201cmore people\u201d and \u201clonger period of time\u201d and \u201ctypically\u201d mean. Is \u201cmore people\u201d two people, 10, 20 or 50? Is a \u201clonger period of time\u201d two weeks, a month or 5 years? Is \u201ctypically\u201d 90% of the time or 95% of the time? You should get used to these types of ambiguities if you want to understand strategy and tactics; reality isn\u2019t as neat as programming. Strategy and tactics intersect and influence each other all the time<\/strong>, something you should keep in mind if you expect to make only strategic or only tactical decisions.<\/p>\n
The technical strategy is nothing more than strategy applied on technical decisions<\/b>. Yet again, reality kicks in and things aren\u2019t so neat.\u00a0Strategic technical decisions<\/b>\u00a0are not only about technology, they\u00a0are heavily influenced by the other functions of the business<\/b>: marketing, business development, financial, product etc. They result from a dance between various needs, constraints, and concerns of the world around development.<\/p>\n
Why is the Technical Strategy Important?<\/h1>\n
The short answer is:<\/p>\n
If you don\u2019t make strategic decisions, someone else will make them for you, and they might not be the best for your business or product.<\/p>\n
Here are a few\u00a0examples of decisions to make for the product<\/b>:<\/p>\n
\n
- The\u00a0technologies used and the infrastructure<\/li>\n
- The modules structure and communication<\/li>\n
- How code is written; new developers will have to change it or live with it<\/li>\n
- The\u00a0source control system and the bug reporting tool<\/li>\n
- Whether it\u2019s OK to work from home or not, and this will influence the tools used.<\/li>\n<\/ul>\n
Someone needs to make these decisions. C<\/strong>an you make them so you don\u2019t waste a lot of time and money<\/b>\u00a0with their aftermath? Or are you OK with throwing money at the problem (maybe rewriting the product completely) when it\u2019s successful?<\/p>\n
Either way, someone needs to make a strategic decision. Then there\u2019s the issue of skills.<\/p>\n
When it comes to strategic thinking, not all people are equal. Our experience shows that it\u2019s not an innate trait; it\u2019s a trained one. It\u2019s hard to say where it comes from, but we suspect a mix of experience, deep analytical skills, and lots of personal exploration. In addition, the person making these decisions has to be relatively comfortable using partial and incomplete information. In today\u2019s world, there\u2019s no time to try and develop the same product in 5 technologies to see which is the best. These experiments tend to be limited to very specific parts of the code.<\/p>\n
It doesn\u2019t have to be one person. With good facilitation, a group of smart people can make better decisions than any one of them. This requires facilitation skills from someone in the team or an external facilitator (brought from a company like Mozaic Works).<\/p>\n
Is your company investing in building a technology strategy? Let us know in a comment how it helps the product success.<\/p>\n
Check below the next 2 articles from the series: \u00a0focusing on what a technical strategy should contain for a specific product and who creates it.<\/em><\/p>\n
Product strategy: technical strategy in practice (II)<\/a> – what a technical strategy should contain for a specific product \u00a0Product strategy: technical strategy in practice (III)<\/a> – who creates the technical strategy<\/em><\/p>\n