Technical is tactical

Intro: levels of war

The US Department of the Army publishes a Field Manual called Operations (FM 3-0), a doctrinal guide for conducting military operations. In it, three levels of war are described. They are:

1. The strategic level (such as national policy)
2. The operational level (such as campaigns and major operations)
3. The tactical level (including battles and small-unit actions)

At the strategic level, national interests and policy inform national and multinational military objectives, and global plans for achieving those objectives are developed.

The operational level consists of major operations conducted by commanders in order to achieve the strategic objectives. These commanders determine how and when to position and employ their resources in order to create favourable conditions for tactical actions.

At the tactical level, short-term actions with defined goals are conducted in order to support and bring about the objectives of the major operation.

Each level is meant to clarify the relationship between strategy, operational approach, and tactical actions in military operations. They describe levels of responsibility and planning when it comes to solving large-scale problems, and though each has a very different scope, it is inextricably linked with the others.

Levels of business

Military operations have many parallels to running a company, especially at the operational and tactical levels.

Like campaign commanders, those responsible for the operational aspects of a company are tasked with creating favourable conditions for the company’s success. Company operations center on the concepts of people and process.

People can be thought of as the aggregation and interaction of individuals, such as with organizational structure. The framework governing this aggregation and the protocol for these interactions is what we call process, such as the interactions between organizational components of a broader organization.

The tactical actions of a company, by contrast, center on day-to-day actions that support the organization’s larger goals or seek to remove pain points. Tactical actions seem urgent, and are at front of mind of those working in the company. They are a vital part of furthering long-term success, however, they do not in themselves achieve a company’s larger operational objectives.

These different levels of approaching problems are important for those in decision-making roles to keep in mind. Often, when a company encounters problems, management or technical leaders will try and address the painful symptoms, rather than solve the underlying issue. All too often, it’s easy to scapegoat technology and tooling, and squander time on its selection and/or modification. Either the inefficacy of present tooling or the perceived lack of any tooling at all is blamed as the cause of the problem, and the company is easily seduced by the lure of implementing shiny new technological “solutions.”

In reality, the problems companies typically face are almost never technical.

Most identified pain points are not the actual problem, but symptoms of the underlying issue. The true problems are often rooted in people and process, not technology.

Attempting to address problems rooted in people and process with technical solutions is attempting to solve an organizational issue with a tactical solution. At best, a tactical maneuver may remove short-term pain, but overall has a minimal and temporary positive effect on organizational improvement. It does little to advance mid-term and long-term strategic objectives.

In other words, technical is tactical.

Understanding the costs involved

A band-aid technical solution can seem to be an appealing, sometimes necessary, quick fix. The lure of a quick technical solution is especially strong when it involves sexy new technologies or tools. Often, however, objective costs for implementing these “quick” fixes are not properly considered and weighed against the alleged benefits.

Technical solutions present a variety of costs in order to select, configure, customize, and implement them. Besides initial purchase or development, companies must consider costs associated with user training, software maintenance, and support for troubleshooting any issues that may arise. When long-term maintenance costs are considered alongside short-term acquisition costs, the ticket price of a new technical band-aid may be far too high, making it a less appealing solution when it comes to treating a symptom.

Avoiding the firefighting culture

To try and solve pain points rooted in people and process with technological band-aids is to constantly pursue a (often short-sighted) local optima. Colloquially, this is often known as firefighting. Companies that aren’t aware of this pitfall unfortunately develop a firefighting culture, and spend their resources putting out small fires instead of solving the underlying issues. Technical teams that engage in this behavior may seem very busy, and may even be very good at putting out the fires that arise. However, they are not able to be very productive as they end up solving the same problems over and over. They’ve mastered the tactical solutions to their technical problems, but fail to consider the broader, operational, point of view.

I saw a clear example of this situation years ago. It affected a reporting and data access group within a company I was advising. The team had very high levels of proficiency with a tool that allowed them to provide reports via web interface to others in the business.

Since this team was so effective at building reports, they built many hundreds of them. These reports depended on a specific database structure, and for certain pieces of data to be present within that database structure. This dependency was choking technological progress in the company because the software involved could not easily be modified without compromising the reporting system.

The team had become very good at firefighting with their technical solution of building the reports, but as a result were crippling the evolution of the company’s underlying data infrastructure. The many hundreds of small, tactical fixes that the team had made created a lot of historical baggage. There had been little consideration for the strategic impacts of the tactical wins.

Upon closer examination of the underlying problems, it became clear that:

1. No monitoring of the report usage logs was being performed
2. No usage analysis resulting from the above was ever performed
3. None of the reports had ever been deleted as a result

Once the usage history was examined, it became obvious that more than 95% of the reports had not been used in months, and that most of the reports had only been used once, presumably either as a test or by the requestor. Thus it was a straightforward decision to stop producing these useless reports, and instead provide training and access for company employees to examine the relevant data on their own. The data and reporting team could then focus on solving more important business problems, allowing the company to improve its development and feature release capability for its users. By examining the underlying issue, it was possible to fix the organizational problem at its root instead of pursuing band-aid tactical solutions.

Finding the underlying problem

There are two main ways a company can determine if it is addressing a symptom or the true underlying problem. One is to follow a framework for examining the issue, and the other is to break down a pain point into its constituent parts.

Using a framework

A company can use a framework to identify root causes of problems, such as the 5 Whys framework. In this methodology, we examine a problem by answering the question of why it exists. For example,

Q: Why do I have heartburn? A: Because I had a spicy nachos and whisky for lunch.

To get to the root of the issue, we repeatedly ask why the above answer exists until we reach the root cause. Here is a continuation of our example:

Q: Why did I have spicy chili nachos and whisky for lunch? A: Because that’s all that was available at the nearest restaurant.

Q: Why did I have to get lunch at the nearest restaurant? A: Because I was short on time and didn’t pack a healthy lunch.

Q: Why did I not pack my lunch? A: Because I snoozed my alarm this morning and I got out of bed later than usual.

Q: Why did I snooze my alarm this morning? A: Because I stayed up playing video games and went to bed late at night.

In our somewhat contrived but nonetheless familiar example, we’ve used the 5 Whys framework to identify the root cause of our heartburn pain point. Now we understand that this pain point can be solved by not staying up too late, getting up on time, and packing a healthy lunch. Furthermore, we have not only identified a likely cause of the heartburn issue, but a likely cause of many other issues as well. By addressing a single underlying cause, we get the solution to many painful symptoms for free.

Ultimately, the methodology is unimportant compared to the company’s willingness to recognize the root causes of the issue. Some objectivity is necessary in order to see where effort is being expended on something other than the underlying problem.

Breaking it down

It is often possible to break down a pain point into its constituent parts. With this approach, we can determine if we can solve a different or simpler problem to achieve the same benefit.

I once advised a company that was having trouble scaling to handle increased demand on their technical systems for Southeast Asian operations. This trouble manifested in problems with their backend servers when handling API requests. The technical team had informed the company’s executives that the performance issues were caused by the programming language used to build the high-traffic portion of their technology platform, and that in order to rewrite large parts of the the system in a new language and fix the issues, a freeze on feature development would be necessary for several months.

Since feature freezes and large system rewrites are almost never a good option from a technical standpoint (because you should Always Be Shipping), it was necessary to break down the issues further and determine if there was a simpler way to achieve a solution. With this in mind, I investigated the overall system architecture to identify individual components that may have been posing scalability problems. I examined each component to identify some common performance-killing design mistakes, and then together with the technical team, we prioritized those areas for modifications.

The work to improve the performance of the problem components took a matter of days to complete, and without any feature freezes or major rewrites in a new programming language. This largely relieved the persistent performance issues. However, this was only the tactical solution to this company’s problem.

The real issue in this example was still not addressed - namely, how the technology platform got into such a state of poor performance in the first place. In order to solve this company’s pain points at the true root of the problem, I had to further break down its constituent parts.

Unsurprisingly, the real issues were largely organizational. There was a lack of appropriate onboarding and knowledge transfer processes in place when it came to hiring developers, as well as a lack of adequate training on the foundations of performance-focused application and database development. Additionally, there were no adequate processes in place for non-functional or performance testing during feature development.

Through breaking down the problem, we were able to determine that the true cause of the company’s issues was rooted in inadequate education and training. Even if the technical team had successfully done a system overhaul in a new programming language, the real cause of the company’s technical problems would not have been addressed, and likely would have worsened.

Never hesitate to break down a problem in order to determine if you can solve a different or simpler problem to yield the same (or greater) effect. Some objective examination in this area may help your company to work smart, instead of working hard.

Summary

If you find yourself in a situation where you are proposing a technical solution to a problem, or someone is proposing a technical solution to you, it is worthwhile to consider whether or not you are solving the actual problem or simply addressing a symptom of a greater underlying issue. Based on my experience working with organizations of varying sizes, levels of technical maturity, and in different geographical locations, I can say unequivocally that the technical symptoms are almost always trivial to identify and address. However, that approach is only part of the solution.

A tactical, technical band-aid simply buys you time that you can use to solve the root organizational human problem. In order to ensure the problem is actually solved, it is necessary to understand the underlying systemic effects that have led to the experience of the painful symptoms. Hint: the organizational solutions to those root causes are almost always related to improving ineffective leadership capabilities.

If you find yourself on the sending or receiving end of a technical solution, just repeat this mantra: technical is tactical.