ConsenseKit - build consensus for hard tech decisions
As a software engineer, your job is hard enough. Solving technical problems and implementing efficient solutions is just part of the daily struggle. Every once in a while, though, the decisions you make have the potential to dramatically impact the business that pays your bills. I’m talking about:
- deciding to refactor
- deciding to pay down “technical debt” and
- deciding to invest in reducing software complexity.
The problem is these decision points aren’t consistently prepared for, and sometimes not predictable in advance. They might pop-up right in the middle of your milestones, as the engineers come to realize that their productivity is being diminished by X piece of infrastructure or Y code integration. Sadly, many decision makers rely on gut intuition and even allow technology trends to dictate the answer. They decide whether to rebuild core infrastructure or keep pushing with the codebase that is at best tolerable in the short term.
To compound the problem, you have to communicate your concerns to a diverse set of stakeholders. Your project manager might empathize with your daily frustrations, but the business and product people will (rightfully) attempt to understand why a codebase should be given more attention. Your account sales manager will struggle to understand why refactoring is worth a delay that they have to explain to the customer. The customer might pushback, so your CEO decides to delay or not do anything right now.
These stakeholders will attempt to understand these tech decisions, but the outcome is highly dependent on your communication skills, ability to empathize with their needs and rationalize the impact of the decisions. Engineers aren’t trained enough for this.
Sometimes, you may not even be sure that refactoring is really necessary. But while developing, there are frustrations that creep up, and it’s your job to raise a concern. Other engineers on your team might have different pain tolerance levels, and may be fine with the way things are. How can you yourself be sure this concern is worth pursuing?
As a software engineer, you’re trained to understand the complexities of code, APIs and frameworks. That’s your main job. If only there was something to help you with these hard tech decisions, too…
Introducing ConsenseKit
ConsenseKit is a suite of tools that help software decision makers build consensus for hard tech decisions. A software decision maker can be an engineer, project manager or CTO. It focuses currently on the hard tech decision of whether or not to refactor a codebase.
How does it work?
ConsenseKit does not decide what is the best decision to make. This is ultimately the job and responsibility of engineering or the CTO.
Rather, it provides communications tools and training that promotes these outcomes:
- Increased likelihood that you use the right language when empathizing with your targeted audience
- Increased confidence that tech debt concerns are indeed valid and need to addressed
- Increases likelihood for earning consensus as an organization, whatever the decision turns out to be
Consensus is defined as a “general agreement”. But it is only a means to an end. The real reason ConsenseKit exists:
- foster culture where software engineers feel heard
- decisions are understood across teams and
- healthier codebase is produced
By relying on ConsenseKit, the effects of these tech decisions can be prepared for. By providing the tools for communicating more effectively, we can make steps toward building digital products more efficiently.
Editors Note ConsenseKit has been renamed to RefactorKit. You’ll find more posts on the blog about this change.
