Jeremy Jarrell

Agile Made Simple

Tag: team leadership

Solving Capability Debt Within Your Organization

“We know it’s broken…but we don’t have time to fix it.”  “Yes, we know it could be better…but we’ll fix it when we get farther ahead.”  “Yeah, it’s not great…but…

“We know it’s broken…but we don’t have time to fix it.”  “Yes, we know it could be better…but we’ll fix it when we get farther ahead.”  “Yeah, it’s not great…but there’s other things we need to deal with, first”.

If you write code then you’ve probably encountered codebases that have been described just like those phrases.  In fact, it’s such a common occurrence that there’s even a term for it: “Technical Debt”.  Technical Debt is used to describe code that is so hard to work with or so difficult to maintain that it slows down the overall progress of the team.

But, debt doesn’t just happen to your code…it can also happen to your process.  Ever had to track your time spent…across 3 different systems?  Or, have you ever had to create excruciating detailed documentation for a feature after it was written just to satisfy an arcane reporting requirement of your organization?  In either case, your organization was likely very aware of the waste that was incurred by the practice and probably even knew how to fix it.  Maybe they knew that it wouldn’t take much effort at all to write a simple integration for those 3 separate time tracking system that would let you track your time once and publish it to the other 2 systems.  Or, maybe they suspected that a feature’s test plan could perfectly fulfill that documentation requirement…if someone would only have the necessary conversation with the compliance team.

In fact, debt can even happen to your skills.  Have you ever performed a routine task for the 100th time but couldn’t shake the feeling that there’s probably a better way to do it…if you could only had the time to try?

Whatever the reason, if you’ve ever found yourself or your organization performing at a lower level than you should be…simply because you can’t find the time to invest in improving…then you’ve experienced Capability Debt.

Capability DebtCapability Debt can be thought of as any point of friction in your team’s software development flow that ultimately slows down the delivery of great software.  This could be redundancy within your organization’s process that the team must adhere to, regulatory overhead that the impedes the development process, or something that occurs in the act of creating software that everyone knows isn’t as good as it could be…but no one can find the time to fix.

Whatever the reason, the result is the same…wasted time and wasted effort in your team’s approach to delivering software to the market. But, just like Technical Debt, the answer is always the same whenever someone suggests addressing the problem…”we just don’t have time to fix that.”

In fact, often the situation is even worse than Technical Debt.  Since Capability Debt is often inextricably wound into the DNA of the organization itself, many teams assume that the there’s simply no way to address the friction that’s occurring so they don’t even try.

But, luckily there is a way to address Capability Debt, and if you’ve ever addressed Technical Debt, then the approach should sound pretty familiar.

What’s the Problem?

First, you need to identify the problem and it’s downstream result.  What is happening in the organization that’s slowing the team down and what effect is it having the broader organization?

In the case of the team tracking their time across 3 different systems, how much time is the team spending to do this?  Is there an hourly burn rate for that team that can can put a dollar value on this debt or is there lost opportunity in the sense of work that the team simply doesn’t have time to tackle due to the time lost?  However you measure it, there will be a cost involved with this effort.  Find out what it is.

Where Did It Come From?

Next, you need to determine how you got here. More often than not, Capability Debt is the outgrowth of some process that had a historical basis within the organization in the past, but is no longer applicable to how the organization currently functions. Understanding the origin of a specific piece of debt can be very helpful in understanding how difficult it will be to address and who can can help you do so.

Pay It Back

Finally, once you understand what the debt is and how it arose you can build a plan to remove it.  Maybe this will be a specific plan that addresses the debt once and for and all, or maybe this is just an experiment to try to solve the underlying issue that may or may not be successful.  Either way, just like with Technical Debt, once you can put a specific number on how much the debt is costing your organization then you’ll be more prepared to invest in a specific plan to remove it.

Solve It

Though Capability Debt arises from an organization’s overall process, it’s really no different than Technical Debt.  While there are often perfectly justifiable reasons why the debt exists, if it’s not dealt with swiftly then its effects will continue to eat away at your team’s productivity.  Investing in solving Capability Debt will keep your team performing at their top potential so they can keep delivering great software to market.

Want to learn more about solving common problems with delivery flow in your organization? Check out my course, Agile in the Real World, for tips and techniques for solving the most common impediments that you team may face.

Don’t have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

No Comments on Solving Capability Debt Within Your Organization

Velocity Is Not the Goal

Teams that post consistently high velocities are often treated as valuable to the organization. However, those teams that tend to be more erratic…posting a high velocity one sprint then falling off dramatically the next…may not be as valuable as they may first appear.

“ve·loc·i·ty (n) – a measure of how many points a team completes during a sprint.”

On velocity

Velocity is often the first scrum metric we encounter.  It’s a quick way to gauge how many points a team completed during the previous sprint, and how many they’ll likely complete in the next.  It’s clean, simple, and easy to understand.  It’s also easy for people to get attached to.

On predictability

Teams that post consistently high velocities are often treated as valuable to the organization.  However, those teams that tend to be more erratic…posting a high velocity one sprint then falling off dramatically the next…may not be as valuable as they may first appear.

The reason is that velocity isn’t as valuable as predictability.  Much of what we do in agile is done with the aim increasing the predictability of our team.  The more predictable a team is, the more effectively we can plan into the future.  This lets us take risks more intelligently as well as formulate more realistic strategies based on what our teams can likely deliver in a given timeframe.

Teams that post high velocities followed by low velocities are very erratic, and thus can’t be planned for.  And if a team can’t be planned for, then its value to the organization declines.

What’s the harm in an erratic velocity?

Erratic velocities can lead to difficult planning for any team.  Not only long term release planning, but even short term sprint planning will suffer since the team won’t be able to accurately forecast how many points they can complete during a given iteration.

If your team is experiencing erratic velocity, then it may be time to look upstream at your estimating process.  Often unpredictable velocities or missed forecasts are the result of poor estimates at sprint planning time.  Even exceeding your forecast can be a symptom of over-estimating the amount of work selected for the sprint.

Regardless of whether your estimates are missing up or down, your planning process is suffering.

So what’s the goal?

If velocity isn’t the goal, then what is?

Regardless of the hype surrounding ‘fast’ agile teams, at the end of the day agile is often more concerned with predictability than speed.  Posting a high velocity for one sprint isn’t helpful if your team can’t sustain it.  However, posting consistent velocity numbers goes a long way towards great planning.

Does this mean that a team shouldn’t strive to produce their velocity?  Not at all, it means that improving a team’s velocity shouldn’t be its goal.  Instead, the team should focus on what it takes to improve that velocity.  Practices such as continuously improving the engineering process or systematically identifying and chasing out risk will naturally result in higher velocity.

Focus on these things and the velocity will come.

Want to see more about how to make textbook agile work on real teams? Check out my course, Agile in the Real World, for tips and techniques for making agile really work in your organization.

Don’t have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

Comments Off on Velocity Is Not the Goal

Zappos and the Elimination of Managers

While the tagline Zappos abolishes Managers has gotten great press, in actuality it’s a bit of an over-simplification of what’s happening.

There’s been a lot of discussion lately about Zappos’ move to eliminate managers from their hierarchy.  If you haven’t heard yet, go check out the Fast Company article on the transition, which does a nice job of summing up the move.

While the tagline Zappos abolishes Managers has gotten great press, in actuality it’s a bit of an over-simplification of what’s happening.  In actuality, Zappos is transitioning to a new structure which organizes its employees in groups around work to be done, called a holacracy.  Rather than following a traditional hierarchical management system, this new structure tends to resemble self-organizing circles focused on individual projects comprised of employees selected for their skill sets.

Are there really no managers?

Perhaps, but that doesn’t necessarily equate to no leaders.  Reams of business literature have told us time and time again that given any group of sufficient size, leaders naturally emerge.  Whether we want them or not, this seems to be a a natural part of human nature…it’s in our DNA.

If this is indeed the case, then any attempt to eliminate traditional managers from an organization may be for naught.  Left unchecked, it wouldn’t be surprising for the exact same organizational structure to reemerge, sans titles of course.

However, this natural tendency to evolve towards structure may not be a bad thing either.  Elimination of titles and structure will effectively give Zappos the opportunity to press the reset button on their organization and allow the true leaders to emerge across the company.

Most organizations would kill for this chance.

What’s wrong with a traditional hierarchy?

Of course, this begs the question “What’s wrong with a traditional hierarchy?”  After all, history is full of companies which have become very successful under one.  However, the fact that traditional management hierarchies have not killed every company in history doesn’t exactly absolve them of guilt, either.

Imagine a small startup, perhaps made up of two co-founders.  It’s unlikely that one co-founder has asserted themselves as the manager of the other.  Rather, its more likely that the two co-founders view one another on equal footing and have come together due to the unique skills each has to offer.  In the early stages, even as a few more employees are added here and there, it’s likely that this culture will remain largely unchanged.

However, as the company becomes successful and begins to scale this organizational structure will not.

Eventually the leadership of the company will face a day when they need to introduce some sort of management structure to help the company scale.  On the whole they will be faced with two options: Flat or Deep.

Flat Hierarchies

Flat hierarchies tend to evolve when individual managers have responsibilities for managing large groups of people.

Flat Hierarchy

This particular structure seems to have come into favor in recent years, especially in the tech industry.  And for good reason too, as flat structures offer a lot of benefits:

  • Fewer layers of indirection between the people on the bottom of the organization and those on the top.  This tends to lead to more efficient execution of strategies set by the top ranks as the strategy is less likely to be watered down or changed as it passes through each successive rank.
  • The evolution of cross-functional teams.  Since less managers are available in the organization, they tend to accrete more direct reports.  One of the common side effects of this is those reports may not only specialize in the same field as the manager, but also those that are complementary.  For example, an engineering manager may not only be responsible for managing engineers, but may also be given responsibility for complementary teams such as quality assurance or technical writers.  These cross-functional teams tend to delivery more efficiently as the walls of bureaucracy are torn down.  In fact, this can even result in reduced in-fighting amongst groups that have to work closely together.
  • Faster scaling teams.  When an individual manager is already responsible for managing 12 people, adding one new employee to their ranks has much less impact than adding an employee to a manager who only has 3 direct reports.  This lets flatter organizations scale up teams more rapidly, for better or worse.

However, for all of the benefits of a flat organization they’re not without their drawbacks.

  • Less one-on-one attention from managers.  Obviously a manager whose responsible for 12 people has less time to spend with each than a manager whose only responsible for 3.  This translates to not only less time for one-on-ones, goal setting sessions, and mentoring, but also less time to simply get to know each employee on a personal level.  This can lead to less engagement amongst employees, less attachment to an organization’s goals, and ultimately, higher turnover.
  • Less mentoring to those employees not in the manager’s speciality.  Let’s return to our example of the fateful engineering manager tasked with responsibility for not only software engineers, but also quality assurance engineers, and technical writers.  If the manager’s background is in software engineering then they are likely to be an excellent resource for their reports who are also aspiring software engineers wanting to take their careers to the next level.  However, what about the quality assurance engineers and technical writers?  If this is not the manager’s area of speciality they’ll need to invest extra time in learning how to coach these employees, or risk having an overall lower skilled team.

Deep Hierarchies

Deeper hierarchies tend to evolve when organizations grow towards many layers of middle management, with each manager responsible for only a few direct reports.

Deep Hierarchy

This is a bit more of a traditional management structure, and can offset many of the disadvantages of flatter hierarchies described above.  Specifically,

  • More one-on-one attention from managers.  More managers means smaller teams which means that managers have more time to focus on each of their people.  This can translate into not only more frequent one-on-ones with each employee, but also more time for career planning and goal setting.  All of this translates into each manager getting to know each employee better and having more opportunities to imbue the organization’s culture and goals to the employee.  All of this can lead to more engagement for the employees and, ultimately, lower turnover.
  • More appropriate mentoring for each employee.  More managers also means that it’s less likely teams will evolve to be cross-functional.  Rather, they’ll tend to stay siloed in teams focusing on specific areas of expertise.  The benefits of cross-functional teams notwithstanding, increasing the likelihood that a quality assurance engineer will be mentored by a manager who built their career in quality assurance means that engineer can have more relevant mentoring and may reach their career goals quicker.

These benefits aside, however, deep hierarchies are not without their drawbacks.

  • Less efficient execution of strategies.  Just like the classic game of Telephone, no matter how great any strategy starts at the top, the more layers of indirection it crosses through the more likely it is to become weakened or watered down.  In the worst scenarios, it may even be corrupted to serve each individual manager’s own goals and agenda.
  • More silos between closely operating teams.  If you have more managers the temptation is greater to divide teams amongst specialities.  While this can lead to better management of each employee, the effect of these artificial barriers between teams working together each day cannot be understated.  Given any team structure the members of those teams will eventually grow to rival and compete against one another.  While a little competition is a great thing, it can easily get out of hand and evolve to resentment between teams working closely together.  Once started, this in-fighting can be difficult to reign in.
  • Slower scaling teams.  When a multitude of hierarchies exist in a given organization adding more employees can create friction.  This is due not only to the greater impact a new employee can have a smaller team, but also to the waves of indirect disruption the change can have on teams that work directly with that team.  While this effect may occur simply because the manager is more effectively managing their people due to the smaller team, the effects that it can have on an organization that needs to scale up and down quickly shouldn’t be ignored.

Will this scale better than a hierarchy?

Returning to our discussion of a holacracy, one of the biggest questions facing the this structure is how effectively will it scale?

Bearing in mind the points above regarding deep versus flat hierarchies, we know that larger teams, in particular cross-functional teams, tend to scale quicker than smaller and more siloed teams.  The holacracy seems to exhibit both of these larger and cross-functional qualities.  In addition, we also know that the elimination of a middle management layer could lead to a more effective execution of strategies since each team member has the opportunity to work closer to the top-level decision makers.  Whether or not this will be the actual result, however, remains to be seen.

While the lack of middle management may in theory give rank-and-file employees more access to top leaders, it also puts the onus on the employee to take the initiative for their own career growth in the organization.  This includes not only mentoring and growth opportunities, but also the adoption and incubation of the organizational culture and values across all employees.  Given what we know about Zappos hiring practices and resulting culture this may not be much of an issue for the average Zappos employee.  However, not every company has earned the reputation of hiring for passion that Zappos has, how this will effect other, less passionate, organizations remains be seen.

Regardless of the result of Zappos move to a holacracy I have no doubt that we’ll have plenty of visibility and insight in the results, due to Tony Hsieh’s transparent operating style.

I’m looking forward to seeing what we can learn.

Comments Off on Zappos and the Elimination of Managers

How to Build the Right Team

Did you know that payroll is usually the biggest expenditure of any software company? If you do, then it should come as no surprise that many companies tout the line ‘people are our greatest asset’. However, it can be scary just how little thought those same companies put into hiring the right people for their teams.

Did you know that payroll is usually the biggest expenditure of any software company? If you do, then it should come as no surprise that many companies tout the line ‘people are our greatest asset’. However, it can be scary just how little thought those same companies put into hiring the right people for their teams. Here are some things that we’ve learned over the years which have helped us continue to build the right team.

A-B-R. Always Be Recruiting

With apologies to Glengarry Glen Ross, the number one rule of the game is Always BRecruiting. Too many times a team will only think about who they would like for an opening just as that position is posted. This is the easiest way to guarantee that you’ll move faster than you meant to on a hiring decision and inevitably settle for a candidate. And, when you’re working on something as important as growing your team, settling is one thing you do not want to do.

So how do you prevent yourself from being forced to make a decision before you’re ready? By always having a pipeline of strong candidates available at any given time. We build this pipeline by constantly having a recruiting presence in our local market by getting involved in networking events, user groups, or by just encouraging our team members to get out and build their own relationships among friends. We’ll regularly troll user groups looking for people talking about the same types of ideas that we value as a team. Or, we’ll post our open positions to LinkedIn and Twitter which allows us to instantly reach out to former colleagues who may be in the market for a change. The goal is to constantly be building a pipeline of great candidates that is ready to draw on whenever a position opens up.

Know Your Gaps (And How to Fill Them)

At the beginning of each year, we make a list of the skills we have on our team and the skills we need…i.e., our ‘gaps’ for the more business savvy amongst us. The result is a list of skills that we know we need to get better at in the coming year, or that are missing entirely from our team. What’s interesting is that the vast majority of our gaps tend to be very niche skills rather than full-blown positions. For example, rather than ‘DBA’ we may list ‘SQL Server performance tuning’ as a gap. But unless we think our team of less than 6 can support a ‘Senior SQL Server Performance Tuning Specialist’ we’re not likely to be hiring it as a full-time position anytime soon. That leaves us with three options:

  1. Grow those skills in our existing team through training and education.
  2. Temporarily bring those skills in from outside through a consulting engagement.
  3. Find a candidate for an existing position who also happens to bring those skills to the table.

Finding a candidate who already has those skills can be a huge win, arguably even more so than growing them in-house since the incoming candidate presumably has real-world experience putting those skills to the test. But how do you find such a candidate? By looking at those who are already in your pipeline.

Imagine that you have an open Software Developer position. Now imagine that you have two equally skilled candidates applying for that same position. Both have several years of experience with the platform that you’re currently using and both have logged enough hours in your domain to wield the arcane terminology of your industry like a second language. However, one candidate worked to improve the performance of a large SQL Server backed application at his last job by tracking down multiple bottlenecks between the application code and the database. Remembering our skillset gaps from above the choice becomes clear. By hiring a developer who already has those skills not only do we fill an open position, but we also fill one of our gaps with someone who can share her experience with the rest of the team.

Don’t Hire Yourself

Let me be abundantly clear, in a team-oriented field like software development fit trumps all. How someone’s personality fits in with the dynamic of your team, regardless of how amazingly talented they may be, is the single biggest factor as to whether or not they’ll be successful. However, just because you’re hiring for someone that fits in well with your team, doesn’t mean that you want your very own Mini-Me.

One of the biggest results of the rapid evolution of our field is that there are now tons of moving parts to any software project and countless ways to handle each of them. Odds are that you’ve developed some pretty strong opinions about the best way to do each piece and, odds are, you’ll gravitate towards others who share those same opinions. Because, if we’re really honest with ourselves, we tend to believe that our opinions are correct by the virtue of them being our opinions. Hiring someone who shares those opinions can have some great advantages as long as we remember this: those that share our same opinions about techniques and technologies will inevitably share our same blind spots. This is true whether those blind spots are confirmation biases about a given platform, ignorance of emerging alternatives, or just misunderstandings about how an alternative technology works. Don’t perpetuate those same blind spots by hiring them again.


In a knowledge worker industry there is no single greater advantage that you can give to your team than to infuse them with good people. Why not approach this task with the same rigorous thought and attention to detail that you expect each member of your team to bring to their own tasks?

Comments Off on How to Build the Right Team

Type on the field below and hit Enter/Return to search