"You build it, you own it" - Creating a DevOps Culture

You know the old saying about how too much of a good thing can lead to unexpected problems? Case in point: microservices.

In recent years, engineering leaders have made growing use of microservice architectures to help their teams develop or update software at scale without disrupting other services in the application. Their use has gained in popularity along with the adoption of DevOps as development teams look to become more agile, but with more operational responsibility shifting to the developer, businesses find themselves trying to balance speed to market and quality.

Platform engineering teams have been more popular as well in recent years, tasked with making sure that the standards and compliance for the business aren’t sacrificed for speed to market. Given each team’s objective, there is a natural friction between the developer trying to build and ship products faster and the platform engineer needing to slow things down and ensure standards are being met.

Enter Ken Rose and John Laban, who saw this tension in the making that begged for a solution. Before pairing up to start their own company, the two had worked together at PagerDuty, where John was the first engineer on the team. Ken was also previously a senior developer at Shopify.

Founding OpsLevel in 2019, they sought to make it easier for engineering teams to adopt a true DevOps culture of “you build it, you own it” by creating an internal developer portal that helps the teams in the trenches move fast while adhering to strict standards.

We spoke with John and Ken about their path to entrepreneurship and how they landed on an idea whose time has clearly come.

Q: You’re both very technical guys. When did the technology bug bite you?

John: Back in high school, I fell in love with it. I found it to be the perfect fit. I liked working with computers. They were very logical and did exactly as you instruct them. And if they didn’t, it was your own fault because you programmed them badly. Anyway, I thought that there was a lot of elegance in the way that everything worked. That led me to distributed architectures and microservices and service-oriented architectures and just how everything interacts together in these big complex systems. It was interesting to me back then. And still is.

Ken: I would say that I have a similar pedigree. Growing up, I loved mathematics, and then my dad gave me my first computer when I was nine. I loved the idea of something you can program and make it do what you want. I found myself diving into the deep end of BASIC and programmed all throughout high school. When I ended up going to graduate school, I still really liked math and computer science and did a degree in geometry processing, which is like the nexus of those two. But it was this love of that logic, as John pointed out. Computers are very systematic. You must be very explicit with them, and there’s an elegance to that.

Q: As far as your personal histories, you two first met when you were both at PagerDuty. How did you connect?

John: I started as PagerDuty’s first employee in San Francisco because that’s where the company started. When we decided to open an office in Canada, I interviewed Ken for a position, and he turned down the offer because he wanted to do a startup.

Ken: Which didn’t work out.

John: But a couple of months later, I met him again — this time at some meetup in Toronto — and convinced him to do a bit of part-time work for us as a contractor to help cover his, you know -

Ken: Bills!

John: And he did. The part-time work eventually turned into full-time contracting, which eventually turned into full-time employment. The rest is history. But that was over the space of a year or two.

Q: When did you decide to do your own thing together?

John: At the time, Ken wasn’t at PagerDuty anymore, but I was like, “Hey Ken, do you want to do a startup with me? Let’s do this.”

Ken: At PagerDuty, we worked together successfully for four years. John was on the managerial track, and I was on the technical track. I loved working with him, and I would love to work with him again.

Q: How did the idea for what became OpsLevel come about?

Ken: We put our heads together and came up with a list of something like 50 bad ideas. But then we found a good idea. There was a lot of complexity in microservices and challenges for software organizations running large production architectures to understand what’s out there and who owns it. That problem kept coming up again and again. And it was also a problem that John and I both had a lot of domain knowledge about.

Q: At what point did you see that companies were encountering challenges as far as their microservices architectures were concerned?

Ken: As part of the discovery that John and I did, we had seen organizations repeatedly building the same kind of tooling internally. For example, I worked previously at Shopify, which had its own tool internally that did cataloging. We saw that Spotify also had built one. Then we saw that LinkedIn had built one. And then we saw that a bunch of other companies, while they hadn’t quite graduated to the level of building their own internal tools, were trying to solve this. So, there was a lot of acceptance that this was a problem that organizations have.

Q: Now you had to convey the value of what you were offering to the folks who signed the checks. How did you help them understand how this solves a pain point and makes their operations more effective?

John: For at least a decade, there had been a big shift towards moving ownership of systems away from central operations teams, moving ownership of running a service to development teams. But a lot of the tooling had fallen behind in terms of the supporting tooling. The C-Suite had very little visibility into what was happening, where you suddenly had a hundred or a thousand of these different services, and ownership was spread around development teams, and they’re all building things independently and differently.

That led to lots of issues because of that lack of visibility, whether it was around reliability or security or being able to speak confidently about their architecture and getting it to a certain level of standardization — which was next to impossible. We could help them to answer questions that they hadn’t been able to answer before and that was a big change.

Ken: Being able to help those folks in the C-Suite to understand risks that they have around dimensions of security or reliability or quality, that was a lot of what our first product aimed to do.

Q: What’s driving the growth — some might call it “bloat” — in microservices?

John: Microservices are there to solve a specific way of building software so that instead of putting everything in one giant piece of software, you start building some functionality into separate pieces of software. But at the same time, the fact is that these architectures are growing, and a lot of different systems are getting added all the time. That’s a problem that we’re trying to solve for companies so they can understand the scope of all the systems that are out there. Who owns them? What do they do? Who’s responsible for them? Are they still running? That kind of entropy grows naturally in companies. If you don’t have a way of keeping track of all these systems, it can get messy.

Q: Let me shift gears. John, you both started your own company, and you started early at PagerDuty as their first engineer. Were there any learnings from those experiences that you’ve been able to apply as you’ve grown into your roles at OpsLevel?

John: For sure. Some of the mechanics around running a business I had done before, so when you’re starting a startup, it helps that you’ve done a few of those things already. At PagerDuty, we saw big changes and a lot of scaling and growth that required us to change how we worked internally repeatedly at different thresholds of growth. Starting from nothing and being able to take an idea and build a product, get it into the user’s hands, get feedback, continue to iterate, and figure out how to sell it — that’s all been new and a lot of fun learning how to do.

Q: Ken, you were part of the Shopify mafia. I know that several people who worked at the company have gone off to do their own startups. And Shopify’s President Harley Finkelstein himself has promoted a spirit of entrepreneurship internally and encouraged employees to go out and do side projects. Did any of that impact the way you thought about your professional career?

Ken: A hundred percent. When I was there, it was absolutely a phenomenal place to work, where the culture of entrepreneurship was very strong. I worked on interesting and challenging technical problems at Shopify. But at the same time, there was also this whole culture encouraging you to be an entrepreneur.

Q: Have you found doing a startup to be different from your expectations?

Ken: Oh, big time. I reflect on this a lot because I think I had very naive ideas when I started. I still think of myself as a software developer; I just get a lot of joy out of building systems and writing software. I still do some of that, but it’s rarer and rarer. And I think when I first started at OpsLevel, I thought that’d be my entire job. I’ll just be working with other developers and building products. But a lot of the job is more of being a manager, being a leader, and helping teams execute and deliver on a vision. It’s a lot more about being very articulate on goals, being very clear on the direction we’re trying to go in, and diving into the details when it makes sense to you. But also, it’s about giving people space so that they can practice some autonomy in the details and leave their own stamp on things.

Q: John, you want to take a swing at that?

John: I think having those early day experiences as PagerDuty’s first employee did prepare me for daily volatility. There is a lot of that at a startup, but I was prepared for it. Every day, there might be a new fire that you need to deal with. At a larger company, you can really focus on your domain, and that’s all you need to care about because other people are protecting you from all the BS that goes beyond that. But as a founder, the buck stops with you, and you need to be the one who deals with things when there isn’t someone else already responsible for it.

Q: How did you learn to handle leading in a remote engineering environment?

Ken: Half of the engineering team was in Toronto, and then half of it was in San Francisco. So, we got really used to the idea of having your standups at certain times and being sensitive to time zone differences, and having a bias towards over-communicating on tools like Slack and setting up Zoom meetings when it makes sense. We try to get the entire company together twice a year just to be able to foster the types of relationships and communications that happen when people are together that you just can’t get on Zoom.

John: The best is if everybody can be in the same room. But you can’t really grow too large before that doesn’t work out so well. Personally, I think the hybrid — where half the people are in the office, and the other half aren’t in the office all the time — is probably the worst of both worlds. We dealt with that a lot at PagerDuty, and it was hard. When everybody is fully remote, I think that works out a lot better, though then we miss some of those in-person things. And as Ken said, we try to get the whole company together on a regular basis for team building and alignment at least twice a year.

Q: As leaders trying to create a company culture, what’s the biggest challenge you’ve encountered?

John: Before we even hired our first person, we created values that we thought were important for us in terms of our culture. Because otherwise, it just happens organically and can go sideways. With culture, you need to be cognizant of the kind of company you’re trying to build. It seems like a waste of time, but when you’re hiring the right people for your company and you’re making decisions based on a shared set of values, it saves tons of time later.

We have a set of five values that we think are critical for us. One is having a growth mindset. We’re always having to solve problems that we might not have ever solved before. So being able to dive in and do that when you’re a small company, and you don’t have specialists in every area already, just having that growth mindset is important. Another one is focus and efficiency. We only have a limited amount of time in the day, and we want to ensure that the time we spend is useful for the company. Another is intellectual honesty. In the decisions that we’re making, are we making the best decision for the company?

And, even if we didn’t come up with the idea, is the idea the best one possible? A fourth one is simplicity in terms of our technical architecture and how we solve problems. Simplicity will help us a lot faster if we keep everything as simple as possible. And the last is empathy. When it comes to working with others, that involves putting ourselves in their shoes and extending empathy to our customers as we build products for them. Understanding their problems is super-important for building a good product.

Q: Let me ask an embarrassing question. There’s a famous Canadian figure skater also named Ken Rose. You’re not him, right?

Ken: No, but there’s a whole meme internally on Slack. Our upcoming offsite company meeting will be held on a lake. So, it’s like, I’m going to give figure skating lessons in the great Canadian winter.

John: We wanna see if Ken can bust out some moves.

Q: Ken, I saw something you tweeted not long ago where you wrote that decisions should always be made with data analysis and rational thought, never ego, title, or emotion. Does that reflect your approach to management?

Ken: That’s the heart of intellectual honesty. It’s not about title or ego. It’s not about who made the decision. It’s how we objectively and scientifically evaluate a good decision. And a lot of that means being steeped in metrics and numbers and quantitative analysis, which is divorced from any kind of emotion or title or internal politics or anything else.

Q: John, is there a motto or a synopsis that reflects your approach to the job?

John: It’s something we repeat often and use to try to work against our own perfectionist instincts — done is better than perfect. It’s about getting something complete and shipped and out the door.

Q: Getaway question before we close. What person in your lives has had the most impact on your professional careers?

Ken: A wonderful man named Jean-Michel Lemieux. He’s an investor in OpsLevel and the former CTO at Shopify. Every time I have a conversation with him, I am blown away. I’ve learned so much in just an hour of talking with him. He has had a ton of impact on me.

Q: John, what about you?

John: The person who’s had the biggest effect on my current career and trajectory would probably be Mr. Ken Rose sitting with us today. He’s basically my work wife, and we couldn’t be where we are today without Ken being a solid partner for me over the last four years.