¶ Intro / Opening
The promise of AI agents and models isn't vibe coding. It's getting real important work done. But how do you give agents access to your internal data systems and services without creating a security nightmare? ToolHive is the open source project simplifying and securing MCP so you can connect your AI agents to the tools they need. It provides a verified registry, consistent runtimes, and built-in security for your peace of mind.
Start building with confidence. Visit toolhive.dev today. We have a meeting where all eight of us, you know, we got on in the first five minutes. You didn't talk to any users. Cool.
Click. Zoom is done. You're going to go do that, and then we'll reschedule the meeting. No problem, but that's like a requisite step. It doesn't matter how good your ideas are. It doesn't matter how much of a bullseye you think you hit or reverse engineering or whatever, or even if you built it before. If you built it at a previous company, we don't care. Go talk to users. Talk to our users.
talk to other users in the market. Engineers are really smart. You'll start to see the patterns across what you're hearing and use that to inform the product. And once you do that, It's locked in. But if you're not talking to users, it doesn't matter how smart you are, how clever you are, you'll be off the mark. But if you do really talk to users, you can launch stuff that feels like a magically good fit for them.
Hello and welcome to the Engineering Leadership Podcast, brought to you by ELC, the engineering leadership community. I'm Jerry Lee, founder of ELC. And I'm Patrick Gallagher, and we're your hosts. Our show shares the most critical perspectives, habits and examples of great software engineering leaders to help evolve leadership in the tech industry.
¶ Episode Introduction: Collapsing Talent Stack
What happens when you collapse the talent stack and empower your engineers to be the product managers, designers, and even marketers for what they build? What if they own the entire journey from the first customer conversation to the final launch? In this episode, we go inside the operating model at WorkOS with CEO and founder Michael Greenwich to explore what happens when you empower engineers to own the full product lifecycle end to end.
We cover how they intentionally structure their org with just 1pm. You'll learn the tactical details behind teaching engineers product taste, the power of having developers talk directly to users, and why Michael's most important job is often to cut scope.
plus how to remove the lossy translation layers between teams to ship higher quality products faster. And we go behind the scenes of MCP night in San Francisco, which looked like a wildly good time. Let me introduce you to Michael. Michael is the founder and CEO of WorkOS. developer platform that enables companies to become enterprise ready through features like single sign on.
Their customers include many of the fastest growing startups, including Webflow, Drata, Loom, and over 200 others. Before WorkOS, Michael co-founded Nylas and studied computer science at MIT. If you're curious about rethinking org design, empowering technical teams, or... teaching engineers to think like PMs, this is the episode for you. Enjoy our conversation with Michael Greenwich. Michael, happy Friday. Welcome. Thanks for joining us on the show. What's going on?
¶ WorkOS's Unique Engineering-Centric Model
Thank you for having me. Yeah, happy Friday. It has been a crazy year, crazy six months for us as we've been growing and getting more customers. And when it rains, it pours. We're working with a ton of AI businesses and everything's just been changing so fast. I think that's probably the only constant thing. this year has been i was joking with a friend it feels like it's been about a decade since january yeah you know and i'm just absolutely here for it
The context you shared there is actually kind of a lot of how we created this conversation or how this conversation got inspired. And I had a little bit of a walk up here because I think there's some important signals I wanted to call out that set the paradigm for our conversation. And just for the background for everybody listening, like our goal here is we're going to be deconstructing how...
work OS operates and some of the really different philosophies, the approaches, some of the different ways of working. But the background here, there's been a couple of signs and signals. Michael, you were talking about a few different ones. I was like, I noticed all of the things that y'all are doing, the releases, the different customers that you've been.
recognizing i was like there's a lot going on here and so i was like okay that's that's interesting so a couple hallmark signals i want to call out so the last two years there's been this trend of flattening orgs so that's something we've been paying attention to we've had some folks talk about that
Two days ago, I had a conversation with the CTO of OpenAI and his team. And one of the things they were talking about was engineers need to become CEOs, was like the platform. He's like, engineers need to be CEOs.
So I was like, huh, that's interesting. Also, and then our conversation where I reached out, I was like, hey, Michael, like WorkOS is releasing a ton of crazy things. Like, what's going on? Like, can we talk about how engineers being led? And you're like, yeah, I'm leading engineering. I was like, oh, okay, cool.
All of these came together, plus a few different themes of our conference coming up. And to me, it started to signal this emerging trend that I think is going to be more common. And it's this idea of flatter orgs. engineering leaders having a broader context in the business or the business needing to be led by a highly technical and business leader.
And so our conversation kind of hits these areas of, you know, what happens when a CEO takes over engineering? Why would a CEO do that? And what can engineering leaders learn from that? And all of these other trends that are starting to kind of converge. So I think first a pause here.
Initial reactions to those signals. Am I hallucinating? Or are these sort of things that you're seeing and observing too? What's your sort of take around that landscape? Yeah, it's a great question. So I think first and foremost, what I would say is... I only have kind of one data point, which is like myself and how this company and how I'm running it. I was joking with somebody like the other day that WorkOS is the biggest company I've ever worked at, you know.
I haven't worked as an engineering leader at other organizations. I didn't have a history of coming from Google or one of these big companies, so I've just been figuring it out. Also, along with that, our product is pretty unique in that we sell to other technology companies. We're not off selling an HR product.
to payroll people or something like that. We're not off selling a product to salespeople or marketing people or accountants or farmers or whatever. We're selling to other engineering teams, the CTO, the VP of Eng, we're infrastructure. and so when it comes to like the collapse of that kind of talent stack around whether it's sales or marketing or product or leading engineering
For us, engineering is at the core of everything. Even when we're doing marketing, it's technical marketing. Even when we're doing sales, it's to a technical person. And so I think there's probably some aspect of this as well that we'll talk about where I wouldn't claim for this to be something that's generalizable to every business.
If you're building a product for lawyers, it probably makes sense to have somebody who has been a lawyer in your product function involved in that to really understand the right fit for that business. Or I think for doctors. God forbid, you know, you have engineers trying to decide what doctors should do. You should be talking to doctors and they should be helping Jeffrey to roadmap. But if you're building a product for engineers, it actually fits really nicely.
The counterpoint of having somebody perhaps who's not technical or not an engineer try to do marketing, for example, for an engineering-focused product, I think we've all seen that happen.
Probably a lot of listeners, podcasts are engineering leaders. And you've had those people try to market to you where they just don't get it. Or you read a billboard that says something and tries to be kind of clever on engineering language. And you're like, no one would ever say that. It's a bunch of BS. So I think it's perhaps like a bit unique. Maybe it's hard. business in me as well.
¶ End-to-End Ownership: Engineers as Product Leads
I believe that. The element, though, that I think is interesting is what you're talking about with the talent stack and the collapse of the talent stack, because there's been a couple different conversations that have sort of poked around at this demand right now, which is that people have the ability now to work in a much more broad.
capacity, like that you're no longer just siloed to your specific function, but you're sort of touching a lot of different things. And there's a lot of different ways that that manifests. And so I guess maybe I want to kind of unpack this concept of the collapse of the talent stack first, and maybe how you're interpreting that and how you see that manifesting with.
within WorkOS. And so can you bring us in a little bit to like, you know, you've been paying attention to that and have started to organize WorkOS around some of the different principles, like bring us into your perspective there. For context, like where we're at today, so we have an engineering team of about like 40 some people engineering and design. And we have about five or six engineering managers around that that are running teams of a couple handful of people.
These are loosely organized around the different products that we have, so different kind of product areas. And we have one product manager on the team other than me. I sort of act as a PM sometimes. But that product manager has a lot of deep technical experience. You know, like I was a director of product at a very kind of architecturally deep product company before. How we operate is really engineering leads, staff engineers, EMs are the ones talking to customers, driving things forward.
actually figuring out what product to shape, working with me and others on the roadmap, but taking things end to end. They're the ones that do initial design work with our design team. They write this type of product spec that gets reviewed by other engineers on the team. They build the stuff and then they actually roll it out and they talk to customers and write the launch blog post and do things end to end. So it's this very kind of end to end entrepreneurial journey.
And even actually when we launch stuff, we will often have those engineering leads do the early sales of it. Kind of this like founder sale mode type of thing before we're monetizing it, get people to onboard and get them to use it. And so we don't have a separate PM that's in that process. It's not the engineers being handed a spec. They're not seeing it for a short window of it and then being done. There's no QA team afterward.
Engineering is at the beginning and at the end of everything. And so that continuity, I think, is the first part kind of collapsing the talent stack. It's having that kind of shared vision around whatever product they're building from the early conception all the way through delivering it to the customers. When did this become a part of the culture and the operating? What was it like to sort of evolve into this being normal? I think every company starts this way, is my thesis.
Every business begins with some person starting the company and having an idea of a thing and then them just being on top of it the whole.
Period. And that first person was me in the organization, right? Had an idea for the first thing to build, hired some people and had the idea to talk to the customers, tied it through with engineering. And so what we've done at WorkOS is taught other people how to do this, how to drive it end to end. We've had people who have previously been founders come to the company.
We've had a lot of people leave WorkOS and go start companies quite successfully. And so I think it's actually been something that we haven't brought to the organization. It's been there since the very beginnings.
It persists because we have a lot of different products and a lot of zero to one work. If you're a company where you kind of built the product and got product market fit, now it's just all about optimizing and scaling it. You know, you might not have a need to do the zero to one work with engineers. It might be fine.
for them to sit in a narrow part of the process. But if you continue to build zero to one stuff where you're trying to get product market fit, trying to test stuff, trying to experiment. You need to have a lot of people do this. You have to shard it, you know, instead of it just being me. And so we've first of all taught our EMs to do that. And then second of all, taught kind of senior staff, principal engineer level folks to do it too.
¶ The Product Building Playbook & User Obsession
Can you bring us in a little bit into the teaching process of that? Because the assumption is that this seems to be the trend that's going to become more normal. Because of leaner teams can do much more, new different types of products can be created much faster. It just seems like this end-to-end focus is going to become, I don't know, my belief right now in what I'm operating with is I think that's going to become more of a common thing.
But I'm like, I'm seeing so many different signs that are pointing in this direction. Yeah, I think it's also more fun. I think you build better stuff and it's more fun too. I think if things are more fun, people will do them more and it will become the compelling. Why do we use GitHub? Because it's like more fun to write software that way. It's not just more productive, but it's actually more enjoyable.
Maybe I'll give an example of a product that we built last year, kind of like zero to one and sort of how it came about. We had a lot of good momentum and success with this product we built called AuthKit, which is our identity product. So it manages user login, registration, it's your login box.
Cursor and a bunch of other companies are using it. So you've probably logged into an app using this. And we started noticing that in addition to this, people were often wanting to augment it with things that did CAPTCHAs or things that kind of blocked like bot behavior. And so we said, could we integrate a third-party system into it what could we build we couldn't really find anything that we were that happy with and so we said okay let's go build this
We often will have like one or two engineers to start prototyping stuff. Go look at what other people have built in the market, reverse engineer things. And then the number one place that we look is we go talk to users. It's our number one operating.
principle when building new products, talk to users. Don't just read stuff, go actually interview them, hear about the pain, see what they're complaining about. And don't ask them for the solution, but ask them for what the problem is, how they articulate it. And we wrap the whole product narrative and product story around that. And then when we build the...
we usually don't build very much of it. It's like 20% of the actual product, just enough that you can demo it and show the experience and show it working and provide some value. but what we really really really try to nail is the whole story of the product why should it exist and so in my mind like when we when we do that
The marketing page for that probably is not going to change for a full year after we ship it. We've sort of captured the full story around it, even though we'll continue to add features and augment it. And I think that... Having the same person that's doing the discovery figure out how the messaging works and figure out actually how the marketing can work and kind of tie the whole thing together.
If you have that happening in multiple people, you have this very lossy, slow translation layer, which is conversations or documents. People have to write stuff down and have meetings and talk to each other. You have the marketing guy, talk to the product manager girl, talk to the designer person, talk to the engineer.
When it's all in one person, it's kind of like, you know, on a CPU, you have like the L1 cache. It's like right there on the machine. It's like that. It's all inside the brain of one person that's spooling. And so the output ends up being this thing that's run the simulation all the way through. And it's like, this is the right way to talk about it.
And so we try to do that with that was a new product like zero to one. Now it's doing millions of checks per month, per week for people. And it's quite successful. But we even do that with small things, you know, very, very small additions. You know, we recently added MCP auth to our auth kit thing. And that was like in the spec. It was recently added the spec. It was like a pretty straightforward thing to add, but we kind of spin it up the same way.
You can almost think about us where we're either like making a movie or making a TV commercial, but you kind of run the same process around doing both. It's just different scale. For us, it's whether it's a whole product or a small feature, it's the same process. And as much as possible, we try to have like the whole idea end to end in at least one.
primary persons had to start we all want to leverage ai agents and models to do meaningful work but that means granting them access to our sensitive data and systems the thought of that is pretty terrifying How do you know which MCP servers to trust? How do you know if you're managing sensitive information like your API keys the right way without just tucking them into plain text config files?
If you're working on anything in the enterprise, you've already probably seen AI agents get stuck on the shelf until the right security guardrails can be put in place. ToolHive was created to solve these exact problems. It's an open source project from the co-creator of Kubernetes that... brings security and simplicity to MCP.
ToolHive provides a verified registry of MCP servers so you can discover and use them with confidence. It containerizes each server for consistency and isolation and manages your secrets with an encrypted vault or one password integration. you can stop worrying Visit toolhive.dev for more information and you can get direct links to their docs, community, and GitHub repo. Start building the agentic AI future with confidence at toolhive.dev.
¶ Cultivating Product Sense: Curiosity and Ambiguity
So what makes this work for the engineers on the team that are leading this part? Like what are the things that they need to learn or what are the skills that they need to lean into that help them be able to do this end to end? So we hire people for these skills. I should say too. We have found that you can learn it for sure. We've actually taught it to quite a few people, but we also look for it in our interview. We look for product sense. A big piece of it is curiosity.
People who want to keep peeling things back and understanding why, how does it work? They're like unsatisfied when they don't know something. I like working with people like that too. It's just fun. They're curious, puzzles kind of get at them and they want to peel it back and understand. The reaction often is when we see other companies having built something in a certain way and we look at it.
Our reaction is not to just go copy a feature or something like that. It's to say, huh, why did they converge on that? Like, why is that the architecture that they have? Why is that the design? What truths are hidden in the decisions, the output that they made? You know, can we reverse engineer?
kind of the decision tree that went into that product. Because oftentimes, if you want to disrupt an existing product or build something better, you don't want to do the exact same thing, but you want to learn from like where they went, you know, kind of skip past the mistakes.
So being very curious and I think very inquisitive is one thing. You know, another thing is being comfortable with lack of information. If you wait to have perfect information before making a decision, you'll never start. And so you can almost measure. someone's level of comfort with unknowing. And the hardest, I think, state is actually often the types of decisions that CEOs make because you have almost no information.
You know, you see people make these crazy decisions with, you know, five, 10% of the information you should need, but you have to do that to get ahead of a curve, you know, to like startup founders, you know, or make making these huge bets of a whole company, despite having no information about the market. And so typically most people in their jobs, if you work at a mature company, you're kind of farther on the information curve.
where most decisions that are made actually are made when they have majority information or large majority of information about a problem. And those large companies don't want to take the risk of making the wrong decision because there's liability around it, or just generally they're conservative, right?
Google's a great example of this. It's like much scarier for Google to make the wrong decision around their LLMs, you know, and have them come out like a little snarky or racist or something like that than it is for them to be early and first, right? So they're very conservative around that today.
They want full information around it. And so I think part of it, especially hiring experienced engineers or people from bigger companies, is to pull them back on that comfort and say, it's okay to only have 20% of the information, but start making some decisions.
And the way that we get them into that state is by getting them to build stuff. So saying, OK, we know this today. Let's cut some scope. Let's actually go start doing some engineering and use that as a learning process. So the prototyping phase.
The exploration phase, the kind of validation with early users. Everything in a startup is a prototype. Every single feature, even once you ship it, even once it's in production, everything's like up for change. You know, the goal is learning. You want to learn faster than the market. And so I think you can create these like ways of working that will lead people into that and then create like comfort around those things. If we make mistakes.
uh or even just build stuff it wasn't a mistake it's just the wrong thing to build the market doesn't want it you know being able to shut it down and not have to be a disaster to someone's career or whatever that those are types of things like that you want to you know embody in the organization and then i think what i've I've been pleasantly surprised it actually is teachable.
We have several people who came in. It was like a couple people in the last several years we've worked with who came in more as kind of like back-end infra-y type of people, but were like really smart, like really, really strong, but had never really done product work before. And within like six months, you know, or nine months, they were like totally crushing. it and able to go do zero to one stuff it's definitely a learnable skill which is pretty cool and i want to find ways to
¶ Unlocking User-Centric Product Development
Ideally, you can teach it to people faster at some point. What do you think, for those particular people, what was the unlock moment? What was the shift? Just starting to think like the user. A lot of companies, maybe for an engineer, you're not allowed to do that. It was like the PM's job.
You know, I remember at one point with WorkOS, maybe two or three years ago, a bunch of people in the engineering team were saying, we need a PM. We need to hire a PM. And I was like, what are you talking about? That's a bunch of nonsense. Like, what do you need? And they're like, oh, we need this, this, this, this. But we need a PM. You know, we're not going to be able to do it without a PM.
And I was just kind of like, okay, guys, I'll go hire a PM. But in the meantime, you need to go do it because it's going to take me a while. And I actually spent like six to nine months looking for a PM and I couldn't find anybody I liked. So I stopped. I just shut it down. And in the meantime, the engineers actually figured out how to do it. They got good at it. And so I think there's this mental block sometimes of like, oh, that's not my job. And nobody likes to.
things they're not good at and so i think engineers are like oh i'm not good at doing this thing i haven't done the product PM type of work. And so I'm not going to be good at it and I hate it. But then once they get good at it, then they really like it. And I think now we're in a place today where engineers really do like doing it. They like talking to users. I mean, we work with some of the most exciting companies out there. Like if you're an engineer and you can go.
spend an hour talking with somebody at OpenAI or Anthropic or Perplexity, it's a great day. And so they like doing it. And that means our bar for PMs has actually got up really high. You know, like if we're going to hire a PM, they're going to be like really, really amazing. And so I think there's part of it that's just kind of don't suck. psych yourself out and go do it. And people are generally I think people are surprised themselves at what they're capable of.
And so for the gaps and like the needs, like was it mainly like they were trying to do product discovery calls and trying to understand like pain points of the different customers? Like what was maybe the gap that they were looking for support and then like what was the skill that they developed? The number one failure mode. unequivocally all the time is that a super smart engineer, really creative, a lot of great ideas, yada, whatever. It's like, go work on this thing.
And they do some research and they start writing code and they write up a thing and they haven't talked to anybody. And we do like product review meeting or design review and they've written up this big doc and they even demo something. And I just ask like, okay, what users did you talk to? And it's like crickets. That's the failure mode. It always correlates with like missing something.
It's so funny. It's like engineers will exhaust every possibility before talking to users. They'll only do it at the last possible minute. And so we put it in our process. We're like, if we have a meeting where we identify early in the meeting, someone hasn't done that, we just cancel the meeting. we're just like oh all eight of us you know we got on in the first five minutes you didn't talk to any users cool click zoom is done
You're going to go do that and then we'll reschedule the meeting. No problem. But that's like a requisite step. It doesn't matter how good your ideas are. It doesn't matter how much of a bullseye you think you hit or reverse engineering or whatever. Or even if you built it before. If you built it at a previous company, we don't care. Go talk to users. Talk to our users. Talk to other users in the market.
If you just do that, and then eventually you'll start listening, you'll get better at listening. If you do it more and more and more, it's not just talking, it's listening. Two ears and one mouth, you know, listen more than you speak. You naturally will build that empathy. And that'll naturally get into actually making decisions. Engineers are really smart. You'll start to see the patterns across what you're hearing and use that to inform the product. And once you do that.
It's locked in. But if you're not talking to users, it doesn't matter how smart you are, how clever you are, you'll be off the mark. But if you do really talk to users, you can launch stuff that feels like a magically good fit for them.
¶ Real-time Customer Feedback via Slack Channels
So in this goal of taking products from zero to one, having engineers drive that. There's one specific pathway that I thought was really interesting. You and I were talking about the Slack channels you have with different companies and how that helps inform a lot of different things. Can you talk a little bit about that practice and how that gets infused in this process?
Yeah, we have thousands of Slack channels with other organizations. We have done it since very early on in the company's history. Some of these Slack channels are years and years and years and years old. They're with our customers. They're with partners that we work with. It's with everybody.
And so if you go sign up for WorkOS today, you will get a Slack channel invite. And through that channel, we will use to ask you about what you're building. You know, you can use it to ask us questions about how to integrate.
Once you actually do integrate, we'll push stuff into that channel about new products we launch, issues with their integration, you know, things that you need to know about. And it ends up being just kind of shared context between companies. In a sense, we're embedded in your organization.
We might not have a desk at your office, but having a channel in Slack with your engineering team is just about as good as that. And so we can push stuff in, but in particular, it also allows our engineering team to go get involved.
And so if our support team sees a user asking about a certain thing where the feature doesn't quite work for them, or maybe they need a slight adaptation to it, they can just tag in the engineer that was the lead on that. We can take that Slack message and make a link to it and post it in another channel and have a whole conversation around it.
so by having our support in situ be in our actual collaboration development environment for our company it creates this like again it's like the l1 cache this like super super fast feedback cycle and that speed and that time it's it's kind of like you know holding energy like
The faster you can do it, the faster you can solve problems, the faster you can get it to customers. And then once a customer realizes that they can give feedback and you can respond to it or fix it super fast, what do they do? They give you more feedback. They're like, oh, now that you mention it, here's three other things that I think could be a little bit better. And so our customers are an incredible asset for us making our product better. It's one of the most amazing things that we have.
I read, I would say like pretty much every single support message that we get. We don't respond to everyone, but I read, read it all. It informs my own product decisions. Having that in situ in Slack for engineering-led companies has been just an extraordinary asset to us. And we've had to build a bunch of stuff around it because it's hard to manage. But we find that people, when we do it right as well, they just have a really magical experience on their side.
¶ Simplifying Products Through Launch Week Messaging
Well, like you said, like the L1 sort of availability of information, like the opportunity to be embedded in an organization and to have a deeper context means probably better, more specific products. I see the feedback cycle there. And just recapping a couple elements of what we talked about.
Big point on talking to users. And the more engineers can do that on the front line, the better. The value or characteristic of deep curiosity. So let's say we've moved through that cycle. We've also got these communication channels providing really good feedback loops. The element of...
involving engineering teams in the side of messaging is a really interesting element as well. And so I was wondering if you could talk a little bit about what's the process of creating the messaging of a product? And then like, how does somebody who's going zero to one and building it, like what is that?
involvement look like to help go from problem discovery to developing that landing page? Like, cause I'm thinking, imagine people listening to this, like maybe you've never created a landing page like that. Like I'd like to know how to do it. It's not easy. I mean, the crazy thing is the simpler the landing pages or the simpler the blog post, the product release blog post is that you read it and it's like three paragraphs and you're like.
chef's kiss you know no notes like perfect that's what takes the longest amount of time those are excruciating to write in so many iterative cycles and just like bashing your head against the wall to cut the words down and get it focused. I mean, on our website, our homepage, it says four words. It says your app enterprise ready. And it took me like two years to come up with that, just thinking about it all the time.
so the first thing is like it's it's just really hard and sometimes engineers can look at simple things and assume that it was a simple process to create them and it's very often incredibly complex and messy process to create simple things one thing that we do that works really well is launch weeks. So we just did one a month ago.
Our summer launch week, beginning of summer. If you go to workOS.com slash launch week, you'll see it. We kind of make these cool like splash pages for it. And it has our summer one is like 1980s kind of beach vibes. You know, it's retro in a way.
And it's fun for the team, but we also write blog posts with all the launches. And the blog posts are written by the engineers that are building these features and rolling it out. And often what we try to do when we're working on a new feature that we think will go into a launch week is we start by writing the blog post. It's kind of similar to what... Amazon does. They talk early on about writing the press release for a feature before building it, or press release for a product.
I don't think anybody reads press releases anymore. I don't even know what a press release really is, but we write blog posts because people read blog posts. If you have to actually go through the experience of writing the blog post, you're confronted with the reality of communicating the value of what you're building to the world. And you can't just kind of say like what it does. you have to say why. And it's like an integration test for the business model of the feature you're building.
and if the person building it can't articulate and they talk to users and they can't articulate like why it's valuable or they draft it and write it and send it to somebody else and someone else is like i don't get it Or this doesn't make any sense. Or this is too long. It's actually a very, very good signal that you got to go back and rewrite something or cut something or get at the essence of it. Often the most valuable piece of that process is it lets you narrow down on like the bit.
that is actually valuable you're like all this stuff you're building but like actually it's this one thing that is the valuable thing and as we're building stuff then what we try to do is cut everything else like what if we just built that thing
¶ The Art of Ruthless Scope Cutting
Why do we have to build all this other stuff? Actually, nobody cares about that. It doesn't really matter. Let's just go build that one thing. And so I think it actually lets you have this prioritization to distill the essence of the thing you're trying to build and ship that. We all know the number one thing that kills products is too many features, too many things.
So we all want to make simple things. I don't think anybody says, I really want to make overly complex things. The hard thing is figure out like... What can you keep and what can you cut? And the way to test that, I think, is actually by writing and trying to articulate it, trying to actually get it out into the world. And you don't need to have written all the code to write the blog post. You can write a blog post for a launch of a feature you haven't written a single live code for yet.
just to tell the story. As part of that talking to users bit, we try to essentially force engineers to do that. We're like, go write the post.
Do I have to you know it's really hard again like the hard things become fun when they become less hard when you get good at them But once we find that that's written or we've distilled out that one bit the actual engineering execution of it is like a straight line it's like you can see the target we just run after it as fast as we can and this leads to like
extreme velocity and then high precision in building great products for the market and we just repeatedly do that again and again and again and i can tell you when you when you build a system that does that engineers fucking love it
It's so much fun because you just be able to, it's just like hit after hit after hit after hit with customers. Your customers love it. Your team loves it. I've just been delighted that we can actually coach or teach engineers to adopt them and have that be part of our culture.
What's interesting about this is right now there's sort of this narrative of like, yeah, you can build really fast right now, but now it's about building the right thing and not wasting time building the wrong thing. So talking about when you can get to the essence of that and have that direct line to building the core thing that's delivering value.
removing everything else like that's kind of i think kind of like the best expression of this sort of like meme narrative going on about like the capability of building with ai tools and everything and then you talk about like how people love like engineers love delivering that like so i'm like wow the core essence of what is that seems to be the thing to unlock
¶ Practical Scope Management: The MFA Example
Have there been questions that you found to be really valuable to help identify that, to help with the clarifying process or the polishing process to get to that core piece? Well, I'm always looking for places to cut scope. My two things that I do in the organization are broaden scope and cut scope.
And so when I broaden scope, it's usually here's the long term vision of what we want to do. Here's how why I think this could be so much so powerful over long periods of time. Or here's, you know, how we can build identity for AI agents. Or here's how we can do authorization and permissions for the large scale systems.
millions of users. Here's things that we can build for the cursors and open AIs of the world to help their AI products work better. And so engineers go off and build this. But then usually when we're actually trying to think about the feature, what I do is to come in and give the team kind of the ability to cut features. Because if you feel...
committed to that big vision, even if you distill down the bit, it's hard to have the confidence that when you cut, it's still going to be meaty enough. It's still going to have enough momentum and weight and kind of be meaningful enough kind of to the market to your customer base.
And so I'm often the one that proposes that. I'm like, well, what if we just cut this? Or what if we didn't have this feature? I'll give an example right now of something that we did. So let's see. It was less than two years ago, a year and a half to two years ago.
we launched our first version of this like AuthKit product, our identity product, right? And this has the login box, it does password auth, it does SAML, it does all the SCIM, does everything you need. It also does MFA. So you can add MFA factors and enroll them.
And we were looking at them and the engineering team was like, well, for MFA, you know, we have the device enrollment, you know, scan the QR code with like Google app or whatever and get a code. And there's also pass keys and there's also SMS based MFA. We got to do it because, you know, here's the coverage of the world and here's SMS MFA. SMS MFA, for anybody not familiar, it's not just like a barrel of worms or whatever. It's like a pit of snakes. It's terrible.
Deliverability is awful across the world. The cost of it is like highly variable depending on what region you're in. Sometimes it doesn't work at all. It's unclear to even secure, right? There's like SIM jacking stuff. It's bad.
right but the team was like we got to have this and i was like why why why do we have to have this and it was just this attitude of like well we have to obviously you have to have it and i was like well no i it's not secure what if we started off having this product like we sell to developers building modern apps we have the moment here to like cut this And we did. And we still don't have it in the product today. We still don't.
You know, we have companies using gazillions of users on our platform. We still don't have it. We did add pass keys later. You know, we decided to loop that in. And we have added some SMS stuff, some phone-based stuff for identity verification for anti-fraud, kind of as an additional layer that you can layer in certain. regions but we have never said hey we need to have this this bid in and i think that that piece around like can we cut this or not
You kind of have to have like one person in the organization that's maybe like a mixture of like has social cred or like authority and is also like kind of chaotic to be able to like suggest that to give the team permission to do it. Because then once we did it, the team was like, oh, yeah, that'll save us two months of engineering. You know, we can actually show. this on time. You ever see that movie The Martian? Absolutely.
yeah i was trying they're like what can we get rid of and they get rid of the nose cone of a rocket you know he's like the nose cone like yeah that's like 800 kilograms you know throw that thing off you could get in the high atmosphere you don't you don't notice it you don't need it turns out all you need is the engines right you know keep that right But that ability to cut, cut, cut, cut.
it turns out it lets you move fast. And so you sort of need somebody in the organization that has the clear. Now they have to be good, right? You want to cut the fat, but not cut to muscle or cut to bone when you're getting precise. But I think that's a hard thing to do. And generally people are rewarded by it. adding more features than removing them and so to try to put that into your practice now nowadays there's other people at the company that do that
¶ The Power of Small, Elegant Features
That will ask that question and be like, what could we cut? If we had to do it faster, what could we do? If we had to do this in one week instead of five weeks, what could we build? And we don't always do it that exact thing, but we at least ask the question. And I think that's a pretty powerful thing to institutionalize. trying to reflect on product experiences where I felt like a company got really to the essence of something.
And the one story that stands in my mind was I was at Config last year, Figma's big industry conference, you know, room full of designers, engineers, product managers, the PM who had done a few different of like their early kind of AI features they were introducing. And, you know, everyone's...
like, yeah, cool. Like, you know, they were releasing a couple different things and you could tell a big announcement was coming. They kind of looked with like a, you know, one of those like smirky, I've got a secret sort of faces. And they were like, oh, and by the way, here's this feature that auto labels all of the different layers of your Figma.
And the room erupted because that represented like the most amount of toil and like probably the worst part of design in the digital interface. And I was like, wow, everybody in this room feels so seen right now in terms of like their world and their space in this company.
just like really spoke to the heart of like one of their biggest pains. And I was like, wow, like what an incredible example of like, it's not a big flashy feature. It's like, no, just auto relabel all the layers. Like, and it's like clear nomenclature. I was like, wow, amazing.
And so I was just thinking about like getting to the root of the essence, like then the impact of that on the people that are then using the product. And you know that that feature was probably enormously complicated to actually build. It was actually probably really, really challenging to ship it in that elegant way.
you know, that it kind of disappears. One of my favorite product features like ever is the thing on iOS where it pulls the code out of your SMS messages for 2FA. You know what I'm talking about? Yeah, yeah. Or like pops it up right above the keyboard. Absolutely, yep. That is so good.
That is like the perfect distillation of product functionality. It's just right there. And they just added this thing recently where now I can pull it out of your email and other things. It's just absolutely brilliant.
And you would know, you know, that feature was like hard to build. It crosses all these different apps, it crosses security boundaries. It's like, does different people have a different SMS formatting? How does it not pick up, you know, the order number from my, you know, like birthday cake I just ordered or something?
into it and it's really hard to get it right you know really really hard but when you get it right it just is this excellence it disappears to me that's the kind of stuff that it's those types of features sing the big ones are great to nail but really great products are the combination of so many small decisions like that together and and it's usually like one person behind it that's like hey you know wouldn't it be awesome if
That's usually how it starts. And so giving that person the ability to go execute on it and having enough kind of scope cutting ability so there's capacity for people like that to do it too. It's a hard balance to get right.
¶ WorkOS's Weekly Operating Rhythm for Alignment
In the spirit of what we're talking about with the collapse of the talent stack and this sort of blurring of different roles, what I find so fun about this conversation is you sit really clearly in the major different functions. You are the business leader. and you're also heavily involved in product and you're also are heavily involved in engineering and in a lot of other like quote unquote like typical organizations or whatever like that that's being blown up right now
And so like for me, I kind of look at like a lot of things you're doing is like early signal of where I believe like things will kind of more likely evolve into. But one of the practices that I thought was really interesting was like your perspective on meeting with different product teams in this collapse of the talent stack, like how you're reducing like friction, like collaboration friction.
and reducing the context switching between the different functions, how do you structure the product team meetings? Give us that world, what that looks like, and why you do what you do around there. Yeah. Yeah. And I'll talk a little bit about tactically kind of how I do it. Right. And this is right now. Right. The size where I don't know if this will how this will scale.
if i am going to be kind of single threading a lot of stuff through like there's kind of there's kind of two ways to solve problems you know you can scale like horizontally or vertically right um when you're when you're scaling systems um the idea of scoring horizontally would be for me to go higher like a gazillion pms and have them all
be like independent product owners in different areas uh or different little mini ceos um but it has a coordination overhead and it's it's sort of like any distributed coordination problem you know we have this like zookeeper paxos or whatever like that like nobody ever implements that correctly much like in software and people much less software. And so the way that we've done it is more like single threading it.
There's really like a few things that happen throughout the week at WorkOS that help align this. First of all, on Monday mornings, we have our staff meeting. We have two staff meetings before lunch. One of them is with our go-to-market team. It's what we start with. So we go through pretty much the whole business.
you know sales marketing finance operations like legal hr and and just kind of plow through everything typically it's like customers are selling to deals we're moving through on the kind of nuts and bolts of the business the second meeting that we have is our engineering product design staff meeting and this is with all of our tech leads
and engineering leads and it's really driving forward like what projects we're doing we do this every single week right so it's like pretty rigorous review of every area we look at uptime reliability any incidents that happened over the previous week um it's about 90 minutes if you know 60 90 minutes so that's a pretty good overview and from
that usually we can make directional decisions it lets all the leads like sync up with each other it's kind of a context sharing meeting and and if there's something where we need to change roadmap or change process we can decide that like monday morning right so we have the whole week to impact it after that On Tuesdays, my day is stacked.
with either 30 or 60 minute meetings with all the different product teams building stuff. And 30 to 60 depends on the size of the team or the scale of what they're working on. Like our AuthKit team meeting is an hour and 60 minutes because there's so much stuff in it. We're shipping so much stuff so fast. where some new, more small teams, more experimental stuff might be 30. I joined that with all the engineers that are working on that team, the EM.
folks from our product team, sometimes people from our DevRel marketing teams as well, if we're getting close to releasing. And it's kind of the like weekly project update brain dump meeting of everything. And in those meetings, we try to make specific decisions that we need to run the product. We demo stuff. It's probably the most important.
weekly meeting for those teams. And we've gotten them into a pretty good cadence where they're actually pretty fun. It's not just like a big stand-up or something like that. But what I end up doing is like stacking those throughout the day. So I start that at 8 a.m. and I end up, I don't know, 4 p.m. Pacific time, 4 or 5 p.m.
It's a long day. Usually I'm scarfing a burrito in the middle. But context switching in between kind of means by the end of the day Tuesday, I not only have talked to all the engineering leaders on Monday, I've sort of talked to the entire engineering organization.
within 36 hours and so we know at that point if there's critical product issues that need to be changed if we're off base for roadmap if we need to change our ship dates if there's gaps of the product strategy you know we know pretty pretty quickly it can get surfaced
On Wednesdays, I do the same thing for kind of the go-to-market team. So I'm meeting with the sales organization and marketing and these other areas. So this kind of like deep thematic focus actually lets me context switch a lot, but I can go deep with the teams and kind of single thread that.
I'm not the one running those product meetings. It's the team leads and edge leads that are doing it. But I'm available to kind of like unblock people. And like I said earlier, too importantly, to cut scope.
You know, if someone gets stuck on something or they're like, oh, I don't know. Or like, how is this going to impact our product strategy? Or does this matter? Or like, you know, to do that, we would have to extend the timeline three weeks. I can be like, ah, okay, like delete, you know, or like, whatever. Let's let's have that conversation now rather than.
than waiting until it blows up the timeline and then come in later. So it's like this kind of preventative, you know, laser like focus on it. I wouldn't say it's micromanagement. I like I don't really get in and make all the decisions.
But it's this really fine, granular, like fast pace of stuff. And again, it leads to us shipping stuff faster. And I think shipping higher quality things, faster for customers. And our team really likes that. So we've adopted this and it's worked. It's worked pretty well. Yeah, so far. I don't know how it'll scale, but it's going well. going well so far.
Well, I think in the context of when you've got teams that are owning end-to-end that are small, like in really, like that context makes a huge difference. And the ability to connect all those dots and like make those decisions instantly or like make those on-the-fly shifts, like that seems like that makes all the difference.
Absolutely. Yeah. Yeah. And I forgot to mention, too, on Fridays, we do a full company all hands for an hour. So it's kind of this bookend to like the week opening up and everyone making working on new projects and new things where that contest gets broadcasted to everybody in the team.
So even if you're, you know, like a support engineer that just joined in the last week and you haven't met anybody, you will see everything about deals we're working on, the financial health of the business, what products we're shipping, you know, what engineering is doing. There's a bunch of demos. And so we actually have this like we call it radical transparency.
¶ MCP Night: A Celebration for Developers
It's kind of this like shared heartbeat context of the organization. And you can just feel the momentum. It's like palpable. That's part of the fun part too. You mentioned a couple of different times about fun. Like engineers have a lot of fun when...
it's these meetings are a lot of fun when and and i was like oh man like you know what's cool is like infusing fun in different elements of the organization but one thing that has looked like a ton of fun has been mcp night yeah so i i followed i followed the launch of the first one uh and then i know you got the second one coming up
I was wondering if you can give just like the quick, what is this? Why does it exist? And what are some of the highlights? Like what are some of your favorite parts about MCP night? Yeah, you know, one of the benefits that you have if you end up becoming a startup CEO of a company that's financed and growing and doing well is you can kind of follow your nose on what you're curious about and interested about. And I am totally like MC Pilled.
I've been joking with friends about it over the last few months. It's just, it's a brain worm that's gotten into me. I think it's so cool. It's so rare that like a new protocol emerges for things that are interfacing.
I am obsessed with what's happening in AI, and it's this enormous breakthrough for human-computer interaction. That's really, at the end of the day, what it is. I could talk for hours about how excited I am about this, but one of the big things is MCP. As a developer, building things are just happening.
been that many protocol shifts. When I started writing code, we had already done TCP IP. We had already done HTTP. We'd already done all these things. MCP is a new thing. We did an event a few months ago called MCP Night. I invited
a bunch of honestly friends of mine that have been building cool mcp stuff i got a bunch of meetups and events in sf and text people i'm like hey i'm doing this event do you want to come give like a five minute demo a bunch of friends of mine came and gave a panel discussion and i thought it was just going to be like 100 some people you know max you know we had over five people come we had this line down the block it was crazy the total overflow
The photos look nuts. This is why I wanted to bring it up. We had a ton of fun. We did a whole bit at the end where I was dancing on stage with this robot. It's a total hoot. If you want to watch the video, it's on my Twitter. But it was a moment to bring together. the entire tech industry around this thing that has just taken the world by storm. And it's just cool and captivating to developers.
And so after we did it and the dust settled and my events team and everybody was like, oh, my God, what just happened? You know, we just threw this huge event. I was like, we're definitely doing it again. And so we're planning it right now. We just recently announced it. MCP night 2.0.
It's going to be on August 7th in San Francisco. And so I think this will air probably right before that. If you're listening to it and you're free, please come. It's a free event. It's going to be at the Regency Ballroom, which is a super cool venue. You know, it's a classic big...
You know, I've seen so many concerts at the Regency Ballroom. Exactly. I know. I know. And we're kind of doing it. The reason to do it there, I was like, this thing is so cool. This MCP stuff. It's like, what if like there was a band that was MCP? Like, why don't we bring the same attention to detail and performance?
and excitement and energy that we have around live music to this thing that developers love and the thing that's taking the word by storm. And San Francisco, in my mind, is the only city that you could really do this in where people come out, you know, for like a concert.
We got a lot of cool stuff we're cooking up for it. We got people coming to speak from Anthropic and OpenAI and Cursor, you know, it's going to be an absolute blast. And we're not monetizing it. Like I said, it's free, but it's just as much for us to learn about it and to push it forward as it is.
¶ Rapid Fire: Future Trends & AI Agents
is for other people to come and see that. So I can't wait. I'm so excited. I love it. I love it. I'm excited for people to check it out. Michael, we've got some rapid fire questions. Great. Let's do it. Okay. What are you reading or listening to right now? The business value of computers.
I heard about this. I literally just started reading this. I heard about this book in an interview, an old interview that Steve Jobs did. And it's written by this guy, Paul Strassman, who was the CIO of the CIA. And he previously worked at Xerox PARC. And so it's about kind of... how software works for businesses. And it's this theoretical breakdown of how technology can inform the way people work together and how organizations can operate.
I think that software and how systems work is just so deeply linked with how humans organize. And I've just been kind of researching that stuff. And I heard this video of Jobs talking about that. I was like, I have to find this book.
All right, next question. Well, we were talking about MCP. I was gonna say, what's a trend you're seeing or following that's interesting or hasn't hit the mainstream yet? But like, maybe it's MCP. I don't know if there's a different trend you want to call out, but. Oh man, the MCP stuff I think is kind of it. I mean, I'm so deeply MCP-led. Claude code, I would say everyone talks about Claude code where a lot of people are using it or using cursor to build stuff
I think that learning how to write code with agents, like there was an early set of people using this who maybe didn't have like formal computer science engineering experience. They were vibe coding. So a lot of like proper software engineers, they look down on it and they're like.
Oh, those people, you know, what are they doing? They're not real engineers. This isn't going to come for me. And what's I think what's magical and changed is the people that get good at it that are senior engineers. It's like imagine you're a musician and suddenly you can play every instrument in the orchestra. simultaneously. It's like that level of interaction.
I think people still underestimate how productive software engineers can be that fully embrace this stuff. They don't just say it's only for junior people or something or it's going to spit out garbage. But you fully try to learn how to prompt and do it. I've just seen like magical things and how that experience myself too. So I'm still...
Very bullish on Claude. That's profound. Yeah, it changes the way music is written and performed, right? And I think the same is going to be true for how we create software and how we create companies. Well, and I think that kind of... provides like a really good, powerful closing to this conversation because like we were talking about the collapse of the talent stack. A lot of that is because of the implications of these tools and what's possible.
what that means in terms of changing how you lead and organize teams and how teams operate daily. And what I really appreciate is...
Through this, we've gotten kind of a window into like what's possible with teams or how these types of teams can take products zero to one and can operate at these different cadences and can like tap in and get product sense and play all of these instruments at the same time and make things more possible. So I just want to say thanks, Michael. This has been, this has been.
blast you know thanks so much for having me this is a really fun conversation and like i said we're recording this in like july you know probably by the time this comes out later this year it'll be a totally different world that's what's so exciting i absolutely can't wait to see what happens
If you're listening to this and you're wondering, how can I connect with other engineering leaders in my city? Pull up your phone right now and go to elc.community. Click our chapters page. You can see that on the menu on the left. Find your local chapter and click join.
We're hosting virtual and in-person events all the time, and this is the best way to help you get involved, expand your network in your city, and support your leadership and career growth. So pull up your phone, head to elc.community, join your local chapter, and get involved. Thank you to all of our local leaders who make community happen. And thank you for listening to the engineering leadership podcast.