The Jobs-to-be-done when communicating software refactors

The ConsenseKit case study

In the month of February 2019, I had some time between projects which I occupied with research into the art of product development. There seemed to be a group of people on my Twitter feed which specialized in something called “product”. I didn’t know what it meant, but one guy made it sound so easy to define what product to build. That’s how I found out about jobs to be done. Here’s what I learned about it, and how I applied this product definition technique to the concept that was then called ConsenseKit (which later was renamed to RefactorKit).

Jobs-to-be-done (JTBD) is a business management theory for describing products and solutions by focusing on the functional task output instead of solution specifics. A common metaphor used is that of a drill bit: builders don’t need a quarter inch drill, they need a quarter inch hole. It is often simplified as a lens that can be used to think about products and solutions. The literature emphasizes the need for correctly defining the “core” job to be done, as well as related and consumption chain jobs. In addition, the theory describes that jobs can exist within emotional and social dimensions, and the evaluation of a product or service should consider the functional, emotional and social dimensions separately.

Projected Solutions

The jobs-to-be-done management theory advocates for thinking about the “jobs” that a solution or service is “hired to do”, instead of specific solutions. These jobs are an abstract concept that is more stable over the long term. Solutions evolve and change, but the jobs might stay the same. It teaches to focus on the job to be done, and not get emotionally attached to specific solutions.

The Core Job

Software engineers communicating tech decisions to product managers or business people who may be non-technical or need to critically understand the impact of decision.

“…Business people tend to be better at convincing programmers to damage the long term health of their code base for short term gains, than programmers are at convincing business people about the importance of having healthy software with few messes and low levels of technical debt”

Blaine Osepchuk, Technical debt: we need better communication, not better metaphors

Jean Hsu also frames the problem from the perspective of engineers, in How to Get Buy-In for Reducing Technical Debt

Evidently, there seems to be a difficulty specific to engineers in communicating these decisions. I had previously considered “software managers” as the main job executors. I think the “software manager” these people may be more trained or prepared when communicating hard tech decisions. The “software engineering” positioning is more focused and will speak to the exact audience segment who performs the core job to be done.

According to the Software Engineering Code of Ethics, advocating for the code is indeed part of the engineers job.

Desired Outcomes

The software engineer wants to ground the discussion in meaningful and thoughtful ways. Instead of so-called best practices or gut intuition, which is the opposite outcome desired.

This product sets a standard for communication which utilizes systems thinking and the forecasted needs of the business as a way to form consensus.

The functional desired outcome is for communication, learning and understanding to feel more like engineering and ultimately have healthy discussions between technical and non-technical team members.

From an emotional perspective, the engineer wants to feel considerate. They want to feel like a good communicator. They want to feel as if they value thought diversity. Most importantly, they want to feel or be perceived as empathetic to the needs of their coworkers in the business that supports them.

Job Map

To understand the structure of the next section, you should first understand what a job map is. It’s a 3 minute read, so go ahead and do that and then come back here.

1. Define

The software engineer is faced with communicating a technical decision that has the potential to critically impact company operations.

The classic example is:

• Refactoring (reduce tech debt) or build new features?

The manager is interested in making the decision seem thoughtful and considerate instead of arbitrary. They are interested in communicating the tradeoffs so that the stakeholders are appropriately informed.

The manager must be able to identify the need for these decisions and understand the tradeoffs and objectives of each decision.

2. Locate

The software engineer must understand the audience for their advocacy.

• Who are the key stakeholders that need to come to consensus?
• Who are the other stakeholders affected by the decision?

3. Prepare

With the audience determined, the software engineer must prepare by categorizing them into groups. The main groups are:

• Business
• Engineering
• Sales
• Product
• Operations

The tech decision may impact key metrics which are relevant to the business units affected. For example,

Format: direction + metric ( categories )

• Increased feature delivery velocity ( business, product, sales, operations )
• Decreased risk of missed deadlines, launch delays ( business, engineering, sales, operations )
• Decreased employee onboarding time ( business, engineering )
• Decreased risk of cost overruns ( business, operations )

This preparation step can be considered a related job, as it may not be performed by the main executor, but can be.

4. Confirm

The software engineer confirms that the decision will impact business operations. Business risk has high-probability of occuring, such as:

• missed deadlines
• reduced scope
• launch delays
• cost overruns
• slower employee onboarding

The job executor needs confirmation that a decision analysis needs to be made.

5. Execute

Software manager uses product to

• define decision type
• clearly identify risks, estimate likelihood of impact
• prepare and categorize stakeholders
• prepare communications to each stakeholder group (KPIs -> ROIs)
• send & deliver communications

6. Monitor

If any advocacy materials were sent to audience, the software manager can monitor their delivery and receipt.

7. Modify

The campaign may have prompted questions from the audience, which the software manager can answer (inline or otherwise) and incorporate into the next follow-up campaign.

8. Conclude

• The software manager is able to share feedback results to audience.
• The campaign can be saved as part of a decision postmortem.
• The results can be saved to a portfolio

---

Using the language of JTBD, this product is “hired” to “do the job of”:

• Helping user feel like they made the right decision (emotional)
• Demonstrate stakeholder empathy & understanding
• Reader is perceived as researching how to communicate and build consensus

Other Notes:

• After Googling “communicating tech debt”, I found a wealth of resources on the front page.
• Literature review on Google Scholar using “technical debt social” as the keywords. Also: “social debt” keywords.