In one of our most recent articles, we examined what "technical debt" is, the impact it has, and how we can measure it through the concept of "drag." However, exclusively focusing on technical debt as a source limits the applicability and utility of determining drag.
More generally, drag should be thought of as a measurement for any active resistance that constricts your productivity. It’s an impediment that must be reconciled.
Expanding our understanding of drag is crucial because there are—at a minimum—three types that can plague individuals, teams, or an entire organization.
Let’s take a closer look at comparing each of them—and why “organizational drag” is the worst of the three.
When first introducing the concept of drag, we equated it to a relative way of measuring the amount of technical debt that an Agile software development team suffers from and must reconcile—both currently and as a ratio determined over time. More precisely, drag from technical debt is measured by comparing the story points from project sprints that add value against those spent on realigning the project’s architecture.
However, there are at least three types of drag to contend with. It can come from:
To recap our previous article on this topic, “technical debt” comes from Ward Cunningham’s metaphoric attempt to explain to non-technical audiences the challenge that occurs when a team’s understanding of the problem they’re trying to solve changes. It’s dynamic and only occurs when that understanding changes.
Specifically, “Debt” describes the misalignment between that new understanding and the architecture the team has built for the project so far. It comes from utilizing and adapting existing architecture, with the “payment owed” being increasingly difficult adaptions and feature additions as your development sprints continue.
It’s a challenge faced by virtually every Agile developer simply because of how the methodology works. Technical debt should be considered an unavoidable consequence—the trade-off of delivering functioning software on shorter timelines rather than year(s)-long waits.
The danger is less that technical debt exists at all and more when it’s allowed to accumulate to paralytic levels.
But what about these other two sources of drag?
Put simply, “cruft” is bad code construction—the thing many people mistakenly regard as technical debt. Examples of cruft include:
Cruft results in drag not necessarily because it’s difficult to adapt or add new features and functionality. Instead, it’s because the through- and outputs the team is working with during development are erroneous (or are far more likely to be) before any new work is even conceptualized.
In effect, cruft is no different than trying to code with your keyboard missing keys. No matter your future diligence, the project is simply broken or suffering from major obstacles in some way. Yes, workarounds are possible—even Ernest Vincent Wright managed to pen Gadsby without using any “e”s—but the burden is wholly unnecessary. Wrestling with it is, frankly, dumb.
The drag here comes from allocating valuable team resources and bandwidth toward identifying and fixing the issues cruft causes or determining those cumbersome workarounds.
And, ultimately, cruft and bad code construction are always preventable with reliable and knowledgeable development professionals who are committed to quality work.
Unlike technical debt that virtually disappears upon a project’s conclusion, cruft is apparent even after delivery. Users will regularly encounter cruft-based challenges when operating the software, which will harm your reputation and future business.
For future projects and implementations, clients will simply look elsewhere.
As described by Tim Ottinger, an Agile methodology thought leader, the user experience of wrestling with crufty software can be summarized by:
“If you are really careful, it will always work.
If you make a mistake, it may fail or just seem not to work.
It may do wrong things.
Now you CAN do your job using this software. It's hard to bring new people up to speed and they are always making mistakes with it, but a skillful and careful operator can use it successfully most of the time.”
As stated above, just because you can doesn’t mean you should.
Organizational drag can come from numerous sources, but it’s indicative and a result of problematic company structures, processes, and culture.
Two of the easiest ways to conceptualize organizational drag are the consequences of poor onboarding (e.g., insufficient or inconsistent acclimation and training) and a lack of development support personnel—whether in quality or quantity.
When onboarding doesn’t set up your new personnel for success, the ramifications begin creeping throughout your team and the broader organization. Flawed training and acclimation periods lead to flawed expectations on the part of both management and employees—whether overly challenging or vague.
And, together, they create flawed environments.
Your employees will lack both organizational support and personal investment, which will be reflected in their work. New hires will eventually learn the lay of the land and begin mimicking their coworkers' disillusioned and lax attitudes.
Incompetent managers are a self-explanatory problem, but if you promote from within this environment or continue the trend of poor onboarding for development support personnel (e.g., scrum masters), the same effects will occur at a much more damaging level.
Competency no longer matters because the organization itself is actively stacked against everyone. Even the most dedicated professional—regardless of their role or position in the company’s hierarchy—has a breaking point where they realize their effort just isn’t worth it.
Have you ever wanted to throw your keyboard after hearing "that's just the way it is around here" one too many times? Experiences like that are tangible examples of toxic organizational drag, directly resulting from environment and culture.
In addition, hiring too few development support personnel will overtax them and further exacerbate the situation. It inadvertently incentivizes corner-cutting practices during every sprint and reduces the essential positive interactions that managers and other support personnel leverage to cultivate a thriving and invested team—degrading your onboarding processes even further.
There’s a reason why IT professionals are known for experiencing excessive burnout: organizational drag isn’t just common, it’s closer to omnipresent.
When turnover rates are averaging 13.2%, it’s more than just the widely reported talent gap at play. Yes, there aren’t enough skilled techologists out there, but too many organizations are grinding their people down and driving them away. But, before they depart, increased cruft and technical debt happen as a natural consequence.
Both cruft and (excessive) technical debt negatively impact an Agile team, but they can be thought of as fairly self-contained to a given project.
Cruft will generally impact how well the developed software performs its intended function, but the consequences are unlikely to extend beyond a clunky, laggy, and error-ridden deliverable. It may reflect poorly on your team or organization, but with every new project, cruft is effectively reset by the blank slate of unwritten code.
Similarly, an accumulation of technical debt can—in theory—always be reconciled mid-project by throwing more effort (i.e., story points) at it, and, upon delivery, that debt effectively disappears.
Misalignment between your team’s understanding of the problem you're trying to solve and your architecture built thus far can always be addressed. The consequences are mostly constrained to longer deliverable timelines and ballooning budgets. Stakeholders will certainly not appreciate being notified of either, but the problem can always be remedied.
And excessive technical debt is a bit of a Catch-22 either way, as allowing it to accumulate and contending with misaligned architecture leads to the same result as remedying it regardless.
While continuous cruft and excessive technical debt may significantly affect a company’s reputation and long-term success, there are natural resets that an Agile team can count on and leverage as opportunities to recoup, recover, and prevent their recurrence.
In essence, that’s a major reason why teams perform sprint reviews.
And it’s a reason why unqualified, too few, or “too-dragged” development support personnel leading those reviews cause an exponential proliferation of the problem. At best, the causes of cruft and excessive technical debt are never resolved. At worst, they compound.
In contrast to these other two sources, organizational drag continuously persists and substantially impacts every project or hire—creating and exacerbating a higher likelihood of cruft and excessive technical debt.
There’s no reset of organizational drag without a considerable and conscientious effort to address it.
The easiest ways to rectify organizational drag return to the examples of onboarding and development support personnel mentioned above. Conscientiously overhauling either will make monumental strides towards reducing organizational drag and its cascading impacts.
For an excellent example, consider how Paragus—an IT services firm in Western Massachusettes—addressed its turnover challenge. No matter how many perks they provided, nothing seemed to change.
The sole thing that worked?
Dealing with the problem from a structural perspective and cultivating an environment that operated as the antithesis of organizational drag:
And Paragus’ growth definitively demonstrates the resulting impact. Per Delcie D. Bean IV, Paragus’ CEO:
“These efforts have been helping us continue to scale up, despite the challenges of today’s labor market. We’ve grown to 50 employees, and our company has hit $7 million in revenue, up from about 40 employees and $4.5 million in revenue in 2016.”
Other companies would do well to follow in Paragus’ footsteps.
We founded ScaleTech Consulting largely in reaction to the challenges of organizational drag. It’s rife throughout the IT industry, and we want to actionably address it, creating healthier workplace environments for the benefit of companies—and their employees.
When organizational drag is minimized, everyone wins.
Between our Transform and People Gateway services, we can debug the issues from both sides—helping organizations both reinvent their onboarding processes and work environments as well as find and hire top talent who will appreciate the effort and reward them in kind.
If any of the three main sources of drag are affecting your organization and teams—especially organizational drag—reach out and talk to us about a solution.
CNBC. A small tech company tried it all to stop employee turnover. Only one thing worked. https://www.cnbc.com/2019/12/03/a-tech-firm-tried-it-all-to-stop-turnover-only-one-thing-worked.html
LinkedIn. These 3 Industries Have the Highest Talent Turnover Rates. https://www.linkedin.com/business/talent/blog/talent-strategy/industries-with-the-highest-turnover-rates
Tim Ottinger. Twitter thread, May 17, 2022. https://twitter.com/tottinge/status/1526576395442434050?cxt=HHwWhMC9zZfJvq8qAAAA