Any given business day you will find an age-old conflict brewing in a neutral-toned conference room or on a tiled video conference call. This conflict is the push and pulls of the idealists and the immediatists. The idealists advocate for the best possible solution with a timeline or cost that is unattainable in the short-term. The immediatists advocate for the fastest mitigation of the problem with little concern for the long-term impacts or the bigger picture.
Early in my career I worked in a couple of operations teams whose purpose was for rapid incident detection and mitigation. In this world I would implement temporary fixes and minor adjustments that often did not solve the root problem or at least did not do much to prevent the same problem happening again. This was important work that kept revenue flowing when otherwise it would had stopped. It also maintained customer good-will and prevented the company’s reputation and service creditability from crumbling.
As my career evolved, I walked myself to the other side of the software development life cycle. I wanted to stop worrying about what happened and begin deciding what would happen. I managed a team of data architects who analyzed the big picture and debated for hours or days over which was the best solution between two acceptable solutions. This too was important work. Building strategic technical road maps and assessing the value of costly engineering effort enabled us to push our platforms forward and bring consistency and organization to what was built.
Conflict can crop up when these two groups of people enter into a discussion around how to solve a problem. This conflict does not come from two opposing points of view, however. It comes from seeing what is in front of us as a single step rather than a path with many stops and turns along the way.
The solutions are often presented as having to choose between implementing the workaround or implementing the ideal solution.
The reality is that many problems present different mitigation steps than the steps necessary to prevent future incidents. This is where a more layered approach to the solution must be taken.
- Identify the ideal solution or desired state.
- Assess what steps can be taken immediately to mitigate the issue while still staying on the path to the desired state.
- Determine what phases are necessary to follow through with the desired state while remembering that the path will zig-zag and the desired state might change over time.
One of the reasons that we can forget this multi-step process is because there can be a lack of trust in the company’s commitment to continue to invest in something that is no longer posing an immediate problem. Too often, we do not follow up with action on lessons learned and invest money or engineering time into larger solutions or preventative changes.
Following through on these post-incident plans is important for building and maintaining a culture of learning. Continuous learning and improvement are necessary for any organization to remain competitive and adaptive to customer needs. This holds true for system and code refactoring just as much as it holds true for product and feature selection and delivery.
Leave a Reply