I visited an organization making an Agile transformation. It looked like the teams were making great progress. But the managers asked, “How can we tell they are working hard?”
Team members seemed happy with their cross-functional teams. They solved problems and worked things independently. Customers loved seeing working software on a regular cadence.
But the managers voiced their concerns:
How will we know …
that senior developers are doing senior level work?
they aren’t slacking off?
they are working hard?
I hear variations on these question in many organizations I work with.
Let’s look at the assumptions and beliefs behind these questions.
Emphasis on Individual Achievement
We have a legacy of emphasizing individual achievement. Formative experiences in school and HR policies (e.g., individual reviews and ranking) reinforce this. Finely grained job levels bolster the idea and contribute to “not my job” thinking. Narrow functional job descriptions (automation tester, exploratory tester, front end tester) have the same effect.
These managers don’t have experience–or organizational support–to think about group performance.
Beliefs about Motivation
Some people believe (other) people will slack off or make minimum effort unless pressured. Pressure comes in the from of deadlines, close supervision, “stretch goals,” ranking schemes, reward programs.
Research shows that these methods don’t work, and actually extinguish intrinsic motivation. Though, they may result in the appearance of working hard (or doing senior level work).
Organizational policies and management practices often work against motivation.
Concerns about Utilization
I’ve heard managers say, “They’re being paid 8 hours a day. I want them working 8 hours a day.” They want people fully utilized, and busy at all times.
Unfortunately, that doesn’t leave much time for thinking. Or coaching newer folks, or learning. Full utilization and busy-ness may create the appearance of working to capacity, but it is an illusion. In the long run, it works against increasing future capacity.
Worry about Social Loafing
During the 1880s, a French agricultural engineer measured the effort expended by people pulling on a rope. His experiments demonstrated that individuals exerted less effort when many people were pulling on the rope than when they pulled alone. And thus social loafing was born.
Social loafing has worried managers ever since. Other social scientists studied the phenomena, which eventually found its way into popular management lore. Failing to give full effort at all times (even when not required) takes on the tinge of moral failing.
Remember the old saying, Many hands make light work? Maximum individual effort isn’t the point. Coordinated, creative, effective effort in service of a shared goal is. Software developers are not pulling on a rope.
In fact, a well-functioning team makes hard work look easy. But many people have never seen (or been part of) a truly high-performing team.
A Thought Experiment
In these situations, I offer a thought experiment:
Suppose we formed four teams. After the new teams get their legs under them, they’re producing good results. Bugs are trending down, code quality is going up. Team members are happy. Customers are happy.
But you don’t know what each team member is contributing.
Then I ask, “Could you live with that?”
Most people say they could live without knowing each individuals contribution. A few say they need to know who to blame.
But that’s a different problem.
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
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.
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.
Esther,
You deleted my previous comment, why?
Rick
Nope. Just approved it.
Esther,
Oh wait… It’s back. Hmm… Strange. It reappeared after I posted again.
Maybe it’s a moderation thing.
Rick
Moderation thing.
““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…
Hi,
Thanks for a great post – it’s quite thought-provoking.
A question still remains: Are they really working hard? 😉
Rephrasing:
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.
The Hard Science of Teamwork by Alex Pentland http://blogs.hbr.org/cs/2012/03/the_new_science_of_building_gr.html
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.
Esther
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).