Balancing Engineering Cultures: Debate Everything vs. Just Tell Me What To Build
Lessons from leaders at New Relic, Credit Karma, Reforge, Hubspot, Trulia, Intercom, VSCO, and more
Hi there, it’s Adam. I started this newsletter to provide a no-bullshit, guided approach to solving some of the hardest problems for people and companies. That includes Growth, Product, company building and parenting while working. Subscribe and never miss an issue. If you’re a parent or parenting-curious I’ve got a podcast on fatherhood and startups - check out Startup Dad. Questions you’d like to see me answer? Ask them here.
I collected a lot of input for this article, but no one provided as much detailed thought as long-time engineering leader, Darin Swanson, who wrote me a dissertation on this topic and to whom I am eternally grateful. He also was a recent guest on my podcast. If you’re looking for advice on engineering leadership (or being a great dad) I highly recommend him.
Q: How do you effectively balance a product development culture of debate and discussion with moving quickly and shipping?
The longer you’ve worked in product development the more you’ll realize that there is a spectrum of culture. In the relationship between product management and engineering the opposing ends of the spectrum are “debate and question everything, build nothing” all the way to “just tell me what to build and I’ll build it.”
Some of you are shaking your heads – “no way Adam, no company falls into one of those two extremes.” Others are nodding so enthusiastically that their heads are about to detach from their necks.
If you’re in the second group, today’s newsletter is for you. I’ve been this person too.
Whether you are a product or engineering leader, a product manager, or an IC engineer read on to learn:
How a company gets to one of these extremes
How to shift out of a “debate everything” culture
How to shift out of a “just tell me what to do” culture
On the “debate vs. do” spectrum, neither one of the extremes are a good or healthy place to be. Cultures that debate and challenge everything, even the smallest of considerations, without ever reaching resolution never manage to ship anything. Cultures that absolve themselves of debate entirely end up disempowered from the end outcome (and also don’t ship anything meaningful, even if they ship a lot from a volume perspective).
In order to get some advice on how to effectively get to the culture you want I talked to a handful of trusted engineering partners – Darin Swanson (New Relic, Gatsby), Matt Greenberg (Credit Karma, Reforge and Handshake), Jeff Dwyer (Prefab, ezCater, Hubspot), and Louis Bennett (Trulia, Intercom, VSCO, and Humanitec). I also got advice from one of my favorite, tell-it-like-it-is, product leaders: Erika Warren (Change.org, WyzAnt)
How a company gets into one of these extremes
In life, the only constant is change. While many people have co-opted this statement in different contexts, its origins can be credited to the Greek philosopher Heraclitus. Is this the first reference to Greek philosophy in an article about product development? Definitely not.
While he probably wasn’t thinking about building companies when he said this, it’s equally true in its application to company and culture building. In startups, the only constant is change. And change is at least one reason that companies find themselves in one of these extremes.
In my conversation with Darin Swanson, I thought he summed this up quite elegantly:
“The companies I have partnered with over the last 6 plus years go through cycles of product definition and decision. Transition from founder(s) / CEO leading the product strategy, to the early team leading the experiments and iterations towards product market fit (PMF), to specific roles / individuals. In rapidly growing companies this can be moving back and forth every 3-4 months as PMF ebbs and flows. Particularly if you are going slow, roles change, or the company grows or shrinks.
These transitions can be clunky, slow, and frustrating if left to happen organically and osmotically. In an interesting and common pattern, things get slow and clunky after a growth spurt where new roles and people are added to the team without the team taking the time to codify exactly how the new people and roles are going to maximize their impact within the company and how you’ll work together.
Often a company will settle into two, less than optimal states: debate everything or wait to be told.”
The second way that companies and cultures end up in this position is through the incentive structure (or lack thereof) within a company.
Jeff Dwyer:
“When people give you a list of all the reasons it can't be done and debate on all the details, it's because their connection and incentive to achieve the actual results has gotten severed someplace. We can end up in a place where we can get in trouble for doing it wrong, but don't have enough information to really do it right. So we spend more time debating how not to get in trouble.”
On the flip side, when companies find themselves in “just tell me what to do” culture it’s often due to an imbalance in expectations between product and engineering.
First, the same root cause of being disconnected from the outcome can lead to a culture of “just do what I’m told.” It’s a self-perpetuating problem; if you don’t expect engineers to be engaged in the outcome then you won’t hire people who are.
The second root cause of “just do what I’m told” is related to fear of failure. If engineers are consistently blamed or called out for getting something wrong then eventually they won’t feel comfortable getting anything wrong anymore or having an opinion at all. If they just do what they’re told then that blame shifts to someone else. It’s not my fault, I was just doing what I was told.
So it’s all well and good that we want to avoid creating the systems that perpetuate these two extreme development cultures, but I imagine for a lot of people reading this newsletter they’re already in it.
So what do you do?!?
Shifting Out of a “Debate Everything” Culture
If you find yourself endlessly debating the work and never moving past that point, you can try the following to break free:
Help people operate in the “gray area”
Introduce the FG scale
Incentivize outcomes
Evaluate how decisions are made and who makes them
Help People Operate in the Gray Area
One of the reasons that people can get stuck in endless debate is if they don’t truly understand the decisions being made. Most decisions are not binary and the nuance can make many people uncomfortable.
But Adam, if people don’t understand the decisions aren’t they more likely to just blindly follow them? I realize this sounds counterintuitive, but no.
Matt Greenberg describes a scenario he found himself in at Credit Karma:
“The best product and engineering collaborations are when they can agree on an approach to a problem that gets maximum impact for minimal work. This is a tough nut to crack. We had this challenge with the Credit Team at Credit Karma. Upstream teams never understood the complexity of the stuff they were asking for because the bureaus and credit data are so nuanced and complex. We’d often be locked in debates for days or even weeks about how to approach a problem, especially ones that seemed simple but were unrealistic. Eventually teams would find fake compromise, kind of a spiritual alignment, but no details. This would lead to late stage blowups and disappointments. Which would make the next round worse. It was a cultural death spiral.”
Matt solved this problem by creating a “rotational program” designed to build empathy and understanding between PMs and Engineers – especially understanding of complexity around credit bureaus and data:
“We eventually solved it (mostly) with a rotational program for both Eng and somewhat PM. Trying to build empathy and understanding. Teams would embed 2 or 3 people per project for a quarter and then reverse it the next quarter.”
Introduce the “FG” Scale
For those of you who are sensitive to language, I apologize in advance. Both Jeff and Erika called out the importance of the “Fucks Given” scale. To put it simply, when you’re mired in debate just ask everyone how much they care about the decision on a scale of 1 to 10.
From Jeff,
“I really, really like the FG scale, which is of course "Fucks Given.” I've used this a lot and it is truly effective. When you get into a situation where there is endless debate just ask everyone to give their FG score 1-10. Most often I get a lot of 2s and 4s, maybe one 7. You can have the 2s and 4s say their piece and then they can leave. Typically they'll say something like, ‘here's what I would do and here's why, but I'm a 3 out of 10 and I trust you.’”
And Erika,
“One tactic I've done within the product is similar to Jeff's FG scale. That is to encourage the option of ‘I don't care or I defer to the group’. I've seen people argue for things on principle but really not have much invested in the decision. And when you have a culture of consensus and lots of debate, it snowballs into a place where that's the norm. I think it's helpful to create the opt-out for people to not feel expected to engage when they may not care. It's also a helpful signal as a manager because if someone is always ‘defer / don't care’ maybe there's something else to dig into on performance or motivation.”
Incentivize Outcomes
The goal of product development is to build valuable products for customers that make sense to them and to us as a business. Endless debate can occur when teams lose sight of that goal. Without making it abundantly clear that the outcome is what matters you’ll get teams who focus more on being right or managing to their own careers than delivering something valuable, especially if PMs are handing down rigid requirements (this is another reason I believe Briefs > PRDs).
As Jeff says,
“Good engineers have to have an extreme pedantry streak. We spend a lot of our day with systems that punish us brutally if we aren't exactingly specific. We can spend hours crying and tearing our hair out because of a small misspelling. If you push a task or a feature (or even worse a ‘requirement’) down to engineering then we're going to analyze and argue about the intricacies of it. If you push down a proper goal and give us flexibility about how to get there, we'll argue about the fastest way to get there and we'll disagree and commit because our eyes are on the real prize.”
And Matt,
“What you measure is what you get. The biggest challenges come when the different orgs measure different things; e.g. if product leadership gives credit for shipping and engineering gives credit for complexity. If you only get to staff software engineer by working on things of necessary complexity then you are incentivized to find complexity. Many times in engineering orgs, engineers are siloed in what counts. If you think back through the teams you are on, some eng managers are more focused on tech debt, developer experience, platform challenges, but most of the time that's because there isn't a clear incentive tied to a business outcome for them.”
Evaluate How Decisions are Made and Who Makes Them
Darin reminded me of the quote (often attributed to Winston Churchill): “Democracy is the worst form of government, except for all others.”
Darin takes it one step further: “Democracy is the best system, but also the slowest.”
A critical piece of avoiding endless debate is to know who makes the final decision and how it gets made. Consensus-seeking leads to endless debate.
From Darin,
“When companies are smaller, by necessity everyone plays multiple roles and the number of people involved is limited so you can solicit input in a timely way. But almost every company has a phase where we start to hear ‘I don’t feel listened to anymore’ or ‘I don’t feel part of the decision making.’ [This can actually result in more people trying to involve themselves in decisions that they’re not a part of.] A test I like to have: for any project, meeting or proposal – can you point me to the document that indicates who will make the decision and how and when that decision will be made and published.”
This is further helped by the idea of defining explicit timelines and how input is considered — you can use a simple framework like Listen, Decide, Communicate as a tool for breaking through endless debate.
Listen: This stage involves gathering information, understanding different perspectives, and considering various viewpoints.
Decide: After collecting and analyzing the necessary information, the leader must make a decision.
Communicate: Once a decision is made, effectively communicate it to the relevant parties. This includes explaining the rationale behind the decision, the expected outcomes, and any actions that need to be taken.
As Darin says,
“Importantly, this does not give you license to ignore the smart and insightful people on your team. It makes it imperative that you make it explicit on how long or if you will seek input and how you will seek input. Listened, considered, rejected is a perfectly valid response to any input. Everyone on the team needs to take this in stride and understand being listened to does not mean always having their input incorporated. Including the “why” on the rejection is a great way to ensure you have really thought about the input.”
Nowhere is this more challenging now than in a more remote and distributed world.
Darin again,
“I have seen this amplified with us working more remote and more distributed. Everything can move to taking at least 1 business day to gather input…a week or more is not unusual! This really gets in the way of urgency and velocity. Time is the luxury we don’t have. Instead, move to 1) publishing the proposal, 2) establishing the ceremonies for input on the proposal (which can include no solicitation for input…but at your peril), 3) completed staff work critique or iteration on the proposal within the teams set and agreed timelines, 4) the owner makes the decision and we move forward.
The owner by the nature of the role and expertise and expectation is the best informed and best enabled to keep things moving. If no input or feedback comes within a timely manner, the default is to move forward. Not wait. Not ask again for input. The window has closed and it is time to move forward.”
Finally, it’s important to be really clear about what is up for debate and what is not. As Louis Bennett says,
“A successful shop needs to establish the ground rules of what's up for debate, and what's not. For example, having an opinionated and established take on the languages and frameworks the team will use helps move things forward. Ditto for establishing clarity and a default process for when and how to have a debate on the smaller things. Logistically, things usually end up in a point where a CTO/VPE needs to create "engineering values" which guide the debate and often decide the un-debate-able items.”
Shifting Out of a “Just Tell Me What To Do” Culture
I think this is the more common culture that teams find themselves in and it’s harder to break out of it.
As Erika says,
“I think “do culture” is harder to pivot away from then "debate.” You can lose a lot of great engineers (or PMs) who don't want to just "do". And once you train an org to take orders, it's hard to rebuild the trust and psychological safety required to have a culture where debate and mistakes are ok.”
If you do find yourself in this position, here are three approaches you can use to break free:
Incentivize outcomes and feedback
Provide context and a venue for discussion
Codify the expectations across engineering and product
Incentivize Outcomes (and Feedback)
Just as with the endless debate culture, being clear about what the outcomes are (and getting engineers engaged in the outcome) is a key to the cultural shift away from “just tell me what to build.”
From Matt,
“Engineers have often been burned building things that nobody cared about. They often don't feel heard and are under-developed to debate outcome merits with a PM when they aren't as familiar with the data or customer. I think to break through it you need to be able to re-align the incentives and show you care about the feedback.”
One way that I’ve handled this in the past as a PM is by creating and engaging engineers around team goals via the OKR process. It’s not a “product” goal or an “engineering goal,” it’s our goal. Shared goal setting within a product development team allows everyone to internalize and feel connected to the results that you’re trying to deliver.
There are plenty of product managers who treat engineers like their sole purpose is to strike keys on a keyboard until software is delivered. But this relegates engineers to code monkey status. Don’t be that product manager. Remember that if people feel connected to the goal they’ll feel connected to how to get there.
Provide Context and a Venue for Discussion
If you’re a product manager, your job is to continuously provide context and encourage discussion (with an end point as outlined above).
Here’s how Matt like to see this,
“Engineers often have a lot less context on the business side. It's important to have a room or venue to share concise summarized context, whether sync or async, so that when it comes to the conversation they aren't heavily penalized for not knowing things. You need to provide the space to actually debate, especially with fewer constraints (both time and otherwise). I think people want debate and also load problems with so many constraints that they only see or allow one path through and don't have time to really think and discuss. They’ll say things like ‘we have to figure this out in the next hour’ and the growth and opportunity can't come from there.”
To avoid what Matt has identified, I like to bring my engineering counterparts into the earlier stages of discovery—record and share summaries of customer conversations with them (or invite them to watch), highlight interesting data and research, and specifically ask for feedback. You’d be amazed how quickly a team member gets engaged when you approach them by asking for their advice and input after they’ve received the appropriate context.
Matt again,
“I think doing things like design sprints are ways to teach all the aspects of behavior you want to happen continuously with more room, time, and structure.”
Codify the Expectations (both engineering and product)
Much with the expectations around collecting feedback and ending debate (to avoid an endless cycle) you can also set expectations around contributing feedback in the first place.
As Darin says,
“Past the stage of senior software engineer there’s no real credit for the code anymore. It becomes the baseline. The strategy impact, the coordination, and the understanding and contributing to the team, company and customer success is part of your responsibility. A demo is the currency of completion and all demos start with a narrative on the ‘why’ behind the work in terms of customer value. Decreasing the perceived value of the how and increasing the emphasis on the why increases engagement.”
In other words, as an engineering leader or product counterpart you have to encourage the contribution.
Darin has a very direct take on how engineering leaders should approach their team:
“If you just want me to tell you what to do then your time is not valuable. In the not too distant future, you will be replaced by automation. Practice bringing the higher value now.”
Final Thoughts
I’ve worked in both cultural extremes—where it felt like we couldn’t get anything done because every last detail needed to be debated or where every time I sought out feedback for a customer problem or solution I was met with silence. When you’re in that situation it can make you feel frustrated and hopeless. And it certainly doesn’t help you build great products.
By understanding and empathizing with my engineering and product colleagues I’ve learned and tried various approaches to getting unstuck. The above is what I’ve seen work well in my own experience and what others have seen in theirs.
To break free of the “debate everything, do nothing” culture:
Help people operate in the “gray area”
Introduce the FG scale
Incentivize outcomes
Evaluate how decisions are made and who makes them
And to break free of the “just tell me what to build” culture:
Incentivize outcomes and feedback
Provide context and a venue for discussion
Codify the expectations across engineering and product
I also believe that this advice extends beyond just building products. If you don’t work in product development and find yourself mired in endless debate or presented with nothing but silence when seeking feedback many of these lessons may apply to you.
This is by no means an exhaustive list and I’m sure that others have even more suggestions than what I provided here. I’d love to hear about them in the comments or elsewhere.