What Do Software Consultants Actually Do?
When Woody Zuill, creator of mob programming and the #NoEstimates push, was 13, he got a job at a local plant nursery. His first boss gave him two rules.
One: Don’t let the plants die.
Two: Report each week with one idea for how the nursery could improve.
When it was time for Zuill to collect his first earnings, he wrote down his hourly wage and hours worked on a slip of paper, left it in the cash register and withdrew the money himself. The boss trusted him, and that left an impression.
Fast forward a couple of decades. Zuill owned his own printing business, and there was a huge stamping machine in the corner of the shop. The machine was too big for even 10 people to move, but one day, the team used an industrial forklift to raise it from its normal spot.
Underneath, Zuill found dozens and dozens of posters, banners and signs. They all had printing mistakes — warped letters, weird alignment. His employees had been hiding their screw-ups from him by shoving them under a (seemingly) immovable metal giant.
“I’d turned into the boss that I wouldn’t have wanted to have,” he said.
Now, Zuill has dedicated his career to freeing employees — software developers, to be precise — from managerial mistrust.
A helpful software consultant:
- Has technical experience and understands software workflows.
- Qualifies companies to make sure their approach is a fit.
- Introduces new ways to think, rather than telling companies what to do.
- Prioritizes collaboration and workflow over individual productivity.
- Values developer input.
Zuill and lean programming creators Mary and Tom Poppendieck all started their consulting careers differently, but their goals were the same.
For Mary, it’s always been about engineers. She started as one, and she loved the job. But as she progressed in her career, she met more and more software developers who hated what they did. To her, the culprit seemed to be corporate processes: Non-engineers were telling programmers what to execute, how to do it and when to finish.
“I found that software developers were being treated like, I don’t know, children,” she said. “And I wanted to change that. I wanted to make it fun to be a software engineer — and challenging and interesting — because that’s the way I found it.”
“I found that software developers were being treated like, I don’t know, children.”
A love of programming turned Zuill from a hobbyist to a professional. His first contract was with a small team of four or five people who worked together seamlessly in a style we’d today call extreme programming.
“I thought: ‘This is wonderful. I’m so glad I’m working in an industry where everybody’s so smart,’” he said.
Energized, he jumped to a longer contract at a big company with 200 developers.
“It was miserable,” he said.
Developers at his new job were tightly controlled by management, and they hadn’t found an effective way to collaborate. As Zuill continued moving from contract to contract, he found that wasn’t the exception, but the norm.
“I started realizing I had to do something about that, because I don’t want to work in an industry where everywhere you go, it’s too hard to do the work, and most of the people are spending most of their time protecting themselves from all the nonsense going on around them,” he said.
Who Can Help?
“I don’t like consultants,” Mary said. “I worked at 3M for 20 years, and if you had a consultant come to your department, it meant you couldn’t do your own job.”
Indeed, there’s an aura of unhelpful corporate paternalism — or even snake oil — around consultancy. But if “those who can’t do, consult,” how do you explain the success of people like Mary, Tom and Zuill, who get paid to visit companies and help them work better?
Perhaps the easiest answer is: They showed their value as thinkers before they ever pitched themselves as consultants. (For the record, the Poppendiecks call themselves “teachers.” Zuill prefers “guide.”)
Mary decided to use her experience as a technical project manager to write a book applying lean manufacturing principles to software design, with Tom editing each step of the way. That book, Lean Software Development: An Agile Toolkit, eventually became a classic, but at the beginning, she had to promote it by speaking at software conferences. Those speaking engagements evolved into two-day workshops, and the rest is history.
“Remember back when there was a trend that said, ‘You can be a manager of anything, and it doesn’t matter if you have experience in the area’? People have gotten over that.”
Zuill, meanwhile, stumbled upon mob programming — a style in which a group of programmers gather around a single computer — while working with a particularly collaborative team. An ardent student of lean and agile thinkers like Kent Beck and the Poppendiecks, he recognized its big-picture implications for software development.
“Rather than trying to optimize for the output of an individual, we’re trying to optimize for the flow of the work. And that’s a very big concept,” he said.
In short, good software consultants have a deep knowledge of software and the workflows surrounding it, Mary said. No amount of charisma or silver-bullet-methodology-speak can replace that.
“Too many people are making a living doing consulting without ever having done the thing they’re consulting about. To me, that makes it hard to have the instincts you need,” she said. “Remember back when there was a trend that said, ‘You can be a manager of anything, and it doesn’t matter if you have experience in the area’? People have gotten over that.”
Which Companies Actually Benefit From Coaching?
Mary and Tom refuse to tell teams what to do. And that’s if they’ll even agree to show up.
“We try to turn down engagements, partly because we’re trying to be retired,” Mary quipped.
Their position is a privileged one, she acknowledged: They’ve always had enough income to say no to certain jobs. But the selectivity isn’t just about their (unsuccessful) attempt to retire. Often, companies are barking up the wrong tree.
Good consultants, they told me, don’t tell people what to do or what to change. They introduce new ways of thinking and let teams figure things out for themselves. Not every company likes that approach, though. That’s because some are looking for a magic set of practices that will fix underlying organizational problems. Others are just hoping to get “employee development” initiatives on the calendar and have no real goal at all. The Poppendiecks have gotten good at sniffing out those scenarios.
For example: If a company reaches out and asks Mary to teach lean concepts, she might say yes. If it asks her to teach scrum, she’ll say no. Lean is a philosophy teams can apply to any problem they’re having — if they can identify what that problem is. Scrum, however, is a set of practices. Teams could implement it without even considering what’s actually causing their problems.
“Typically, if someone says, ‘We need to learn how to do this particular thing so that we’re better,’ that means they’ve already come to the conclusion of what’s going to solve the problem,” Mary said.
If a company asks them to stay longer than a few days, the answer is no. If the email comes from a human resources, training or procurement department, she doesn’t respond.
Ruthless? Perhaps. Necessary? Yes. Once Mary and Tom arrive, they immediately have engineering managers and senior developers sketch out “value stream maps” showing the team’s entire workflow from the moment a customer has a problem to the moment that problem gets solved. If engineering leadership didn’t opt in, that process will be uncomfortable at best.
“They really didn’t want to have the low-level people thinking about processes. They were supposed to do whatever they were told.”
“Value stream maps tell you so much,” Mary said. “After a day of doing some exercises, we know the fundamental issue that people in the company are having that they don’t want to talk about.”
Mary and Tom always share what they believe is preventing the organization from reaching its goals. If the team isn’t bought into the Poppendiecks’ software philosophy, the workshop won’t help.
Nor will it help if teams don’t really want to make changes. That goes for both on-the-ground engineers and management. Once, the Poppendiecks arrived at a company in Denmark and asked each developer to brainstorm some ways the organization’s processes could improve.
“The CIO came in and said, ‘How dare you talk about how to change our processes?’” Mary said. “They really didn’t want to have the low-level people thinking about processes. They were supposed to do whatever they were told.”
If companies aren’t prepared to treat developers like capable problem-solvers outside of the codebase, Mary and Tom consider them a lost cause.
I asked if there’s any obvious metaphor to be made about what makes a successful marriage and what makes a successful software department. Turns out, there totally is.
“The foundation of good relationships is respect for the other person — their ideas, their opinions, their attitudes,” she said. “You have these really smart people, and one of the things they happen to be able to do is to write code. And then there’s no respect. [Managers] say, ‘Oh, they only want to write code.’ Where did that come from? How do you know?”
Mary and Tom have few nice things to say about agile — they believe that, as it’s practiced today, agile often strengthens the corporate hierarchy and ceremony it was supposed to tear down.
Zuill had less venom — he chooses to think about agile as it was meant to be. The Agile Manifesto is still “extremely valid,” he said, but many misunderstand its intentions.
“Agile itself is just some ideas that were brought together,” he said. “It’s not a methodology. It doesn’t provide the exact mechanisms for fulfilling the values and principles.”
Take the first agile value: individuals and interactions over processes and tools. That means every single process or tool should make it easier for individuals to excel and easier for interactions to be effective. If that’s not true, those processes have to go.
A good way to assess processes and tools is to examine whether they support collaboration, Zuill said. In fact, collaboration is what he thinks the entire manifesto is about.
“Almost everything you read — the four values and the 12 principles — somehow is about working well with others,” he said.
That’s something companies do poorly, according to Zuill. Developers are siloed off based on expertise and encouraged to maximize their own productivity, and that expectation makes work less fun and effective for everyone. Zuill himself spent 15 years programming entirely alone.
“Most programmers are the same, they’ve worked alone most of their careers. And as individuals, we start preferring to be alone. When we work in an organization, the interference from other people can really depress us,” he said.
“As individuals, we start preferring to be alone. When we work in an organization, the interference from other people can really depress us.”
For developers, every interaction with a coworker can feel like an interruption, and companies do little to change that. To course correct from a prickly collection of individuals to an efficient, imaginative software department, companies must see themselves as systems, Zuill said. A simple system (one founder) evolves into a complex system (multiple workers), which eventually develops a hierarchy and incentive system.
Systems are good at perpetuating themselves, and it’s tough to evolve from the inside. So companies spiral deeper into a tangle of hierarchies and incentives, powered by processes and measured by metrics.
“I believe most employees are highly motivated. But we’ve forced them to be motivated about something other than being effective in their work,” he said. “We motivate them to make it look like they’re working hard, to take credit for things they didn’t necessarily do themselves, and so on. We turn our organizations into fear-based organizations, and we destroy the ability for people to be innovative.”
Zuill believes that companies must — counterintuitively — shift focus away from business success and toward collaboration. Mob programming is one way to do that, so that’s what he teaches. But, in the end, real change in software departments depends on how companies choose to treat developers. Are they loners to be siloed? Rebels to be managed? Loafs to be incentivized? Code machines to be controlled?
Companies — not consultants — have to answer that for themselves.
“You want to hire a hero, but heroes don’t exist,” Zuill said. “If there is any hero, it’s the people on your team. You've just kept them from doing the things they need to do.”