Tag Archives: work system

Last week, someone tweeted that the C-suite “gets agile,” but middle managers “resist” it. I also saw a tweet that the C-suite doesn’t get agile, but middle management does.

I don’t doubt the observations of either of these tweeters.

I have observed situations where both senior and middle managers saw the value in moving towards a team-based organization and iterative incremental delivery. In my experience, it’s a little more common for middle managers to hold onto the existing pattern. And why not? When they don’t see their place in agile they don’t embrace agile. And agile is silent on the role of middle management. Blanket statements that dismiss the need for managers or management don’t help.

Organizations moving to agile still need management, and often still need people in management roles, especially in large complex organizations. In traditional hierarchies, middle managers look up the hierarchy for direction, and focus down the hierarchy to accomplish cascading goals. When teams pull work from queues and self-organize to meet goals, the real opportunity for middle managers is to look across the organization to improve the system and develop people and teams.

So what do middle managers do when they aren’t directing day-to-day work? Plenty.

Now you see some of the things middle managers can do to help their colleagues, their managers, and teams. Do you need help shifting the role of middle managers in your organization? Give me a call or drop me an email.

Agile methods depend on effective cross-functional teams. We’ve heard many Agile success stories…at the team level. But what happens when a product can’t be delivered by one team? What do you do when the “team” that’s needed to work on a particular product is 20 people? Or 20 teams?

There are no simple answers. But there are design principles for defining workable arrangements when the product is bigger than a handful of agile teams.

I recently did an interview with the nice folks at Softhouse.se for their Lean Magazine. The interview was a lot of fun, and made me think (which is fun).

The full interview will be in their special anniversary edition, schedule to be out by Christmas. (Information on obtaining the magazine here.) In the meanwhile, some thoughts on the role of managers….

LM: We notice a lot of confusion when we meet managers.

They see a new behavior in their development teams that have started to work according to lean/agile principles and usually the development teams are happy with the change.

But as a manager the questions comes up ñ what should I do now? how can I support this? how do I avoid to destroy the good things?

What is your message to these confused managers? What can they do?

E: Don’t tamper if things are working. Ask what is getting in the way, and go fix it. Ask what the team needs, and obtain it for them. Ask what you can do to help. If the team says “nothing,” don’t inflict help.

The truth is, when teams are working well, managers don’t need intervene. The hard work is in establishing a real team and ensuring enabling conditions are in place. When managers of self-sufficient teams feel like they aren’t doing much, it’s a sign they’ve succeeded. But managers shouldn’t abandon the team. Teams need support and a connection to the organization.

Managers still have an important job to do, working at the system level. Collect metrics that will give a window into the system. Start by tracking the ratio of fixing work to feature work. Then, find out what is driving the fixing work, and start working to improve those issues.

LM: Are there individual managers that will not fit into this /new/ management?

E: People who cannot manage themselves should not manage others. People who can only work through telling, selling, and yelling won’t be successful in companies that embrace lean and agile philosophies.

Some companies find they don’t need as many managers. Some people who are in management roles find they are happy to go back to technical work. But, to me the new roles for managers are exciting and full of promise–developing people, seeing and steering the system, creating environments where people can build products and services that delight customers, satisfy stakeholders, and empower employees.

LM: Can everybody change their behavior or do we need to move some people? To where?

E: Not everyone is capable, and not every one will want to. Some of those people will leave of their own accord. If there is a place in the organization where people who can’t or don’t want to change can still be of service within the organization, support them to find it, and then let them be.

We can never be 100% successful when we expect everyone to change. Don’t spend your precious energy trying to change people who don’t want to. Work with the people who want to change, and most often, when a critical mass has moved to a new way of working, most will come along.

If there are some people who are acting in a way that is destructive to people or the organization, help them find the door. (This advice applies whether you are using lean, agile or any other method known to man.)

I recently set aside my analog wrist watch and started wearing a runners watch. It’s accurate to the second on the face, and to a 100th of a second on the split timer.

I’ve noticed that when I have a precise measure, sometimes I use it, even when precision isn’t necessary. For example, when someone in a workshop asks me how much time is left in a simulation or exercise, they don’t need to know that there are 2 minutes and 27.15 seconds remaining. “Two minutes” would be an adequate response.

But there are times when a bit more precision is helpful– like in the way we name the social units that perform work in organizations. Take the term “team,” for example.

I hear the term used for any group of people who share almost any common characteristic.

In some organizations functional groups are referred to as “teams” even though the people in those groups don’t work on a common project and their work isn’t interdependent or aimed at creating a whole product.

Teams have these characteristics:

Teams….

Share a compelling work goal, and that goal is well-understood by all members of the team. Some person(s) in the organization eagerly await the product the team is producing–else there is no reason for the team. Without an external goals, a group may form a social unit, but they are not a team.

Members are mutually accountable for achieving the external goal. Team members do focus on completing their work; but they know that completing individual tasks–by themselves–isn’t enough for success. Success comes from achieving the overall goal.

Are doing interdependent work that requires the skills of all to create a finished product. Their skills are complementary and it is the combination of their skills that enables them to reach their goal. It’s not like a ski team where everyone has the same skills, and the team result is the sum of individual scores. On a team, the results aren’t additive, they’re integrative, generative, and collective.

Have a shared approach (though not a rigid process). Team members make agreements on how they will work together. They choose methods that fit the work and the goal. They need enough constraints on their process so that they can work creatively–avoiding both anarchy and stifling routine.

Teams almost always have fewer than ten members. Some say five is the sweet spot. When there are fewer than five members, there’s not much sense of teaminess. When there are more than ten, the work is so big that it breaks on along natural lines…and so do the people, falling into sub-groups that act more like a team than the bigger unit.

Have shared history/identity. This implies that a group is not a team on it’s first day together. It also implies that shaking up groups every few weeks or months ensures that you’ll never really achieve the surpassing results that cohesive teams are capable of.

But what about a group of 100 people focused on a common goal of creating a whole product?

At a local user group, there was discussion about such “teams.”

That stretches the definition of “team” too far. Teams are small enough that they can coordinate planning and the flow of information necessary for day-to-day work themselves. They may use task boards, build lights, and other mechanisms to help disseminate information and reduce the load on interactions between individuals. But they seldom need a person whose job is coordinating efforts of individuals. They’re small enough that they don’t break down into sub-groups.

One of the participants in the discussion asked how teams that large made decisions quickly. The person advocating large teams (100+ people) described how the overall manager pulled together people and information and then /he/ made the decision. That’s a perfectly reasonable way to handle decision-making when there are 100 people working towards a whole product in a commercial enterprise.

But if there’s an overall coordinating structure, it’s not a team. Teams are small enough that they don’t need additional coordinating structures and people in coordinating roles who are not working members of the team. (They still need managers who provide support and create an enabling conditions.)

Some times it does require the coordinated effort of hundreds of people to create a whole product. Within that collection of people there may be units of social organization that are teams. There may be work groups and individual contributors. And there are people whose role is the efficient coordination of communication, activity, and decision-making across the various sub-units within the overall structure.

Each of these units–work groups, real teams, conglomerations of workgroups and teams–are different social organizations and have different needs. Each requires different support structures, boundaries, and infrastructure.

Calling such disparate arrangements by the same term causes confusion, inappropriate expectations, and mismatched actions.

One summer, long ago and far away, I was on a softball team. It would be an exaggeration to say I played softball, but I did participate in practices, showed up for games and imbibed of the general post-game joie de vivre (beer). There were a lot of team members like me. It didn’t matter so much if everyone turned out, or if some people didn’t show. Friends of friends were invited. They might play half the season and then disappear. It didn’t matter because it wasn’t about reaching a goal, it was about socializing.

Too many teams have boundaries like that softball team. It’s never clear who will show up, and who the team can count on to play. If you care about getting work done, don’t mess with team membership.

The fundamental criteria for a team is stable membership. To be a team, people need to know who the team members are. Weak membership boundaries make it hard for any team to do it’s work. Unstable team membership leads to miscommunication and misunderstanding. And that adds up to time and money. Team members can’t be mutually accountable if they don’t know who is makes up “we” when they commit to deliver.
Some organizations assign people who in between projects (or managers) to what ever team seems (operative word “seems”) to need more staff. This is the warm-body theory of staffing, that holds that you can plug a person with roughly the right skills into a team and achieve productivity right away. (There’s a related fantasy, that full utilization is desirable and efficient). The reality is that plugging people into a team creates a revolving door effect and the effort to bring people up to speed slows down productive work (see Brook’s law).

In terms of getting work done (and keeping people engaged) organizations are better off it people who are “in between” work on their own special projects, attend training, or just take a breather.

The belief that a group can start working at full potential the first week they are together is a fantasy. It’s also a fantasy that teams can function with who ever shows up.

“If you call a tail a leg, how many legs has a dog? Five? No, calling a tail a leg don’t make it a leg.” Abraham Lincoln

The zeroeth trap of teams is calling any old group of people a team and then expecting teamwork and collaboration. A team is a social organization, a group of people who work collaboratively to accomplish some goal. Every team is a group of people, but not every group of people is a team. In order to be a team, a group needs to fit these criteria.

Teams….

Share a compelling work goal, one that is well-understood by all members of the team. They result they are producing is eagerly awaited by some person or persons–else there is no reason for the team. Without goal outside the team, a group may form a social unit, but they are not a team.

Are mutually accountable for that goal. Team members do focus on completing their work; but they know that completing individual task isn’t success. Success comes from achieving the over all goal.

Are doing interdependent work that requires the skills of all to create a finished product. Their skills are complementary and it is the combination of their skills that enables them to reach their goal. It’s not like a ski team where everyone has the same skills, and the team result is the sum of individual scores. On a team, the results aren’t additive, they’re integrative, generative, and collective.

Have a shared approach (though not a rigid process). Team members make agreements on how they will work together. They choose methods that fit the work and the goal. They need enough constraints on process so that they can work creatively–avoiding both anarchy and stifling routine.

Teams almost always have fewer than ten members. Some say five is the sweet spot. When there are fewer than five members, there’s not much sense of teaminess. When there are more than ten, the work is so big that it breaks on along natural lines…and so do the people, falling into sub-groups that act more like a team than the bigger unit.

Have shared history/identity. This implies that a group is not a team on it’s first day together. It also implies that shaking up groups every few weeks or months ensures that you’ll never really achieve the surpassing results that cohesive teams are capable of.

Fit for Function: Different work calls for different types of organization

Some work is much better done by a team, some work needs a group, and some needs many same-skilled individuals. It depends on the how interdependent and tightly coupled the work is. Growing teams takes energy and commitment–both from team member and managers. If the work doesn’t require cross-functional collaboration on a day-to-day basis, the work doesn’t need a team. (But beware of inappropriate serialization.)

0. Most people in management roles want to do a good job, but may not know what to do or how to do it.

1. People in management roles are dealing with incomplete and ambiguous knowledge. It’s a fantasy that they have all the information and know what to do (which may be held by both managers themselves and people who wonder why their managers do clueless things).

2. Most people in management roles receive little or no training on how to be good managers. Many people are promoted into management roles because they excel at technical work. This is not an easy transition.

3. Many people in management roles are working out of a mental model of management that limits their effectiveness. (See Don Gray’s Managing in Mayberry for two common mental models and one that’s less common.)

4. Many of the role models new managers have aren’t helpful. If people have never experienced good management, you can’t fault them for a lack of imagination.

5. Much of the management training out there is crap.

6. People in management roles are expected to achieve results over which they have no direct control. They must work thru other people and create work environments and work systems that support other people to do excellent work. Most managers have no training in how to do this.

7. Most people in management roles face demands from their managers and from the people who report to them. The are pulled from above and below. These demands are not always aligned and may be mutually exclusive.

8. Middle managers receive little peer support. Most managers face isolation and competition from other middle managers who are trying to meet locally optimized goals, obtain scarce resources and look good to the next level up. This is even more salient for new managers. Power difference (not matter how slight) changes the relationship with former peers.

9. People in management roles need to see the system and work on system, but receive little to no training in system seeing/thinking/acting. Relentless pressure tends to hold their focus on short term events and results, making it difficult to see patterns and connect the dots of seemingly unconnected events.

10. People in management roles need to work on the work system; they are also in the system, and their behavior is shaped by the system they work in. Both top managers and middle managers fall into predictable patterns of behavior.

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.

When companies decide they want the benefit of the team effect, or adopt agile methods, they (sometimes) realize that they need to update their management style as well. And too often, they enter an 4-step dance of oscillation.

Managers feel overburdened and overwhelmed. Teams are disengaged. They want teams to take more responsibility, and show more engagement. The managers stop telling teams what to do, and wait for teams to step up, take responsibility, and morale to flip into the positive zone. So the managers step back, and the 4-step starts, and usually ends up back where it started–overburdened managers, disengaged teams, and an uptick in cynicism.

If you are in this pattern, you are not alone. It comes from trying to solve a problem, when what you have is a polarity. There are upsides and downsides and you have to attend to both.

You don’t have to get stuck in the 4-step oscillation. If your organization wants to move from command and control management to something more like servant leadership, here’s some help for the journey.

Here are things a managers can do to move, and manage the upside and downside of becoming servant leader to a team.

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.)

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.

One manager devised this workflow in the name of efficiency, eliminating waste:

This manager devised an "efficient" workflow.

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.)

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.