This is the most common failure mode I’ve experienced:

> 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.

Every rapidly growing company I’ve worked for has reached a point where we have product managers and program managers and engineers and engineering managers and stakeholders and suddenly nobody can even identify who is the decision maker.

Weak leadership then pushes a “we all have to work together to come up with a solution” angle that clarifies nothing and turns everything into a consensus-building operation. Progress slows to a crawl.

The second most common failure mode I’ve seen is, I hate to say it, similar to what this author is proposing as a solution: Product Managers who view themselves as facilitators of a process where they get others to come up with the answers about what to build. The product managers call meetings where they shuffle context and requirements and suggestions from stakeholders to engineers and customers and back and forth under the idea that their job is to lead others to the conclusion. I’ve worked with some product managers who produced prodigious amounts of meetings and slide decks and Figma charts and process documents and Notion pages and after meeting summary e-mails but can never actually conclude what we should build. They’re so enamored with process and documents and afraid of being prescriptive, so you only get questions and prompts and meetings and frameworks to follow to supposedly arrive at a conclusion about what to build.

Culturally it is best to train developers to just do something, then provide non-judgemental feedback when what they do isn't what you want. Maybe schedule in some rework time to try again. That way, developers move quickly and sooner or later start building useful things.

"Just tell me what to build" is a dangerous attitude to foster. It pushes more work into the management layer which is already a bottleneck for making decisions. That is bad strategy. A couple of devs thinking that way is OK, but it is going to accentuate the inevitable management dysfunction.

The best approach is a culture where PMs understand customer problems and give quick, effective feedback to developers about whether what they just did affected a customer in a good way. Then management lets developers do what they do as quickly as possible. Alternatives can work, but that is the sweet spot.

The ultimate goal of any software company is to have that one lucky dev who just gets it, builds something amazing quickly and then the company comes in to maintain and milk the product until management miscalculates, destroys it and the cycle starts again. Failing that, the next best option is a product guy who just gets it and organises the engineers to build something that makes customers happy. Neither of those states depends on debate or, curiously, on what the median developer is doing. Software developer productivity is one of the spikiest, most disjointed and chaotic metrics I've ever dealt with and most of the time it appears to be $0/day value add or slightly negative. Then sometimes it spikes to a few million dollars an hour. The culture should all be about working around the spikes, not the day to day.

Organizations that debate everything and do nothing are afraid of other people being upset with them for doing the wrong thing.

Organizations that do nothing until someone else tells them what to build are afraid of sticking their necks out for some dominant manager to just ignore them anyway.

This is why executives and managers are recommended to foster psychological safety. Respect the efforts of people who built some skunkworks project, then discuss realignment with them afterwards (understanding that you, the executive, may need to be the one who re-aligns). Encourage people who never stick their necks out to start to tell you what they think, even if only privately at first, and eventually hopefully they'll start to join the discussion too.

There's a lot of talk about clarifying who exactly the decision-maker is in any situation. It's a nice fantasy to think that the decision-maker should always be some kind of manager or executive, but the truth is, if you issue a dictate from on high to someone to do something that they deeply disagree with, eventually everybody's going to leave. That's not the way you lead people. Ultimately, the person who does the work is the person who decides - all that you can ask from them, as a manager, is for them to listen to you (and other stakeholders) first, especially since someone who never does as they're asked is someone who will, sooner or later, get fired. But no manager can truly control the actions of their subordinates, and the wise manager understands that and channels that into productive workers who are mostly (but never fully!) aligned with the organization.

Sometimes (but not always) the reason for these cultures is more due to nature than nurture, in which case it can be virtually impossible to change without replacing people.

I worked on a team that went from a very strong "debate everything" culture to a very apathetically strong "just tell me what to build" culture, and it was primarily due to the hires we made. We hired for the ability to grow technically, and that certainly proved true. But the interest in the "why" behind the work never developed the way the "debate everything" folks assumed would happen with all good devs. The QA team cared, and remained in "debate everything" mode, but the dev team eventually just wanted to be left alone to focus on relatively meaningless (without context) work. No amount of connecting the dots to real user need seemed to really get through. They just wanted semi-challenging technical problems, and a paycheck. Nothing wrong with that in moderation, but it ended up infecting the entire team.

So be careful how you hire. If you have a blind spot for this phenomenon and hire exclusively for technical skill and/or potential, you might just get unlucky and end up with a critical mass of "just tell me what to build", and then you're screwed, because you'll have a technically strong team that has zero interest in understanding the bigger context of their work, forcing you to choose between getting sucked into the codependent relationship, or resigning yourself to doing the wrong thing with great technical prowess.

> 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.

This is an underestimation of the potential of software systems. Of course it depends on the software application, but in many cases there is a lot of value lost when organizations implicitly create a technical ceiling for their engineers, and push their focus away from the theory and practice of engineering.

Saying that there is more value for an engineer to coordinate, plan, and present, is almost like saying that there is a point in which software systems can no longer be innovated or improved, or that there is nothing about software that requires more than 5 years of experience (or whatever the senior level would be). This is a sure way to build naive systems that brake all the time, when instead it could implement more sophisticated solutions. Of course this would mean that engineers would have a harder time communicating their solutions, but once again, it would be limiting software just because the managers want full control and visibility at every step of the way.

We're now talking about the possibility of AGI, yet it seems every software org still goes through the same problems, with the same type of bugs, pipeline problems, etc. This is definitely not because software can't solve the problems, so it must be that the solutions are too hard to implement, and so the question is why is that hard?

I didn't really vibe with this dichotomy but I did get the sense that both of them seem like a symptom I have seen often:

Too many chefs, not enough cooks

In general this happens when companies over-value management. If you find each "team" of 3-7 software developers have at least 3 "managers" on the team (in addition to the visual designer and other folks in productive roles): you've got too many chefs. Decisions have to go through the committee, the process, etc. Software developers that are making the product itself are rational, intelligent, capable people whose hands become tied behind meetings, documents, and permission-seeking. Too many chefs make for busy work and they focus on the wrong work.

One manager for 5-8 software developers is often good enough. Someone who interfaces with HR, handles administrative tasks, and is the voice of the team to the rest of the company at meetings. A good manager enables the team to do their best work and stays out of the way.

The reason we debate is so we're able to build the product that actually works for you and we can maintain for you. If this weren't necessary, why would product need experience devs? The no-debate fantasy is at least a little akin to the no-code fantasy.

GitLab has a quite nice decision making framework that avoids these problems: https://handbook.gitlab.com/handbook/leadership/making-decis...

One of the key problems that exacerbates this is removing the business use case from engineering.

In most cases, you are engineering a solution to solve a business need. Each engineer should know the business metrics you are trying to move, and why, not just the PM. This tends to highlight that navel gazing on which framework to use is pointless, because unless you actually build something, the money isn't going to arrive, and you'll be out of a job.

Software engineering is all to often treated as a black box, that must be isolated from the real world, lest the magic smoke escape. But that leads to terrible decisions, and allows "carbon fibre" programmers to flourish. Engineering should be a business unit like any other part of the company.

I am not sure whether I can agree. Isn't this just another Goldilocks principle? In addition, not only company but also national culture matters.

Ref.:

https://news.ycombinator.com/item?id=38437104

If you're on the side of "just tell me what to build", you better really, really trust your leads and managers. Bad managers can destroy engineering culture in an instant to the point where "just tell me what to build" becomes a symptom of burnout and not a bona fide aspect of a work culture.

Debate "everything" isn't optimal, but it's tolerable so long as a decision is made and folks can move on. Even if the decisions aren't the ones I'd make or I'd consider optimal, that's a situation that I can deal with.

What I'll never do again is work at a place where every decision is subject to re-debate anytime someone decides "they don't like it." I just don't have the mental energy for that bullshit any more.

My approach as the senior software engineer (but not the manager) of my team is to not debate everything, but to point out everything that I think is wrong, can be improved, or should be designed differently.

But then, I leave the developers and/or the manager to make their own decision and shoot themselves in the foot if they happen to make the wrong decisions.

This approach takes more time, but I think it improves the sense of ownership of developers and their maturity over time.

Some of the disparity described seems to relate to the size of the organization/team and where value is placed. Many say that as an organization grows, it takes more people to get the same work done that a small team can, a la entrepreneurial spirit. The effect in my experience comes from a few distinctions with the greatest being a team wholly bought into the mission, and equal participation. The later doesn't imply equal say, but, rather, the opportunity for all to be involved or informed of every aspect of the project and not rely on roles or expertise to carry the day. I've sent engineers along with product managers into the field to gather requirements; each has a different perspective, and through mutual respect, come to understand that their collective feedback builds a better product. It also means deferring to a third party authority, such as the 'customer' rather than one's ego. Again, the mindset of the individuals in the team is very important, often more so than their assignment skill level. Of course a strong leader needs to act as coach and commander, helping the team move forward and making the tough decisions when momentum is waning.

I think "debate everything" comes from:

1. Uncertainty. People haven't done X before, and are concerned about the outcome, so they delay, by debating. They don't know whether they're right or wrong. They're really just trying to figure out their own opinion. So they will bring up objections, even if they don't actually have a concrete reason to object. They just literally don't know if something is valid, so they pose a hypothetical. Another form of uncertainty is lack of trust. If somebody has trust that an outcome will be acceptable, then they can deal with any fears they might have about whether a given approach will have the outcome they hope for. If they can't trust the process, or people, they'll bring out road blocks.

2. Ego. Let's face it, we work with people with big egos. People who are smart, and capable, and know it.If their egos don't feel adequately compensated, they will debate until it is.

I think "just tell me what to do" is easier to understand:

1. Apathy. It's a real killer, and it can hit any organization. Sometimes people care too much; if they don't feel like they can affect change, that turns into caring too little. Or perhaps they've just been burned too often at this job. Frustration builds until the stress or friction is too much, and they compensate emotionally by disconnecting. Some people carry this from job to job, like a form of PTSD.

2. Inexperience. When you have a lot of experience, you mostly know what to do already. But if you're working on something very new, or the organizational hierarchy isn't clear, or goals aren't clear, or processes, or you just don't have a lot of professional experience, you can be lost in a sea of uncertainty, not sure what to do. Maybe you have ideas of what to do, but it's not clear how to decide on it. So you relent, just waiting for someone to give you some guidance.

In each of these cases, the missing component is: leadership. There must be good leadership to help people do their best work and keep the ship sailing. Bad leadership, or the absence of leadership, will lead back to these problems.

The endless debates wear me out. Sometimes I just want the engineers to just do. It's labor for me to tell someone their idea is bad, both mentally and emotionally. At the beginning of the relationship, you have to engage in that labor to get people to trust you. But if it continues to break down, I try to figure out why and it's usually because another designer/PM were flippant in their choices.

Similar to the FG scale in the OP, LOGAF is a fantastic system to use, especially in asynchronous/remote environments. It's radically improved our code review iteration cycles.

https://blog.danlew.net/2021/02/23/stop-nitpicking-in-code-r...

That said, review debates are only one part of a "debate everything" culture. Architectural disagreements are much harder to solve while maintaining morale. One thing I've found effective as an engineering leader, when we need a plan of action, is to ensure I listen to every technical take, but make it clear that while I'm incorporating all those concerns into the decision, some concerns need to be weighted more than others based on larger medium-to-long-term business context, and that those concerns need to drive the design. It isn't always the best approach with 20/20 hindsight, but the removal of paralysis has been a net positive so far.

Both of these extremes to me are both just lack of actual leadership.

A real leader should absolutely value and respect the input of their team, but also know when to just say “of the options, this is what we are going with, here is the trade off we are making and why” and have the mutual respect and trust of their team to make both of those activities successful.

We debate everything ad nauseum at work. I'm going to try the FG scale. We'll see if I get fired for being disengaged.

Debate is a good if you all have a shared idea of what constitutes 'good'. IE, simplicity, performance, whatever.

> Idea: An anonymous "vote to end meeting" button where if 50% of people press it, the meeting ends immediately.

https://twitter.com/joeylorich/status/1468976175821250565

If the right decision isn't obvious to everyone in the room, including the least experienced person in the room, you don't have enough data to make the decision. You should break, get thr data, and regroup when you have the data to make thr proper decisions.

Data driven decisions.

Decision making is a craft. If you just go with the flow, you'll not be very likely to achieve optimal results. I think for every large enough team, you should be explicit about how decisions are made, and why they are made that way.

You need to minimise the debating. Especially if it shows to be based on assumptions.

Debating is also used as a human interaction tool for "feeling part of" or "being good enough" and it's especially clear in a startup and early company setting where everyone kind of tries to show their own merits to the rest of the group.

It's unhealthy to debate a lot and it's a clear sign that there is either too much uncertainty, too much ego, too little subjective evidence or simply too shallow leadership.

Debating should be very surgical and not attempt to either look into the future or favor the most outspoken.

As a DE my attitude can be described by the following sentence:

I don't care what kind of data you want me to load, but let me know the frequency, the type, the schema and other technical information and I'll load it for ya.

> Culturally it is best to train developers to just do something, then provide non-judgemental feedback when what they do isn't what you want.

My preferred method of development is tell me what you think you want, then be available for the stream of questions I'll be asking you to make sure what you need is accomplished.

I've found that it's almost always a bad idea, for everyone involved, to implement what someone says they want, unless they're assholes or competent developers.

As a former freelancer in the webdesign, webprogramming, graphics design etc field, what astounded me the most when I first got to work with a software developement company was that there was no design session.

For me it was normal to assume that neither my customers nor I know what they need automatically. This requires a creative process and the finding of a common language at least in the beginning of the project.

The worst thing is when developers you work with are "Ok go!" without discussing and you know they got a hammer and now everything to them looks like a nail. Sure they get things done, but if so do builders that start building a house without a plan.

That strategy works if the requirements are foolproof and straightforward, but as soon as the project reaches a certain complexity. Sure requirements can change, customers can fuck up and misjudge what they want, but a good craftsperson thinks about the future of a project as well. And while you might think you sell software, you are also selling a relationship with the customer. If they feel like you tackled that problem openly together with them, that is worth something as well.

I don’t live in an alternate universe where “Maybe schedule in some rework time to try again” ever actually happens.

Yup pretty much this but you need to grind that $0/day work that you see right problems.

I'd argue that your best approach is only the "best" approach in specific environments you have encountered and that it is not a universal truth. I think it totally depends on the environment and what is expected from that environment what works best.

This sounds a lot like letting the monkeys bang away on typewriters while you sit back waiting for Shakespeare...

TFA seems to present reasonable advice. Yet lots of comments here don't seem to agree that "give experts necessary context and trust to build good products" is a decent strategy.

Another startup founder here. I regret not working early enough with an HR expert. It takes forever (any many relationships and many tries) to find the correct one, but:

- They’ll help you profile who you need. Questions you would never have dared asking, like “Tell me a situation when you reacted to xyz”, not only they filter the person, they also change the attitude of the relationship, the person itself goes from “it’s just a job” to “let’s put the extra neurons in, to make a product people actually love”,

- And they’ll give you weight in negotiation, asking questions you never dared asking.

It’s expensive, but recruiting more than one guy will be expensive anyway. And the engineering coming in, will feel safer that it’s a microstartup but it already has the structure to manage them, starting with HR.

And I say that as a person who only saw HR as the legal goon of the boss in the past. Don’t hire those, hire a consultant in recruiting.

You say it’s a hiring problem and I see an incentives problem… either way a management failure but what you describe should’ve been reorged promptly.