GitPrime elevates engineering leadership with objective data. In this interview series, Engineering Leaders talk about how to build high performing teams.

Naturally, we all want to keep improving our companies and ourselves.

We see what happens when old business models get comfortable and fail to grow and evolve well: they go the way of dial-up internet and desktop-based email. Great.

But defining what a true company culture of continuous improvement looks like – that’s much more challenging than simply saying you want to improve.

“Those words get thrown around all the time,” Kevin Goldsmith, chief technology officer at Avvo, says of company culture of continuous improvement. “But what does that actually mean?”

Goldsmith has built much of his career around this idea of continuous improvement. He’s worked with Spotify, Adobe, and Microsoft, and he gives presentations worldwide on topics like leveling-up agile teams, changing your organizational structure, and creating a culture of continuous improvement.

As for the latter, “what it boils down to is we are constantly looking at how we do what we do and asking could we do it better,” he explains.

At Avvo, an online legal marketplace that helps connect consumers and lawyers, Goldsmith has spent the last year and a half walking his talk and creating that very culture. He talked with us about how he is shaping that environment for his company, and how anyone can implement these philosophies in their own organizations.

“Nobody comes into this world knowing what this looks like or how to do it,” he says. “You’re trained not to question things. Your leadership tells you what to do, and so you do it. That’s your job. And what we’re trying to do is the exact opposite.”

Start by building autonomy

In Goldsmith’s view, a culture of continuous improvement is a culture where people are adaptable to change, advocates for improvement, owners of the company mission, and empowered to own their work.

There’s a whole toolkit for creating this kind of continuous improvement in your organization. But all the tools in the world won’t do a lick of good if your team isn’t both trained in how to use them, and free to use them however they want. Therefore, before you hand out the tools, you have to set up the conditions for a ‘continuous improvement’ mindset.

“A broader level of autonomy is required,” Goldsmith says. “Once a company is able to provide that, people will then own the tools for continuous improvement, and be able to use them freely.”

A team with autonomy has the ability to own their improvements. It’s incumbent on them both to figure out how they can improve – which they know better than anyone – and to be free to implement that improvement.

That means that the impetus to improve is not coming from above.

“Senior leadership sets direction,” Goldsmith explains. In this model, leadership gives out the big-picture information they have about the product and the organization. They can state what they think should be done about it.

The difference here is, that information is not a directive.

This isn’t a radical shift for many organizations – a shift in breadth rather than approach. “Doing agile development, we give teams autonomy within a very narrow context,” he says. “We’re just giving them a broader autonomy.”

Enabling that autonomy is twofold:

1. Establish that it’s okay to question and challenge. “Set up structures so that people can do that in a nice way without making it personal,” Goldsmith suggests.
2. Establish those structures so that people can question the bigger things, too. “I’m talking the things beyond their team, getting back to that global perspective outside of day to day responsibilities,” he says.

“It's really easy when you're working on a team to go, wow, the way we're doing this, this is a little bit goofy, could we do this feature slightly differently?” he elaborates. “That's expected of you in an agile team.”

But it’s another to feel empowered to change a process that is stitched throughout the organization. To go from complaining to your peers about, say, the interview process, to actually taking the initiative to improve that process.

“Part of that is just giving people the tools,” Goldsmith says. “Say, ‘If you want to make those changes, this is how you do it.’”

Cracking into the toolkit: DUHB(R)s

Goldsmith’s primary multifunctional tool – his sonic screwdriver – is the DUHB, pronounced “dub.” It’s the nuts-and-bolts of how you actually enable your teams to enact the potential improvements they identify.

“Basically, it's a data-driven decision making tool,” he explains.

DUHB stands for data, understandings, hypotheses, bets (and there’s a silent R for results):

• Data is the background information that informs the topic. Data should be incontrovertible, and it can be either internal product or external industry data.
• Understandings are the interpretation of the data, and they must follow from the data.
• Hypotheses are based on the understandings from the data. They are strategic interpretations of how to address the situation or problem outlined by the data and understandings. These hypotheses, by nature, should be debatable.
• Bets are the tactics taken to validate the strategic hypotheses. They can be sequential or parallel, and ideally are reasonably small in scope.
• Results, no surprise, are the documentation of the bets and their outcomes. You can use these for future reference and to inform future DUHBs.

“So essentially, you assemble your data. You infer from that data, take your understandings, and interpret the data,” Goldsmith says. “You have hypotheses. This is what we should do given our understanding of the data. And then these are the bets we execute to prove or disprove the hypotheses.”

Let’s look at the employee who doesn’t like the current interview process and thinks it could be improved. She knows about the DUHB tool and is trained on how to use it. So to collect data, she researches how other companies conduct their interviews, in order to form an opinion from hard data instead of personal feeling. She can then make interpretations from that data, make hypotheses around how Avvo should change its process, and design the bets that can prove or disprove those hypotheses. At that point – when the process is autonomously complete – she can bring it to Goldsmith or someone else in tech leadership.

It’s a true democratization of the executive function, he says. “And the great part of that is we trained everybody on how to write DUHBs. We wanted to encourage people to make their decisions using data instead of gut feeling.”

Furthermore, the compilation of DUHBs becomes a repository of all the decisions made at Avvo and why they were made. A new person can come on board and review the DUHBs to understand why processes are done they way they are. Then they’re free to make a new DUHB if they think they see an even better way.

The next tool: RFCs

From there, Goldsmith uses a process he developed at Spotify and brought to Avvo.

“I didn’t invent RFCs, which are otherwise known as ‘request for comment’ documents,” he said. “They’re well known in the industry. I just applied them to organizational change.”

His approach with RFCs is to roll out any ideas to emerge from the DUHB process. Leadership can lay out the plan, based on the DUHB, to explain how they’re going to change things in the organization. Everyone has the ability to comment on that plan, make suggestions, challenge it. After a few iterations of that, the group that puts together that RFC and then rolls it out.

“What we’ve structured, really, is how we change. But not what the rules are.”

“We are literally doing this right now on two different areas,” Goldsmith says. “We built a career ladder. That's rolling out right now, for individual contributors. And we are doing a new interview process. Both of these were driven by individuals, not managers, not me. I supported them, but I'm not driving them. These are individuals deciding how we as an organization could do this better.”

The structure of using a DUHB and an RFC is an established process at Avvo. And Goldsmith recognizes the pushback that can come from enacting new processes.

“I’ve seen this now at a few companies,” he says. “When you start to add processes, and people say, ‘Wait a second. I used to just be able to do what I wanted. Now I have to ask or I have to do things in a certain way.’

“So you have to balance that out. That’s why I like this way of doing it. Which is more about continuously changing and adapting. And what we’ve structured, really, is how we change. But not what the rules are.”

Where’s the bathroom today?: Moderating your changes

Even when an idea is intuitive, reasonable, and empowering, Goldsmith suggests you strive for wisdom in how you roll out changes. It’s a lot like how Jean Hsu recommends we introduce process when the team feels the need for it. And it’s also about moderating how much change a team can handle. After all, change – even positive change – is still a stress.

“As leadership, we look at it, not from the perspective of being gatekeepers, but more the perspective of managing how much change is happening simultaneously,” Goldsmith says. “Because, you can blow out people's change budget, which we did last year. We've learned from that lesson.”

He leans on Avvo’s relationship with author and researcher Britt Andreatta. In her book Wired to Resist, she discusses this concept of the change budget.

“Imagine at your company, every day the bathroom moves to a different place,” Goldsmith says. “Just like, every morning you’re at your desk you have to go to the bathroom. And every day you have to find the bathroom. It's somewhere in the building, but it's a different place every day, right?

“And then the coffee maker moves every day. And then the refrigerator moves every day. One of those things maybe, you would be like, alright well this is kinda funny. Every day, I have to find the bathroom. Oh, have you seen the bathrooms? It's kinda cute. But when too much change is happening simultaneously, you get exhausted.”

“As leadership, we look at it from the perspective of managing how much change is happening simultaneously.”

He admits that his teams got to that point before the improvement-enabling processes had evolved well enough to function. There was definite desire to change within the organization – people knew they could be doing things better. So they jumped in on the chance to enact change.

“We didn’t have to convince people,” he says. “They were really excited, and we just took on too much. And we were moving the bathrooms and the coffee machines and the refrigerators every day.”

You can also be aware of how the structure of your teams will both impact and enable change. For Goldsmith, that means that his teams have more than broader autonomy; they also have broader scope.

“We used to have lots of little teams,” he says. “We had ten or twelve tiny little development teams between three and seven people.”

Now, they have six teams with 12 to 30 in each of them. The idea is that these teams not only have test product UX development, but they also have data engineering, data analytics, and in some cases marketing, sales representation, and finance people in them. This way, they are truly cross-functional.

That cross-functionality gives them a lot of freedom in how they move and how they attack problems. They are also not impeded by any of the other teams, while they each also have a big enough scope that they can all work in very different ways while still working well together.

Restructuring your organization would be a fairly drastic step toward creating a culture of continuous improvement. But Goldsmith has done it in the last year-plus at Avvo. Whether you aim big (to the level of a reorg) or simply empower your engineers to speak up and propose changes to your systems, creating a culture of continuous improvement is a project well within your power to achieve.