Fernish’s Kim Burgaard on implementing healthy processes

Illustration by Matt Peet

Like many developers and tech leaders, Kim Burgaard has experienced organizations so laden with rigid processes that he felt suffocated. Of course, these processes are meant to ensure things got done the right way. But that’s not what ends up happening.

“What I’ve seen is people do things that are way outside the process,” Kim says. “And then they have to spend time reverse-engineering the process document, because it’s impossible to do what they need to do with that process.”

He sees that such draconian processes squelch developers’ creativity, motivation, ownership and buy-in. That’s a death knell for any organization that thrives on creative solutions and problem-solving approaches. Most of the most desirable developers will bail on a company that treats them like that. And the ones that stick it out? “They’re zombies,” Kim says. “Day in, day out, in the data entry zone.”

He’s also experienced the flip side: really small companies with no process whatsoever. That also doesn’t work.

So when Kim joined Fernish, where he is now Director of Engineering, he knew he needed to create some processes as guidelines and guardrails for his team—in a way that still afforded them the freedom to create and the willingness to buy into the organizational culture.

“Having a process ensures that we avoid common pitfalls and have an end goal, what we want to achieve,” he says. “A good process is not a step-by-step process. If you want to help people solve complicated problems in a creative way, you need to give them room to be creative.”

In this exclusive interview with Pluralsight, Kim digs into how to create the kinds of processes that enable, rather than debilitate, development teams—helping engineers to thrive in the process.

The rigidity of some organizations’ processes and procedures may come from good intentions of keeping things on track, but it ends up creating more problems than it prevents. Rather than using process to constrain negative possibilities, Kim’s ethos is built around using process to respond to real scenarios.

“A continuous degree of change means that there will always be things that you don’t have a good process for yet,” he says. “You discover you need the process because some kind of recurring problem begins to happen.”

With this philosophy, it makes no sense to impose a process for a new technique or approach. Engineers are curious types, and when they first encounter a new kind of problem, they need the chance to try things out. Teams and leaders need a certain amount of tolerance for that stage—at that point, process would only restrict creativity and hinder potential outcomes.

Once that new approach has been attempted three or five or ten times, the developer and the team can begin to appreciate the range of reasonable outcomes. That’s when the team should start thinking about the best practices they’ve discovered, and how they’ve addressed the problems they encountered—steps which they can then codify as a process.

“It jives well with the design mantra that I preach to the team,” Kim says: Instead of overdesigning things up front, when the team hasn’t figured out all the needs and possibilities, just play around with the problem and see what you learn—both what succeeded and what caused problems.

Kim has one exception to this rule for creating established processes, and that is “If there is something you do very, very rarely, but is incredibly important or critical to the business,” he says. “You also need a process to govern that.” In this case, it’s like a fire drill procedure: no point in experimenting and learning on the fly when the time comes. Have the process written down to make it as effortless and clear as possible.

Ironically, there’s no process for implementing process—but if it is going to help a team produce its most creative, effective and functional work, it needs to work with the team. That means getting their buy-in. And that means implementing process based on where they’re coming from.

“In my experience, it’s a constant series of adjustments and conversations,” Kim says of implementing process. “Some of our engineers have this initial knee-jerk reaction [against process]. ‘Why do we need to talk about that? Is this necessary?’ They need to feel like they’re not being turned into mechanical robots.”

To succeed, leaders require a mix of patience and persistence. They may well have to win over the more skeptical developers on a team while also accommodating the ones who take to structure more readily. Kim believes that one indicator of positive feedback is silence: if process is implemented well, the team won’t take issue with it. 

But implementing process is never finished. So the same goes for getting team buy-in on an ongoing basis. “They get used to what they have,” Kim says. “They get comfortable. But we are in a constant state of change. The team grows, or maybe the focus of the business changes. So now we’re doing slightly new things or introducing more things. At some point, we have to introduce a process that didn’t exist before, because it didn’t used to be a problem. And there are things that don’t happen unless we actually remind people through a process that they are necessary.”

Another strategy for getting buy-in from the team is providing them the context—the why behind the process. Even if the idea of process is distasteful to them, they can still appreciate that it has thought-through reasons and is not simply arbitrary. And, they can work within that reasoning.

“If you can get everybody to understand why you want to do something, whether that's process or the product you want to build, then there’s a lot of other stuff you don’t have to worry nearly as much about,” Kim says.

As an example, he presents leaders with two options: They can give their team a bunch of requirements for building a wooden structure (four walls, a ladder, built up off the ground). Or, they can tell their team to build a treehouse.

Which one is going to get the better results?

“You can get really meticulous and thorough about the what and the how,” Kim says, “but if you don’t get everybody to understand the why, you still get twenty people running in slightly different directions. They don’t have the same mental picture you have in your head. You lose their buy-in and their sense of empowerment, because you’re giving them a blueprint.”

If, instead of offering a blueprint, the leaders present a purpose—offers the reasons for an initiative, presents context for the decision and can explain how this fits into larger goals—everyone can understand the why behind the project. And leaders can then trust their teams to solve the problem, without having to prescribe every step of the way.

Sure, metaphorically speaking, they might build a round treehouse instead of a square one, or it might have a rope ladder instead of a wooden one. If certain requirements matter in designing and codifying a process, leaders can hammer those out with the team. But by that point, they’re already on board with the end goal and what that process needs to accomplish.

“You still have to talk about the how and the what,” Kim explains. “But you have to worry a lot less about them if you have buy-in on the why.”

Like we said earlier, there is no process for implementing process—but fortunately, Kim has developed certain principles that guide his teams in that process:

·  Understand that no process is permanent. Kim attributes a saying to the Chief Product Officer at Fernish: “There are very few decisions that can’t be undone.”

This attitude helps untie the knot known as paralysis-by-analysis. Too often, leaders worry that a process (or anything else) isn’t perfect, and therefore implementation should be put off. Realizing that any process a team implements can be reworked, replaced or discarded down the line reduces that pressure.

“In the moment, it's much better to make a decision than no decision,” Kim says.

·  Apply the single responsibility principle. Here, Kim borrows from the design philosophy that each function should be responsible for doing only one thing. That idea scales up to each class having only one responsibility, as well, even with each component function having its own responsibility within it. Say a class is responsible for handling payments; it should not also be responsible for creating invoices.

“To me, that’s a pretty good design, at least in the abstract,” he says. So he applies it to process, as well—as much as possible, each process should be responsible for one thing, like a class. Stages of the process might accomplish various tasks—the same way that the payment-processing class might have functions for handling refunds and recurring charges. In other words: keep it simple.

·  Follow the Rule of Three. Kim’s teams create processes for all kinds of tasks, from ensuring regulatory compliance to easing onboarding. Many of these fall in the fire-drill category described above, the ones that need to be done a certain way, at certain intervals. They have some room for creativity, but they’re not the real sandbox. Those are the processes built to improve creativity and performance on a regular basis. Kim calls them the Rule of Three.

They are: improve quality, promote consistency and prevent unforced errors.

Creating and maintaining processes for these three purposes act as a lighthouse steering the team away from those rigid, burdensome processes that slow teams down rather than speeding them up. If the team is working on—or working under—a process that honestly does not address one of those goals, it’s worth evaluating if that process is even needed.

These principles are intentionally simple; it helps everyone implement them, for starters, most especially the developers and teams getting warmed up to the idea of healthy process. “As teams do pretty well on those, they can begin to get a little more sophisticated, adding things to the mix,” Kim says.

Kim stresses that his goal, as a people manager at Fernish, is to get the biggest overlap he can between what the company needs and what the employees need and want. In a young and scaling organization, that means he’s working with developers who are hungry for opportunities to grow with the team.

Implementing process isn’t some line they have to toe if they want to grow. Rather, the right kinds of process will empower them to grow.

“We’re going to do the best when we actually collaborate,” Kim says.

So each of his insights into developing process is about more than creating effective developers—they are about enabling developers to thrive:

·  Solve problems, don’t prescribe practices. When process is about controlling outcomes, it chafes engineers and other creative workers. So Kim makes sure that process is all about addressing problems, helping developers clear them and resolve them more efficiently.

·  Meet team members where they’re at, rather than imposing structure on them. Team members can get comfortable with the way things are, but development is a field of change. Leaders need to balance patience in bringing reluctant team members on board, with accommodating (often more experienced) developers who relish a good process.

·  Provide the reasons behind implementing process. Kim’s kind of process isn’t a case of rules-for-rules’-sake. Every process has a purpose; including the team in discussion of that purpose helps them discover the why behind the process. This improves buy-in, sure, but ultimately it engages engineers with the higher-level purpose of their work and motivates more creative, engaged problem-solving.

·  Keep the process principles simple. Kim strives to remember that almost no decision is permanent. He lifts the single responsibility principle from design work to process implementation, where a process should ideally have only one function. And he always keeps his eyes on the purposes for building and maintaining any given process. After all, each one must both suit the business outcomes and develop better engineers.