Why the Popular & Easy Career Ladder Prevents an Agile Culture, Part 1

As I've been speaking about the Modern Management Made Easy books, people ask these questions:

  • We're pretty good with our agile approach. It's time for performance reviews. How do we reward someone based on individual work when we want teams to work together? What do we do?
  • Can we extend whatever that is to our hiring effort?
  • What does performance management look like when we want to reward people for their collaboration?

These people tell me their career ladder doesn't work to enhance agility.

The performance review problem helps them realize the source of this disconnect:

How can we focus on aperson's solo contributions to the work when we want to encourage and retain collaboration?

That disconnect occurs when managers, HR, everyone focuses on resource efficiency, not flow efficiency.

If we ask people to work in flow efficiency, how can we possibly reward them on resource efficiency?

We need to think and act differently:

  • How we define and offer jobs
  • What we encourage in the work
  • How we promote and reward people.

The disconnect is not one piece—it's an entire system. That system includes:

  • Career ladders assume people have linear careers.
  • We have very few effective dual-track career ladders.
  • Organizations reward people as individuals—but agility demands collaboration.

Let's start with examining the linear career fallacy.

People Enjoy Non-Linear Careers

I created and enjoyed a non-linear career.

  • First two jobs: software developer plus project management responsibilities. “Managed” one person who actually taught me how to be a manager.
  • Next couple of jobs: software developer plus intermittent project management.
  • Third job: tester. Added project management. Then transitioned to program management. Then moved to management: first-line manager, group manager, director.
  • Next job: director then program manager. Then director again (of a different group).
  • After a baby, returned to work as a developer. Then transitioned to management again.
  • Became a consultant.

Is my career that strange? No. It's not. People bounce between various roles. Why? When they bounce, they learn in a different domain. I learned how to collaborate differently, increase my learning, and how to influence at various levels.

When people learn more, they become more valuable to their team, the project, the product, and the company.

That means the career ladder needs to reward bouncing—not penalize people for bouncing. The career ladder needs to be—dare I say it—agile. Maybe a better way of saying this is that we want agility in our career ladders.

First, let's talk about a typical career ladder and how you get “ahead.”

Typical Career Ladders Reward Based on Individual Deliverables

Simplified Career LadderHere's a picture of a simplified typical career ladder.

I drew this ladder with just six levels. I know many of you work in organizations with 12-14 levels. Maybe more. I can't manage that many in my head, so I'm talking about this simpler version.

Notice these things:

  • The more you deliver complex deliverables, the more progress you can make. All that progress tends to be up and to the right.
  • Once you get to level 3, you have more options to move to the right and up the ladder—still based on your personal deliverables.
  • Most organizations do not value people moving from the middle or right-hand column “back” to the left-hand column. In other words, from process- or people-oriented deliverables “back” to technical deliverables.

This idea of this traditional career ladder can work if (and only if) we can separate any single person's contribution from anyone else's.

However, none of us work on solo projects. At a minimum, we get requirements from people or we deliver to customers.

More likely, we work with other people to create the total deliverable. I like to think of all deliverables as products. We need other people to create that product:

  • Other developers review a developer's code.
  • Testers test the code.
  • UI people help design the product.
  • A product person might visit with a customer and bring information back to the team.
  • And probably more people who support the product creation.

All those “other” people compose the team.

What about a “lead?” Sure, there are people who act as technical leaders. However, they can't deliver this product alone.

When we hire, reward, and promote people based on “their” deliverables, we ignore the entire system.

Solo Achievements Ignore the Real System of Work.

Many organizations attempt to reward and recognize people based on their “personal” deliverables. Those solo achievements do not tell the whole story.

Everyone—in any kind of cooperative or collaborative organization—requires other people to achieve “their” deliverables. That means we need to think about influence in various ways, instead of deliverables.

It's time for new career ladders. Those ladders can also support how the organization manages “performance” and “employee engagement.”

I'll talk about new career ladders in Part 2.

This is a series:

3 Replies to “Why the Popular & Easy Career Ladder Prevents an Agile Culture, Part 1”

  1. Great information. My one comment is it will fail if you have a manager that cannot work with people with more intelligence than they. I have seen may initiatives fail.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.