Leading a group of engineers might be easier when the task at hand is simple. But how often are engineering, people, and process problems actually simple (especially in high growth companies)? Let’s face it — as creative problem-solvers in rapidly advancing industries, we exist in a space of challenge and complexity.

Kathy Keating, CTO and Co-Founder at Apostrophe Health, thrives on managing complex problems at scale. Keating has led several successful technology startups, founded her own technology consulting business, and has guided the product strategy for multiple different organizations. “Now, I’m in healthcare, trying to tackle and fix a really broken industry,” she says.

“Hard problems,” as she defines them, are ones that haven’t been solved before, or perhaps they have been solved poorly. The reality is, how an engineering leader manages these challenging unknowns determines how well their teams perform. Keating opened up to us about how she manages through difficulties, and how you can adapt to do the same.

Essentially, every problem worth its salt is a hard problem. But saying so doesn’t give your engineers the faintest idea how to address it. Figuring out how to start tackling a problem, particularly when components are already moving (or already broken), is key.

Keating, in these instances, is a firm believer in the concept of VUCA.

“VUCA stands for volatility, uncertainty, complexity, and ambiguity,” she explains. “When something is really hard, you need to understand why it’s hard. Is it hard because it’s unknown? Something could come at you that you don’t expect? That’s volatility.”

Do you have multiple unanswered questions? That’s uncertainty. Or perhaps the problem is knowable, it’s just really complicated with a lot of moving parts. That’s complexity. Or it turns out the problem is vague and unclear; it’s ambiguous.

When you figure out what makes your problem challenging, you can start to tease apart the best way for your team to address it. Get a clearer sense of the specs to make it less ambiguous. Strengthen your architecture to withstand unforeseen problems and reduce uncertainty.

“There are different approaches to tackling a problem,” Keating says. “When I think about healthcare, we’re coming in and tackling something we know. It’s known how healthcare claims are processed, how payments are made — how the industry works is known. We just have to get in and understand it, and then look at the multiple failure points. Then figure out how we can rewire them to make them more efficient. Known, but complex.”

Once you’ve established the type of difficulty you’re facing, you can strategize how to find solutions to it. While it’s common practice to use KPIs (Key Performance Indicators) to measure ongoing processes and activities, many teams also use OKRs (Objectives and Key Results) to solve new problems or drive innovation. The Objective tells you where to go, the Key Results will let you know whether you’re there or not

“We take a slightly altered approach to OKRs,” Keating says. “We’ve renamed the concept to GEM — Goals, Experiments, and Metrics.”

GEMs allow you to explicitly establish and state your purpose in tackling large, difficult problems. Is your goal to rewrite the whole program? Or is the goal to make one part of the program more efficient, the experience more pleasurable for the customer, or some other smaller task? Odds are, your problem is not as big as the entire code base, and you can identify smaller, more manageable problems to set your sights on.

“It’s about not giving in to analysis paralysis, where you don’t know where to start,” Keating says. “Find one goal that you can do to reduce the scope or complexity of the problem.”

Once you have a goal, start experimenting with it. Hypothesize how manageable changes can create desirable results. Run your experiments — and Keating recommends keeping the experiments small in scope.

“If you think you can change the whole world in one feature, you’re dreaming,” Keating says. “So break it down to a single experiment, change that flow, measure how it works. Did you meet that goal? Then run another experiment. We do almost everything by building out small experiments, running them, measuring them, and feeding that back into the cycle. Before you know it, after just a few iterations on that process you’ll have caused a significant change in the flow.”

Keating works with her engineering teams to see the work as multiple small experiments rather than one big problem. Doing so reduces uncertainty while providing the team with focus and direction, she says, and it breaks the scope of the work into pieces that are much more achievable.

It’s one thing to suggest your engineers focus on small problems. It’s another thing to actually enable them to do it. The main concept that helps Keating’s engineers focus on smaller goals is to implement shorter timelines.

“It’s about how you run your process,” she says. “As a growing startup, we have to get a lot done in a very short period of time, get feedback and iterate quickly, so we don’t do detailed quarterly plans. We’re Lean/Kanban, we move quickly, and we reprioritize constantly. Every project we do is less than a week long, if at all possible. Once we break things down into the smaller parts, everything can move very quickly through the system.”

When Keating does break down problems into larger pieces, with more complexity, that’s when her teams might find themselves blocking each other. No one knows how to move forward because there are so many interdependencies, and so effecting change on any one thing can become challenging. And that’s clearly an inefficient way to achieve the team’s goals.

“We keep our focus on managing our work queue to constantly prioritize small items along with a clear definition of what needs to be implemented,” she says. “This lets us build a cadence where we’re constantly moving through these small items.

As management, Keating recognizes her job is to ensure that her developers are clear of obstacles, so they can work on what makes sense in the moment. And this process is proving to work well, even when a lean team is carrying the entire load for Apostrophe.

“We just hired someone from a large healthcare company in operations and he routinely tells our team, ‘I’ve never seen an engineering team be so efficient and build so much without a huge team,’” Keating says. “It’s not that we’re superheroes. It’s just that we’re really efficient at how we break things down and run them through the process.”

For the GEM model to truly work, the E — experimentation — must be genuine. And as with any experiment, that means embracing failure as part of the process.

“Everything is an educational moment,” Keating says, “It’s even an educational moment for us as managers. Even if it goes really wrong and we can’t recover from it.”

She admits that she’s had two data centers go down on her in her career — not just servers, but entire data centers. Those were educational moments for her about how the organizations needed to diversify and strengthen their architecture. The first time it happened, it took more than eight hours to failover. The next time, multiple years later, they failed over in less than 20 minutes.

“I definitely feel like I learned from that scenario about how to structure my data center so that I can support my customers when they need to be supported,” she says. “There are educational moments in every failure. Failures happen. Things go wrong all the time. It’s how we react to these failures that matters.”

Most failures won’t be as extreme as losing a data center. But it’s still easy to feel the pressure to get the right answer the first time — another reason that small goals on a small timeframe are beneficial to help manage those hard problems. Running a month-long experiment chews up more resources than investing a day in a smaller one, and smaller experiments reduce the variables that could go wrong in the quest for a right answer.

“It gets back to that complexity conversation,” Keating says. “Failure is a great way to learn how to solve complex problems. Every failure is an exercise in looking at the complexity of the problem, breaking it down into what really matters, and then focusing on the order of operations to fix it. Freak out after it’s done, but in the moment, just break down the problem into its parts.”

Panic is a much more natural response when the failure leads to severe pain points — the company losing customers or money or reputation. That response is much less likely when you’re looking at smaller goals. You’re no longer solving The Big Problem; instead you’re creating many small solutions that cumulatively will lead to significant change for your organization.