Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles The Misaligned Middle and Getting off the Hamster Wheel Using Kanban

The Misaligned Middle and Getting off the Hamster Wheel Using Kanban

Key Takeaways

  • Middle management is often not incentivized to adapt to change
  • What made managers successful in the past no longer works in today’s volatile environments
  •  Visualizing the value stream can help identify areas for improvement, both from a management perspective (where are the handoff points and what is the impact of optimizing one area on the surrounding areas) and as a tool for improving the flow of work in a system
  • Kanban identifies blockages and problems in the flow or work – people need to address the problems identified
  • Most often the problem is not the people, it is the design of the workflows 

At the Agile 2016 conference InfoQ spoke to Dominica DeGrandis and Julia Wester from Leankit about their conference talks.

Dominica gave a talk titled “The Misaligned Middle” in which she explored how come middle managers don’t seem to get DevOps? How come executives and individual contributors seem to understand and see the value in DevOps, yet middle managers are often a source of resistance.  Julia spoke about using Kanban to help teams Get Off the Hamster Wheel.

InfoQ: Welcome Dominica, thanks for taking the time to talk to us today.  Please tell us a little bit about yourself and about LeanKit,.

Dominica: Okay. Well, I grew up doing builds on IBM mainframes back in the day.  Configuration management, build, release. I've spent most of my career doing that, either working on, or on behalf of, operations teams and my passion for the last ten years has really been using visual workflow methods like Kanban and Flow to help change lives. This was why I love LeanKit so much because LeanKit helps teams visualize the entire Work Stream so that we can see all the different functional silos within that Work Stream. It's hard to manage invisible work. There’s lots of unplanned work in IT ops, and I find that using a visual like that helps to provoke necessary conversations in ways that regular conversations just don't. So, I love my job; love the company I work for. I like that we were SAAS, small SAAS company, and our leadership built the company to reflect the place where they wanted to work. Pretty much enjoying my time there and it's a continuation of my work that I did as a consultant.

InfoQ: So LeanKit builds a visualization tool?

Dominica: It's a lean workflow management tool. Relies heavily on visualization. So you can build Kanban boards at different levels. So you can have high level maps for senior leadership or build road maps all the way down to more granular team work, and connect cards across the different boards. And it's not just IT that's doing that. It's spreading into business units.

So we have marketing using Kanban and finance and sales. It's angles, if you will, out to the business, because it is about the whole workflow from beginning to end. And a lot of times, at the DevOp stage conferences, we get CTO's and VP's asking, "How do we get the business engaged with us to understand that we have a maximum capacity, and that if decisions are made from above that are deterministic with due dates and promises made that it's going to be a challenge for us to meet those all the time?" Conflicting priorities are a huge problem.

InfoQ: You gave a talk titled “The Misaligned Middle” – does that talk to how these conflicts happen.

Dominica: I wrote a blog on it last December. When I went to last year's DevOps Enterprise Summit in San Francisco, there was a lot of discussion on middle managers. How come middle managers don’t get DevOps? Why do execs get it and why do individual contributors seem to get it? What's going on with managers?

I was really intrigued by that and I wanted to understand more. And I had my own ideas and thoughts, but I found on interviewing DevOps luminaries that there were really two camps. Camp A was of the impression that it was really a leadership issue, that alignment was a leadership issue. When leadership says, "Yes, let's do a DevOps initiative. That sounds great, go forth and do that," but then down the road, reprioritizes another initiative on top of that, then they're not showing that they're fully invested, with skin in the game. And that message speaks loud and clear to managers below that, and they're smart enough to recognize that they're being measured on how their specific team or function performs.

And then the other camp was that, "No, misalignment is really a management problem." And that the tolerance for change is limited. People have invested a lot in their careers by the time they've gotten to middle management, usually in ten years. And every year there's usually some leadership turn-over, and that brings in a new platform or a new framework or a new management method, new buzzwords. The tolerance for that change year after year is mentally taxing. And for those who are nearing retirement, there's even less incentive for change. I've heard it explained really well by Damon Edwards. He's the founder of DTO Solutions and talks about how middle managers can't see the forest for the trees. Like the people with their hands on the keyboard, they're getting paged at 2:00 AM. They know exactly what the problems are. And execs, they have the 30,000 foot views so they can see the impacts on revenue and competition with their competitors. But the folks in the middle, they're too far removed from the actual problems that they once knew so well and yet the higher level is too abstracted from their work, so it's hard for them to see and understand some of the benefits.

I think my own observations on why middle management seems to be a bit removed or not as incentivized or motivated to take on change is that I've witnessed a lot of conflicting strategic themes from exec leadership from above.  In Chicago there's a company where the CTO has a VP and the CIO has her own VP and those VP's battle it out on what the strategy should be evolving in their groups.  That disconnect just drives down to their teams. When I worked at Corbis, that's Bill Gates' other company in Seattle, at one point we had two VP's that wouldn’t even stand on the same stage together. I don't know why they didn't like each other but it permeated down to their organizations who battled each other and didn't like each other.  So I think that plays a role because middle managers are people too, they're just trying to survive in the situation that they're in.

Another big one is how they're measured. Currently, managers are measured on the progress of their functional team. So there is no incentive to look at the whole organization. There's no incentive to optimize the whole. And there's a saying that I like. It's, "We pay attention to what is inspected, not expected." So, "Tell me how you're going to measure me and I'll tell you how I'm going to behave."

InfoQ: So, how can we help?

Dominica: The solution. Well, what some companies are having lots of success with bringing the visual of the whole value stream to the group. So it's getting everybody in the room, and having the people who are actually doing the work do that value stream mapping and get it all up on the wall so that we can stand back and see where things are getting stuck.

Then removing the people from the equation and looking at what's really happening so we can have this necessary conversation. And there has been lots of success even at the Federal Government level using value stream mapping where we can see that optimizing the frontend development process, maybe using an agile method, and that might take this long. And then looking at what happens when it goes through delivery and that thing -- sorry I'm moving my arms here to stretch it out to show how much is involved with delivering that change.

So optimizing in one area can cause problems downstream in another area, and we don't recognize that if we're not looking at the big picture. Getting people to see and understand the big picture, and then having that help bring previously maybe even warring tribes together to have a conversation about how to fix it.

Secondly, DevOps has a lot to do with culture. It's not just about automation and how can we change culture from a top-down command and control approach to a more distributed power to give people autonomy to do the work that they need. So some of the models that we're looking at is the Western behavior model which is the elements for a pathological kind of organization that's run by fear, versus a bureaucratic organization that's usually run by rules, versus a really agile organization to work with that's run by high cooperation and diversity and tolerance for change and experimentation and novelty, and it's a fun place to work.

Middle managers have more anxiety and depression than any other role. More than execs and more than individual contributors. They're stuck in the middle and they're having to absorb discontent from above and below. So it's a hard spot for them to be in, and with all the latest articles from HBR to Forbes to the Atlantic on the need to just fire all the managers, there's fear of that role going away.

InfoQ: And so how do they adjust in that in this environment?

Dominica: When it comes to matrix management, that's very powerful too. So if you got a good Kanban system in place, you'll be able to get good data on lead time, cycle time, with limits on work in progress than can help people. We show the data. There's that saying by Jim Barksdale, CEO of Netscape, that's, "If we've got data, let's look at data. If we're just going with opinion, let's go with mine." So I think it's important. Show the data so that you can become the voice of reason in your organization and help people see the change.

One thing I'm really excited about right now is understanding the need for change, because we're so resistant to change. I don't know if you're familiar with the British Physicist Brian Cox? He does a lot of YouTubes videos about the universe from a physicist's perspective. And he says that there will always be irreversible change we can't prevent.  He talks about why that is, and he talks about the second law of thermodynamics and how everything goes toward decay. Everything goes from ordered systems to disordered systems. Everything goes from low entropy to high entropy. That is the nature of the universe.

It's why stars blow up. It's why buildings deteriorate. And that if we do nothing, if we think that we're going to be safe by not making change, then we're choosing decay. I think that is a powerful message for people that are reluctant to change. Because I'm running into people and they're nervous about change. They don't even want to put their big toe in that pond unless they're convinced that everything is planned out, and that all the outcomes are knows. And that's just not how our complex world works.

InfoQ:  Julia, Thank you very much for coming to talk to us today. You're an improvement coach at LeanKit and you're a speaker here at the conference. Please tell us a little bit about yourself?

Julia: I am an improvement coach, and what that means is that I go out to teams and I help them take a little bit of the chaos out of their everyday. I use a lot of Lean and Kanban methodology and mindsets, it's really agnostic to approach but we just look at the problems and find the right solutions to help them do more with less stress.

InfoQ: Please tell us about your conference talk: Jumping Off the Hamster wheel with Kanban.

Julia: Well it was about 2009 where I took my first management role and I realized that I was going to have to change my logic and code puzzles for people and process puzzles. And the first puzzle that presented itself was that my team was working so, so hard but they weren't delivering anything. We were losing a lot of confidence from our stakeholders and we were getting frustrated.  We really felt like we were on that hamster wheel. Kanban ended up being a catalyst for us. I'm not going to say the solution, but a catalyst for us to find our own solutions, and sort of get off of that hamster wheel and move forward.

InfoQ: In what way was Kanban a catalyst for that?

Julia: Kanban is a method for change helping you look at the existing workflow in your system, and overlay some light practices on top that help you identify the roadblocks and barriers in your work. The goal is to have a steady stream of work through your system, much like a river. We want smooth flow through the river. So what we had to do essentially was find all the rocks in it. And Kanban made us visualize our workflow in our work, and then it made us bring the water level down so that we could see the rocks.

What that means in work terms is limiting our work in progress, not doing so much at one time, so my team, when they were on that hamster wheel running and running and running, I looked and maybe they were trying to do 15 or 20 things assigned to them at one time. And that's why everything was taking so long.

It really just made us reflect and caused us to change some of our underlying assumptions about how we get work done;  double loop learning. Once we saw those items, it didn't tell us how to fix them. It just helped us identify what they were. Then we did some experiments and tried to figure out some approaches, and we just started to learn about and experience the cycle of continuous improvement or Kaizen. All of these things together is really how Kanban helped us jump off that hamster wheel and realize that it wasn't the people that were the problem, it was us getting in our own way by the way we chose to structure our work.  The way we built our system wasn't efficient and effective for what we were trying to do.

InfoQ: What advice would you give to a team or a manager who feels that they are on the hamster wheel? What do they do first? How do they go about changing things?

Julia: Well what I did first was I read the blue Kanban book by David J. Anderson and I followed it step by step while I was learning.  What I would say first is to step back, try to get a little bit away from the emotion and let yourself off the hook that you're not doing a good job and realize that you might be trying to do too much. Look and see if trying to do everything is the thing that's keeping you from doing anything, and to really consider whether you need to do less to finish more. That's a primary place where people are stumbling. They feel like if they don't start everything they'll finish nothing. But starting everything is the self-fulfilling prophecy of finishing nothing.

InfoQ: But there's the pressure from above that says, "Do this. Do this. Do this."

Julia: Right. And what happens is when we start everything, we're really evading the concept of facing the reality of our capacity, and avoiding discussions about priority. And it's not an easy message; it's a counterintuitive message. So when you go to someone, a business person especially, and you say, "You know what? I'm going to do less. And watch me, we'll get more done." They freak out a little bit.

But when you start to show them some costs through some simple exercises on context switching, and you start to give them some equations and equate those equations to lost time, and that lost time to wasted money and capacity, then it's starting to give you a little credibility to maybe carry out that first experiment to say, "Okay, we're not going to start any new work until we start getting some of these things out of our workflow”.  Then if we try this and we actually finish some things, then maybe that's permission to take it the next step further and get down to a situation in which we're limiting with and then eventually turning a push system into a pull system.

InfoQ:  You’ve written about the impact of task switching?

Julia: I wrote a blog post or two about the cost of context switching and I tested this out with my development teams and made sure that my numbers weren't manager numbers where you think they're right but they're really not right.  The reality is someone can have five interruptions a day. And it might be a meeting that's in the middle of your work, or a five-minute question from someone, or just a task interruption, or an emergency comes in. Each time you have one of those things, your context switched, and  that takes up time. Not the time to do the thing, but ramping down from what you were doing, and getting into the mind space for that interruption. And so that can easily take ten minutes. I validated that number with my team like I said; to make sure I wasn't overshooting it and trying to make the number look better.

So if you have five of those a day, that's about 50 minutes. And we think, "Oh, that's not so bad. That's the cost of doing business, 50 minutes a day." Well you think 50 minutes times five days a week, that's half a day per person, you're starting to get a little concerned - maybe that's not so great, but you're s till not super bothered about it. But when you look at it across the whole team and you say, "An eight-person team is losing half a day a week, just by the decisions we're making about how to structure our day and structure our work, we're losing four person days each week.

My business partner that went through this with me, I asked her, "What would the business say if I told you we're wasting four days a week by just making some bad choices?" And that's when they really get on board. When they begin to see what the true cost is of five simple interruptions a day, and if we can see that in a sort of simplistic exercise like that, and we imagine how exponentially that changes in a complex situation like our workplaces, then they really start to think that you might know what you're talking about a little bit and they're willing to give you a little bit of leeway to move forward and try some experiments.

One of the good things about the methods I've learned so far is that they encourage small evolutionary changes, so you're never asking anyone to take a giant risk all at once. You're doing a prototype, a proof of concept from a process perspective and testing it out before you ask them to take the next leap of faith.

About the Interviewees

Julia Weste brings 15 years of experience working in and managing teams at Turner Broadcasting and F5 Networks. Julia is passionate about teaching others how to tame the chaos of everyday work by embracing transparency and continuous improvement, as well as talking about how management doesn’t have to be a dirty word. Julia joined LeanKit as an Improvement Coach in 2015 and is now the manager of LeanKit’s education team. Julia blogs at and, and tweets at @everydaykanban.

Dominica DeGrandis teaches technology & business organizations how to visualize uncertainty. She helps teams reveal mutually critical information using Lean, Kanban and Flow methods for knowledge work. As Director of Training & Coaching at LeanKit, Dominica helps ITOps and DevOps enthusiasts level up their business capability. She blogs at and, and tweets at @dominicad. 

Rate this Article