But are they working hard?

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.

  • pairing
  • mentoring
  • 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.

18 Replies to “But are they working hard?”

  1. I have seen this question and challenge occur with teams that have been working towards agile practices for 6 months to a year. And the good news is, they generally have a hunch that good things are happening — you’ve done a nice job giving direction of some specifics to work towards.

    In the past, I’ve recommended that if teams want to get a barameter on how the team is doing with the adoption that they look at things like the Nokia test.

    What other things should they look for if “quantification” would be helpful to the cause of the agile adoption?

    I do recognize that you shouldn’t measure for the sake of measuring, so I’m looking to help those organizations that need some data to help their cause.

    BTW – I love the use of Texting speak – OTOH

  2. Great post Esther! A team I worked with a few years back used to do Find Bugs (a code quality tool more or less) sessions with the whole team (programmers and testers). We’d spend a few hours in a boardroom in front of a projector looking at code and ploughing through the suggestions Find Bugs came up with. I found that to be a powerful team-building event on top of the value of having the whole team talk about how to improve the code.

    I like your other bullet points as well, I think they are great mechanisms to help a team thrive and I’ve seen the impact on the opposite end where teams “don’t have time” to do those things, usually have less-than-stellar “quality” outcomes which leads to management wanting more control, metrics or other (IMO) silly things to make sure everyone is doing their jobs properly.

  3. In the knowledge worker age that we are in. Working *hard* is a bad thing. Working *smart* is what people need to focus on.

    That’s a good topic for my blog at InnovativeSoftware(.info). I always announce the topic one post ahead. So, not next post but the post after I’ll talk about working smart not hard.

    Thank you for the post Esther. It not only taught me something. It got my juices flowing and I’ve come up with a new blog topic.

  4. Esther,

    Oh wait… It’s back. Hmm… Strange. It reappeared after I posted again.

    Maybe it’s a moderation thing.


  5. […] But are they working hard? – A look at the problems managers get themselves into when they concentrate on inputs (hours worked, “busyness”) rather than outputs (actual results); and when they try and attribute team results to individuals … most performance reviews completely ignore that individual achievements in a business context are extremely rare – most, if not all, results are a collective effort. […]

  6. ““Manager think” is shaped by emphasis on individual achievement in formative institutions such as schools, and by HR policies within their organizations.”

    It’s also shaped by the expectations placed on those managers and what they’ve “promised” (under duress as well as by virtue of ambition etc) to others.

    A manager who’s promised a deliverable by date x will likely fall foul of the “overtime issue” unless they’ve also got some practice at scope management, prioritisation etc.

    Summary: Manager behaviour is somewhat about education but also environment, Deming would probably have a lot to say on this…

  7. Hi,

    Thanks for a great post – it’s quite thought-provoking.

    A question still remains: Are they really working hard? 😉


    If I reduce the size of that 10 person team by 20%, can they still deliver at the same rate?

    Do they try to optimize and reduce waste or they embrace deficiencies because it gives them a chance to chill and browse a bit or engage in water-cooler conversations?

    Ok, I admit I’m one of those managers, but isn’t it a fact that people tend to slack, especially when the job is a bit boring and the environment is not exactly Google-like?

    • Hi, Tarek –

      It’s in a interesting turn of phrase…”reduce the size of that 10 person team by 20%.”

      Your words hide the complexity of the people and the team. The people on the team have skills, relationships, and interactions that make the team effective. You can not just lop of 20%. You take two people off the team. Which two do you remove? How does that effect the mix of skills, the relationships, and interactions? Remove two people, and you have a different team, with different capability.

      No, it is not a fact that people tend to slack. If people have boring work and a poor environment, what are /you/ doing to make the work more interesting and improve the environment? That’s your job!

      BTW, there’s some recent research that shows that the quality of informal conversation (what you call “water-cooler conversations”) has a lot to do with team success.

      • “BTW, there’s some recent research that shows that the quality of informal conversation (what you call “water-cooler conversations”) has a lot to do with team success.”

        Could you provide a pointer to that please? Thank you.

      • Hi Esther,

        Thanks for your response.

        I’m sure that making the work more interesting and improving the environment would help, but it’s not always feasible. Sometimes a team is stuck with doing maintenance for quite some time and that brings the morale down.

        Shifting people around helps but, again, not always possible since the people on the team have the complex domain knowledge.

        I checked out the article you pointed out. What I understood was that he meant the content of the conversation didn’t matter as much as how the communication was done, but I didn’t think he meant that the team could be spending extended periods discussing non-work related topics and end up being as productive as other teams who might be spending maximum 15 – 30 minutes a day on the same.

        However, what I’m really not buying yet, is how much the article deemphasizes the individual factor. My own experience is that one person with exceptional skills can have insights that can save the organization weeks and maybe even months.

        Also, an individual who is enthusiastic about his work will spend his free time learning new things that will benefit the organization where others will browse and chat.

        Maybe I’m old school, and maybe I’ll change my mind if I see enough evidence, but not yet.

        • Tarek-

          I have also seen individuals whose exceptional skills save weeks and months. But, I have seen people who are perceived to be exceptional cost the organization week and months. The truly exceptional individual are rare. Counting on those exceptional people to show up and do wonderful things isn’t a useful strategy. Better to create an environment that makes it possible for everyone to do their best and learn from each other so everyone improves.

          As for making maintenance work more interesting or motivating, the fact that you haven’t figured out how to make it motivating doesn’t mean it can’t be. One question I might ask is, “why is there a separate maintenance group?”

          As for convincing you, I have a feeling I could spend a year putting evidence in front of you, and you would still ask for more data. There is a lot of research about the team effect and about how the work environment supports or constrains performance. You can find it if you look.


  8. […] Esther Derby在她的博客上发表了一篇文章,在文章中她质疑了人们普遍存在的观念:管理者想觉察到所有的团队成员正在“努力工作”,而不是看他们交付物的价值水平。这篇文章的标题是“但是他们真的在努力工作吗?” […]

  9. Hi. Just discovered your work, & I agree with most things you write. But there is one point I’d like to react to(hoping it’s not too late) :

    “One question I might ask is, “why is there a separate maintenance group?”

    My answer is “because mixing project and maintenance activities does not work”. I’m experiencing it right now, at my expense. I’ve been recruited for making software maintenance(I like it), but I am sometimes required to make some project, too.

    Problem is, when in the same day, I’m doing both. Pace of maintenance is radically different. In http://www.paulgraham.com/makersschedule.html , Paul Graham speaks about the difference between maker’s schedule & managers’s schedule, and how they don’t mix well. My experience is that project is on maker’s schedule, & maintenance on manager’s schedule.

    The maintenance developper is always interrupted, makes a lot of very small tasks, does a few miracles, and then forgets everything & comes back home. The project developper had better not be interrupted, must think long-term, and brings back work at homen at least in its mind. If you are doing both, the maintenance will always take over, because its emergency nature will put you on an ever-changing pace. That pace is good for maintenance. It’s very bad for project. We, as a team, are congratulated for our maintenance work, but our projects are always late – we have tough time just to BEGIN them. The only successful project I’ve made on time here, I was not annoyed with maintenance, and it is not a coincidence.

    For motivation, most people hate maintenance as they see it a waste of their capabilities. Well, me not, but I’m unable to say why. But mixing it with some project at the same time(at least within a day, and probably even within a week) seems to me a medicine worse than the disease.

    (PS : please forgive my poor english, It is only my language number 3, not counting programming languages).

Comments are closed.