Metaphorical origins

When I began my career 25 years ago, building a house was the predominant metaphor used to understand key aspects of software development. In this analogy, stakeholders acted as the future tenants, specifying what needed to be built and at what cost. Programmers played the role of plumbers, carpenters, electricians, and other tradespeople building the house. Tension inevitably erupted after the initial phase of construction. Stakeholders would be surprised and upset, perceiving the house as a money pit:

• A new addition requires changes to the existing housing infrastructure. Why is rework necessary for a net new room?
• More tenants using the house causes the floors to collapse. Why can’t it handle a few more people inside it?
• After a few years and many changes to the house, a seemingly simple task like hanging a picture in the living room causes the furnace to break down.^[1] Why does every change inexplicably cause unforeseen trouble?

When applied to software development, the construction metaphor has many flaws. Its biggest one is creating an expectation that once software (the house) is built, it can easily be extended, and maintenance is minimal and predictable.

In contrast to the construction analogy, Cunningham’s technical debt metaphor is nearly perfect in its illustration of this core challenge of software development:

• Deferring technical work is like borrowing money.
• Refactoring is like repaying the principal.
• Slower development due to complexity is like paying interest.
• The whole project caving under a mess is like when the big guys come around and slam your hands in the car door for not paying up. ^[2]

This straightforward framing unlocked a broader understanding of the cost of tradeoffs and the need for maintenance when building software over an extended period. Non-technical stakeholders and engineers benefited alike. As I moved from senior engineer to tech lead to architect, technical debt helped me articulate why investment in technical work is critical. Technical debt was the topic of my first conference talk; I was so excited to spread the word!

Incremental expansion

As revelatory as it was, the initial definition of technical debt was imperfect; it didn’t account for unintentionally deferred work (caused by bad design, ignorance, etc.). Martin Fowler addressed this by expanding the definition and providing a mental model of reckless vs. prudent and deliberate vs. inadvertent technical debt. ^[3] Fowler’s extension of technical debt offers helpful nuance and strengthens the underlying metaphor. The same challenge of when and how to pay down the debt applies regardless of the cause.

Explosion of coverage

Not all expansion of a good idea is a good thing. A broadening of what technical debt covers occurred as awareness and understanding of it increased. Unfortunately, this accumulating scope muddied the metaphorical waters. One example of this inflation is an academic paper published in 2014 that identified 13 types of technical debt:

• Architecture debt
• Build debt
• Code debt
• Defect debt
• Design debt
• Documentation debt
• Infrastructure debt
• People debt
• Process debt
• Requirement debt
• Service debt
• Test automation debt
• Test debt

It’s easy to assume the good intentions behind this ontology. For example, infrastructure and automated tests are excellent examples of areas beyond core application code where the line between “good enough” and “too much” is highly subjective and debatable. Applying the lens of debt to these areas makes sense so they can be revisited and potentially improved later. However, debt categories such as “defect,” “people,” and “requirement” are all areas with typically well-established means to assess, track, and act upon them. What benefit is gained from framing them as technical debt? This overzealous application of technical debt opens the door to additional difficulties.

Organization as avoidance

Once an expansive definition of technical debt is established, a natural next step is to break down and organize what it encompasses. After all, a common principle in software development is to decompose the big problems. All the categories need to be clarified, all the instances accounted for, all the relationships between potential work identified, etc. This can certainly be helpful, but only to a degree. Classifying and quantifying technical debt can provide rough indicators of underserved areas of a tech stack or a need to recalibrate acceptable trade-offs during development. However, efforts to inventory technical debt can quickly become distractions and encourage busy work. As a result, engineering organizations become like my grandfather, a carpenter and a child of the Great Depression. He saved every screw, nail, piece of scrap wood, and old tool he came across in his work. Organizing all his odds and ends became a second job, yet little of what he saved was ever used. Likewise, I’ve seen too much effort spent configuring (and reconfiguring) Jira (or whatever ticket system you use) to categorize, quantify, and track technical debt “just right.” Individuals and teams mistake cataloging and sorting technical debt for acting on technical work.

Categorical infighting

Going further, expansively categorized technical debt creates motivation to use categories as a primary driver for prioritization decisions. Again, at a high level, classifying and quantifying technical debt can guide granular decisions on where improvements can be made. Individuals and teams can be encouraged to lean in a particular direction when navigating scope compromises. However, at a ticket-by-ticket or even project-by-project level, one type of debt will never be fundamentally more valuable than another. For example, security changes may or may not be more important than architecture updates. The details and larger context are critical to weighing the value of different types of work against each other. Decisions driven by categorization will fail to ensure the right work is done at the right time. When so much time and effort is invested in a complex framework to manage technical debt, limiting its influence on prioritization is challenging.

Bottom of the slippery slope

Further refinement and expansion of the technical debt metaphor have snowballed to a point where it is all-inclusive. I’ve seen and heard firsthand the following referred to as “technical debt”:

• Foundational work required to implement a feature
• All “non-feature” work

It might be tempting to assume the people who over-extend the idea come from outside the engineering discipline, such as product managers or high-level executives. However, software engineers have been just as culpable, if not more so. Humans crave mental shortcuts, and perceiving all debt as a whole rather than a long and ever-growing list of flavors is understandable. In the ticketing system, most people won’t register the type of debt indicated by a drop-down. They will simply notice that the ticket represents debt. Paradoxically, focusing so much on decomposing technical debt incentivizes many people see it as an opaque monolith.

No fun

When most, if not all, technical work is defined as debt, an aspect of the original metaphor becomes harmful: debt is perceived as a burdensome obligation. It represents something that could or should be put off for a long time, if not forever. Framing all technical work as debt defaults to it being a secondary concern to anything viewed as an investment, like features. Technical work is assumed to be a bottom-line obligation rather than a top-line accelerator. Classifying a large segment of potential work as debt diminishes its perceived value, especially when comparing it to “non-debt” work.

Mind the gap

Together, these problems with technical debt deepen the fundamental gap between the disciplines of engineering and product. Software development has long been divided into technical and non-technical (or “feature”) work. Separate processes are created for different roles to identify, track, and prioritize different types of work. For example, a typical pattern is the product manager stewarding “feature” work in cross-functional teams, with the engineering manager handling “technical” work. Managing technical debt has become an engineering practice when the ultimate goal should be inclusive cross-discipline prioritization.

Don’t call the language police

To address the counterproductive application of technical debt, one might be tempted to wrangle its definition closer to its original form. Given the high risk of coming across as pedantic, I hesitate to suggest this. “Well, actually, technical debt means something else…” Modifying language won’t reverse the inflated notion of technical debt that has taken hold, nor will it improve our debt management processes. More importantly, reigning in the concept of technical debt does not result in a net improvement in the gap between product and engineering.

Focus on value

Moving beyond technical debt means focusing on the inherent value of technical work. As much as possible, technical work should be evaluated based on clear goals, success measurements, and solid reasoning. Assessing technical priorities against non-technical priorities should be a direct, “apples-to-apples” exercise. Although this may seem simple, I’ve seen technical practitioners struggle to explain the value of work. I attribute this to a lack of history with doing so. For too long, we’re relied on the concept of technical debt to express value for us. Focusing on technical value requires technical practitioners to level up and for the organization to break down barriers between disciplines.

The emergence of technical debt was initially a boon for software development. Unfortunately, it is now getting in the way of the difficult but necessary challenge of understanding and prioritizing technical work against other potential work. The metaphor of technical debt deserves its exalted place in history. It’s also time to move beyond it.

Feedback is welcome via Bluesky: @computersandpeople.com.

Ticket-driven software development is an approach to development in which

• Ticket creation and work queue (backlog) management is primarily handled by an individual or small group, usually in roles such as engineering manager, product manager, project manager, tech lead, etc.
• Tickets defining work are picked up from a queue (or backlog) and completed by individuals with a limited say in ticket creation and queue management.
  Simply put, there are work creators/planners and work doers.

A few of the reasons ticket-driven development is problematic:

• Delivering real value becomes a secondary objective to completing a ticket. Individuals are incentivized to focus more on what is in front of them (the ticket) rather than the bigger-picture goals of the team, project, etc. Individuals are ill-prepared to notice disconnects between tickets or issues with individual tickets.
• In software development, designs and plans are never perfect. The outcomes of smaller pieces of work (tickets) are critical and necessary inputs to refining the plan and design as you move forward. Again, individuals are less able to participate in continuous refinement plans.
• If a project doesn’t go well, people tend to argue about ticket hygiene, discounting the many other factors impacting software delivery.
  Ticket-driven development directly opposes the idea of a highly engaged and self-directed team invested in continuous improvement.

I’ve come across a few different drivers for ticket-driven development. As an engineering manager, I found that each situation required a different approach to find success.

Seeking safety

In one situation, immediately after joining a new team, I realized the QA engineer was practicing ticket-driven development. Digging deeper, it was apparent the QA engineer was overworked, was dealing with an extremely high incidence of bugs, and was worried about being singled out for allowing poor-quality work to be released. In addition, the other team members spent significant time disagreeing, going down rabbit holes, and dealing with constantly changing priorities. Reverting to ticket-driven development was a safety mechanism for the QA engineer. They could avoid the drama overwhelming the rest of the team and ensure some structure in their QA work. If something went wrong, they could blame a poorly constructed ticket. The QA engineer was locked into their approach, hesitant to change, and adamant that they could get by just grinding through tickets.

Instead of addressing the ticket-driven development behavior, I focused on the upstream challenges within the team. I worked to align the engineers and product manager on priorities and decision-making approaches. Once there was some broader stability across the team, there was space for the QA engineer to engage in helping to define what work the team took on and how. They successfully transitioned to a fully engaged team member, with individual tickets dictating much less of their day-to-day work.

Well-intentioned cross-team efficiency

More recently, I supported two infrastructure engineers, who in turn supported four cross-functional delivery teams. The company's infrastructure was reasonably mature, and the engineers on the delivery teams were highly enabled, so embedding them on the delivery teams didn't make sense. The infrastructure engineers proactively guided other engineers on ideal collaboration and communication to avoid ticket-driven development. They wanted to collaborate directly with the delivery teams, not pull tickets off a queue.

Interestingly, software engineers on delivery teams still defaulted to a ticket-driven approach when working with the infrastructure team. They would create tickets in the infrastructure team’s Jira project and await a response. An oft-repeated mantra in software development is to minimize dependencies between teams, as coordinating work across teams is challenging and perilous. Sometimes, these dependencies are unavoidable, likely due to the organization's structure. Unfortunately, a reaction to mitigating risk and avoiding overhead can be defaulting to a ticket-driven approach. It took consistent effort by the infrastructure engineers and me to change this default behavior.

Individual preference

Over the years, I have worked with a handful of individuals who strongly prefer ticket-driven development within cross-functional teams. Reasons for this preference included:

• Collaboration with a broader team and engagement are perceived as counterproductive overhead, even in the absence of team dysfunction.
• A strong desire to minimize their workload as much as possible in line with their job title. They did their job well and were pleasant to work with, but they were adamant about the narrow scope of their responsibilities. (They wanted to “clock in and clock out.”)

In one case, the individual who preferred ticket-driven development was an engineer who reported to me. The individual was frustrating their teammates, given the outcomes of their work often misaligned with the team’s higher goals. The engineer pushed back against my guidance and feedback from their peers. I coached them out of the organization, understanding they were better suited for an environment that was not team-based.

In another case, an automation engineer was a member of the team I supported but reported to a different manager. My attempts to move the automation engineer beyond ticket-driven development were unsuccessful. In hindsight, I assumed more alignment with the QA engineer’s manager than existed. Although we agreed on the goal of highly collaborative, highly engaged, cross-functional teams, the other manager and I had different perceptions of how that ideally manifested. That manager saw the role of test automation as a “follow-up” activity to product development. I incorrectly and unproductively attempted to address individual behavior instead of focusing on the bigger context and aligning with the manager

There are cases where ticket-driven execution of work is appropriate. A customer support organization is one example. The danger is when this model is applied to an environment built on engaged, self-directed, cross-functional teams. Ticket-driven development is assembly-line development or, worse, Taylorism in action. Whether due to broader team dysfunction, well-intentioned attempts at cross-team efficiency, or personal preference, addressing the root cause of ticket-driven development is critical to mitigating it.

Feedback is welcome via Bluesky: @computersandpeople.com.

How do you balance, as an engineering manager, the trade-off between

• building a team that feels very psychologically safe, where everyone really likes to work with each other
• the need to split the team in half to accommodate company growth, new hires, etc.

People have expressed sadness and complaints, and no one wants to “leave” the existing team. How can I find a good compromise for both people and the company? Both sides are valid. Of course, the feeling of togetherness should not harm company growth, but I also don’t want people to leave eventually.

I empathize with the person asking the question. In my first managerial role, the organization was growing quickly and hiring extensively. After working hard to help build some great teams, I was tasked with pulling individuals from existing teams to establish new ones. One of the teams, in particular, was upset by this news. I felt very conflicted. From this experience, I learned that it’s important to remember that psychological safety is more about how you engage with direct reports regarding challenges and much less about shielding them from those challenges.

The manager who asked this question started off on the right foot by engaging with team members and hearing their input.^[1] Openly addressing challenging situations and seeking input are two crucial aspects of psychological safety. Most humans feel valued when they feel listened to. In addition, discussing the changes could reveal a valid reason to change plans. In this case, disappointment is the overriding input from the team members, which does not rise to that level.

Psychological safety also requires candor.^[2] In this situation, the manager must explain why the change is happening (the need to grow and absorb new hires) and convey that these business objectives take precedence over team member concerns (discomfort and sadness). Shielding team members from this reality is counterproductive to psychological safety.

Servant leadership also plays a crucial role here. The manager feels tension between serving team members and serving the company. Nonetheless, individual benefits can and should still be maximized within the company's constraints. For example, supporting new hires presents an excellent opportunity if existing team members wish to mentor others. Additionally, are any team members interested in formally or informally leading the establishment of psychological safety in one of the new teams?

Finally, the adverse outcome that the manager fears, an employee leaving, should not weigh heavily on their mind. After going through some version of team splitting a few times, I’ve seen individual feelings normalizing as people settle in with their new colleagues. If a team member cannot overcome their disappointment or adjust to the new normal, leaving may be the best choice for both them and the organization. A growing company with multiple new hires may not provide the environment they desire. They may be better suited for a smaller organization and/or one that is less prone to change.

While seeking compromise when splitting the team may seem like the right approach, the goal is to maximize the team members' positive outcomes in the context of the constraints. Psychological safety and servant leadership provide a means to navigate the change, not a reason to avoid it.

Feedback is welcome via Bluesky: @computersandpeople.com.