The problem
I’ve seen many cases where a CEO or a manager asks for technical strategy and doesn’t get the response they want. Their technical team takes a long time to produce something that seems comprehensive and impenetrable at best and scary at worst. It’s rarely something that works for the executive who asked for it.
When I look at how this process looks from the engineering team’s side, typically, one of two things has happened. Either the tech team has gone down a “rabbit hole” of trying to research and debate the definition of strategy (a rather fun topic, but one that’s neither particularly easy to define nor especially useful to have defined), or they’ve just written up something that sounds technical in the hope that it will stop the questions and let them get on with their work.
Neither the business nor the technology team feels they’ve been understood, and neither group feels they are working with the other…
It’s worth taking a moment to reflect on what it is that the leaders or managers actually want. They want a way of thinking about, managing and supporting whatever the technical effort is. They don’t really care about whether it meets an academic definition of what strategy is, and I’d wager good money they don’t want a hard-to-read document that feels like it goes over their head.
So rather than trying to define technical strategy, I claim it’s much more helpful to talk about what conversation needs to be had. What are the useful questions to ask, and who needs to answer them?
The Solution
Obviously, that’s a big topic, but I like to distil it into four areas - four conversations that need to happen at the start of the project and be revisited regularly throughout the life of the project. Conversations that help keep everyone on the same page. These conversations focus on the areas of Business, Design, Tech, and Upkeep & Stewardship.
The Business Conversation
The manager/leader should lead the business conversation. This conversation needs to go into topics like defining the business drivers for the initiative, how the business hopes the technology will further the goals of the business, who is the audience for whatever’s been being built, what’s the financial context surrounding the project, and what the business’s attitude to hiring either staff or contracts for the development of the technology.
Without the business conversation, there are a bunch of things that can go wrong. These range from building a great app that doesn’t directly support what the company is trying to achieve to designing and starting to build a platform that isn’t financially vaible or doesn’t bring in the revenue the business needs. I’ve also seen companies that wanted to be able to pull from a range of contract developers using an “on-demand” approach that ended up with a project developed in a specialist programming language that was only known by a small handful of developers who don’t want to work on short term contracts.
The Design Conversation
The second conversational area is design. That doesn’t mean making things look pretty - though it can include that. It means taking a good look at what are the problems or issues that the desired users of the technology have. This is the same as asking how the software will provide value to the users. It also includes the same questions for the customers if you’re in a situation where the users are not paying for the software. Finally, the design conversation needs to cover what must be true for the user’s and customer’s problems and issues to be addressed by the software.
This conversation needs to be led by people with experience in product design and really needs to be a research effort. I often see business leaders having an opinionated view of the user’s problems. In many cases, these opinions are driven by past experience being in the shoes of the user or having talked to many of them in the life of the business. This is a big mistake.
In nearly all cases, a range of users have a range of problems, and they often are not able to articulate what those problems are. The manager who used to be a customer only has one perspective, and unstructured conversations with users normally fail to pick up on all their implicit and explicit needs. That is why a structured conversation that uses established methods to extract user needs and includes a range of user representatives needs to happen.
The Technology Conversation
Next is the topic of technology. This covers all the various aspects of building the software and most of the day-to-day activities that developers and engineers spend their time on. Good things to talk about here include how the development team thinks the software should be structured when it’s done; What the structure is now (often quite different from what the developers want it to be); How the build process is managed (eg agile or waterfall or something else), What are the established development practices that are used on a daily basis (eg Pull Requests, Code Reviews, Unit Testing, Code Linting etc.).
In most cases, the business leaders or managers do not possess the knowledge necessary to do more than learn in these conversations, and so sometimes skip them. That’s a really bad idea because it builds distance and distrust between the two groups. I strongly encourage them to participate to know at least that the teams have an idea of best practices and a culture of following them. It also gives the managers better knowledge about what makes a good engineer, and that’s never a bad thing.
The Upkeep & Stewardship Conversation
Finally is the conversation about “Upkeep & Stewardship”. I should define what I mean by that. Basically, it covers everything that needs to happen after the software has been built and is in use by users. Software isn’t something that is ever “finished” or “done”, a fact that is too often overlooked. Everyone needs to be involved in this conversation.
What needs to be talked about here and understood is how you are monitoring if the software is meeting security and regulatory rules, how to tell if the project is meeting the needs of the business, if it’s meeting the needs of the users and customers, and how to keep an eye on if the technology team is doing a good job - which is often hard to tell as the results can sometimes look poor even when the tech team is doing great work if some other aspect of the project or underlying assumptions are wrong.
Summary
Technology “strategy” (like all strategies) is continually changing. All strategies have to be dynamic and respond to changes, but change and learning happen in technology projects at a speed unmatched by nearly every other aspect of the business. Not taking active steps to start this conversation early and keep on top of it can cause a project to wander badly off course, sometimes even before it’s initially launched!
Doing something involving technology is often a new experience for an established business but exciting. Making the time to have these conversations makes the process a lot smoother, and over time working with a technology team stops feeling like a strange, incomprehensible magic act and just another tool in the toolkit of a good business leader.