I don’t doubt that its possible to have an organization with out traditional managers. I’ve read about Semco and Morningstar Farms. I’ve talked to people who work at Gore. My husband works for a less well know firm that doesn’t have traditional managers.
But those companies didn’t get there by happenstance. They got there by design. People chose, designed, evolved practices and structures to support a specific culture. They didn’t take off-the-shelf models of functional or product based organizational structures. They didn’t slide into typical for people management practices, organizational structures, job levels or reporting relationships.
Most companies settle for practices shaped by management thinking of the first half of the last century–without a second thought. The language of this thinking is mechanistic and dehumanizing. It’s the language of efficiency, compliance, hierarchy, rules.
If you want a different sort of company, start with using a different language.
For example, rather than talk about “managing performance,” talk about giving people the information they need to continually improve or sitting down on a periodic basis to examine how we can work better together. Does that feel different to you? It does to me. Those words offer a different set of possibilities.
Because we are talking about people and complex human systems, not moving parts in some vast machine.
“The thinking that got us here isn’t the thinking that’s going to get us where we need to be.” attributed to Albert Einstein
I have this niggling concern about retrospectives.
I have no doubt that retrospectives that are too short, don’t result in action / experiment, or fail to delve beneath the surface are a waste of time. (I suspect many retrospectives fall into this category, since many people teach that an entire retrospective consists of Keep/Drop/Add or some variant there of. This is seldom sufficient for deep or creative thinking.)
But what about earnest retrospectives that focus on an area of concern, examine data, analyze underlying issues and result in action? I worry that some of those fall short, too. Why? Because the thinking that got us here isn’t the thinking that will get us where we need to be.
People work out of their existing mental models. When they examine their current actions, they may achieve incremental improvements. But they may take a potentially useful new practice and kill it with 1000 compromises, shaping the new practice to fit the old mental model.
This can happen even when people are trying to learn a new way of working. The first OO program I wrote looked remarkably procedural– I was trying to wrap my head around the new paradigm, I hadn’t quite gotten there yet. In a retrospective, if people try to improve their agile practices, they may improve them right back to serial development. Or, people may make a genuine effort to improve, but they only know what they know, and the possibilities for improvement they can see are within the bounds of their current thinking.
So the task, then, is to examine the thinking and expand possibilities.
Single and Double Loop Learning
Single loop learning asks, “How can we do what we are doing better.”
Double loop learning asks “Why do we think this is the right thing to do,” and involves scrutinizing values, thinking, and assumptions.
Transformational improvement and significant learning come from making beliefs, assumptions, and thinking explicit, testing them, and experimenting.
Teams may need a little help to make the jump into the second learning loop, As teams are examining their practices, ask questions that help teams surface assumptions and test them.
What would have to be true for [a particular practice] to work?
[practice or action] makes sense when ___________.
[practice or action] will work perfectly when _________.
[practice or action] will work well-enough when_________.
[practice or action] will be harmful when__________.
What do we know to be true? How do we know that?
What do we assume is true? Can we confirm that?
Why do we believe that?
What is untrue, based on our investigation?
What do we say our values are?
If an outsider watched us, what would he say our values are?
What is the gap? How can we make the gap smaller?
How could we make things worse?
Chewing on a good subset of these questions usually helps a team see their assumptions, and take a different view on what has worked, what hasn’t worked as expected, and the reasons why.
Then, they are in a better position to choose a more effective action, or design an experiment that will help them learn what action to take.
Many managers ask me, “How can I motivate my team?”
I’ve certainly seen many efforts to motivate teams. Contests, prizes, pep talks, badges, points, canned thank you notes, and recognition events. Most of this comes down to using rewards to motivate people to continue certain behavior.
Some of these work for some people, some of the time. But most of them backfire, for most people, most of the time.
Consider these attempts at motivating:
A team lead receives a substantial sum of money when the team meets a critical deadline. Despite pleas from the team lead, management will not divide the money equally between all team members.
A developer worked late into the evening to fix a critical bug. His manager, wanting to motivate others to show similar dedication, gave the developer a ticket to the opening night of a big movie. One ticket—another night away from his wife and kids.
A programmer discovered and fixed an error that was costing the company millions. He worked with an account rep to provide data that allowed the company to recover a substantial portion of the money from erroneous invoices. The VP of the division gave the programmer a gift certificate for $100 at a local restaurant.
A manager singled out one person from a team for public recognition, and didn’t mention the contributions of any other team members.
A VP called a special meeting. When all the developers were assembled. He opened his brief case, which was full of cash. Every programmer received $300 cash money. When they got paid the next Friday, they found that the award was taxed, and taxed at a higher rate then their normal salary. Actual pay was $100 less than than they usually received.
Each of these attempts at motivation backfired. Many people (but clearly not all) know that rewards and other extrinsic motivators aren’t effective; in fact, they often diminish intrinsic motivation. And making one person the winner makes other people losers.
So why-oh-why do managers do such things? Do the managers who came up with these ideas (and others like them) ever put themselves in the place of the person they were rewarding, and asked themselves how they would feel if someone treated them that way?
I suspect not. But then, why wouldn’t they do so?
Some managers still assume that “workers” won’t work without carrots (or sticks). It doesn’t occur to them that carrots might not be the preferred diet.
Some managers don’t understand what motivates people doing technical work. Just look at the surveys that report what managers believe are the key motivators for developers, and what developers report motivates them. Major mismatch.
Some managers see themselves as different from “workers.” For example, they often believe that money is the primary motivator for “workers,” but they don’t ascribe such crass motive to themselves. Just like they don’t need carrots and sticks, but “workers” do.
Some managers can’t imagine that “workers” wouldn’t welcome some sign of management favor and approval. This is about power and status, pure and simple.
The zeroth step in boosting motivation is to stop doing things that demotivate people.
A while back I was talking to a manager who complained that “no one” in his organization was “accountable.” Of course, he exempted himself form that category.
This manager, (I’ll call him Tom) feels like he’s accountable— he knows that if they people creating software products don’t get their work done, he’ll hear from his boss, and it won’t be fun. So, Tom schedules meetings, hands out plans, talks about urgency and exhorts other people to do their work.
I asked Tom to draw me a picture of how the work was organized in his company. It was quite a tangle. The development groups (UI, DB, middleware, apps, test….) live in silos and report to different functional managers. The project managers sit is another organization, from where they coordinate project work across the development groups. Each project manager manages four or five projects. The development folks are likewise forced to multitask, as they spread their time and attention across a similar number of problems (and have 4 or 5 project managers telling them what to do).
The senior managers change their minds about priority—at the project level—every few weeks. Every one is busy, but not much gets done. Given the picture Tom drew, I was not surprised that Tom feels frustrated.
But Tom’s answer is that they need better people in the project manager and development roles—people who will be accountable.
Tom is not an anomaly. Many managers I talk to believe other people have no innate sense of accountability (what ever that means) and that no one holds them accountable. In fact, most people—regardless of where they stand in the hierarchy—feel that they are held accountable; sometimes they believe that others are not.
How can this be?
Accountability, the way Tom talks about it flows one way. There’s no sense of mutual accountability or partnership. The person telling the story is doing his job; others are not. The manager tells other people what to do, and they are supposed to do it—no matter that the deadlines are madness, people are forced to multitask, the goal is hazy, the requirements shift by the minute, and the folks doing the work don’t have all the skills to do the work.
When people aren’t “accountable,” I wonder what gets in the way of accomplishing work and makes the appear to be “unaccountable.” I wonder if the managers see their job as creating an environment for people to accomplish work. Or whether they think their job is telling people what to do, and then blaming them (read: “holding them accountable”) when organizational obstacles get in the way. And I think about the fundamental attribution error: When “I” don’t finish work or complete assigned goals, it’s because external circumstances prevented me from doing so; when you don’t finish work or complete assigned goals, it’s because of a character flaw—no sense of accountability, in this narrative.
When I look at Tom’s picture, it’s clear that the majority of the barriers are of management making. Deadlines, multitasking, unclear goals , shifting requirements and priorities, hiring unskilled people or failing to adequately train people are all management issues. But somehow that doesn’t come into the assessment of accountability.
When managers do their part and create work systems that makes it easier—not more difficult—to get work done, they usually find that suddenly they have people who are accountable. Accountability is about negotiation and partnership; it is not a cudgel to blame people for not meeting unilateral demands.
1. a : a source of supply or support : an available means —usually used in plural b: a natural source of wealth or revenue —often used in plural c: a natural feature or phenomenon that enhances the quality of human life d: computable wealth —usually used in plural e: a source of information or expertise
Economic or productive factor required to accomplish an activity, or as means to undertake an enterprise and achieve desired outcome. Three most basic resources are land, labor, and capital; other resources include energy, entrepreneurship, information, knowhow, management, and time.
Sometimes, when I hear people talking about “resources,” I ask if they mean people. Usually, they agree that they are talking about people, but the responses fall into two categories.
Some people have a moment of recognition, as if coming out of a trance, that “resources” isn’t the word they want to use. They know that people do work, and they’ve fallen into a habit, led there by the language of corporations and project tracking software.
Other people respond with a brush off, as if only an idiot would ask such a question.
What happens in the rest of the conversation is interesting. For the second group of people, even when they use the word “people,” they still talk about people as if they were “productive factors” in a reductionist universe, not living, breathing people.
And that’s a problem.
Productive factors may be fungible. People aren’t. Even when they have the same skills, people aren’t interchangeable. I tried a little thought experiment to see if I could imagine a job where people are fungible. Dishwashers? Are dishwashers fungible? They have no special skills, one is pretty much the same as the other. errrr….Not so much. On the task level, dishwashers might be interchangeable. But if you’ve ever worked in a restaurant, you know that not all dishwashers are the same and that the human characteristics of dishwashers can change the mood of the kitchen.
Productive factors may be required to have specific skills, and those skills are all that matters. The rest of the person is irrelevant. I sat on a panel recently, where one of the other panelist was a resource-thinker. Some of the people attending the panel discussion were training for a second career, and asked about trends in the current job market. According to the resource-thinker, the employment outlook for these folks was entry level work.
Some of these folks had managed dozens of people, run businesses, designed precision parts, taught school, managed inventory, or managed job queuing. All of these strike me as interesting when I consider how a person can contribute to a team or an organization. Apparently, none of that matters if you are a productive factor.
Productive factors don’t have personalities. People do. Even when people have similar technical skills they have unique preferences, qualities, styles. They bring their own experiences, points of view, ability to solve problems and relate to others. To ignore this is to ignore the importance of human communication and group dynamics in getting work done.
Productive factors are utilized. But thinking of people in terms of utilization leads to burn out. The resource-thinker on the panel talked about requiring 90-100% utilization after layoffs. Since he was in big consulting firm, that mean 90-100% billable hours, which are only a portion of the hours actually worked. Oddly, most resource-thinkers realize this about machines, but often forget it about people. When you fail to change the oil in your car, the cost are visible. But the cost of fixing a person (sick time) or replacing a person (after the burned out person leaves) is hard to count, especially on the local budget level.
Productive factors can be allocated–across many many tasks. (People in manufacturing recognize set up and switching time, many people managers do not.) I’ve seen project managers assign people to five or ten tasks in little tiny slices–15%, 10%, 5%–all in one week. There are lots of tasks that only take an hour or so. But assigning people 5%? Micromanagement. Task-switching. Utter lack of understanding of how most humans work. Many project managers reverse engineer their understanding of project management from software tools; maybe that’s where they get such ideas.
Productive factors don’t care about autonomy, mastery, or purpose.
Resource-thinking leads managers to focus excessively on labor rate. Labor rate is not labor cost. Driving labor rates down is very likely to drive labor costs up. Work gets done by people who can figure out how to work together. Managers who have a plug-and-play mentality about people may achieve lower labor rates, but almost certainly have higher labor costs.
Resource-thinking leads managers to ignore that work involves communication, interactions, relationships.
Resource-thinking sucks the soul out of work.
Our thoughts shape our language, but our language also shapes our thoughts. The zeroth step in creating humane workplaces is to start talking about the people not resources.
BTW, first know use of the term Human Resources was 1961. So much damage done.
I’ve seen lots of managers struggle to help teams. Often, they are driven by deadlines and goals set by their managers. They do what they think will help, acting out of their current view of how things work.
Sometimes they look for new ideas on how to manage. One of the ideas that’s been popular in the circles I travel is Lean. Lean suggests three things a manager should do.
1. Reduce overburden.
In manufacturing, overburdened machines break down. In knowledge work, overburdened people make mistakes, fall ill, or burn out. So help the team hold to a sustainable pace by managing the amount of work flowing into the team.
2. Eliminate unevenness in the work load.
The aim here is to create a steady flow. One way to do this is by using team velocity to allocate work (velocity is a measure of the completed work a team can finish within a specific time period). Create an even pace by allocating work in timeboxes based on measured ability to complete work. Over time, as the team matures, velocity may naturally increase. Even flow of work means predictable delivery.
3. Eliminate waste.
Anything that does not directly add value to a product is considered waste. Extra processes, task switching, and partially completed work are examples of waste.
These three things—reducing overburden, eliminating unevenness, and eliminating waste—work synergistically to increase the capacity of the system.
I don’t have a problem with focusing on these three areas. Many managers push too much work onto developers or demand overtime without understanding how that actually reduces the work completed (or completed to some quality standard). Many managers don’t understand how pushing to much work actually makes the work take longer–and paying attention to how work flows through the system is more important than looking at the speed of individual task completion. Many manager don’t understand the dynamics of work in process, the cost of multi-tasking or context-switching.
These things aren’t much taught in CS classes and barely touched on in many business schools. So it’s not surprising that they many managers don’t know about them. (I do wish people–managers and developers– would continue to study their chosen professions after they leave school, though. By that I mean study, not skimming a few articles. Though if they’re my articles, keep reading.)
And any tool (or piece of advice) can and will be misapplied. This is especially true when a tool is plucked from one context and applied in another and when the use of the tool is divorced from the thinking and philosophy behind the tool. (John Seddon has some comments on Lean and Tool Heads.)
But I digress. Back to the three-legged stool of Lean,
1. Reduce overburden
2. Eliminate unevenness in the workload
3. Eliminate waste
Sadly, to many managers start at the bottom of the stack, and never get past #3. And they start on #3 without a deep understanding of how the work works.
That’s where managers get into trouble. When managers focus on eliminating waste without attending to reducing overburden and eliminating unevenness–or understanding how the work works, they do enormous damage.
I hear about managers who approach this out of a cost-control mindset–and start looking for ways eliminate wasted money by making sure they are getting the most out of every employee.
On paper, , “efficient utilization of resources,” seems a like a Good Thing (assuming that you are not disturbed by referring to people as “resources”). After all, if you are paying someone for 40 hours a week, its waste if they aren’t on task for each of those 40 hours, right? That’s the thinking.
“Efficient utilization of resources” drives context switching, when people are assigned to multiple teams to achieve 100 % allocation. “Matrix teams” (which aren’t really teams, in my experience) look efficient, but impose communication and coordination overhead. When slack is gone people cannot respond to unexpected events and things fall apart. Task-switching makes everything take longer.
So hoping to do good, managers make the situation worse.
One manager devised this workflow in the name of efficiency, eliminating waste:
It did look quite neat and efficient on paper.
But the team wasn’t performing as he hoped and he wanted to “fix” the team. He was upset that they weren’t achieving the improvements inherent in his work design.
It turned out that the product had dozens of code modules, and each developer specialized in a handful, but knew next do nothing about the others. Under the managers design, as soon as a developer finished one piece of work, he should take the next item in the prioritized queue.
If he knew about that code module, the process worked okay. But chances were pretty high that he’d pull a module he didn’t know anything about. Plus, they got calls from the support desk, from the product owner team, and the production support team, all of which were considered as priority interrupts (by everyone, including the manager–which he some how forgot when he designed the work flow).
It looked more like this. The arrows show communication flows related to an unfamiliar code module. This picture only shows work for one person…it would be really messy if it showed more. (I also found it quite interesting that testing was a sort of mysterious cloud in this organization.)
Why so slow?
Interdependent work, non-fungible people, steep learning curves and multi-networked queues.
There were a bunch of ways to improve effectiveness at this company. But the fantasy workflow wasn’t one of them.
Rather than start with a slogan (“eliminate waste”), start by understanding how the work works. And that means understanding structures, behavior over time, communication flows. That’s management work. When managers take action without understanding the work or the theory, the result is seldom pretty.
So what is it that managers should do to move from big boss to partnership? It’s actually quite a long list, so let’s get started.
Expand Contextual Knowledge
In June, I wrote on how knowledge is bifurcated in many organizations. People at the top of the hierarchy know about the business model and the context (at least we hope they do) and people closer to the bottom of the hierarchy know how things really work, have technical knowledge and skills to build what ever it is the company builds. People at the top don’t know much about what it takes to get work done, and people doing the work don’t know so much about how the context. The extent of the bifurcation varies in different organizations, but once there is a hierarchy–even a fairly flat one–it shows up.
So one job is to extend the overlap between contextual and “how things really work” knowledge.
So part of what managers Dev teams need to know how their company makes money. This may seem painfully obvious, but somewhere in my distant past, I met a group of programmers in a financial services company who suggested that the fund managers avoid trading options because programming for options was proving difficult.
Once the programmers understood how much money there was to be made trading options, they figured out how to write the programs.
Dev teams need to understand how their company fits into the market and what their company’s aspirations are. For example, one manager communicated that the company aspired to handle 100,000 simultaneous users. Team members had this fact in their minds as they built the Web site incrementally. While the software they built in the first few iterations couldn’t handle the load, they made choices that made it feasible to build up to that level.
Some teams explicitly defer all decisions about the cost and benefit of building features to a product owner. But I find that the more team members know, the more they can ask intelligent and relevant questions that hone not only their own thinking but also that of their product owner partners.
The best way to understand customers is to see them in their natural environment, using the product.
You might use this little map (from Osterwalder and Pigneur) to talk about these topics.
What is our value proposition?
Who are our customers?
How do we build and maintain a relationship with our customers?
By what channels does our value proposition reach our customers?
What are our revenue streams?
What’s our cost structure?
What are our important people and resources?
What are our key partnerships?
Of course, we’re not looking for a mind-meld, where everybody knows everything that everyone else does. But when people understand what it takes to do work and how the work fits in the big picture, partnership becomes a possibility.
Questions matter. The questions we ask open one avenue of inquiry, but close others. If we want to change the way we manage, we need to change our questions. And so, here are my slides from my talk at Agile 2010:
14 Essential Questions aimed at refocusing management attention on creating work systems that work–creating products the customers want, returns that are acceptable to stakeholders, and providing satisfying work for employees.
Let me tell you a little story, a true story, about how our beliefs influence what we see in the world and affect our ability to solve problems.
Two years ago my friend Julia, who was forty-four and a bit portly at the time, starting experiencing troubling physical symptoms. She was fatigued, depressed, and generally uncomfortable. After several weeks, she went to the doctor. The doctor didn’t find anything specifically wrong.
Julia was sent home with a vague diagnosis and a prescription for Prozac. After a while her mood lifted and she felt less tired, but the discomfort continued. Finally, after several months and several more visits, her doctor determined she had a fibroid tumor that was increasing in size. He decided to remove the tumor.
Julia wasn’t happy to be facing surgery, but was relieved that after seven months of discomfort there was a diagnosis and a concrete plan. Two days before surgery, Julia went in for an ultrasound to precisely locate the tumor.
Based on the ultrasound results, Julia’s surgery was cancelled. Julia was sent home to prepare for the birth of her daughter—who arrived, full-term, two months later.
Now I’m willing to bet that you guessed the end of this story by the middle of the second paragraph. It’s obvious…if you don’t already have any particular beliefs about Julia.
Julia and her doctor, however, did have a belief, built up over years, that Julia would never become pregnant. And over the course of six months of office visits and medical exams, no one ever suggested pregnancy as the cause of Julia’s symptoms.
We could say that the medical staff were incompetent, but I would say they suffered from a belief problem. Their belief caused them to overlook information that was readily available—and also limited their application of the information they were using as they diagnosed the cause of Julia’s symptoms.
What does this have to do with software?
We all have beliefs about the world and other filters that affect what information we take in. Our beliefs, built up through education and experience, form the internal maps that help navigate the world we live in. Our internal maps can enable us recognize and categorize the vast flood of sensory inputs and think quickly. And often they are very helpful as general models of how the world works.
Other times, our beliefs keep us from seeing what is blindingly obvious to someone with a different set of eyes. It’s “as plain as the nose on your face” to someone looking at it without our particular set of blinders.
Take Tom the test manager, for instance, assigned to a team that had always operated on participative and consensus-based decision making. Tom’s framework for managing relied on his belief that, as a manager, he should entertain input from the group but make all final decisions on his own.
Soon after Tom was assigned to the group, the team was assigned to finish an evaluation of testing tools. Tom read the reports and listened to the group discussion, then closed his office door and decided which tool he favored. At the next team meeting, as he discussed his decision, he reminded the group that “we decided this at our last meeting.” Tom didn’t notice that most of the other heads in the room were shaking back and forth, indicating “no, we didn’t.”
Was Tom a bad manager? Maybe, but it’s hard to say based on one incident. What we can see is that because of his belief about how decisions should be made, Tom didn’t ask questions that might have given him direct information about how the group operated, and he also filtered out valuable non-verbal information that would have given him additional clues. As a result, he was far less than effective in working with the team…at least until he became aware that his map didn’t match the territory.
We often don’t consciously account for the existence of our internal maps, which makes them more likely to trip us up—just as Julia and her doctor, and Tom, our test manager, stumbled when their maps didn’t show all the ups and downs of the territory.
Our thinking process happens so fast that it’s extremely difficult to pause the process in the middle and ask, “What unconscious beliefs, filters or maps are influencing me right now?” The challenge is to pause between the time we reach an initial conclusion and the time we act on that conclusion…kind of like how we test a piece of software before we ship it to understand the quality of the product and the risk associated with releasing it in its current state. I have four questions I use for this pause in the mental process:
1. What have I seen or heard that led me to this belief?
This question reminds me to really look at what data my response is based on. If I hear myself saying something like “because its always been like that…” I send up a tiny little internal red flag.
2. Am I willing to consider that my belief or conclusion may be mistaken?
If I’m not willing to consider that I might be wrong, it’s a sign that I’m reacting out of a belief I’m pretty attached to…and it’s a clear sign I need to go to the next question.
3. What are three other possible interpretations of this situation?
If I can’t think of any other interpretations, it’s time to get some help shaking up my assumptions. I find a colleague I trust and we brainstorm as many different interpretations as we can.
4. What would I do differently if one of these other interpretations were true?
This gives me a wider range of responses to choose from, and increases the chance I’ll choose one that will help solve the problem.
When I start to test my conclusions, I can surface and examine my beliefs—my assumptions—about the situation. If I’m willing to admit that my initial interpretation might be inadequate, I can gather more information and represent the situation more accurately. And when I do that I open up the possibility of making better decisions, working more effectively with people, and—coincidentally—building better software.
This column originally appeared in STQE magazine in 2001.