Pre-amble/tl;dr: I recently published The Lloyd Braun Principle of Agility mostly as a silly-but-true observation about how that classic Seinfeld line "Serenity now, insanity later" relates back to Agile. I ended that post with a statement about how we need to better prepare for the "Insanity" that comes later. With that in mind, I'm introducing my approach to building productive teams. It's about paying down your Systems Debt.
The modern tech team is broken. We rely too much on Seniors, and don't leverage Juniors.
I've been thinking about this problem a lot over the last year, as I've adapted multiple teams to our "new normal." Months ago, I began an article to support the case that hiring managers should hire juniors. To make an effective argument, I knew I had to address a common concern: "First I need seniors to train the juniors..." Quickly the article grew and grew.
If you're new to management, this is my "treatise" on Management. It's about how to build highly effective and productive teams and is based on more than a decade of successfully managing multiple large teams.
What follows is a long read - so the tl;dr is:
We talk a lot about #TechnicalDebt, but Technical Debt is a symptom of a larger problem I'm dubbing Systems Debt.
The recipe is simple:
1) Task your Seniors to pay down your Systems Debt, and make work easier.
2) HIRE. JUNIORS.
3) Stop fighting attrition. Juniors will stay for an average of 18-24 months. They want varied experiences. They will seek other jobs. As a tech community, we WANT Juniors to gain more experience on their path to Seniority. It makes them better, and it makes us better. So, let's embrace the attrition. Let's start focusing on enabling them to get the most out of those 18 months, and then support them on their next steps.
Any good delivery team emphasizes usability. The principles that drive usability appear in many different forms: the Pareto Principle, the Grandma Test, the Principle of Good Enough, and more. And all of them get at something very human: Is this harder than it needs to be?
We see it all the time: Minimalist designs that prioritize ease of use and are hyper-focused on a clear vision. Everything else is a distraction, it's bloat.
There are a whole lot of people talking about leadership, management, work/life balance, and remote/in-person work. Everything is being re-evaluated - and the question lingering in my mind for months now has been simply that: Is work harder than it needs to be? It’s by no means a new question, but it’s a thread that’s woven through most of my career. I love writing code and building products, but a holistic view can reveal that more code is not always the answer. More code means more training and maintenance costs.
If you’re a new manager, keeping this question in mind can be very valuable. Managers are responsible for a lot: you’re helping each individual - accomplish their deliverables and their personal goals. You’re responsible for the team’s cohesion, and direction. You’re often responsible for establishing processes and policies. Then there’s resource allocation and planning, as well as working around PTO schedules. But the guiding light to all this is that same question: Is this harder than it should be?
When is the last time you evaluated your internal mechanics? Thinking of your delivery team as a product, how easy is it for your consumers (the business/operations team) to achieve their goal? And thinking of your entire business as a product, how easy is it for customers to achieve theirs?
Focusing on the people, the same questions apply: How hard is it for your team to do their work? What structures, frameworks, contrived processes and hierarchies exist that would make your grandma shake her head at how much you've complicated things?
This whole thought train of critically evaluating your internal processes is, in fact, a part of the Agile philosophy that is often overlooked. Teams claim they are fully Agile, or an "Agile-hybrid" but taking a closer look you realize what they mean is they are simply cutting inconvenient corners to deliver sloppy products faster. When it comes to software, any seasoned developer will know exactly what this becomes a recipe for ever-growing technical debt. The ongoing joke of coders is that the last person did it wrong, and if you want it right, you'll need to rebuild it. This isn't due to laziness or lack of ability. Greenfield work is easier because it does away with all the technical debt - but, left to the same bad processes, it's only going to grow once more.
Technical Debt is a symptom, and even when you're good about actively paying it down - you're still only treating the symptom. This symptom comes from the mistake of thinking Agile is just about software delivery.
A proper definition of Technical Debt is the 'accumulation of work that needs refactoring.' As mentioned, it arises from taking shortcuts when focused on delivery. Unless you're actively paying it down, it grows rapidly. The result of too much technical debt is brittleness and instability.
At its best Technical Debt is an intentional decision: it's putting something on credit with the intention of paying it off later. In such cases, Technical Debt isn't bad - provided you are diligent about paying the debt down. The more nefarious incarnation of Technical Debt is when you unintentionally add to the debt, or worse - you are unaware that you have added to it.
Technical Debt deals with technology, but there's a similar concept of Process Debt - legacy processes that have grown stale, function poorly, create friction, impact cross-team dynamics, or may no longer apply as roles have changed. Process Debt covers our non-technical operational deficiencies.
There are still other forms of debt that impact delivery: Design Debt, Architecture Debt.
Of course, debt isn't inherently evil. Just like you can strategically carry a healthy amount of financial debt, taking on any of these forms of debt is a strategic decision. Instead of paying $20,000 on a car all at once, you take out an auto-loan and spread the payments over 10 years. Similarly - the technology stack you use, the way you've structured your team's skillset, the seniority of those roles, and the processes that drive your business take on a form of debt that gets paid down over a period.
Only - sometimes we don't pay it down. Or, worse: we think we're paying down debt but we're really accruing more.
I'd like to introduce a concept which I'll call Systems Debt (Systems as in Systems Theory; for more on Systems Theory read Donnella Meadow's fantastic Thinking in Systems).
Systems Debt is the overarching and root cause of the downstream forms of debt that impede or negatively impact delivery - whether through decisions from the business, or technical, architecture, or process decisions. It is the product of taking calculated shortcuts in the business, putting work on credit. System Debt impedes a functioning system through its structural design.
In Thinking in Systems, Meadows provides a simple example of a system: a bathtub. The input to the system is the faucet, the output being the drain. Meadows explains how different factors can cause the tub to never fill, stay level, or overflow. An optimum system is the water remaining level - with the input (faucet) and output (drain) flowing at the same rate. Systems Debt would be the consequence of taking shortcuts when composing the system. To stretch the bathtub analogy, maybe the faucet is poorly installed and water eventually leaks. Maybe the drain's location leads to water accumulating in certain areas so the tub can never fully drain. Maybe our water needs softening and causes lime to build up.
In these cases, there’s no immediate impact, and it’s still possible to create an optimal system - but what’s hidden is the accumulation of debt that is straining the system: the faucet has to flow faster to compensate for leaks, or the faucet flows slower and the tub takes longer to fill.
If you're familiar with Meadows’s book - many of her examples are rooted in reality with models generally providing a static vision; the system doesn't change over time. It's perfect for her purposes, but when it comes to individuals, teams, operations, and businesses, who we are today is not who we will be tomorrow.
To define Systems Debt in a slightly different way:
With Software teams, you see Systems Debt manifest in a few ways:
With Product & Operations teams, you see Systems Debt in similar ways:
To reiterate: All forms of debt are when we elect to take a shortcut now with the intention of fixing it later. Technical Debt is when we do this with code. Process Debt is when we do this with our formal processes. Systems Debt is when we do this at the organizational level. I prefer to see it as 'Systems Debt' instead of 'Organizational Debt' because thinking of the organization as a system, it means that Technical, Process, Design Debt are all directly caused by Systems Debt. The factors that lead us to take on Technical Debt are ultimately related to Systems Debt. ("You can only save so many people from drowning in a river before you start looking upstream to determine why they keep falling in.")
As an example: The development team is releasing a new feature that was properly planned and costed. The team has been on track but in the final stages encounter an issue that forces a dreaded question: Delay the release by addressing the issue properly or do the bare-minimum fix and then resolve it properly in the next iteration? They elect to take on the Technical Debt: "We'll get it on the next iteration."
This is now where Systems Debt begins to enter the equation. Will the team really be able to address it? Is the team adequately skilled to refactor? Will the business respond with "it's good enough, we need to move on"? Will future costing reveal it's now become too expensive to do the right way? Will a shift in priorities, or a surge in urgent issues, suddenly delay the fix by another iteration? Then another iteration, then another...
Additionally, looking upstream: why did it take so long to encounter the issue? What bad assumptions were made? Were they bad assumptions? There's always the issue you can't determine until late in the game - but then why did it become a question of delaying the release? Were promises made too soon? Should there have been a bigger buffer? Would this have been resolved if Person A (upstream business salesperson) spoke more to Person F (downstream developer) following the shortest chain?
Another all-too-familiar example comes with the infrastructure, architecture, and hosting models we lock ourselves into early on, based on assumptions on how the business will scale in 3-5 years. A small team may elect to take on infrastructure and architectural debt early on in favour of faster delivery than to adhere to the best DevOps principles.
Of course, it's easy to paint scenarios like this without the specifics - but regardless of the specifics and excuses for those specifics: Systems Debt will accrue. It's inevitable. That's OK - it just requires constant attention and focuses on paying it down to maintainable levels.
We take on debt - System or otherwise - as a shortcut. Before digging deeper into Systems Debt and how to pay it down, let’s first take a step back and ask why are we taking the shortcuts? Shortcuts, just like Debt, aren’t inherently bad - but they should be analyzed closely.
Thinking about physical shortcuts is a great way to start. If you’ve ever been a pedestrian or cyclist, you’ve for sure noticed how things are designed for vehicles first, pedestrians second. When you walk, you end up taking many “shortcuts” and don’t follow the roads - but of course, these aren’t shortcuts. These shortcuts are the as-the-crow-flies optimal paths for a pedestrian who can go where cars cannot. In fact, building our routes primarily for cars in pedestrian-heavy areas is [another form](another form) of Systems Debt.
In the business world, we take shortcuts to compensate - for lack of time, lack of budget, lack of resources, lack of accountability, or lack of taking a broader view. Time, Budget and Resourcing all get the spotlight - but accountability and a broad perspective are exactly at the heart of my opening question: Is this harder than it should be? When you’re saving people from drowning in a river, it’s taking that look upstream (broad perspective) and pointing to the person (accountability) who keeps pushing people in.
In other words: If you are going to have a serious conversation of Systems Debt, everyone needs to be a part of the conversation. Localized efforts only get so far.
Let's get back to that earlier question: How easy is it for your delivery team to deliver? If you've never considered this question, it's time to get some metrics! These metrics won't necessarily give you the answers but they're an important starting point. When it comes to KPIs, the best advice I'd ever received was that an individual KPI is neither bad nor good. It's objectively just a number, a value. It's your business-as-usual - and for you to decide whether or not you want to adjust that number up or down. If you're a fan of the OKR system or SMART goals, this is great because knowing your KPIs allows you to make better OKRs that are easily quantified.
So let's start with some basics and get down in the weeds. What follows isn't a comprehensive list, and there may be better questions suited for your group. Think of this list as a starting point to asking better questions.
These questions may seem familiar to anyone who tracks their team's performance - but remember to ask these at the organization level. The developer's Lead Time may have started from when the ticket was created - but how long did it exist in someone's head?
Getting a simple sense of how long it takes for something to go from inception to availability can be very enlightening - especially when it's a customer issue.
There are a number of resources that help improve the metrics above - but the key philosophy behind all this is: 1) Measure, 2) Analyze, 3) Resolve, 4) Iterate. The more issues Tier 3 can offload to Tier 2, the more Tier 2 to Tier 1, and the more Tier 1 can enable the Customer to resolve independently the more productive everyone becomes.
For comparison: Etsy is a great example of efficiency and makes for a great benchmark. Etsy ensures developers deploy to the production on their first day.
Given all the numbers and metrics behind the above, I'll reiterate that any of these numbers represent your business-as-usual. While they're not intrinsically bad or good, Systems Debt makes it harder to maintain these numbers long-term. Some numbers may be surprising and reveal areas where such debt may have already had an impact.
The next step is to consider how these metrics change overtime - as you've matured and continue to mature. As an example - the engineers who built the core product locked you into an architecture that is nearing the limits of its scalability. In these cases, teams look to how they can pay down the Technical Debt - but what about Systems Debt? Given a limited set of resources, an increasing risk of attrition, and a maturing business - how do you maintain the delivery KPIs while paying down Technical Debt?
Those are a bunch of bold statements in one heading. The point in it all is that: Being "helpful" to shortcut a process can be dangerous. If we subscribe to the idea that “what gets measured, gets done” the problem with being helpful is it often doesn't get measured.
Imagine a customer calling because they accidentally deleted a record in their portal when moving too quickly. They're short on time - and can't go through the process of restoring a record. They call in and your Customer Support employee, wanting to be helpful, immediately escalates to the database engineer who, wanting to be helpful, immediately restores the record. The customer is thrilled, the NPS score goes up. Everything is great, right?
Ignoring the obvious risks of someone updating a production database for a moment, there is a lot of valuable information that gets lost in being helpful:
Let's be clear: my headline is bold. But, I'm not advocating against assisting a customer - however, I think such actions should be followed with some root cause analysis. Nothing overly formal - but something to avoid a similar problem in the future.
In one organization, I improved our development team's productivity by 50% simply by implementing a Playbook. A customer calls in and they're courteously greeted by a Customer Support rep who follows a clear workflow towards resolution. If they can't resolve it, then we have a feedback loop so that they only ever escalate an issue once. The result was a more capable and skilled Customer Support team, a development team with fewer interruptions, lower stress overall - and, importantly, happy customers.
The point is that when helpful work happens in the shadows, you can't fix the root cause.
We see the same issue with the Rock Star developer who takes on too much work and responsibility to make up for a lower-skilled team - only for them to grow frustrated, get burnt out, and leave (a cost which can be devastating). Will Larson's great book - an Elegant Puzzle - does a great job of how to handle your "Rock Stars".
Seniors are critical to an organization and product's success - but they are equally one of the greatest risks.
For example, a Senior Developer will know the code base through and through. They know what's documented and what isn't. They'll know where it scales well and where it falls apart. They'll know where the skeletons are buried. We turn to them often - relying on them to build and design features, architect solutions, and help resolve the trickiest bugs. They are the knowledge gurus that can answer any question. They train and mentor the junior staff and are consulted when developing solutions.
Suffice it to say, plenty is asked out of the senior staff. It's an obvious statement, given their experience and perhaps vested interest in the organization's success. However, I'd submit, that this is where we take on the most Systems Debt.
Any senior staff member that progresses a deliverable is a shortcut that accrues Systems Debt.
I'll reiterate because it's easy to misinterpret. You can have a Senior team member work on a deliverable, but you must plan to pay down the debt that will have accrued in doing so.
Relying on Seniors for deliverables is a broken model - particularly in today's world where there are many Juniors and Skilled Entry-Level candidates, and the risk of Intermediate to Senior attrition is both high and costly.
The remote virtual workforce has made it more critical for any organization to elevate the junior/intermediate team while reducing the impact of Senior-staff attrition. This doesn't mean diminishing the Senior staff, but it does mean a structural difference in approach.
Using a generalization, today's Senior teams are largely responsible for the complexities behind systems: their experience and expertise produce mature systems, and the smaller task-based components are implemented by the more junior team members.
This is exactly the model that proves problematic when a Senior team member leaves, and also the structure that accrues Systems Debt. In this situation, the Senior is responsible for complexities and can step in to assist when the junior team cannot deliver (the "Rock Star" developer, as an example).
This problem is further exacerbated by the current staff attrition rate: for example, Junior developers nationally will stay in a role for 18-24 months (longer at larger firms). In other words, by the time a Junior reaches a point where they can begin to make more significant contributions, they're on their way out.
Organizations will fight to retain Senior staff, fight (somewhat) to retain Junior staff - and are constantly suffering from a knowledge drain. Ultimately, this is a losing battle - even if staff is retained, or new team members join, they're now in a position of having to pay down a large amount of Systems Debt.
Imagine a small Michelin-starred restaurant. The head chef is very involved in producing the plates, with dishes too complex to distribute among a team of cooks. The chef is the restaurant in this case.
Contrast this with the broader franchise restaurants. You have a head-chef back at Corporate whose responsibility is not to produce dishes that are consumed by customers. Instead, their goal is to produce reproducible dishes. Dishes that can be easily reproduced (while still being tasty). Dishes that are optimized such that the learning curve is minimal - new cooks can easily be trained to produce the dishes, and the loss of their eventual departure is less impactful. The head chefs also partner with efficiency experts to look at how the franchisee kitchen can be optimized for delivery.
This is the model we should use when we think of the modern team. The Senior team's responsibility should not be product complexity. It should be focused entirely on simplifying delivery: simplifying training and ramp-up, set up times, build times, streamlining lead and cycle times (across the board, from Sales/Product Solutioning, through to Iteration Planning, to Release).
How would you structure things if you know you can only retain people for 18 months? In fact, how would you structure things if you put them on an 18-month contract, with a hard termination at the end? You'd want the ramp-up to be as fast and short as possible. You'd want your team of experts to make sure your new hires can be ramped up in weeks so they can maximize the impact. You'd want to make sure your team of experts can keep a revolving door that maximizes efficiency and never step in to assist (for risk of building Debt).
In building a system that can be more adaptable, that can embrace and leverage short-term employment, you'll subsequently reduce the impact if you were to lose a Senior team member because the knowledge becomes immortalized in process, not in people.
Who taught you how to play tag? No matter where you are in the world, you likely learned to play this game from other kids. Adults don't need to teach the kids to play tag.
We think of memes as funny images, but the original definition of a meme is an element of a culture or system of behavior passed from one individual to another by imitation or other nongenetic means.
Tag is a meme. No one owns the rules. No one is responsible for improving the game. In fact, the rules are simple while still supporting variants like Freeze Tag. Furthermore, it can be adapted to different environments. It's designed for a revolving door of children who eventually turn into teenagers that are too cool.
There's very little Systems Debt to a game like Tag. Compare Tag to other playground games that require more players or more equipment... British Bulldog, Dodgeball, Duck Duck Goose, Cops 'n Robbers, Red Rover. Maybe you've played these games, maybe you didn't. These games carry slightly more Systems Debt. More rules, more equipment, or more players means needing more facilitators.
A rising tide lifts all boats. Seniors should be the tide, not the boats.
A guiding principle throughout my career has been to understand how the problem impacts productivity. It's not been to make more efficient teams but more impactful teams. Product Managers have a mantra of measuring Outcome, not Output. Efficiency matters when you know what you're doing, and you just need to do it faster. The impact is an amorphous, poorly defined, moving target. It requires adapting. It's why Agile principles, OKRs, Lean, and Kanban can be so powerful when used correctly.
Focusing on system-wide outcomes and paying down Systems Debt has given me the opportunity to be impactful in a variety of ways.
I wrote earlier that localized efforts only get so far and I stand by that. When the entire organization takes a critical look at how to be more efficient, that’s where you see real improvement. Localized efforts only get so far - but they do get far, and when they do, they bring with them the capital of influence.
I'll conclude with these final principles:
That's all! (He wrote, acknowledging the full irony of having written his longest article.)