Becoming an Agile Tech Strategist
If you’re a developer who dreams about contributing to important architectural choices and multi-team technical direction, you need to develop the habits of a tech strategist. Tech strategist is not a job title — it’s a mindset. Anyone with the desire to influence key decisions can become a tech strategist.
Becoming a tech strategist enables you to have a huge impact on your entire organisation’s ability to deliver software efficiently, build game changing products, and innovate. However, to become a tech strategist there is one big secret you must be aware of… making technical decisions is the easy part.
The key to becoming an effective tech strategist is understanding the goals of your organisation at different levels. What is your organisation’s mission? What is the business model? How do your current products and roadmaps contribute to the vision? Who are your customer segments and what are their needs? How is the organisation structured to achieve it’s mission?
Not only do you need to answer all of those questions in order to make judicious technical decisions, you also need to influence those different parts of the business. You need to ensure your organisation is structured in the optimal way to deliver the software that will help the organisation achieve its vision. You need to ensure product ideas have been carefully considered before you start building them.
All of this may sound overwhelming, especially if you’re used to focusing only on great code. But don’t worry, in this post you are going to see concrete practices to help you get the information you need, and importantly, you’ll see how to develop the mindset of an agile tech strategist.
An effective technical strategist understands their true goal — to use technology, process, and working practices to create a high-performing organisation. A good tech strategist helps their organisation to deliver software frequently, enabling faster product innovation and cheaper operating costs. Accordingly, as a tech strategist you need to understand what makes a high performing organisation.
A good tech strategist helps their organisation to deliver software frequently, enabling faster product innovation and cheaper operating costs.
Importantly, you also need to have belief in yourself — it really is your responsibility to understand the organisation as a whole and improve processes. Many software developers are shy of non-coding topics — they think process, agile, business stuff is someone else’s job. But it’s not. You can teach yourself about these topics.
There are many ways to learn about high performance organisations. For a start, you can read books like Lean Enterprise, Business Model Generation, and Kanban. You watch conference videos online. Check out videos from conferences like Lean Kanban France, Lean Agile Scotland, or any talk by Henrik Kniberg or Dan North.
Early in my career, I was immeasurably fortunate to work at an extraordinary organisation with software developers who taught me to think about all aspects of an organisation.
We were building a complex, highly-scalable application with some of the biggest tech organisations in the world using our platform to build their own music catalogues and streaming services. We had only one manager for around 50 developers, yet every team was deploying to production on average 2–3 times per-day. How was this possible?
We were a high performing organisation because every developer was a tech strategist. We had self-organising teams where every developer was focused on improving all aspects of the organisation from process, to priorities, to the product innovation. I know it is possible for any software developer to learn about these things because I have seen it.
To make good strategic technical decisions you need to be immersed in the business context. You need to know what business goals you are working towards in order to decide how to optimise your tech strategy.
Are you optimising for time-to-market or long-term stability? Is this piece of a work a good opportunity to train junior members? Is now a good time to pay back technical debt?. Only when you know business goals, can you make those kinds of decisions effectively.
It’s this transition to thinking about business perspective where developers make naive mistakes — “let’s ask the business what they want”. In truth, we have to go much deeper than that. But don’t worry, it’s not as difficult as it sounds.
It’s this transition to thinking about business perspective where developers make naive mistakes — “let’s ask the business what they want”.
I like to think of technical strategy as a pyramid of needs, where each layer builds upon the previous layer. This pyramid shows me all of the different layers and concerns of an organisation that I need to understand before I can start on any piece of work.
I teach this pyramid in my Advanced Strategic DDD Workshop. I teach engineers the practices they can use to get the information they need at each level (you can download my Strategic DDD Practices training booklet if you’d like to learn more). I also encourage engineers how to make information from all of these levels part of your definition of ready for any major piece of work.
Every business has some kind of mission and vision. The mission describes what they want to be or how they want to change the world. It can be a little fluffy and vague but it’s an ambition that guides every employee organisation towards some inspiring ideal.
As an example, Salesforce.org (a Foundation created by Salesforce) has the mission statement:
Salesforce.org is based on a simple idea: leverage Salesforce’s technology, people, and resources to help improve communities around the world. We call this integrated philanthropic approach the 1–1–1 model because it started with a commitment to leverage 1% of Salesforce’s technology, people, and resources to improve communities around the world. By encouraging and enabling companies to adopt the 1–1–1 model, Salesforce.org is helping to spark a worldwide corporate giving revolution.
During my workshop, the first activity we do is to break up into teams and create a mission statement for a new imaginary business. And through the rest of the day, I can see how each team is guided by their mission statement.
Organisations may also have a vision statement which describes, also at quite a high-level, how the organisation intends to achieve it’s mission.
If you don’t know what your organisation’s mission statement and vision statement look like, it’s a good idea to start there.
Business strategy is all about market research — analysing large-scale trends in the market, looking for opportunities upon which to capitalise. The business may talk about things like plays and business models.
There are many practices for learning about your business strategy. My favourite is the Business Model Canvas and it’s the one I teach during my workshop as well (there are many other useful canvases and practices, too).
I started learning about the Business Model Canvas because I wanted to have meaningful conversations with non-IT people. I wanted a language to communicate to them with and I wanted to see things from their point of view. The Business Model Canvas has been immensely valuable in helping me to achieve those things over the past 5 years.
The Business Model Canvas contains nine sections. The most important are Value Propositions and Customer Segments. These sections help you understand the most valuable products or services your business provides and the customers you care about the most. Two pieces of information that should drive every technical decision. To learn about all sections of the canvas and how they can drive technical decision making, check out this post.
A few years ago, in my days as a consultant, I was helping an organisation to build a new online marketplace. It was amazing working with developers who were so passionate about building an amazing product, but I noticed a misalignment. The developers were talking about lots of exciting platform features making it easy to buy and sell things. So I asked the developers to create a Business Model Canvas.
We took the canvas to the investor who wanted the new platform and he looked on in shock. “No, it’s not about the platform. My goal is to create a social experience where people come every day to see what their friends are selling, so they can gossip about it, even when they are not selling”. This insight completely transformed the team’s approach to building the product.
Product strategy is all about design research, working with smaller numbers of customers to identify what products can be built to satisfy their needs in order to achieve the business strategy.
To understand your organisation or department’s product strategy, you can experiment with canvases. You can collaborate with your product manager to create a Product Strategy Canvas, for example. It’s also important to understand business analytics.
As a tech strategist you should strive to deeply understand your customers. I advise you to get involved in user research. Try and be there in the room as user researchers are interviewing customers or showing them prototypes. Or at least try to watch the videos later. Try to understand the key use cases that truly create value for your customers.
When I worked in the UK government, I was exposed to user research for the first time. My team was building a 15 page online service to make it easy for citizens to pay their taxes. Us developers, we could blast through the entire 15 page form in about 30 seconds. It was easy to us, we assumed it must be easy for UK citizens as well. Our tech strategy was built around these assumptions.
One day, though, our user researcher made us watch her interviews with UK citizens. It was a huge wake up call for us. One person got to page 2 on the form and almost started crying. Others were complaining about their saved data being lost, bits of the page jumping round, weird validation rules and error messages. From that moment, we drastically re-allocated our efforts on fixing problems that affected customers the most.
One day, though, our user researcher made us watch her interviews with UK citizens. It was a huge wake up call for us.
You’ll notice that there is overlap between business strategy and product strategy. In theory, product strategy is a specific interpretation of the business strategy. In practice, the lines are blurry and there is two way feedback.
To create a tech strategy that enables your organisation to build a high-speed agile engineering capability and the ability to innovate rapidly, you have to influence the shape and structure of your organisation. You need to align your teams with your software architecture to minimise dependencies — reducing the expensive costs of cross-team collaboration, and improving the autonomy of each team so they can own decision making and iterate faster.
If organisation design is new to you, the prospect can seem extremely daunting. Admittedly, it’s not easy. Organisation design is a wide and deep topic that very few people, if anyone, has mastered. However, you definitely shouldn’t feel uncomfortable. There are principles, practices and patterns you can quickly learn about. They will get you upto speed much faster than you think.
The first technique to learn about is Strategic Domain-Driven Design — understanding how to break down a large complex problem space into smaller bounded contexts aligned with the domain. Check out my Strategic DDD talk if you want to learn more.
Secondly, you should also learn about Theory of Constraints (ToC), an approach that was originally developed in manufacturing in the 1980s. ToC has become hugely influential in the agile world, showing us how to design organisations by eliminating bottlenecks. You can combine DDD and Theory of Constraints to improve autonomy in your organisation by removing dependencies between teams — your bottlenecks.
Over the past couple of years, I’ve been talking and blogging quite frequently about the importance of aligning organisational and technical boundaries using Domain-Driven Design and Theory of Constraints. If you want to learn more, you can check out a recent talk of mine Domain-Driven Architectural Alignment which I presented at Craft Conference.
Craft Conference is Europe’s premier software craftsmanship conference, as an aspiring tech strategist, you should definitely try and attend if you have the opportunity.
As an agile tech strategist, Domain-Driven Design and Theory of Constraints are a fundamental part of your skillset. I highly encourage you to read The Goal to get started with ToC. You may also want to check my blog post demonstrating how to combine DDD and ToC to improve customer responsiveness in an organisation.
In order to make strategic tech decisions it’s not enough to just have a deep understanding of the business. You also need a wider understanding of your organisational context. You need to understand the priorities and responsibilities of the other teams in your organisation.
When you propose strategic decisions — rewriting parts of a system, restructuring teams, adopting new process/practices, applying new technologies — you need to understand how they affect multiple teams. You need to convince others you understand the bigger picture, and you need to demonstrate how your strategy will provide system level benefits affecting many teams.
The broader your knowledge, the broader your sphere of influence.
Here are a few of my favourite hacks for gaining a wider organisational understanding.
In his Alignment at Scale talk, Henrik Kniberg explains how Spotify uses their Big Bets Spreadsheet. It’s a prioritised list of all initiatives in the organisation, showing how each team is being utilised. It then links off to more detailed information.
This is precisely the type of information we all need in order to make good strategic decisions. As a tech strategist, find ways to make this information visible in your organisation.
To gain a better understanding of other team’s priorities, their architecture and their domain models, go and spend a few days working with them. Pair up with a developer in another team.
Not only is cross-team pairing invaluable to tech strategists, it is highly enjoyable. One of the most enjoyable weeks of my career occurred when I had the opportunity to pair up with another team. As I was implementing features in their model, I had so many revelations about my own teams model and how the system worked as a whole.
Over the past few years, a workshop format called Event Storming has become hugely popular, especially within the Domain-Driven Design community. Event Storming encourages you to get a diverse group of representatives with different job titles and from different teams, and then you map out complex domain processes together.
During an Event Storming workshop, you model processes that span multiple teams, leading to lots of interesting discussions and lots of valuable insights that help everyone to think beyond their silo in order to optimise the system as a whole.
Do you want to be a tech strategist? Great. Then you are a tech strategist, no matter how experienced you are or what job title you have. Just remember these key things:
- Gain a deep understanding of your business
- Gain a wide understanding of your organisational context
- Ensure every decision you make is built on all the layers of the tech strategy pyramid
Also, build yourself a learning path that enables you to get better at those three goals. I would highly recommend you start by reading the following books and by learning about the industry you work in.
Also, try to attend conferences — especially those about process, product, UX, business, etc or at least watch videos online. It’s a fantastic way to make your daily commute productive.
Finally, I also have to encourage you to watch Crossing the River by Feeling the Stones. A sensational talk by revered business strategist Simon Wardley.
Good luck on your journey.
Originally published at medium.com on May 18, 2017.
