Recently, I met with a group of managers who work in an organization moving towards agile methods. People seem to be happy working on cross-functional teams. They solve problems and work things out without management intervention. Best of all, they produce working software that the customers like. This makes the managers happy.
But the managers have a lingering concern: How will we know that senior developers are doing senior level work? How will we know they aren’t slacking off?
I hear variations on this question in many of the larger organizations I work with.
So let’s unpack what might be going on here.
It could be that these managers have no experience how teams work together to produce results. They don’t have a visceral understanding of what it feels like to say, “We can’t single out one person’s contribution. We did this together.” Their own experience as managers in the organization reinforces the individual focus. In many organizations, management rewards and incentives leads to local optimization at the expense of over all goals–which obscures the interdependency of their work.
“Manager think” is shaped by emphasis on individual achievement in formative institutions such as schools, and by HR policies within their organizations. For example, individual ranking/rating systems ignore interdependency. Finely differentiated job grade levels reinforce the notion that its possible to put a neat box around each person’s contribution. Further, they focus attention on “doing my job” –or not doing a job that a more senior (or more junior) person should do–rather than on accomplishing a broader goal–such as delivering customer value. Narrow functional descriptions (automation tester, exploratory tester, front end tester) have the same effect.
Some people in management believe that if people aren’t pushed, pressured, and held accountable, they’ll slack off.
I have observed that many people are motivated by following through on commitments they themselves make. Many people find time boxes and deadlines useful to prioritize and organize where they spend time and attention. Commitments–made by the people doing the work–and time boxes can be useful structures.
Pressure, pushing, oversight work in a very different way (or, more likely, don’t work).These managers might be worried that people won’t do senior level work if no one is looking.
I actually find the opposite happens more often–people engaged in their work strive and go above and beyond. OTOH, sometimes people create the appearance of striving (and doing senior level work) when they are pushed, pressured, and “held accountable.”
Here are some of the “senior level” things I would expect to see on a thriving team.
- informal lunch and learns
- looking for patterns of problems in the code
- convening discussions about standards to address code quality
- initiating coding katas
- modeling good engineering practices
- task walls and a pull system for tasks
- delivering working code each iteration
- examining the teams practices and looking for ways to improve
Managers don’t need to be involved in the day-to-day tracking of technical tasks to observe that these activities happen.
Senior people don’t have to initiate these activities.
I’ve seen many teams where junior people–both in terms of time on the job and technical skills– lead in these areas. If only senior level developers initiate good practices, I worry that they’ve created a pecking order on the team, and junior people with good ideas don’t get a chance to contribute. (Its a variation on the HiPPO problem–deferring to the Highest Paid Person’s Opinion).
Sometimes I try thought experiments. I might say, “Suppose we formed four teams. After the teams have some time to get their legs under them, they’re producing results. They are getting software out the door, and the customers are happy. But you don’t know exactly what each team member is contributing. Could you live with that?” Most people say they could live without knowing. When they can’t, that’s indicative of a bigger problem.
Very often, the notion of social loafing comes up. Then we’ve reached the crux of the matter.
The original experiments on social loafing looked at uninteresting physical tasks. Some of the experiments involved people working under compulsion. But we aren’t talking about odious work done under compulsion–at least I hope we aren’t.
Remember the old saying, many hands make light work? People talk about social loafing as if it is morally wrong for one person to reduce his effort because others are working at the same task. I hear the same logic when a well-functioning team makes work look easy. Someone inevitably complains that if they aren’t struggling, they must not be working hard.
When people hold beliefs like these, the systems they build tend to be self-reinforcing, dysfunctional–and difficult to dislodge.
When people are in small teams, and engaged in meaningful work, social loafing is rare and working hard is common. But it might not look that way to someone who hasn’t see a thriving team.