Ch-Ch-Changes!

Strategic change is easier said than done. The bigger the change, the more likely you'll face internal resistance.

When you work in a startup, it can feel like you’re in a constant state of flux. If you’re in a high growth company (tripling or more year over year) it will feel like new company every six to nine months. You’ve got different customers, sales channels, products and competitors at every new stage.

Incremental change, such as a new market segment, new sales territories, a new pricing level is easy for most people. But when you make a change in strategy that can be harder. Especially changes like:

• New product

• New positioning

• New market segment

• New business model

Or all of the above when a company undergoes a major pivot.

Station to Station

Strategic changes are by their nature more disruptive. They have the potential to change the trajectory of the company and the careers of those involved. But only if people get on board. If you don’t manage the transformation, you might find that internal resistance or indifference slow things down.

Unfortunately, you can’t just make a grand pronouncement in a town-hall meeting and expect that everyone will “get it.” No matter how clearly you’ve articulated the logic, people will gravitative back to their old ways. Yes, of course there’s the new thing, but I’ve still got my old job to do!

If you don’t manage people through the change you can lose weeks or months to the status quo.

The early days of Duo Security were fraught with change. As with many companies, there was constant pressure to get new features out. Usage had grown quickly over a couple of years and as we added more large customers, peak usage exceeded our capacity. We suffered a couple of server outages which tarnished our prior 100% uptime track record.

Is It Any Wonder?

The problem arose through suboptimal decisions made by independent teams. New trial users were all placed on one server, known as Duo1. Once they became paying customers, the customer success team was to move them to other servers in a round-robin fashion. Unfortunately, because there was often minor re-configuration required on the customer’s side, many large customers were not moved.

The result was a steadily increasing volume on Duo1 while other servers were well below capacity. The concentrated workload resulted in multiple outages on Duo1 impacting a disproportionately large number of customers. Sometimes the most damaging problems in scaling companies aren’t caused by bad decisions—they’re caused by perfectly reasonable decisions made in isolation.

While Duo’s early customers (many of whom were themselves startups) might be tolerant of an occasional brief outage, larger enterprise customers would not.

This required rewiring the organization to understand that our priorities had to change. I worked directly with Chester Kustarz, the head of Engineering, to solve the issue. Chester was a phenomenal leader and he understood the technical and organizational challenges. While we were all somewhat embarrassed of the outage, that wasn’t going to fix the problem.

I joined Chester in a meeting with his direct reports and team leads. I knew people already felt bad about the outage. In my experience there’s nothing to be gained by getting mad or blaming people for the sins of the past.

Instead, I emphasized that our newest customers, including hospital doctors, could be locked out of systems during an outage. What happens if they can’t prescribe the drugs that are needed during an outage? Everyone understood the severity. We had all used products that started off great and then grew bloated or unreliable over time. We didn’t want Duo to end up like that.

We Can Be Heroes

This established a clear emotional reason for why we needed to do a better job. We had to do right by our customers. Chester listed all the feature priorities for the quarter. And at the top he wrote “P0 - Reliability.” This was our new priority.

A hand went up from one of the team leads. “But what happens when the founders ask about our ship date for the next release?” It was a good question because it brought forward an underlying fear many of the Engineers had.

“If it takes us 30 days to make the product more stable, that’s the time we will spend. I have your backs. And I will push back on the founders to let them know this is necessary.”

“But what happens if it’s more than that?”

“Don’t worry. If it’s 45 or 60 days. I will push back.” Then I smiled. “But if it’s 90 days, we might have a problem.” We still had pressures in the market and I wanted people to feel a sense of urgency.

Chester scheduled a follow up meeting with a larger group where we brainstormed ideas. Not every idea was necessary or practical. We later met with the managers to pare it down to a dozen subprojects that would have the highest impact. By working in the open we got more good ideas and more buy-in than we would have had otherwise.

The next stage was the trickiest. We had to make sure that people got moving on the new initiatives. It’s surprising that people can intellectually understand a need for change, they may even be emotionally motivated to change, but the practical matter of actually changing their behavior can easily get bogged down in day-to-day reality.

It’s not because people are trying to undermine the change, it’s that they still have existing obligations and projects that were started before the strategic change.

So what Chester and I did was meet with every engineer to review what they were working on and help them to wrap up their old work as quickly as possible so they could get started on the new tasks. They could have a day or two to clean up and check-in their existing code. But we were clear that this change in priority around reliability was not just some abstract concept. Their work had to change to support it.

I have found that this last phase of change is the often neglected resulting in wasted effort and expensive delays. You train sales people to sell a new product, but as soon as they get a prospect meeting scheduled they go back to demoing the product they are already comfortable with. That’s just human nature.

In some cases, you need to absolve people of feeling bad for leaving one project, perhaps not quite finished, in order to start on the new thing. Sometimes it helps to acknowledge that you’re putting an existing project into a state of “benign neglect.” Most importantly, people need to know that even if things aren’t perfect, they won’t get in trouble for working on the new thing.

Rebel, Rebel

In larger organizations, you won’t be able to meet with everyone, so you need to identify other agents of change. You may need to build a tiger team of believers who are excited about the new thing. Maybe there’s a sales person who’s ready for a new challenge. Maybe it’s just a couple of engineers who want to work on something new. The most powerful teams are those filled with passionate believers. And likely, you may need to operate outside the normal organization structures.

When we launched a new subscription version of MySQL, we couldn’t get buy in from the head of Sales. He liked the existing license model and didn’t want to distract his team. So we found one sales rep who was willing to give it a go. We got a couple of engineers on loan and one marketing person to help build the initial subscription product. Only after our cowboy sales rep closed a few deals did others start to believe in the new model.

The more radical the change, the more likely you will find opposition from internal leaders. If someone has spent ten years building a SaaS business, they might understandably be skeptical of the ability of AI to replace it. This scenario plays out every time there’s a platform shift and it’s one of the reasons agile startups are able to disrupt larger incumbents.

The best way to win over skeptics during a transformation is to operate with high transparency sharing every win, every loss, and every lesson you learn along the way. At Duo Security we put up a sign that highlighted how many days of uptime we had without incident. Our new reliability initiatives were given significant airtime in all-hands meetings, so people could see reliability was valued as much or more than new features.

As you share progress, share the spotlight, too. Let individual contributors, rather than executives, speak to their work. They will have more credibility with their peers than any top down announcements.

Change is never easy. It takes way more effort than you expect. But if you follow this approach, you’ll get more people moving in the right direction than if you just announce the change and hope for the best.

If there was one constant in David Bowie’s career it was change. His 1976 greatest hits compilation album ChangesOneBowie was a seventies rock classic. Though many artists stick with a proven formula, Bowie continued evolve well into his, ah, Golden Years.