How One Medical’s CTO Calibrates Technical Teams with This Simple Shift
Sure, engineering, product, and design all work towards the same goal: to create the best possible product for their users.
But there’s plenty of room for interpretation around what the “best possible product” actually looks like.
“I’ve discovered that while it’s fun to solve interesting technical problems, people are even more interesting,” Lockhart says. “The opportunity to design processes and people systems that really work to keep people happy, and that motivate people to do the right thing for the company, is a really good fit for me.”
Today, she runs product management, engineering, design, support, IT and security. At One Medical, these roles are distinct — but not necessarily separated. “I’ve had a chance to compare and contrast organizations that have a separately reporting product management org, engineering org, design org, and I really experienced the trade-offs firsthand,” she says.
Instead, Lockhart developed a system that aligns everyone’s focus with one purpose: creating end-user value. It’s a shift in focus that not only helps prevent silos from forming between teams, but ultimately incentivizes the different functions to work together and discover the best possible product — for each use case. And it’s really not that radical or complex in practice.
Rather than aligning employees into teams according to a part of the product or layer of the engineering stack, Lockhart instead designs her teams’ structure to be centered around use cases.
“The way our teams are organized is by user experience,” Lockhart says. “For instance, we have individual teams focused on the in-office provider (or doctor) experience, the virtual provider experience, and so on. For each of those teams, the primary focus is on that specific use case. They get to know their end-users and spend time not on a specific part of the product, but serving a specific population.”
Similar to changing a mission statement, changing one’s primary purpose fundamentally changes their incentives. Even more, it narrows teams’ focus, encourages greater autonomy, and improves their ability to understand the user. Here, engineers solve problems and write code that ultimately enables a specific population to use the product exactly how they need to.
“They get to know their end-users and spend time not on a specific part of the product, but serving a specific population.”
“One of the reasons that our organizational structure works well is that we’ve been very intentional about what everyone’s primary team unit is,” Lockhart says. “If you were to come to one of the engineers on our team, they’re going to tell you that they are part of the product development team. They are not going to tell you they’re part of the engineering team.”
Interestingly, the teams themselves aren’t constructed in some crazy way. Instead, the differences are in the way people identify with the company’s mission, the conversations teams are expected to have, and who is giving guidance within the teams.
Why we have roles
Building teams around the end-user experience may be a fundamental shift, but it’s not an unattainable concept. After all, Lockhart says, it’s still built on traditional roles.
“At One Medical, your full-time job is still an engineer, a product manager, or a designer, and you report to the lead of one of those functions” she says. “But you’re asked to think outside your role and contribute to all aspects of work on the team.”
So while each team is designed to be porous to original and unexpected ideas, the traditional roles of an engineer, product manager, etc. are ultimately used to distinguish who makes the final decision.
“A product manager will make the final decision on the product triage and what each feature does,” Lockhart explains. “The designer gets to make the final decision on how something works for the user, and the engineer gets to make the final decision on how it’s built and how long it will take.”
“The reason we have roles in organizations is so that folks can determine what they should spend most of their time doing, and we can build balanced organizations around people doing specific jobs.”
There’s sound, practical reasons for having and maintaining these roles. For starters, you ultimately need to have that structure, she says, especially at scale. At some point, a decision has to be made, and the person who has the relevant expertise should make that final decision.
Furthermore, you’ll maximize your employees’ skills (and probably make them happier) if they get to focus on what they both enjoy and are good at.
“The reason we have roles in organizations is so that folks can determine what they want to spend most of their time doing, and we can build balanced organizations around people doing specific jobs,” Lockhart says. “And above a certain scale, you cannot have people who are engineers and product managers and everything else. You have to have some way of establishing who makes the final decision, or else you’ll have chaos.”
How Lockhart actually manifests this kind of broad ownership across roles is by facilitating a weekly check-in between teams. Unlike many other organizations, it’s not the product manager, scrum master — or whoever is the person at the helm of a team — who functions as the sole contact between the team and centralized leadership.
“Our regular check-ins are made up of anybody across the org who would like to attend,” she explains. “People about what’s going on and anyone can ask questions — in front of everyone.”
The purpose of these check-ins isn’t just to suggest a different course of action, though that may sometimes be the result. It’s more about engaging all members of the team so they can gather context from other areas of the organization, and learn about other teams’ constraints, progress, and strategies.
In a logistical sense, these check-ins are fast-paced and simple, as well. “Our check-ins are a string of fifteen-minute sessions where representatives from Engineering, Design and Product Management come and present,” Lockhart says. The meetings last much longer than that, but each team gets only 15 minutes, which helps these meetings feel fast-paced. And everyone who attends will leave with a holistic and real-time perspective on what’s going on in technology.
“We get a sense of what’s going on, and frankly, we can all catch issues or overlaps very early,” she says.
Another massive benefit of this approach is the diversity of thought within a team. If engineering and product and design are consistently having conversations, ideas will emerge and information will be shared.
“We come to work, and every part of our job is focused at end-user value.”
“The engineers know how the systems work, and so they can find shortcuts and they can often find outside-of-the-box opportunities, simply because they know what the technology is capable of,” Lockhart explains. “There are these rich discussions when it’s not off the table for an engineer to suggest a different prioritization decision.”
This openness to different perspectives derives from — and serves — One Medical’s cultural emphasis on the customer experience. When engineers aren’t a part of just an ‘engineering team’, but rather a specific user experience team, you end up with cross-functional units that effectively serve the same purpose. “You come to work and every part of your job is focused on end-user value,” Lockhart says.
Ultimately, Lockhart recognized that there’s a strong correlation between organizational structure and how teams work together. By simply giving teams (with different skillsets) one shared purpose, and facilitating communication within those units, she’s established a system that creates a better employee — and customer — experience.
Ben Thompson is a co-founder at GitPrime where he leads design and customer experience. He is a Y Combinator alumni, with a background in product design, branding, and UX design. Follow @thebent on Twitter.
Get Engineering Impact: the weekly newsletter for managers of software teams
Keep current with trends in engineering leadership, productivity, culture, and scaling development teams.