Scaling software products has always been incredibly difficult, but it’s especially difficult right now. “The market is tremendously crowded,” says Michael Lopp, an engineering leader at Apple. “I could dream up something right now and have ChatGPT bring it into existence in the next three hours. Democratization of product is a great thing, because it makes it available to anyone, but it’s also super tricky.”
Swirling in the discourse about this technology is a debate about what it means to be an engineer right now. Some think you don’t even need to learn how to code and instead should focus on building other skills. Others think there will always be a need for engineers, citing concerns about LLM code quality (and its ability to scale) or security.
“To me, it just comes down to good judgment and incredible operations. Who's making the decisions and how are they doing with those decisions?" Lopp says. Put differently, even if anyone can vibe code an app between meetings, it’s still the people who matter in your eng org (at least for now).
Lopp is an expert in the people-centric side of engineering management. In addition to his time at Apple, Lopp has spent his career building products for the likes of Borland, Netscape, Palantir and Slack. At each stop in his journey, he’s continued to hone his approach to leadership, sharing his wisdom on the intersection of engineering, management and leadership on his popular blog “Rands in Repose” and as a renowned author of three books (and this article on how to make meetings suck less, right here on The Review).
In this exclusive interview, Lopp goes beyond the technical aspects of the engineering function, instead turning his attention to the backbone of any successful engineering org: its people. Drawing experiences from vastly different companies and cultures, he offers tactical advice for founders and engineering leaders alike.
Lopp begins by offering tactical advice on creating durable, effective engineering orgs and discusses the pivotal relationship between product and engineering. He then charges leaders to ask themselves if they possess some of the people-centered skills he’s seen of successful leaders over his career. Let’s dive in.
Create a structure for your team that enables them to do their best work
At each stop on Lopp’s journey, he’s run into the same idea over and over again: engineering matters.
“When people look at the last three companies I was at, they’re all completely different businesses. But they all shared that same ethos that prioritized engineering, rapid growth and smart people.”
To help craft an engineering org as successful as those at Pinterest, Slack and Palantir, Lopp offers three tips.
Tip #1: Encourage “wolf time”
In Lopp’s ideal world, engineers split their time 71/29. “71% of that time is very clear. Build things that you need to, get them done and get positive feedback,” he says. “The other 29% is time to do whatever the heck is inspiring you based on the 71% stuff.”
While this creative time isn’t useless, it isn’t necessarily time that can be easily explained to a manager — and Lopp says that’s exactly how it’s supposed to be.
I call it wolf time. Sniff around and see what you want to do next and explore. My engineering utopia is a world where 71% of time is spent on the ‘real’ business tasks and the other 29% is time to be a free electron and just create.
The goal of the 29% time? “To not be able to answer that question at all,” says Lopp. “It’s time for things to be created and spin out of that little poetry jam, and you can't let management and product folks into that world. They’ll know when something’s happened there, and it always does.”
In terms of operationalizing the process, this is Lopp’s one exception. “I tried to operationalize this at Palantir, and it was a huge disaster,” he says. “I gave it a title, and it suddenly became this thing where everyone wanted to be on the wolf team because it sounded cool and there was a sort of status associated with it. It became an argument over who could be there, how we’d measure that and it just collapsed.”
Instead of formalizing it, Lopp relies on good old-fashioned conversations that tend to be at odds with conventional wisdom on how to ship software. “I just go over to engineers and say, ‘I see this thing you’re doing, and I want you to know that I think it’s a great idea and you should keep working on it.’ Sure, I’m telling that person to take that week and do something that isn’t measurable, but it’s important to the long-term success of the organization.”
As Lopp’s seen himself, word travels fast amongst engineers, so even just one encouraging conversation can have ripple effects across your whole org.
“The only thing I’ll do beyond that is say, ‘Hey, if you guys want to chat about anything or show off an idea and jam on that, we can check in every Friday for an hour.’ That meeting always ends up happening. There’s no agenda, but people bring a lot of valuable stuff and you get slightly more formality without creating the Palantir problem.”
Lopp’s main takeaway is that you want people to know that this kind of time is encouraged. “If they don't know that kind of time is okay, then they're just sprinkling it in and doing it when they're walking between meetings. Nothing meaningful is naturally going to rise out of that.”
Tip #2: Keep debate regular
Great orgs are like three-legged stools. For engineering operations to run smoothly, there also needs to be input from the product and design teams.
“You need equal parts engineering, design, and product,” says Lopp. “Product and design are there to tell the story of the customer and to simplify things down to ensure that positive user experience.”
But with this kind of cross-org collaboration comes debate. “The question I always get asked is ‘What happens when those folks can’t agree?’ That’s exactly what should be happening. I want that team to be able to argue with themselves and say things like, ‘No, you're wrong. This is a design problem. This isn't a product problem. This is an understanding how the feature works thing. So design, you should listen to me and I get to decide here.’”
To create great products, you need to have a steady stream of cross-org debate. No matter who gets the vote, equal participation in the conversation gives companies the best chance of making sound decisions.
Of course, that’s easier said than put into practice. “Debate culture is super hard,” Lopp says. “It's not fun. You walk in with your idea and smart people that are vastly smarter than you just tear it apart all the time — and they’re usually right. But no matter who’s right, you have to recognize that this kind of discussion is such an important part of avoiding the hot garbage and building products that can last.”
While he encourages debate between teams, Lopp also recommends spurring it from the top down so that you’re creating a culture where people feel comfortable challenging leadership. “I'm always listening for those stories where Employee X was arguing with the founder and said this amazing thing that changed the course of the company forever,” he says. “These kinds of things aren’t written down, but they’re set early on by the way the founders and company leaders engage with their folks.”
Tip #3: Build operational systems that can scale while maintaining quality
Lopp suggests engineering leaders think about two key elements when considering how to create good products and scale them: having sound judgment and maintaining sound operations.
At the root of bad product decisions are bad judgement calls. And the difference between sound and bad judgement, he says, comes down to accountability. “If you ask most people what accountability means, they say, ‘It means if I don’t do what I said I was going to do, I’m going to be in trouble.’ But that’s not it at all. Accountability means to give account — the story of — what you’re doing.”
In practice, that means making judgment calls with an explainable, discernable why behind them so folks can understand the why behind what you’re doing.
Decisions made with sound judgement can stand up to scrutiny, have an explainable story behind them and have buy-in from the people it involves.
While sound judgement is limited to an individual or a small group of people, it must grow into a sound operation — so your company can scale. To make the machine run smoothly, Lopp says leaders must be aware of its inputs (the people), the outputs (the product), and how these come together to form a version of what good looks like.
“Are the people who are building this thing building it to scale? Are the operations predictable? Are they understood? Or is it just three smart people shooting from their hip, making it sound like they know what they're talking about?” Lopp says.
This group of people enabling a sound operation are extremely important — those “building and turning the crank,” he says. “It’s not sexy work. It’s all process stuff, but how you actually scale a company is through that operations piece.”
This comes to life in a number of different ways. Lopp gives one example for recruiting. Do you get a quick response? Do you talk to someone who knows what they’re doing? Does the interview process happen quickly? Is there a conference room? Do you get a clue about who you’re going to talk to? “These are all indicators of a well-designed organization process,” he says.
When you’re building the product, you’re also building the company that builds the product. And in Lopp’s mind, the classic startup adages aren’t an excuse. “The excuse is, ‘It’s a startup, we’re just making it up.’ You don’t get to say that. You’re building a product, but what you’re actually building is a company, an operation — and you’re building it to scale.”
How to foster the relationship between engineering and product teams
A tale as old as time. Much has been written about the sometimes contentious relationship between these two functions, but getting the relationship right is important to building quality products at scale.
Bad product managers create a scenario where engineers don’t feel like they have a stake in what’s being built. Great product managers make sure engineers know the “why” behind what’s being built — they have a very complete picture not just of the feature engineering is building, but of the entire thing.
Lopp argues engineers are “how” people, the ones actually building the product. “For consumer software, I would argue you have equal parts engineering design and product,” he says. “Product is there to tell the story of the customer, and to think like the customer, and not be encumbered by the how or the design.”
To make sure engineers have enough context, Lopp’s suggestion is simple: ask questions. “One of the things I do, especially when there are new product managers running around, is ask an engineer why we’re doing X feature. If they ever were to say, ‘Well, product said we have to do this,’ I’d get livid.”
In Lopp’s experience, it’s generally not the case that the product team is saying anything wrong, it’s simply that the engineer doesn’t understand why it’s important. “You never want your engineers to give up on understanding the importance of the why. They have to care about it, because they’re literally building it with their own hands. Even if it’s something like an advertising metric that’s far off in the future, you still have to explain to engineering how it all fits together and why it’s important.”
At Slack, Lopp saw this in action with co-founder Stewart Butterfield’s product vision. “One of the first things I asked when I got there was, ‘Why doesn’t Slack have a block feature?’ Stewart was really clear with his answer. He had a really strong perspective of making information visible to everyone. He explained that, when you turn to blocking, it creates this whole political situation inside of a community, and you’re suddenly more worried about that as opposed to why the community and product exists in the first place.”
Good PMs help their engineers by putting each idea or feature in the context of the broader product vision. That’s the 'why' piece everyone needs to be invested in.
What makes a good leader?
Impactful engineering leadership goes far beyond technical mastery. Lopp puts his focus on people. “Everywhere you go, you’re going to encounter totally different sets of people,” he says. “There’s the learner, the curiosity person, the pattern matcher. Being an engineering leader — or any leader for that matter — exposes you to quite the catalog of all the different types of humans that exist.”
To get leadership right amongst all the various characters, Lopp says it comes down to mastering three key traits.
Leadership trait #1: You’re malleable
Not everyone on your team needs to be adaptable. But as a leader, you have a higher bar. “When you’re leading a team, you’re interacting with so many other humans,” says Lopp. “You’ve got this job of adapting — and not being duplicitous — but just being understanding of all the different personalities out there.”
When looking back on his time at Pinterest versus Slack, Lopp admits how distinct his approaches were based on the very different groups of people he was leading. He even says that if you compared the two groups of people who reported to him, they’d see a very different leader each time.
To enforce this kind of adaptability, Lopp asks the same question of all new managers: How do you update your work based on the feedback you receive? “Failure to do this as a new manager is a big red flag. You have to be willing to take the feedback and add new skills to your repertoire,” he says.
Yet even those at the top of the ladder tend to get nervous at the mention of feedback. “Most people’s minds go to, ‘Okay, I'm going to be fired, but tell me why.’ But that's not it. It's just information on the thing that you have to work on. Yes, it can be scary to hear and feel like you’re failing, but you need to hear it to be a good leader, especially at the top of an engineering org. That’s an essential part of the gig.”
Adaptability also extends itself to the construction of your team. While leaders might want to build their teams around a core set of motivations or behaviors, Lopp says gleaning them in the hiring process from a few interview questions is difficult. “One of the downsides of rapid growth startups is you don't really get the best sense of people’s real-life behavior during the interview process,” he says. “Actually getting that person in the trenches and doing this stuff is when they’ll expose their best and worst work and be their most honest selves.”
This is what leads Lopp to re-org every six months. “You start to see, ‘Oh geez, Julia’s amazing at this and Marcel’s great at that.’ Then you can shuffle those people around to optimize the team in a way where everyone has the core set of skills for the technology or product they're building.”
Leadership trait #2: You’re a great storyteller
There are many views on micromanagement. Some are positive, like Carta CTO Will Larson who says here on The Review, “One of the biggest lessons in management over the last decade is that micromanagement is bad. But I think this is an anti-pattern, because it creates disengaged and context-free leadership, and leadership can be so much more than that.”
Lopp is firmly in the other camp. “As an engineer, nothing ticks me off more than micromanagement,” says Lopp. “I never want to tell people what to do, because I never want to be told what to do.” Lopp says this is because many engineers are builders with a vision for what they want to create. If you read his books, you’ll see that, instead of the typical “do this, do that” advice, at the core of his communication style is leading through stories — and specifically, stories that inspire.
“Instead of giving people a list, good leaders offer them a box and fill it with interesting ideas,” says Lopp. “It allows the folks you’re leading to go and put themselves in that box and see what they want to do with it. Whether you influence them or not doesn’t really matter. Your goal is to get your people thinking and give them as much information as possible.” This empowers individuals to make decisions for themselves, which also ends up making them better leaders.
But even with the benefits Lopp has seen from this approach, it hasn’t come without some criticism. “I’ve gotten frustration from engineers who end up saying, ‘Can you just tell me what to do here?’ Most of the time, I say no. Sure, a lot of people want to be told what to do, but even when you try to be dictatorial, they tend to apply their own approach to that order anyways.”
As a leader, it’s your job to be a storyteller. Give your folks the soup, then leave it to them to drink it as is or add whatever they want.
Leadership trait #3: You understand individual goals and motivations
Lopp credits a large part of his success as an engineering leader to a simple trait: curiosity. “Whether you’re a brand new leader or a VP, you should know exactly what every single person on your team needs to grow,” he says. “And if that’s too big of a thing to know just yet, you should at least be curious about what motivates them.”
To illustrate his point, Lopp gives a couple examples. The first is a hypothetical engineer who craves hard, technical challenges. “He likes stability. He isn’t a climber and doesn’t want to be a manager. He just likes solving technical problems and being recognized for that,” says Lopp. “By talking to this person and getting curious about what keeps him going, I know I have to keep putting ginormous technical challenges in front of him.”
Another example is from an admin at Palantir. “Early on, she told me, ‘I just want you to know I’m money-operated. If you compensate me well, everything’s going to be great.’ It sounds kind of douchey, but it cleared everything up and made it a lot easier for both of us to do our jobs,” Lopp says. “She was amazing. So when it came to bonus time, I knew to dial that up and make sure she saw I did that.”
You have to know what each person’s one core thing is. It’s a leader’s responsibility to constantly invest in that and make sure there’s potential for growth — no matter what the exact path looks like.
Lopp finds that it’s his curiosity that drives him to have the honest conversations that uncover what’s motivating the members of his team — even if people don’t know this about themselves.
At the heart of his curiosity is one simple question: “Why?” Why someone made a decision, why they reacted to a challenge the way they did, why they wanted something. “What I’m doing is pattern-matching in my head and trying to figure out what archetype they are — even if they don’t fit exactly into any one,” he says.
Bringing it all together
Throughout all of Lopp’s insights from his wide-ranging career journey, one message rings particularly true: Successful engineering hinges on smoothly functioning human dynamics.
To create great products, leaders must start by empowering the folks that make up the org. “At the end of the day, an engineering team is just a huge tapestry of all these crazy, lovely humans that you get the opportunity to learn about,” says Lopp. “When you’re motivated to figure out the intricacies of how they interact, you set your company up to successfully communicate the value of your products at scale.”