Bonus for Productivity?

The Whole Idea Is A Little Insulting

Scholtes' /The Leader's Handbook/ says that motivation through reward is insulting -- it assumes that you have been withholding effort all this time, waiting for someone to offer you an incentive to actually do your work.

Hadn't really thought much about it before.

But yes, it does assume you have effort on tap that you're not applying to your work.
And yes, it is a little insulting.
And yes, you could intentionally hold back until offered another bribe (but just enough not to be punished).

Everyone wants a little more money, but P. Scholtes notes that it's out of alignment with the idea of humanitarian management who realize that the employees are their greatest asset.

Not Only That, But It Doesn't Work

Likewise, Daniel Pink reports that rewards for knowledge workers tend to have the opposite effect of that intended. It might not be a good idea for programmers and managers in non-manual-labor fields.

Pink does mention that the system works great for physical labor.

Then How Do We Reward Team Members? 

At Industrial Logic, we have bonuses.

We have a health-n-safety bonus which we spend making our lives better. Some pay gym memberships. Others buy standing desks or treadmills or bicycles to help them keep fit.  It's not guaranteed every year, and the amount reflects profitability or generosity instead of performance.

We also sometimes have a profitability bonus, split evenly across the board, to celebrate another great year. We don't count on them, but they've been helpful to us as well.

The bonuses don't buy loyalty or effort. They're congratulatory and helpful rather than transactional.

Do you have any stories to share about your great (or awful) bonus system?

What do you feel about what Pink and Scholtes have to say about knowledge workers and bonus programs?

Too Many Developers?

My friend and colleague Curtis Cooley recently blogged "You Might Have Too Many Developers."

Overall, I agree that smaller teams move more quickly and swarm more effectively on task than large ones seem to, and that there is definite overhead with large groups.

You already know some developers are more effective than others. 

What if you could find 1000 within the 2000 that collectively are twice as effective as the other 1000?

Joel Spolsky has claimed the best programmers can be as much as 10 times more effective than the worst programmers.

The argument continues describing how many developers are much better than others, and are better in a smaller group than they can be when they are encumbered by less competent programmers.

I also agree that smaller teams of more expert programmers make sense on many levels and represent a savings in frustration, cost, and time.  

As Red Adair would say: "If you think it's expensive to hire a professional to do the job, wait until you hire an amateur."

Mythic "better people"

I don't think that Curtis is wrong. I have seen teams with too many programmers, staffed hurriedly with warm bodies or with badly-defined HR requirements and biases towards archaic styles of work and project management.

I've seen managers repeatedly hire and fire for the same position, complaining "why can't I find the people who can do what I want them to do?"

The Mythical SuperDeveloper

Should we consider a different question: Are we asking for feats that real people cannot perform?

There's an old saying about marriages that "If it's more than two, it might be you." I suspect this applies also to revolving door positions in a company.

Sadly, a lot of these revolving door positions exist when we are looking for unicorn developers -- magic omni-competent people who have hyper-productivity and efficiency installed in their DNA. People who never say no, never complain, and always deliver just the right thing on their first try and are never a problem to manage.

They are "better people." Programmers on staff, are, by comparison "not very good people" -- evidenced by the fact that we want more stuff than they can deliver. We're already frustrated with the system we have, and the answer must be "better people."

Deming has offered us the sound bite that 94% of our problems involve the system, and only about 6% of them are attributable to individuals.  That's harder to see when the work is largely invisible, as is the case with knowledge workers, instead of physical laborers.

It's just easier to see progress when work is motion and products are physical. All sympathy for that problem, but it goes wrong when we try to make management easier by treating knowledge work as if it were physical work.  Sometimes we want people who can do great information-type work as if it were great physical-type work, and who make management and measurement easy. Such is the nature of bad HR requirements.

Not recognizing the information-nature of the work makes industrial-age management a really bad system for managing software development, and "a bad system will beat a good person every time" Deming would quip.

Bad Systems?

Size may be the symptom of organizational dysfunction.

It may be that the organization isn't dealing with people well, and so it must have many of them. If it is only 10% effective,  it certainly feels as though the organization needs 10x as many people.

An organization's system may involve too much process around getting permission to do work, too many cycles through finished-work approval processes (reviews, QC, expenses, time reports). All of these can prevent quick feedback and learning. Without feedback and learning the productivity of programming is significantly limited.

The system may have strangled productivity so much that all the work being done is treated as a one-off rush job.

Perhaps the code base has been rushed so much that it has started to take its revenge in the form of immutable code and multiplying defects. There are always consequences for deferring crucial tasks indefinitely.

There might be a planning problem at hand, where the organization is trying to do large things in a single step. Without small steps (story slicing) and continuous delivery, there is no chance to exercise options. Instead the problem seems to be all about "going faster." Perhaps cutting scope is smarter and less expensive than adding headcount.

Or possibly you have evolved the system to work with 2000 developers during a rapid growth period only to find out now that you can't operate your current system as-is with only 200 or 20.  You will need a whole new (simpler) way of working to get back to being productive in small numbers.

Good Systems?

But maybe you have great people that you've worked very hard to gather and train and educate and you have given them reason to believe that you are looking out for their interests. 

Perhaps there are many of them because you've had such a great growth in the market place and having more experts (and a steady stream of new thought leaders) has kept you operational and cutting-edge. 

Maybe you are an extremely good organization with a great culture and your success has blessed you with fairly deep pockets. 

Maybe you are just looking for a way to continue operating, produce results well, and not break your commitment to the people who look up to you. 

You just don't want to let go of the people you have, and they don't want to go either. Maybe a lot of these people have shown leadership interest and potentially, and have earned jobs in management.

You want to preserve your organization because you have taken responsibility for the well-being of your chosen tribe.  Good for you. I see nothing wrong with that. I do recognize that it leaves you with some difficult questions and issues. I want to help.

Maybe the question isn't so much about how few people you really need, but how to maintain a humane, productive, innovative culture and introduce products now that you have the critical mass to take on many projects at once.

It may be that un-encumbering people by using a more lean or agile process will free up resources to do more creative and innovative work -- along the line of Google's famous 20% time. 

Curtis didn't say that you have too many people. He only suggested that you might. 

Individual Work Assignments: Neither Agile Nor Team

I managed to set off a small avalanche of retweets, agreement, and absolute angst in the past few weeks, when something I'd said sometime last year appeared as a quote in a lovely frame (thank you so much Agile Fortune!).

Here is the image for your enjoyment:

It seems that maybe I've touched on something that people are thinking about, and possibly on a point of contention in many organizations. 

Most traditional management has a focus on resource loading and utilization. What we are learning about people who do knowledge work (for instance, software development) is that utilization of resources is exactly the wrong idea. 

Let's explore what I had in mind when I wrote the tweet:

What is a Team, Anyway?

For now, let's put the whole "agile" thing aside entirely. It doesn't matter if you're agile or not. I can pick that back up in a few paragraphs. For now, concentrate on the concept of a team.

To team (the verb) is "come together as a team to achieve a common goal."

A team is "a group of people who work together" (MW).

C.Avery says "the task is the reason for the team" -- a team is a temporary organization created to complete a specified goal, and their alignment is a defining characteristic. They're not an arbitrary assemblage of persons.

In many organizations, what they call a team is "people who report to the same manager, but who never share any work items, who have separate areas of responsibility, and who avoid communicating with each other so that they don't interrupt the other person's task."  You should know that such a structure is no team at all. They don't share a common goal, they don't come together, they don't share a job between them, they avoid conversation.

My definition might be a bit of a higher bar:

A team is a multi-person shared headspace where all the participants are actively pursuing at least one common goal they intend to achieve together as a unit.

Developers who don't share work assignments are not a team; they are polite tenants in a shared building.

Tell-Tale Signs

A team is different from a group of individuals in qualitative and quantitative ways. One can sit in a single status meeting and tell the difference.

A group of individuals all have "their own work" and are responsible for clearing "their own plate."

They may have handoffs between experts, but they work alone and minimize conversation and interaction.

They may be stack-ranked, so they often feel they are in competition and frequently their goals are in competition with those of their "colleagues."

Groups of individuals all maintain separate areas of responsibility and separate sets of skills. As a result, very turbulent workflow results with less-expert developers waiting on experts to (solo) complete parts of tasks. While they wait, they take on extra tasks (to stay busy) and soon there are many tasks in progress, few finished, and developers become overwhelmed.

The individual style of work is great for defined processes (assembly lines, etc) but for knowledge work, it seems to suffer more drawbacks than group work.

A team works together to accomplish goals.

What is a Team Like?

Watch the first couple of minutes of Agile and The Seven Deadly Sins, and see what Mike Cohn says is a fundamental attribute of agile practices.

A team uses interaction to complete work quickly and well, and to share knowledge and skill to build group competence ("watch the baton, not the runners").

They are in profound cooperation and do not compete against each other. This is one of the reasons that Deming referred to performance appraisals as one of the Seven Deadly Diseases of Management (referenced also by Esther Derby's excellent article).

The work of an individual in a group cannot be assessed apart from the work of his peers.

In fact, individual assignments are considered an anti-pattern.

Teams are powerful, self-directed, and hard to "rank and yank." Individual awards and punishments don't apply. 

They're not as easy to manage as a set of individual drones who do as they're told, and whose work is solitary and easy to appraise. They're not under managerial control. But they get a load of work done and they learn and improve quickly.

What about that Agile stuff? 

In the tweet, I am not saying that you cannot be a team unless you are agile.

I'm saying that you cannot be truly agile unless you become truly a team. 

Agile methods require us to start and complete work in very small increments and to keep the code in a running state that is open to modification.

Consider two different situations at the end of a project:

• 100% of the work is 70% done
• 70% of the work is 100% done.

The former is an unmitigated disaster.
The latter is a workable situation and a qualified success.

Agile teams apply the maximum number of people to work on the smallest number of tasks, in order to bring each to completion soonest. This focus ("watch the baton, not the runners" in Lean parlance) makes it possible for us to have the most work completed and deliver it soonest.

Delivering high-quality, high-value code as soon as possible is the agile way. It's not something you can do well with a dozen people who don't talk to each other and don't sit near each other and don't converse or participate together.  

Without teaming, necessary code hygiene will be abandoned as individuals rush the maximum number of stories to done. The primary value of teams in agile organizations may be to slow the rush and ensure work is done well. Without this care, work becomes increasingly difficult to complete through the life of the project, which is frequently observed and misdiagnosed as "teams slowing down." 

If you are working incrementally and evolving your code base, then you have to be more strict about the quality of the code, not less. Any unmanageable changes come back to haunt you very quickly, and any untested code can be broken at any time by any number of people.

Without teaming, I'm not sure that any agile method can be successful. 

Without teaming, is it a team at all?