Tag: team leadership

6 min read

Dividing and Conquering: Finding the Right Size for Your Team

August 27, 2018 6:00 am August 27, 2018

6 min read

This post originally appeared on the PivotalTracker blog. Your small team has been doing great. You’ve delivered significant value to your stakeholders. You’ve shown noticeable improvement in how you work together…

This post originally appeared on the PivotalTracker blog.

Your small team has been doing great. You’ve delivered significant value to your stakeholders. You’ve shown noticeable improvement in how you work together sprint after sprint. And you’ve proven to your organization that this whole “agile” thing can work. In fact, your team has done so well that your organization has decided to reward you by increasing their investment in your team.

After all, if your team has delivered this much value with only a few people, then a team three times that size should be able to deliver the same amount of value three times faster. Right?

Not so fast. While it can be tempting to increase the size of a new team after that team has shown some initial promise, simply increasing the size of an agile team isn’t always the best choice.

How big is too big?

Although it may seem surprising, simply increasing the size of an already successful team is not guaranteed to increase that team’s success—and it may even put that team’s chances of future success in jeopardy.

A team is a complex system and increasing its size increases that complexity even further. As a result, it can become more difficult for the team to continue to function in a high-performing state.

One of the most common areas where this becomes evident is in the increase of relationships and corresponding interpersonal communication pathways that are present on the team. Adding one additional team member doesn’t merely add one additional communication pathway—it adds one additional communication pathway between that team member and every other individual on the team. This increase in communication pathways can significantly increase the complexity of that team’s interactions, especially when that team is following an agile practice that emphasizes face-to-face communication.

Handling the influx of work

However, an increase in the complexity of team dynamics isn’t the only challenge faced by teams who have suddenly increased in size. Another surprising challenge is the ability to keep your new larger team busy.

If asked, most organizations will say that they have more work than they’ll ever be able to finish. In fact, this is often the impetus for increasing a team’s size in the first place. However, what many organizations take for granted is how much of that outstanding work is actually ready to be worked on.

Much of an organization’s outstanding work is vaguely defined or only partially conceived. While this can be perfectly acceptable for work far down a team’s backlog, when a team suddenly finds itself with a sharp increase in capacity, this vaguely defined work quickly makes its way to the top. When this happens, the team suddenly finds themselves tasked with work that seems to generate more questions than answers. As a result, the team cannot process this work as quickly as they expected and their new velocity fails to meet the expectations that the organization had for the larger team.

To complicate matters even further, some of this work may be dated and no longer relevant to the product’s vision or may simply be of low value to the product’s stakeholders. Often a product manager will justify investing in this low-value work as a way of keeping a team busy while higher value work is found. However, this assumption ignores the ongoing maintenance costs the team will incur to support this new work as well as any potential increases in technical debt that were necessary to deliver that work. When the total costs to create and support this low-value work are considered over the long term, we often find that it’s more cost effective to simply keep the team idle until truly high-value work can be identified.

Keeping small teams effective

So, with the all of the challenges that can face larger teams, you may be wondering if simply creating additional smaller teams might be the right choice for your organization. In fact, many organizations find that this can be a very successful approach. Luckily, there are a few specific steps you can take to keep your small teams effective.

The first step is to keep your small teams…well, small. But how small? The Scrum Guide recommends that development teams stay between three and nine individuals. But even the upper end of that range that may be a bit too large for some tastes. Those of us who shudder at the thought of a nine-person team will be happy to know that studies from such management thought leaders as the Harvard Business School or the Wharton School of the University of Pennsylvania have placed the ideal size of a knowledge worker team at five. This means that if you are looking for the ideal size for your teams, around five members per team would be a great place to start.

But size isn’t the only consideration for building an effective team. You must also consider the mix of skills that will be present on that team. Successful small teams are structured in such a way that they are cross-functional and have the right mix of skills necessary to deliver an increment of product with minimal dependencies on other teams. For example, if your team’s delivery flow includes designing a compelling UX for your product, writing the code to realize that UX, and then validating that the entire experience works as expected, then your team should have UX designers, engineers, and testers all committed as part of the team. This will allow the entire increment to be created and delivered without the need of enlisting the help of external teams. This not only increases the team’s sense of ownership over the work they are delivering, but it also allows each individual team to operate more independently within the organization.

Putting this to work for your team

Finding the right size for your team can be a daunting task. Many factors can come into play, including the amount of work that’s defined and ready for your team to tackle, the mix of skills available on your team, and the steps your team must take to ship your product. But by keeping each of these challenges in mind while you structure your teams, and erring on the side of smaller teams, you’ll be sure to find the perfect size for your team.

Are you ready to learn the skills that will transcend any agile methodology your team chooses? Check out the course series ICAgile Certified Professional – Agile Fundamentals from Pluralsight to learn the underlying theories and values that will help you create real and sustainable change in your organization, regardless of the agile approach used by your team. This series discusses common traits of agile teams, self-organization, and, of course, how to discover the perfect size for your team.

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

No Comments

5 min read

Uncategorized

Should A Manager Be A Scrum Master?

Jeremy

July 23, 2018 6:00 am July 23, 2018

5 min read

No Comments

5 min read

In a recent post, I discussed whether the Scrum Master and Product Owner roles could be successfully combined. As you probably recall, the answer to that question was a resounding…

In a recent post, I discussed whether the Scrum Master and Product Owner roles could be successfully combined. As you probably recall, the answer to that question was a resounding “no”. In fact, the Scrum framework intentionally keeps these two roles separate in order to encourage a healthy tension between the needs of the development team and the ultimate needs of the organization.

However, when posing this same question in the context of the Scrum Master and the Development Manager, the answer becomes less clear. This is primarily because while the Scrum framework clearly describes the roles of Development Team, the Scrum Master, and the Product Owner, Scrum has no concept of the role of the Development Manager. This means that the Scrum framework offers no guidance to how this role should relate to the Scrum Master role.

Considering The Ideal Traits Of A Scrum Master

To better understand how these two roles might relate to one another, let’s take a moment to consider their responsibilities.

In addition to all of the responsibilities that are defined for Scrum Masters, one of the most important qualities of a Scrum Master is that they are viewed as a Servant Leader to their team. Servant leadership is a deep topic, but some of the qualities of a true servant leader are that they share power with their team, they put the needs of others first, and they put a strong emphasis on helping those with whom they work with grow both professionally and personally. In fact, one of the most telling traits of a servant leader is that rather than believing that their team is there to serve them, they instead flip the pyramid and believe that they exist to serve their team.

Comparing These Traits To A Development Manager

Let’s compare the approach of servant leadership to that of a traditional Development Manager. While there are managers who are exemplary servant leaders, the traditional definition of a manager is one who has functional authority over their team.

One aspect of this is that these managers often have hiring and termination authority over their team, which can significantly alter the dynamic that exists between the Scrum Master and their team.

In addition, many managers are also responsible for the day-to-day tasking of their team. While this may seem to be a simpler and more reliable approach for many organizations, it flies directly in the face of the principle of self-organization that a Scrum Master should be attempting to instill in their team.

Dreaming The Impossible Dream

With so many core differences between the Scrum Master role and the Development Manager role you might think that combining the two successfully is impossible. But this isn’t actually the case. While it can be incredibly rare, the right individual can find success in both roles.

To do this, that individual must be keenly aware of the responsibilities of each role and where they might conflict with one another. For example, such as how the expectation that a manager provide day-to-day tasking to their team conflicts with the very qualities of self-organization that they should be trying to grow in that team.

In addition, where these conflicts exist this individual must also make it clear to their team when they are wearing the hat of a manager, when they are wearing the hat of a Scrum Master, and when they are trading one hat for another. This explicitness in the role that they are currently serving can help provide the context that their team needs to best interpret the Scrum Master/Manager’s advice.

Making The Most Of A Bad Situation

While combining the Scrum Master and Manager roles can be challenging, it may not be without its perks.

Scrum Masters often encounter tough organizational impediments that can be challenging to resolve on their own. Such impediments might include responsibilities outside of the sprint that are distracting members of the Scrum team or an inability to secure key hardware or computing resources that are necessary for the completion of a key story. But by leaning on their role authority as a manager in the organization, Scrum Master/Managers can often facilitate the removal of these impediments much easier than that of a non-manager Scrum Master.

In fact, a successful Scrum Master/Manager can even use their authority to grant greater latitude to their team which better empowers their team to take on more responsibility, moving them closer towards self-organization.

So while combining the Development Manager and Scrum Master roles is far from an ideal situation. An individual with a keen sense of the responsibilities of each role can still find success in this difficult situation. In fact, the right individual might even be able to use the unique combination of these roles to their advantage.

Want to learn more about how to make Scrum work in your unique environment? Check out my course, Agile in the Real World from Pluralsight, for tips and techniques to help your organization get the most out of their Scrum adoption.

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

No Comments

6 min read

Uncategorized

Starting Your Team On The Right Foot With Team Chartering

Jeremy

May 7, 2018 6:00 am May 7, 2018

6 min read

No Comments

6 min read

This post originally appeared on the PivotalTracker blog. One of the best things that you can do to help your team deliver great products is to make sure your entire team…

This post originally appeared on the PivotalTracker blog.

One of the best things that you can do to help your team deliver great products is to make sure your entire team is starting off on the right foot.

A great way to do this is by creating a team charter, which is a document that formally describes how a team will work together. But in order for a team charter to be effective, the entire team must be vested in its output. To accomplish this, they must be actively involved in its creation; otherwise, if the team feels like the charter has been forced upon them, they’ll be more likely to reject it.

If you’re lucky, all members of your team will be fully committed to your team.

Defining How The Team Will Work Together

Team charters are often created as the team first begins to take shape and may persist across multiple projects throughout the team’s lifetime. While many of the specific details of a team charter may vary depending on the type of product the team is creating, the technology stack they are working with, or even the dynamics in play in their broader organization, generally speaking, most team charters will answer the following questions:

What Is The Vision For The Team?

The team charter should clearly state what the team will accomplish together. For example, if your organization is making its first foray into the mobile space, then the team’s vision may be, “To successfully deliver the organization’s first mobile application to market.”

What Are The Team’s Values?

The team charter should also define what qualities will be important to the team as they accomplish that vision. For example, does the team prize craftsmanship in the code they create, mutual respect across the entire team, or active learning and continuous improvement? Regardless of what values your team holds dear, asking them to actively consider and commit to those values greatly increases the chances that they will be upheld.

Who Is On The Team?

If you’re lucky, all members of your team will be fully committed to your team. However, many teams must contend with members who are shared across multiple teams or who are available to their team but not actually a part of it. A team charter should clearly specify who is on the team and in what capacity to help address directly any ambiguity about each member’s availability.

This is also a great opportunity to clarify what the roles of each member of the team will be. Simple roles such as Product Manager, Engineer, or Tester are often more than sufficient to help the team start to form a picture of how it can work together, as well as help new members quickly orient themselves to who they will be working with.

What Are The Ground Rules For The Team?

Finally, the team charter should clearly define what will be expected of each member while they are on the team. Often these expectations will be influenced by the values that the team stated earlier in the chartering process. For example, if your team values face-to-face collaboration across the team, then they may establish a ground rule that all members of the team are expected to work in the office during established core hours. On the other hand, if your team values individual responsibility, then they may establish a ground rule permitting working remotely, but clearly specifying by what communication channels each team member is expected to be available.

Regardless of what rules your team specifies, they should make it clear what is expected of each team member if they wish to remain in good standing with their peers.

Keeping The Team Charter Relevant

While your team should periodically have the opportunity to revisit their charter to ensure that it accurately reflects the way they want to work, this should not occur too frequently. Your team’s charter should serve as a touchstone for how the team will operate and changing it too frequently will inhibit the team’s ability to absorb the way of working they’ve defined for themselves.

Ideally, revisions to the team charter will best occur alongside major milestones or other opportunities for reflection and long-term planning. For example, after your team ships a major release of their product might be a good opportunity to consider revising the team charter based on the team’s experience in the last release. Or, if your organization operates on an annual planning cycle, then this can also be an opportunity to revisit the team charter’s in preparation for the coming year.

Even if your team has already formed without the benefit of a charter, it can still be beneficial to go through the process of creating a team charter. Creating a team charter with a team that is already established can be a great opportunity to level set a high-functioning team to ensure it continues operating at optimal levels, or even to reboot a team that may struggling. In either case, creating a team charter can give your team the opportunity to identify and capture what’s working well as well as to voice their concerns about what isn’t.

Getting The Most From Your Team’s Charter

Regardless of the terms that your team specifies for their charter, to get the most out of it the entire team must commit to respecting and honoring the terms they’ve agreed to. In addition, the team must also be committed to offering feedback on the charter and incorporating that feedback into future versions when opportunities for improvement arise.

If your team is committed to creating a charter that adds value to the way they work, and then honoring that charter after creation, then a team charter can be an excellent tool for starting your team on the right foot towards delivering a successful product.

Want to learn more about helping your team reach their true potential? Check out my course Scrum Master Fundamentals: Growing Yourself and Your Team for more tips on helping your team become their very best.

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

No Comments

5 min read

Uncategorized

Solving Capability Debt Within Your Organization

Jeremy

October 23, 2016 7:20 am October 23, 2016

5 min read

No Comments

5 min read

“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 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

3 min read

Uncategorized

Velocity Is Not the Goal

Jeremy

March 26, 2014 7:16 am March 26, 2014

3 min read

Comments Off

3 min read

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

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

9 min read

Uncategorized

Zappos and the Elimination of Managers

Jeremy

January 28, 2014 8:09 am January 28, 2014

9 min read

Comments Off

9 min read

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.

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.

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

5 min read

Uncategorized

How to Build the Right Team

Jeremy

February 14, 2011 8:27 am February 14, 2011

5 min read

Comments Off

5 min read

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.

A-B-R. Always Be Recruiting

With apologies to Glengarry Glen Ross, the number one rule of the game is Always Be Recruiting. 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:

Grow those skills in our existing team through training and education.
Temporarily bring those skills in from outside through a consulting engagement.
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.

Summary

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