Your Platform Org needs a purpose. Here’s how to find it.

Recently I’ve had a number of conversations with leaders in other companies that are considering building some kind of Platform Engineering organization.

Often there is a loose collection of teams that are already managing aspects of the infrastructure, like their Kubernetes clusters, and providing tools for engineers. All staffed with individuals that have “DevOps” somewhere in their titles.

The question I get asked is: “How do you turn this into an organization?”

I love this question, because this is what we did at Doma.

Platform Engineering at Doma started a little more than a year ago as a collection of teams focused on specific areas like developer experience, cloud infrastructure, product security, and quality frameworks.

We had individual teams, but collectively we didn’t have a clear identity that our customers and stakeholders understood.

What do you do here?

Without a clear identity that united us, it was hard for us to know what work we should or shouldn’t take on beyond the tool or domain specific items. It also made it hard for us to align on cross-domain priorities. Finally, it made it hard for leadership to understand the impact we have on engineering or the business.

We realized in order to become more than the sum of our parts, we needed to see and define ourselves as an organization.

How we defined Platform Engineering

Defining our organization was not an overnight process. It took us weeks to really understand the customer pain that we needed to address then design and communicate out a plan for doing so.

To avoid an overly long article, I will break down how we did this work into 4 parts and dive into the details in separate articles, starting with the first part below.

Part 1: Starting with the “why”

Years ago I watched the Simon Sinek video on the power of “why”. While the video was focused on outbound communication, it is also highly applicable for internal alignment. A “why” or “purpose” is a powerful tool for not only shaping where you focus and what you execute on, but also how you operate and eventually evolve.

I like this example from Disneyland back in 1955:

The purpose of Disneyland is to create happiness for others

This simple purpose guided everything from the uniforms that people wore, to the design of the parking lots. Further, it has lasted for more than 60 years, and still provides guidance as the park evolves. This is the essence of a great purpose. It’s simple, timeless, and meaningful.

What makes a good purpose statement?

· It should be emotional and inspiring — You should jump out of bed saying “I want to work on that!”

· It should be simple but meaningful — It should be in plain language, and easy to understand

· It should live as long as the org does — Strategy and tactics change; your purpose should be stable

To ensure we identified a purpose that would resonate with our customers and stakeholders, we knew we needed to gather a lot of input first. Using some of the principals from the Customer Driven Playbook, we assembled a working group of individuals from our teams and began to research.

What we researched

We interviewed people across every customer team

We took a very UX-researcher-like approach to this. We needed to understand directly from our customers what their lives were like today. While we did ask questions about pain, mostly we wanted to gather context on how they solved specific problems. A great way to think about this is the “jobs to be done” framework. HBR has a great article on this.

Areas we dug into were:

• How they set up their development environment?
• What the process looks like from picking up a Jira ticket to getting code into production.
• How do they debug production issues?
• How do they know there is a production issue?

If you’d like to try this at home, you can take a look at our interviewer guide to learn more about how we ran the interviews, and the questions we used.

We met with stakeholders and leadership

Leadership, especially in the Senior Director level and above, are not involved in the tactical problems that our customers experience. Instead they think about the more existential, longer running pain that will impact the business if it is not addressed.

Here are two of the questions we asked from our CTO, VP of Engineering, VP of Product, and VP of Design:

• What keeps you up at night? — This is a classic question that helps to reveal current concerns. It does suffer from recency bias though. So it’s helpful to get more context on each of the responses to find out things like how long that concern has been an issue, and what have been the impediments to it being addressed.
• What are the critical projects or initiatives that must be successful? — Understanding what is visible to them helps you understand how you can link your future investments to stuff that matters in their eyes.

In the end, senior leadership needs to understand why you exist, otherwise you’re liable to be caught in an endless cycle of justifying individual investments and fighting for resources. These questions above give you a glimpse into their minds and what they value. Dale Carnegie summed this up well:

“If there is one secret of success, it lies in the ability to get the other person’s point of view and see things from that person’s angle as well as from your own”. — Dale Carnegie, How to win friends and influence people

We reviewed backlogs, roadmaps, and plans

Finally we grabbed all the work details we could find. The roadmaps from each of the engineering groups, we pulled in our backlog of asks, and we gathered a list of projects and initiatives. The goal here was to understand the direction that our customers and leadership wanted to head over the next 12–18 months.

This helped us understand a few important details:

• What were our customers trying to get done? — Just like with leadership, we needed to know what was going to be on the minds of the engineers in the near future. Would they be building lots of new apps? Are they going to scale up services for customers? Do they need to migrate to a new app platform?
• What impediments might affect their success? — If we have a sense of what activities they will be doing, we can start to look at what inefficiencies exist in those activities today. How many steps does it take to spin up a new application? What teams are involved in doing so?

A group effort

The research was done by not just leaders, but also individual contributors in Platform Engineering. This was especially important in the customer interviews, as we wanted to ensure that we created a purpose that would resonate at every level. This also helped create a much better awareness, and empathy, for our customer needs across the organization.

When the research was completed, we had an offsite with the a core working group to dive into the details. We asked ourselves questions like:

• Who are our customers?
• What kind of pain is the most impactful for us to address?
• What impact would it make for the business if we were successful?

I believe the last question is especially critical, because it helps to bring the entire conversation back to the business. That is vital. We can iterate on neat tools, wrap multiple steps behind a single CLI call, and take care of infrastructure details. But what we prioritize, what we focus on, how we measure success, ultimately all comes down to what will help the business move forward.

This was a critical discussion to have, not because it was a novel realization, but because having it together helped everyone absorb this into their bones. For a purpose to work, you have to feel it, not just know it.

Eventually we came to the following statement. Our purpose:

Make it fast and easy to build great products

Good artists copy; Great artists steal

In full transparency, while we landed on the same meaning in our group, the phrasing was largely adopted from a former colleague of mine who was at the time leading the productivity group at Google.

It’s a great purpose statement, and set us up for the next step: dreaming together.

I hope you enjoyed part 1, please keep an eye out for parts 2.