Welcome to the digest #3 of my "Technical Leadership and Architecture insights" (or TLA_insights for short).

light

This is a special "aggregate" issue of TLA_insights focused on "Tech Vision and Strategy", especially on the topic of "Setting and Operating" or "Life-cycle" of Tech Vision and Strategy (yes, I see it as a cycle that should be continuously operated).

"Aggregate Issue" - yet another pivot on TLA_insights format, where I put together ("aggregate") a series of TLA_insights records on a specific topic. The idea is to create a sort of "state-of-the-art" overview on a given topic, while also bringing some consolidation and insights from my side.

This topic is still a bit "mystical" (as Will Larson, a reference in this issue says): people/orgs approach it differently; a lot of special ceremonies and overhead is put into it; many times people in the tech organization don't embrace it as they don't understand why it is important for them or how it enables them; and worst of all, and the most common pattern: approach it as a "one-off" thing, built top-down as a long document done once a year, which is "skimmed once" and then forgotten.

I have selected several interesting references to shade some light on the issues mentioned above and explain:

  • Why is it important (in a nutshell "it enables aligned and accelerated technical decision making by teams in the organization");
  • How to approach it (i.e.: how to build it, but also "operate it" - as to maximize its potential it should not be a one-off thing, it should be a continuous process embraced by the whole technical community);
  • What it can look like (i.e.: important sections and elements to make sure this is an effective and used resource);
  • When to do What (i.e.: the cadence for activities and time-windows to consider, e.g.: Vision should target a multi-year window to provide safety on longer-term decision making, while a lot of tactical strategies will target shorter term and are much more concrete and scoped - still contributing/aligning with the longer term vision).

I hope you enjoy this special issue and stay tuned as I will be publishing follow-up material on this topic (new entries on this "aggregate", and an article on the topic with my own views and consolidation of the insights gathered from these and other resources).

On a personal note: last 2 months were very busy, but also very interesting on topics relevant to TLA_insights (especially on the "Technical Leadership" area):

  • I became "Principal Tech Lead" at bol.com (the largest online shopping platform of Netherlands and Belgium). I am leading the official kickstarting of Tech Lead function in the organization. Bol.com has had "unofficial" Tech Leads (or Software Architects) organized in a rather "ad-hoc" manner for a good while. However, with the very fast growth we have been going through over the last 5 years or so, that model was not scaling well anymore, so we have introduced Tech Leads as an official function with clearer "areas of responsibility" and empowerment. We are positioning them as "Enabling Teams" (as in Team Topologies), and their mission is to maximize the potential of the product teams they work with and create an explicit network of knowledge and technical enabling in the organization. (I have an article on the pipeline to share Why we took this decision, What it looks and How we are approaching setting up this "team" or "network" of people on our product-led organization).
  • Related with kickstarting the Tech Leads at bol.com, we have also had the honor of having Pat Kua giving us his "Shortcut to Tech Leadership" virtual training. Pat Kua has been an inspiration and reference for me as Tech Lead for more than 5 years now, and it was great having him sharing a lot of insights and tools for our new Tech Leads (most of them been working as Engineer - "Maker" role, and now transitioning to a Tech Lead - "Multiplier" role, which is the exact focus of this workshop by Pat). Highly recommended to help new Tech Leads, but also to experienced Tech Leads (as a way to consolidate and organize the many things being a Tech Leader involves).

If you found this issue interesting or useful make sure to subscribe to the newsletter or follow-me on twitter so you get notified of new records in this topic and other TLA_insights areas. I hope you have fun and find some interesting insights here. Don't hesitate to contact me if you have questions or want to chat about these topics.

TLA_insights digest #3 - "Tech Vision and Strategy"

light Tech Strategy: You Need it, But What is it?, Nick Tune

Great article by Nick Tune that touches on the "Why" ("the need") of Tech Strategy within (tech) organizations and "What" exactly that can look like to enable the desired effect - technical alignment and velocity.

Tech Strategy, why you need it and what it can look like (in the form of a multi-level approach: enterprise > departments > products).

record overview | 🔗 record

[Article]

light My Insights: Tech Strategy is a rather ambiguous term and construct in most organizations and for most people. This has many reasons, but the fact is all organizations have a Tech Strategy (like they have a Software Architecture): sometimes it is explicit and people "see it" and align to it, sometimes it is just an non-explicit thing that exists but is interpreted differently by different people. This last form is very risky and most of the time does not enable to maximize the alignment of the different parts of the organization. That leads to incoherent and conflicting decisions, e.g.: different teams working in extremely different tech stacks, or owning non-essential infrastructure platform systems, among many other things. Having clear (enabling and non-blocking) Tech Strategies is very important for organizations to optimize their "operating model" and how to support their teams on best building their products. As discussed in the referenced article (by Nick Tune), these Tech Strategies may be defined at different levels of abstraction, e.g.: an Enterprise wide Tech Strategy, to provide the "core elements that are common to all the products and teams in the whole organization"; and then have more specific strategies per departments (if needed) and products (as they are almost always at different levels of development and deal with different customer challenges). This enables people to be aligned, and if well defined will not block teams autonomy to take the best decisions on their particular context, but enable them to take those decisions more easily. Furthermore, and essentially: Tech Strategies should be defined to drive the Business Vision and Strategy, i.e.: should not be a pure "technical exercise" but a supporting construct to enable the end goal/ambition of the organization, i.e.: they will change overtime and must adapt/evolve to match each other.

(Subscribe here to get notified about new TLA_insights)

Analysis & Summary

These insights and notes are focused on Tech Strategy, and are driven by a great article by Nick Tune that touches the "Why" ("the need") of Tech Strategy within (tech) organizations and "What" exactly that can look like to enable the desired effect - technical alignment and velocity.

"Tech Strategy" is a term we hear often, but the way people scope and define it can be rather different (and most of the time ineffective on its implementation). The most common pattern I see is this being a (long) document created purely by higher-level leadership as a "one way communication channel" to address high-level concerns and governance of Tech developments in the company. What is the issue with that? That it becomes "yet another document" that (maybe) is read once, shares "aspirations" and creates some awareness, but does not truly connect to the veins of the organization - i.e.: people don't adopt it as an effective reference/north-star on their technical developments.

Nick does a great job on sharing ways to start addressing these concerns and effectively define a Tech Strategy that can create alignment (i.e.: common direction) for the different tech activities within the org. His proposal consists of a multi-level model to define and implement/operate Tech Strategy in organizations, namely:

  • Enterprise level Tech Strategy
  • Business/Department level Tech Strategy
  • Product level Tech Strategy

Enterprise-level Tech Strategy focuses on the most foundational level of Tech Strategy. It provides a base and guidance for all the other Tech Strategy levels. This level may contain different elements and sections, namely:

  • Business and Organizational Context: starts with a clear positioning and understanding of the "business and organization context", i.e.: the purpose and goals behind the business and/or product(s) we are building. This should be a strong driver for the Tech Strategy (i.e.: "the Why" behind defining a certain Tech Strategy). If there is no clear understanding of the business behind, the Tech Strategy is "not grounded" (as Nick mentions: "if you can't communicate the problem you are solving, you probably should not be creating a strategy").
  • High-level IT Vision: defines the technology vision that will enable supporting business/products vision and strategy. This section may be rather "high-level vision", focusing on the big elements, which provide a "north star" for the different strategies being defined.
  • Current IT Landscape: this presents an overview of the current IT landscape. Make explicit how our current landscape looks like, so we can start seeing how we can move from "as-is" to the "high-level IT vision" (the "to-be" situation). This section may also list challenges we are facing on the current landscape.
  • Proposed IT Landscape: depicts an overview of the vision for the landscape, justifying the proposed vision and how the different elements that define the desired target state. A recurring issue in this part (as Nick mentions) is the lack of attention to "organizational setup" that will be building and owning those the depicted target IT landscape (yes, this is Conway's Law - i.e.: the organizational and technical components/systems must be aligned). Another important point in this section is: we want to provide some clarity on the most foundational elements of the IT landscape, but not be too prescriptive - i.e.: "Ivory Tower Architects".
  • Who creates this strategy? This is a great question and one I do not have a clear answer. I do agree with Nick: "responsibility for enterprise-level tech strategy resides with senior IT leaders". However, we should involve people that can understand and work with all those parts to bring together a strategy that enables them. Involving can be done in different manners, and does not mean this makes people involved "responsible".
  • Who is it intended for? This level of Tech Strategy is normally intended for "everyone". Example: it allows "middle management" to have guidance, but also provides clear guidelines/direction for teams building applications/systems and taking decisions on how to evolve them.

Business/Department level Tech Strategy addresses strategies targeting particular elements of departments/parts of the company. This level contains things such as:

  • Agreements and alignment regarding policies, standardizations and how the teams in the department plan to move in terms of technical strategies.
  • These strategies should touch on elements to drive technology decisions, but also processes, people and priority setting (i.e.: be a sort of framework that enables people navigate through their decision making processes within a given business department).
  • Who creates this strategy and who is it for? In general someone within an IT leadership position within that department or business unity (with the involvement of people from different parts, including the people that are going to use this). This document tends to be targeted to the people delivering the work, i.e.: it is a sort of blueprint or guidebook acting as alignment across the different teams.

Product level Tech Strategy entails specific elements for a product within a department:

  • Having Product-level strategy is very important as different products require different strategies, e.g.: some products may be greenfield - and allow for different technical solutions to be crafted; while many times products are in place and have certain teams and ways of working, which impose specific constraints and conditions on the strategies for them.
  • This is a key strategy level in modern product-led organizations to enable products to sharpen their strategies to the particular challenges of the product. To enable that, the enterprise and department strategies should really be lean and focus on creating guidance/accelerate teams on elements that are common to all products, while not block innovation on the developments of products.
  • Tech Strategy at this level tends to have good architectural diagrams to help show where we are and where we want to go. Furthermore, it will also provide clear guidelines on "practices" recommended, in order to have alignment across the different teams that are contributing to building the product.

Nick finishes with this question: "So what is Tech Strategy and When do we need it?

  • In his own words: "Tech strategy is a collective set of non-trivial decisions created to guide the use of technology and related factors in order to achieve business or end-user outcomes. It involves not just technology choices, but process, organization design, and cultural elements."

Some extra remarks:

  • It is about "alignment" and "guidance" to navigate "decision making" processes, and that is why it is so important to have different levels of granularity - to align across company, per department and per product.
  • It can have different forms, it is not an exact science. The important thing is to "set clear game rules and language" at the start and have a clear understanding of the "Why" for the Tech Strategy. This can vary from company to company, but in general it should be linked to the business/product strategies and vision, as a way to enable them.
  • Tech Strategies at the different levels evolve, like anything within organizations. Given this, don't write your strategies on stone, but create feedback loops/mechanisms to continuously observe your org, and take that knowledge and insights to "calibrate" the Tech vision and strategies.

InsighTweet



light Defining a Tech Strategy, Sarah Taraporewalla

Elements to consider when creating what Sarah calls "The Strategy Document". What I find refreshing in this article is that Sarah does not stop on the writing of the document, but goes on and makes great remarks on the execution of the Tech Strategy (namely: how to go about distributing it and even more importantly "continuously improving it over time").

Tech Strategy is not a project, it is a product: continuously improved and calibrated based on learnings. Goal: create more alignment and a clearer framework for decision making for teams / org.

record overview | 🔗 record

[Article]

light My Insights: In modern ("Agile + DevOps + Product-led") organizations there is a tendency to not spend time/efforts looking ahead more than a few weeks in time. While I fully agree with driving our developments incrementally based on discovery with customer, I see a lot of waste and misalignment due to the lack of longer term vision and strategy on how teams take decisions on how to build their products (and platform supporting them). This is where a clear Tech Vision and Strategy can help. Tech Vision and Strategy should be enabling, grounded and realistic, so that it empowers teams to take faster and better decisions. With this teams should be achieving better outcomes, while still have freedom to find the best approach for their specific product/challenge. A key trait to achieve this is to stop treating Tech Strategy as a (one-off) project (done purely top-down), it should be treated as a product that we continuously improve and calibrate based on our learnings (mixing top-down and bottom-up perspectives). Another very important and challenging element is to create conditions to make sure it is properly executed/operated, i.e.: making sure it is usable by teams and it captures the needs of teams and business, etc. To achieve that I strongly believe that companies need to have strong enabling people/teams/communities (e.g.: Architects and/or Tech Leads) that take more explicit ownership on "maintaining" this in close collaboration with teams and leadership.

(Subscribe here to get notified about new TLA_insights)

Analysis & Summary

The notes and insights of this record are driven by an article by Sarah Taraporewalla, which focuses on elements to consider when creating what Sarah calls "The Strategy Document". What I find refreshing in this article is that Sarah does not stop on the writing of the document, but goes on and makes great remarks on the execution of the Tech Strategy (namely: how to go about distributing it and even more importantly "continuously improving it over time").

The article has three main parts: Purpose; Format and Distribution, which should provide a great guidance for people looking at insights on building a Tech Strategy document.

Purpose: this part starts with a clear statement on how tech strategy supports the business strategy. From there it focuses on setting a clear framework for alignment and effective technical decision making. To accomplish that purpose several elements need to be considered, namely:

  • Values, principles and guidelines to inform architecture and decisions.
  • Architecture vision and (an idea of the first steps on the) roadmap to that vision.
  • Cross-Functional Requirements (or Non-Functional Requirements - interesting fact, Sarah was the person that coined the term "Cross-Functional Requirements"). This defines guidelines to assess how we should operate our systems.
  • Architecture Operating Model, which provides a framework to support the elements of the Tech Strategy in a continuous manner.

All these elements will evolve (i.e.: should be continuously updated). However, Tech Strategy should provide enough direction without requiring continuous review and updates (e.g.: should be sufficient enough to support teams for six months). Sarah recommends revisiting Tech Strategy quarterly to remind teams of the direction and update it with what we have learned from implementing the Tech Strategy. Furthermore, it also should be kept aligned with the Business Vision and Strategy - i.e.: Tech Strategy should be a living document.

Notes: I strongly agree more with this "evolutionary" positioning and see its neglect as one of the major points companies fail on truly executing and benefiting their Tech Strategies. Organizations are "living and evolving systems", if our Tech Vision (North Star of alignment of the different teams and developments) and Strategies (concrete initiatives we define and execute to move towards our vision) are not "calibrated" based on that evolution (i.e.: the learnings we gather and observe) we will be operating in a sub-optimal setting. Sarah mentions "six months" of support for teams, I do agree that is a great goal for "near-future strategies", but we should also have clearer longer-term vision and strategies in order to enable more clarity and alignment for a longer period of time (this is very important to support decision making on developments that are more complex).

Format: Sarah recommends "wordy document instead of a slide-based approach". The main reason is that such a document (with proper images, tables, etc.) can stand on its own and people can quickly understand it without having to have someone explaining it when needed. This also becomes an excellent tool for onboarding new people. Overview of proposed sections:

  • Executive Summary: few clear sentences on the title page to explain the main points of the tech vision and strategy. Additionally highlight the changes in the latest version, compared with previous (so people can quickly understand the "diff").
  • Purpose: clear statement of the goal of the document - to make sure there are no misinterpretations.
  • Business Strategy: contextualize the business/product vision and strategy in order to see how the Tech vision strategy can be shaped to best support those.
  • Tech Vision: "elevator pitch" for "where we want to go", i.e.: this is our "North Star", and "Why" (how to connect to the previous points).
  • Architecture Vision: provide an overview of the current state we are (including diagrams), the target state we want to move to and some guidelines on the first steps to move there. Important to take an evolutionary architecture approach, i.e.: assume changes will take place and we should not define a hard end-state but calibrate as we learn more.
  • Cross-Functional Requirements (CRFs) : specify the CRFs/NFRs to help understand and judge how our systems should operate in Production. This provides base-lines for CFRs cross-organization and features implemented on different parts/products should adjust according to their particular requirements.
  • Tech Radar: Tech Radar can be a great way to provide a balancing act between autonomy and consistency across teams in the organization. Tech Radar enables discussion on the technology portfolio used in the company, and with that there is an alignment and knowledge exchange between people in the org. The result is a clearer statement on the tools, technologies, techniques and platforms used in the organization.
  • Architecture Operating Model: an approach and framework to support the architectural decisions ("the important decisions") and direction. This makes several elements explicit (e.g.: roles and responsibilities, WoW, decision making process, decision tracking, etc.), which helps in the execution/operation of the Tech Strategy.

Notes: I fully agree with Sarah on the need of an operating model to make things explicit, integrated on the veins of the organization as a way to support the decision making process. To me this is one of the major problems in most Tech Strategy docs - they are just docs and don't get into the organization operating model. The result is: they are read once and then forgotten (until next year, when a new document is written from scratch), which does not yield the impact we want.

Distribution: avoid the endless perfectionism, create a "minimum usable version" and release it (it should be usable and not generate more questions than alignment!). Fact: it will (should) change in time, and as such will be iterating and improving it (with new learnings). Sarah shares some good pointers to "go live":

  • start with a public presentation to the teams that will use it;
  • follow with an email with a copy and then add the document to the teams Wiki/Confluence/etc. (make sure there is a single location where we keep the versions of the doc we produce - with the changes we make);
  • iterate as needed and share the changes so people can "update" their view on it.

InsighTweet



light GitLab Strategy Operating Model

Multiple "open resources" from GitLab used to provide the company with an aligned "direction and strategy" for their organization and product development. In this article I mostly focus on the general principles behind the company and product vision and strategy. However, these can be easily extended and used to define Tech organization vision and strategy.

Strategy is a continuum, but we can define a cadence of alignment periods to set where to focus & which actions (eg: work on "Values" to enable the 10 year vision; OKRs to align with 1-year plan).

record overview | 🔗 record

light My Insights: defining company and product (or Tech) vision and strategy is just one part of the equation. Many times people forget about the goal of such activities, which is (in my view): to help the company to understand where to move to ("the vision") and (in different time-windows) what strategies and/or plans to move forward in order to take steps towards that vision. GitLab has a rather explicit approach to comprehensively address this, which I find very refreshing. They define clear time-windows and a cadence of activities per phase. This is key and crucial, as we cannot have the same type of actions/activities on a 1 year time-window and a 10 (or even more 30) year window. In far future time-windows (e.g.: 10 or 30 years time) we plans make no sense (the world is a "Chaotic System" - as in Cynefin [Cynefin], so you "cannot" plan in such time-windows). However, that does not mean we can set a "vision" and/or "north star" to set a common long-term goal/direction for the whole company and product. Furthermore, there are things we can work on in the present to enable moving towards that vision. These tend to be "Values" and foundations for growth, which don't necessarily need a clear plan for a 30 year window. The shorter term strategies, e.g.: 3 year strategies, are much more closer to plans of action. For these we can define "strategic themes" which are more specific and zoom-in into the specific topics to work on the product development in coming years. With that, we can (for example) yearly define even more concrete investment plans, which then can be aligned by the whole company in a regular fashion (e.g.: Quarterly via OKRs and measuring KPIs that enable assessing progress). This connected strategic approach with the right sort of action/focus per period is a powerful tool to enable developing and moving forward as a company and product - i.e.: defines a sort of "Strategy Operating Model".

(Subscribe here or follow me on Twitter to get notified about new TLA_insights)

Analysis & Summary

The insights and notes of this record are inspired and driven by multiple "open resources" from GitLab used to provide the company with an aligned "direction and strategy" for their organization and product development. In this article I mostly focus on the general principles behind the company and product vision and strategy. However, these can be easily extended and used to define Tech organization vision and strategy.

GitLab is a truly inspiring company: they are fully remote and extremely open on their strategies and ways of working. Sid Sijbrandij (GitLab's CEO) shares [GitLab-Open-Strategy] that this "Open Strategy" is key to enable customers to understand "why certain choices are made" and this explicitness is key to make clear to everyone around the world working at GitLab what are the important things to focus on. This is very explicit on this statement at the bottom of their Strategy page [GitLab-Strategy]:

Our strategy is completely public because transparency is one of our values. We're not afraid of sharing our strategy because, as Peter Drucker said, "Strategy is a commodity, execution is an art."

In the following I will share some notes on some core documents GitLab used to shape and operate the vision and strategy at GitLab.

GitLab Strategy [GitLab-Strategy] document defines core elements of the "operating model" for the company with respect of company strategy. It specifies the Why, What, How and When elements on different strategic time periods/windows in the future.

GitLab Strategy

(Credits: GitLab Strategy page [GitLab-Strategy])

  • 30 years: Mission
    • Why: sharp motivation for GitLabs existence: "everyone can contribute".
    • What: focus on the Mission (long term vision for the company, sort of "North Star"). This is a really inspiring message ("when everyone can contribute... we greatly increase the rate of human progress"). To achieve this mission GiLab further defines what they call a BHAG ("Big Hairy Audacious Goal"), which basically puts down a very their 30-year audacious goal ("in the next 30 years become the most popular collaboration tool for knowledge workers...").
    • How: to step towards this (really) long-term mission (~30 years in the future) GitLab focuses on "Values", i.e.: the "heart and blood of the company". This is the sort of thing we can focus and (with high level of confidence) develop now in order to step towards that long-term mission. I find this a very strategic and pragmatic approach, as at this time-window you cannot make plans, the level of uncertainty is just too high (i.e.: plans at this time-window tend to be "wild guesses" → waste!). So, focusing on creating strong Values to drive how you operate your company is your best "bet".
  • 10 years: Vision
    • What: at this time-window GitLab defines "Vision" and "Goals". (Product) Vision is a paragraph statement for the "target state" envisioned for the Product ("single application... that enables everyone should be able to afford and adapt... everyone can contribute"). Then the Goals section defines a list of more concrete points, which sort of defines the "strategic areas" for the company and product to focus on.
    • How: to scope and enable stepping towards that vision GitLab defines a series of core elements that provide context and scope for this 10 year product vision. For example, it details the view on "Everyone can Contribute", "Customer Acceptance" but also clear statements on the fact that the market is evolving and also risks around the product. All in all, the "How" at this time-window focuses on scoping a bit further the direction for the product development, while having room and clear that this is not yet specific enough, so it also has clear statements on managing risks and leaving room for "maneuverability" to cope with the market and forces around the product.
  • 3 year: Strategy
    • What: defines the specific 3-year strategic goal ("become the leading complete DevOps platform") and then details strategic themes and priorities to enable accomplish that goal (which per se aims at realizing the (10 year) "Vision"/"Goals"). In this section a few (in case of GitLab 4) strategic themes are presented, which really set the scopes GitLab wants to focus in the next 3 years. These are "action statements", e.g.: "Accelerate market maturity around the DevOps Platform". This is shaped iteratively (using GitLab's Merge Requests (MRs) in order to sharpen it up.
    • How: the how to develop work on these strategic themes (for coming 3 years) is founded on a few elements, namely:
      • Principles: to guide how teams/people execute their work. Example: being "fast follower", they don't want to/need-to be the first on doing something, but want to be able to move fast on embedding the great developments on their area.
      • Assumptions: which defines and scopes elements that provide a "context" for the company to be on the same page (especially important on decision making and how they work). Example: "Open Source stewardship", which defines this clear assumption that as a company they will put "the wider community first... and play well with others and shape the pie with other organizations commercializing GitLab".
      • Pricing: provides a clear picture of the GitLab pricing model.
      • Dual Flywheels: setting clear the "business model" and "development strategy" for the product (and company). Namely GitLab has an open-core model, which means investment on the open source will drive more features that can be embedded on their commercial offerings, which then brings more users and also revenues/contributions. It is really interesting to have this also as part of setting the strategic context (i.e.: people joining the company can get this clearly in a few minutes and get into the right frame).
      • KPIs: key element to measure success of the strategies and the development of the product. In this section you can see the essential KPIs, to which part of the flywheel they belong to and who is owner of that.
  • 1 year: Plan
    • What: these are the actual investments to be made on tactical strategies and implementations over the next year. These align and contribute to the 3 year strategic themes. This is a rather concrete plan, which defines the investment on the portfolio of products of the company over the next year.
    • How: on this part of the document we are redirected to a page GitLab calls "Direction" [GitLab-Direction]. This is a rather interesting page from GitLab, and it basically focuses on setting clear the Product Vision and Strategy (which provides "Direction" to the whole company). This page has several sections, namely:
      • Vision: which coincides with the Strategy page (10 year) Vision - to set clear the big vision topics.
      • 3 year Strategy: which extends the Strategy page "3 year strategy" section by with a more detailed overview. In this section they follow a very interesting template, namely, based on the general "Strategic Themes" defined they define more specific "Strategic Challenges" and the "Strategic Responses" they foresee to approach them. Again, this enables people to start aligning on the important "challenges" and also get ideas on the "responses" that we will (most likely) follow when defining more specific plans.
      • 1 year plan: at this levels you get a very sharp set of key themes to work on the product over the next year. They provide detailed plan per theme so that everyone can understand them (and the implications).
      • Quarterly Objectives and Key Results (OKRs): to make sure that goals are clearly defined (and in sync with the yearly plan) and aligned throughout the organization.

GitLab "explicitness" on how they approach their vision, strategy and planning does not stop in these two core documents ("Strategy" and "Direction"). They have another very interesting document called "Cadence" [GitLab-Cadence], which basically puts on paper the company cadence, i.e.: the time-periods/windows they have and the types of activities the company and its people do in each. Bellow I present a simplified overview of GitLab's cadence (and a list some of the core activities per period):

  1. Day
    1. Team work
    2. Calls
  2. Week (5 workdays)
    1. 1-1 cadences
    2. Team work
  3. Month (4.3 weeks)
    • Releases
    • Retrospectives
    • KPIs
  4. Quarter (3 months)
    • OKRs
  5. Year (4 quarters)
    • Annual plan
    • Most Direction
  6. Strategy (3 years)
    • Most Strategy
    • Some Direction
  7. Vision (10 years, 3.3x)
    • Product Vision
    • Principles
    • Vision Areas
  8. Mission (30 years, 3x)
    • Mission
    • BHAG (Big Hairy Ambitious Goal)
    • Values

This clarity and connected strategies provides a lot of clarity and in a way sets a clear "Operating Model" for the company, i.e.: how the different people (spread over the world) get a clear understanding and direction on what is important and what to focus on. This enables them to build on each others developments instead of pushing in different ways.

References

InsighTweet



light Engineering Strategy, Will Larson

Article from Will Larson that describes a "recipe" for shaping and defining "durable and grounded Engineering Strategies and Vision". This approach is rather interesting as it takes an "iterative bottom-up learning approach" where we observe the common big engineering challenges (from Design Documents on teams) and from there synthesize the (current) relevant Engineering Strategies. Then, to provide extra longer-term direction, Will proposes an extra layer focusing on Vision, which extrapolates how the different Strategies (and their relations) pan out on a 2-3 years time window.

Engineering Strategy and Vision should be a "life-cycle" based on the concrete problems (& designs from teams), providing extended enriched insight to guide and speed-up future technical decision making.

record overview | 🔗 record

[Article]

light My Insights: this article by Will Larson is a rather interesting and refreshing way to approach setting and continuously operate Engineering/Tech Strategies and Vision. Classically Tech Strategy and Vision tend to focus on "ambitious points" and rather long windows of time, plus mostly driven by the company and product vision and strategy (i.e.: top-down). Will takes a completely different path in this article by proposing a bottom-up approach that continuously focuses on spotting the relevant engineering challenges, which arise on multiple "design documents". The common challenges and approaches to solve them define the Engineering Strategies (in a nutshell: a pattern solution/guidelines to a problem context, which enables anyone facing the same issue to speed up their technical decision making). As more and more of these Strategies are identified, we can start defining longer-term strategies (or Engineering Vision), which consolidate multiple strategies into more stable longer-term vision on important topics (2-3 years time). This approach surfaces the significant strategies for the organization, which enables teams to speed up their decision making when faced with similar problems. By being driven by the "problems faced by the teams" we get a winning factor that is rather challenging on other Tech Vision and Strategy approaches: "self-evangelization" of the strategies. Teams basically see their input consolidated into an enriched and improved version, which means they are more likely to buy-in into those strategies instead of looking at alternatives. One element, also mentioned in the article, is that for longer-term strategies it is crucial to not just look at the Design Documents, but bring in extra context to enrich the decision making guidelines. This is rather important for "big shifts", normally influenced by changes in product vision, or business strategy. It is crucial to consolidate those and bring them in so that new Design Documents take those in consideration (and automatically they get updated on the Engineering Strategies, which becomes a life-cycle of learning and improving design decisions).

(Subscribe here or follow me on Twitter to get notified about new TLA_insights)

Analysis & Summary

The insights and notes of this record are inspired and driven by an article from Will Larson that describes a "recipe" for shaping and defining "durable and grounded Engineering Strategies and Vision". This approach is rather interesting as it takes an "iterative bottom-up learning approach" where we observe the common big engineering challenges (from Design Documents on teams) and from there synthesize the (current) relevant Engineering Strategies. Then, to provide extra longer-term direction, Will proposes an extra layer focusing on Vision, which extrapolates how the different Strategies (and their relations) pan out on a 2-3 years time window. This paragraph pretty much summarizes the proposed approach:

To write an engineering strategy, write five design documents, and pull the similarities out. That’s your engineering strategy. To write an engineering vision, write five engineering strategies, and forecast their implications two years into the future. That’s your engineering vision.

Strategies and vision are excellent mechanisms for pro-active alignment: they provide clarity for decision making on a particular context, which enables teams to move quickly and with confidence. This also avoids teams to "redo" a lot of investigation (i.e.: waste) and take very different decisions for no strong reason.

In the following I elaborate on the different phases Will mentions to setup and operate an Engineering Strategy. The sketch below presents my summary of the discussed approach (with some small extensions of mine, I call it "Engineering Strategy Life-cycle" as this really is about a life-cycle of activities).

Engineering Strategy Life-cycle

Phase 1: Write (at least) five Design Documents

  • Why:
    • In order to start identifying the relevant Engineering Strategies (and from there the Engineering Vision elements), we need to "understand" the relevant (and non-trivial) engineering problems in your organization and product(s).
  • What:
    • Design Documents (in some companies called Tech Specs, in others Request for Comments (RFC) documents). These are documents written by a team detailing the problem at hand and very concrete details on how to approach it.
      • This document can be reviewed by people from outside the team. Such an approach can be a great mechanism to gather extra feedback; and also is a great way to share/align knowledge in the organization.
    • Typical template: problem description; then ideas of possible approaches to solve the problem (does not need to be complete, but should be good enough for proper/productive review).
    • The elements on the design doc must be sharp and very concrete (not just ideas).
      • This is something that high-level/long-term strategies don't have.
  • How:
    • Write Design Document (prefer good over perfect, which takes too much time to complete) and gather feedback.
      • Gather input from different people (e.g.: in the form of RFC), but have one person writing the document alone. This makes sure the message is clear and sharp (instead of multiple styles mixed in the same document).
    • Create at least 5 of these documents to be able to go to phase 2.

Notes: Will mentions five documents, in my view this is just an indication and once we have identified the most relevant strategies this will be a continuous effort, as a function of learnings. Will provides a great pattern to approach this: "if you see the same discussion three of four-times, it's time to write another strategy". I really think this is a great way to continuously "calibrate" strategies and surface learnings into actionable knowledge that the whole organization can use.

Step 2: Synthesize the five design docs into a Strategy

  • Why:
    • To highlight the relevant and controversial decisions that happen in multiple designs. These particularly hard to agree points are the ones that require a common shared agreement (e.g.: what database technology to use for each use case in the organization).
    • If we consolidate the "best approach for us" for certain (classes of) problems, we provide guidance and alignment for the whole organization, which enables teams facing the same problem to "just use" those Strategies (and focus on solving new problems), instead of spending(duplicate) time on solving the same problem.
  • What:
    • Strategies: defining the context of the problem and providing a good overview of the tradeoffs made to accomplish a guidance/recommendation.
  • How:
    • Take five recent design docs and identify the points that generate the most "controversy" and "discussions".
    • Write the specifics and concrete problems at hand. (Great advice from Will: "Write until you start generalize, and then stop writing")
    • "Be opinionated", but also provide clear reasons to back the decision made (this will most likely be linked to the points identified in the Design Docs - especially the different views that different docs may have).

Notes: A Strategy becomes like a "pattern" (I call these more "Tactical Technical Decision Making" strategies). They provide direction for addressing a given problem that fits a context. This is really interesting and enables speeding decision making by teams when they face this "problem pattern", e.g.: when building a new application/service handling a certain type of data or requiring certain properties, they can refer to the strategy for database selection and in matter of minutes have an informed decision on which database to use (well supported by the organization, tested by other teams, etc.). I think the approach that Will presents towards scoping a Strategy is in some cases close to the TechRadar methodology [Tech Radar], i.e.: it provides guidelines on technologies, methods, frameworks and platforms recommended (and not-recommended) within an organization. TechRadar may not cover all possible engineering strategies required by an organization, but may be a great way to complement and visualize Technical Strategies.

Step 3: Extrapolate five (recent) strategies into a vision

  • Why:
    • As we gather more and more strategies to address particular patterns of problems, it will become challenging to reason about the directions that these strategies define - they may even be contradictory or their scope too narrow.
    • By reasoning on multiple relevant strategies and defining "higher-level strategy" (or "Vision"), which considers a window of 2-3 years time, we provide more clarity and direction to the technical decision making process.
  • What:
    • Vision document: defines strategies that are relevant in a longer time window, and with that providing clearer guidance for decision making (especially on non-trivial topics, ones that may require rather big investment or effort - "provide a robust belief in the future").
  • How:
    • Start from the most relevant and up-to-date Strategies and look for the contradictions and challenges you see.
    • Write vision elements considering a window of 2-3 years, so it can provide some "stability" for significant technical decisions to be made.
      • For well established companies, this can be an even longer window of time.
    • Consider business, product and user context:
      • This input should be made explicit and influence the Vision so that teams can use those and make better technical decisions without having to (again) do all of that analysis themselves.
    • Keep it to one or two pages long, should be a readable/usable document and one that does not change very regularly (stability is an important trait for Vision).
    • Once you have a reasonable version, share it widely across the engineering organization for validation and consolidation.

Notes: vision elements are an harmonization and direction setting mechanism. They consolidate multiple forces into clear and actionable directions for teams in a longer-time window (I call these "Strategic Technical Decision Making" Strategies or Vision). Given they are created based on Strategies (which are based on Design Documents), they tend to be "recognized" by the engineering organization, and as such should not raise a lot of questions. If questions are raised, this is a smell that something must still be sharpened up. As Will mentions: "a great vision is usually so obvious that it bores more than it excites. Don’t measure vision by the initial excitement it creates. Instead measure it by reading a design document from two years ago and then one from last week; if there’s marked improvement, then your vision is good."

Will has many interesting insights throughout this article, but at the end it sort of boils down to the fact that: "good engineering strategy is boring, and that it's easier to write an effective strategy than a bad one". There is a lot to unpack in this sentence, but in a nutshell the main point is: if we focus on addressing the "concrete problems" the different teams are facing and drive our strategies out of that we will be most likely addressing the important strategies (which seems boring, no "brilliant new ideas", simply address the problems you are facing). By sticking with that we are driving our strategies based on "bottom-up organization learning", which makes them grounded and connected.

References

InsighTweet