14

I'm cursed with the blessing of a highly performing Scrum team.

One of the benefits of this team is that they function as a very cohesive unit. Each team member is bringing their own particular strengths, but they focus on the team's success.

As a result, it's proving difficult to figure out a way to give them a sense of career progression since it's hard to figure out how to promote individuals. Nobody is "standing out" because they're all standout performers.

The rest of the company maintains a more tiered approach to work and this lends itself nicely to a tiered org chart.

I've been asked to establish appropriate tiering for my reports, but it just doesn't seem to fit with the approach we take to our work. However, if I unilaterally reject tiering, I'm concerned that my team will see their peers following clear career progression paths.

Does anybody have any experience with dealing with this issue? Any examples of techniques that have worked? One approach I'm looking at is delineating tiers based on the impact that my team members have outside of the team (providing training for others, spending time helping other team with issues). Has anyone taken this approach? Did it work out?

Clarifications

  1. This is the only Scrum team in the company. The rest of the teams in the company are structured in more hierarchical ways which lend themselves nicely to a hierarchical org chart
  2. I'm not mistaken in my assessment that my team is made of standouts. There is no dead weight in the team. Week to week, one individual or another will stand out, but no one person stands out persistently over the others.
  3. My primary reason for wanting to fit in with the company-wide approach is so that my team members don't stall by being in my team and, when the time comes for them to move one, they're well positioned to do so.
  • 1
    Have you spoken to your manager or HR about this? I'm not sure what you mean by "appropriate tiering" nor is it clear what the rest of the company specifically does and how you believe it doesn't apply. – NotMe Jan 21 '15 at 19:46
  • My manager is a company founder and our HR department (such as it is) isn't really staffed to provide this kind of insight. – Dancrumb Jan 21 '15 at 19:47
  • Regarding tiering, the other development teams have 'senior developers' and 'architects' who distinguish themselves by taking all the ownership of issues and farming out work to junior developers; it's a very top-down approach, so tiering makes sense. Scrum is absolutely not like this. There's no hierarchy in the team - they're a team of equals. It's hard to make tiering fit here. – Dancrumb Jan 21 '15 at 19:49
  • Same as always; reward those who handle hardest issues, maintain highest individual cadance, deliver most value to the team both internally and, as you suggest, to customers both internal and external. Same evaluation any manager makes, except that, if anything, you have better records to draw upon. – keshlam Jan 21 '15 at 19:49
  • 2
    Is the team even asking for this change? If not and the founder doesn't know how to solve it, then why push it? Just leave well enough alone until one of those team members starts asking for a title change. – NotMe Jan 21 '15 at 19:52
8

Scrum is build on another set of assumptions. It doesn't have a hierarchy and it doesn't need promotions. By trying to apply your traditional management thinking to a performing team, you may only harm it. From a management point of view, get out of their way.

From a HR point of view however, your worries are reasonable. But you should keep in mind that not everyone wants a hierarchical promotion (in engineering horizontal careers are often preferred). Also you should think not only about promoting/rewarding individuals, but the team as a whole as well.

On an individual level, you have to have regular one on ones with the team members and listen to their own plans, desires, dreams. Probably they will have some career goals as well - it may or not be a promotion, some of the members may need better assignments that will provide them with experience in a field they are interested in, they may have side projects, or they may pursue different career path (like you are going to promote someone for a team lead of the developers, while what he actually wants is to be a DevOp or product manager or whatever else). Then figure out how you can support whatever the person wants to do.

Also, if the pay is not tied to the title beyond your control, you can provide higher pay / other benefits to the team members.

Next, consider how you can reward the whole team - recognition inside of the company, more flexibility, benefits, maybe allowing them to work on something of their own interest (contributing to open source project, developing developers' tools, etc.), provide them with access to the best tools, etc. For this you should also listen to the team members themselves.

In short, since they are self-organizing and they work great as a team, it's best to leave them to figure out how to reward and advance them in their own careers, and then provide them with everything they need.

4

Does anybody have any experience with dealing with this issue?

Sure.

It turns out that individuals don't particularly care about titles, or even pay when in the moment of working in a team. As long as your Senior Widget Specialist and your Widget Specialist work well together, treat each other with respect, and understand that they each bring different strengths to the team then you are largely free to have the official org chart however you want. You're free to provide compensation and title-only promotions however is needed to keep people happy and the team seeing that progression occurs. Your difficult job is to continue making people work together well as a team.

That said, your question leaves me with two major concerns:

  1. You seem to be assuming that your team is static. In the best of cases, scrum teams will shift based on what work you're doing, adding and removing people with the right skills to tackle the problems. While your current cohesion can be good for your team, it might be bad for the company. Worse, if your team is stuck on your team even with a promotion then you suddenly become the one who is blocking their career progression. Consider what opportunities exist for your team outside of your purview. This might not be relevant for these roles, but if your team cannot find their career advancement from you they will find it elsewhere.
  2. "Everyone is standout performers"? Unlikely. When you have a group of individuals, they are going to have some natural variance to their abilities. Sure, they each have their strengths, but some of those strengths are naturally going to be more valuable to your company - either from their rarity, or from their usefulness. When push comes to shove, who comes through? Coworkers largely know who the real stars are in their group, and hold no grudges if that person is compensated appropriately since it reinforces the idea that they will be compensated appropriately when they get better. Even on teams that focus on equality and teamwork.
  • Good points; however regarding 1), that's actually a big part of why I want to find a solution. Sooner or later, my team members will want to move on and I don't want them to be stalled because they were on the only Scrum team in the company. – Dancrumb Jan 21 '15 at 19:52
  • Regarding 2), here you are mistaken. I'm actually lucky to have a very highly performing team with no dead weight. Week to week, this individual or that individual might stand out, but over the weeks, the team excels as a whole. – Dancrumb Jan 21 '15 at 19:53
  • 3
    @Dancrumb - I'm not talking about dead weight. I'm talking about the team member who is a few steps ahead of the other excellent ones, or even who is marginally harder to replace. I might be wrong, but 9+ times out of 10 this "everything is awesome" perception is caused because of a disconnect between manager and the day to day work. – Telastyn Jan 21 '15 at 19:58
  • That's fair comment. I'll give that some consideration. – Dancrumb Jan 21 '15 at 20:00
  • 1
    +1. Don't confuse scrum with communism - your team members have different skills, different amounts of skills, and are worth different amounts on the open market. One may be a 'great' junior developer and another a 'great' architect - they're both great but if you reward them alike you'll be left with only great junior developers - I think you can bet they don't take everything as egalitarian as you think things are. – mxyzplk - Justice for Monica Jan 22 '15 at 22:42
1

It might appear easier for you to justify promotions and raises when you're working alone in a corner and coming out of it every now and then, being able to show off the work that you managed to do on your own, perhaps things that you chaotically struggled with.

You need me.

However, as you already know, the overall gain of the projects are way more per x individual when in a team since you have a common goal, peer criticism and retrospective, etc. It's just harder to see who did what without taking a closer look. And some don't take a closer look.

You need my team.

All you have to do, when discussing promotions or salary, is to talk about the gain of the team. You are a part of that team. You know it, they know it. It's up to you to remind them, though, about the milestones that your team reached.

You talk about the individual, of course individual skills matter as they're put into play in a bigger puzzle. It's up to you to identify where you came into that puzzle and explain how you contributed to the team so that it performed better than it otherwise would have.

You need me as a part of the team.

It's harder to identify those very specific contributions, but if you can have a clear vision of your contributions, on top of all of those great achievements that you're team is doing, then you should be just fine.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.