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.
As a PM, I believe what you're describing is the torrent of people who used to work as "project managers" and "business analysts" who've transitioned into Product for the higher pay, without appreciating any of the differences between the roles.
IMO, the fundamental role of a PM is to make the decisions nobody else wants to (and own the consequences of them). If my team is making progress and decisions are being made, I get the fuck out of the way.
I jokingly refer to myself as the "designated scapegoat", basically meaning it's my job to tank the risk for situations where everyone is nominally in agreement about something, but nobody wants to be the person to put their hand up and own the decision because of the risk if it backfires.
When I started my first PM role, I was lucky enough to work for a boss/mentor who had the same mindset. As a dev for most of my career before moving into PM, it made sense to me:
“If things go well, dev team gets the credit. If things go poorly, PM takes the blame”.
This is fundamental to building trust with the dev team and gaining the respect of leadership.
This made it possible to guide the product in directions the dev team wasn’t immediately comfortable with, because they knew it was my ass on the line. And when those decisions led to good outcomes, it further reinforced the trust relationship.
I haven’t countered many PMs who live by this, but it sure makes a big difference.
Damn I wish any PM I had ever worked with had this attitude. Honestly I don’t recognize any of this ownership in the last few companies I’ve worked with. PMs are just people that don’t talk with customers, review a product backlog, and cover their eyes and point at the Feature du jour. I wish more PMs had your ownership approach.
To jump in front of a bullet that no one wants to be struck by? As a PM, I want my eng team to be courageous and stand by their decisions rather than respecting me only once I offer my self in a sacrificial ritual.
Are they technical decisions? Yeah, sure, that's on them.
But a LOT of decisions in reality are ones where there is no clear "organic" owner. In that scenario, assuming nobody else is putting their hand up to own it, that's the PM's responsibility.
Nobody will ever tell you this in interviews, it's never part of the job description, but it is one of the most important parts of being an effective PM.
Hard agree with this take. Also, a good PM should be technical enough to really understand not just how customers use the product but how the product works. you should be able to be the designated person to answer a question from customers when nobody else knows the answer. In my role as a PM, I'm usually the person the buck stops with for Sales, Support, Solutions Engineering, et al. You can't do that if you don't actually know how anything works, which I see way too much with other PMs in this industry.
As a PM, you unlock a lot of value by getting engineers out of a lot of these meetings, by being technically competent enough (for these contexts) to not need them 99% of the time. It isn't even just about the devs' time either. It is about their focus and reducing context switching too.
100% agree. This is the biggest debate I have with other PM's who say "you don't need to be technical"... Total bullshit.
You're expecting to be able to engage with your engineering team around the relative effort and complexities of different technical solutions... You're gonna need to have an understanding of the underlying technical details.
The way I see it, I don't necessarily need to know how to build the thing (as in, all the implementation details). But I absolutely need to know how the thing we're building works, what all the key moving parts are, and how they relate to each other.
Without that, there's no way I can develop any kind of intuition as to what is and isn't possible, which is CRITICAL when managing expections with customers or internal stakeholders.
Mismanagement leads to failure. Failure leads to layoffs.
We’ve hit industry maturity with ever slimming margins but with management still operating like costs don’t mean anything. If management was doing their jobs they would discover the cost of meetings and ultimately the cost of indecision!
PMs shouldn't have to fix organization dysfunction while operating in Hero Mode.
I'm not a PM, but you are exactly the kind of PM I love to work for.
So many PMs are either over bearing or scared to make decisions; or, the worst, that do both, over bearing and micromanaging all the time and then blames the team when their decisions back fire.
As someone who studied film/arts I always thought the art world was a disorganized mess. That was, until I worked at some corporate places and realized that in the art/film world you have at least the artist/director with a clear stance towards the project.
A good film set runs like a well oiled machine with an extremely clear division of responsibilities. Decisions can be made fast, because time is of the essence (the sun only shines so long). This is cool, because if I do the camera I usually don't need to worry about anything else. But usually I also don't have to do anything else: For the duration of the shooting, the film becomes all I need to worry about. I get food, I get a place to stay and most importantly: I chose to be there.
Meanwhile in corpoworld there are X meetings with people who don't even know why they were invited, don't wanna be part of it, are not given the time/resources/mental headspace to be there and then corperate wonders why the project doesn't goes as swimmingly as it could. If your people already do two jobs and the project becomes a third, guess what: they are going to avoid doing too much and maybe if you are lucky some poor sap carries that thing over the finishing line alone. But if that is the outcome, wouldn't it have been better to free that person from their daily duties and put them in charge of the project and whom to talk to? The resoueces of the company would have been better spent, the result would have been better, the thing would get done quicker etc.
If you want to take two things away from this post:
- put someone in charge of the project, make sure they want to do it
- Daily cruft is the enemy of projects. Free people from the rest of their duties, even if it is just a day of the week, e.g. "on Fridays Frida works on project X".
How do you evaluate whether someone wants to do a project?
If a boss asks, "Do you want to do this project", seems like another way to ask "Do you want to remain employed?"
It’s important for your boss to frame that differently if it’s truly optional.
They can’t leave it at “do you want to do this project?” They need to follow up with, “It really is optional, I won’t be hurt if you say no.”
They also can’t do it with a big decision first. They have to frame small decisions that way sometimes, to build trust that when they say you have the ability to decline, they mean it. Then, they can ask that way on big decisions.
If a decision isn’t optional, they should phrase it a different way. I use something like - “I need you to do this project - how does that make you feel?” I want them to tell me if it’s a hardship, but I don’t want to imply that I’m leaving the door open to a different outcome necessarily.
Establishing a culture where that assumption is not the case and engineers can say “no I’m not very interested in that”. Also a boss that can actually read people (correctly).
After the roadmap is finalized, as the manager I ask every one on my team to stack rank at least N preferred projects from the roadmap. I map preferences to projects with some optimizations (e.g. career progression, avoiding knowledge silos), review it with everyone, and then commit for the roadmap.
If there's grunt work that no one wants to do, I distribute it fairly among the team. Fairly can be splitting it up evenly among the team (everyone refactors _n_ files) and sometimes it means we round-robin the responsibility (e.g. quarterly compliance reviews with auditors). Obviously this depends on the team size and role in the company, but I think it's only come up a few times over ~4 years.
I mean, there is many ways to do that, but one way is to instead of asking a single person you let people apply. For projects that are not as attractive you up the compensation/bonuses till someone is interested.
Then they made the choice themselves and even if the project sucks in the same way, they made the choice themselves.
An important rule of low/no budget film-making is: no mattee who is in your crew/cast, know why they agreed. For an established actor that might be trying out a new or different acting style, a different role, whatever. For the sound guy it might be learning the tools, or going to a certain landscape or some compensation. Know what motivates your people besides the salary and treat that motivation like the most valuable secret intel tou could have ever aquired.
In my experience this is usually a result of misapplying the idea of "consensus". The best formulation I've seen work is "nobody is vetoing". It doesn't mean that everyone agrees, just that nobody disagrees strongly enough to block progress.
I would go even a bit further. For a good consensus to be had, everyone that cares to should have the opportunity to share their opinion and defend it, to provide stakeholders all the viable options. The "consensus" then isn't that we all agree on the "right" option, but that we all agree that the person in charge, after evaluating the options, makes the final decision and we all move forward with that plan without taking any disagreements personally or getting angry if your option wasn't selected.
I'm lucky enough to work in such a team, and it's been fantastic.
A good way to approach this is to think like a military: there might be a staff, but there is only one commander in the unit. Their whole job is making the right decision as quickly as possible and assuming responsibility for it.
If the manager keeps avoiding making decisions and diluting responsibility, they aren't fit to be a manager.
I’ve used this analogy before but people hate it. on internal projects at my firm everyone wants everyone else to have an equal voice out of guilt. The meetings and navel gazing never stop and the work becomes working on the process and never actually delivering on the need.
With client projects it’s different, you have a budget and deadline. Miss it or screw up on the way and the client fires you and hires your competitor. My client delivery teams are a much harsher environment but roles and responsibility for decisions are very clear and everyone’s job is at stake so it gets taken pretty seriously. There’s no room or time for consensus building, the flip side being owning a bad decision means working somewhere else.
Oh, it's important that everybody has a voice. But it should never be equal, making it equal almost guarantees the project will stop.
Making sure everybody has a voice is a task for the people that actually have power there. The other part of that task is cutting those people down and overruling them when needed.
> and suddenly nobody can even identify who is the decision maker.
For management more interested in playing politics, this kind of ambiguity is a feature, not a bug. This is how you take credit for successes, and shift blame for failures.
I think weak leadership is the default, with a micromanager trying to own everything as an over-correction coming in as the runner up.
I've worked across 18 companies, and about 2-3 times I've been given a person to onboard me, once we had a decent central wiki, and the rest of the times I've basically been left figure it out.
I don't even think these things are overly hard to figure out, but very few people in tech straddle the lines between tech and org, and when they do, they're usually kept at bay by the non-technical tech roles ( deliver manager, etc ).
In my limited experience, you have a real problem if the dev team hijacks what will be done and how it will be done. There is a good chance your product is going to be over-engineered, difficult to steer and all the minor but important details will never get done/corrected because hey, lets build another mammoth worthless (in business terms) functionality.
I also saw powerful product managers get support from higher-ups and then shovel their ideas down the throat of engineering orgs. A PM in Uber's Marketplace org used to create and present a brand new architecture for the entire Uber's marketplace. It was not concrete enough. It didn't really convince people of what problems to solve. It was not even a good architecture (maybe it was, but at least few people got convinced). In fact, the presentation didn't even get many questions but hundreds of blank stares. Needless to say, the architecture was not implemented. It was nevertheless quite a humiliation to the marketplace's eng org.
Saw this firsthand when I worked at Nokia. It was consensus building taken to extreme levels, resulting in having 7 different UI toolkits and 4 developer platforms. Absolute hell, but very polite and conflict-free.
I don't think consensus-building is necessarily bad on it's own. Depending on the environment, when people don't feel like they have an opportunity contribute, it can potentially lead to other issues.
To your point, I think a lack of leadership can kill a consensus-building process. Whoever is coordinating needs the authority and will to end the discussion when the time is right (among other things.) Otherwise, it really can become endless debate and drawn out attempts to get some unwilling party onboard.
> I don't think consensus-building is necessarily bad on it's own.
Making decisions based on consensus is just often not the right choice in this context. If used for the wrong type of decision, it will lead to a "design by committee" type of process and result, driving a lot of people mad along the way.
A better way to make decisions in a software project is to consult with stakeholders (if necessary), identify the appropriate decision maker based on competence and then let that person make a decision.
> A better way to make decisions in a software project is to consult with stakeholders (if necessary), identify the appropriate decision maker based on
competence and then let that person make a decision.
Holy shit. This is one of the most profound things I've read about management in a long, long time.
> 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.
Spot on. If I could have all the years wasted through this back, I would be a young man again. In my experience, these are product managers that have never actually been involved in building anything.
Also modelable with Storming/Forming/Norming/Performing
Except every time you add someone new, it slips back to a prior state - and every time the group gets bigger, it takes longer to ‘settle’.
Eventually, roles/ownership/structure. needs to be codified, or the group never ends up actually performing - and if not done right, that won’t happen even with that.
I once as team lead had to preside over a product designer and senior dev (who used to be a CTO at a tiny startup) who never saw eye to eye, but the designer always had the final say, (unless there was a good technical reason to do something differently), because that’s what she was in charge of
I think there's a reason why historically many cultures in a time of crisis tend to choose a leader to take responsibility until the crisis is dealt with, like the dictator in republican Rome. Pirates often elected and even unelected their captains, but during any action their power was absolute. And so on.
Making a decision based on input from relevant coworkers while being competent in the domain you are making the decision in isn't exactly dictatorship?
> This and, especially if the decision maker made it to their level based on merrit.
Assuming a competence hierarchy, that should equal competence. Unfortunately, oftentimes it's not a competence hierarchy. In those cases, it may take some time to trust in someone's competence.
Yes, undoubtedly. Although once appointed as a dictator the benevolence part normally slides.
So what happens in the happy case is a very complex system of figuring out who should be the dictator and when they need to be moved on. If you look at successful open source projects that process is often visible - a brutal communal negotiation (of global scope!) to work out who in the world is the person with the best motivation to control a project.
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.
> 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.
Very much this - I regularly find that asking "what problem are we solving?" allows me to work with the stakeholder in question to find a better solution than what I was initially asked to build. It's fine to take a stab at a solution but it's also a good idea to remember that you hire experts for a reason.
Very much this. I have a long-standing saying that I share with those that want to bypass the "explain your goals to me" portion of the conversation and want to skip to "just do what I asked."
"Be very careful what you ask for because if I really dislike you I'll give you EXACTLY what you ask for and you'll find out quickly how much you didn't want that."
It's easy to say with a smile an a laugh, but definitely depends on your organization. I do tell people almost exactly this in my solo dev role, but more win the context of "I literally don't have the time to redo this, so let's get it right the first time".
I think it's an engineer's responsibility to present likely outcomes with their likelihood without judgment. Opinions are usually not needed unless asked.
> 1. Engineers shall be guided in all their relations by the highest standards of honesty and integrity.
> ...
> b. Engineers shall advise their clients or employers when they believe a project will not be successful.
There's nuance around how hard you should push back on bad requests and where ownership/accountability and decision-making responsibility ultimately lie but providing professional judgement/advise/opinions is definitely in bounds for engineers.
Exactly. Wants (as initially stated) are rarely the actual business' needs. There also has to be some level of depth and breadth understanding, the implementated needs with be fragile and break easy.
That said, interpretating what's and crafting them into needs is more enginner than developer.
A lot of the replies to this are dancing around just ask them "Why" they want what they want. Then the "what is built" can be creatively explored and even negotiated as long as it solves the why.
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’m in management and routinely allow for this. Not as much as my team would ideally like, as is and should be expected, but much more than zero. Sorry about your crappy job.
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.
> This sounds a lot like letting the monkeys bang away on typewriters while you sit back waiting for Shakespeare...
Well, humans are primates and I suppose we could draw a parallel between keyboards and typewriters. Although if a dev is trying to write Shakespeare they will get gentle feedback that this is an inappropriate use of their time.
> 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.
I expect all the opinions agree that the plan is to give experts necessary context and trust to build good products. There aren't actually that many options here. You have to talk to devs, and then you have to let them dev. The question is how much context can/should be front-loaded and how to deliver feedback.
And those are relatively simple to answer; much as possible and frequently. Beyond that we're relying on monkey-typewriter dynamics.
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.
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.
Those types of questions are likely to engage "problem solvers", aka people who don't just wait to be told what to do, but who actually demonstrated proactive critical thinking by reacting to a challenge. Those types of people are more likely to put extra neurons in for future problems (contrary to stock markets, past performance is actually a strong indicator of future success, when it comes to hiring).
If you don't have any scenarios from your work experience where you can demonstrate being a "problem solver" who reacts to stuff, then you probably aren't someone to likes to fire up the extra neurons, and hence wouldn't be a fit for the parent comment's desired team/org profile.
Incentives operate on a slow time-scale. Let's say you have a decent team as a baseline, but starting to fall into this "just tell me what to build" apathetic failure mode. How would you turn this ship around?
As a manger, you could go as far as saying explicitly -- "hey, any engineer who demonstrates customer obsession and shows attention to impact, will receive their choice of project to work on, will get promoted faster and higher than those who don't, etc.", but this is unlikely to create a positive outcome. At best, 1-2 people may rise up, but the rest of the team will resent them for "try-harding" probably; crabs-in-a-bucket mentality is a very natural human group phenomenon. And now you've got 1-2 "stars" who won't want to stick around to deal with the rest of the shitty team members, so once they leave, you're back at square one.
Reorging is a reasonable step to take, but it's risky and you could just as well end up "infecting" other orgs or team members, by carrying the contagion of bad culture with you.
Firing and hiring again more carefully, is honestly both faster and more direct, and shouldn't be seen as a "last resort" option IF the culture is truly too far gone AND the culprits are readily identifiable. First step is probably to make sure you have a firm and accurate diagnosis of the problem, then if you're 99% sure you can identify the right people to fire -- go ahead and fire them.
> 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.
It seems like this can also happen when management is under-valued and each individual contributor can always make all their own decisions. I'm sure this can work on a team disciplined enough to share important design decisions they make with each other and to voluntarily adhere to some design decisions they may not entirely agree with. But for a lot of teams, without someone taking the lead on making important decisions, you end up lost.
As long as the chefs also do cooking, having chefs is not a big deal. The problem is the people who do not produce anything but keep themselves busy doing stuff that ends up wasting everyone's time.
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.
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.
> unless you actually build something, the money isn't going to arrive, and you'll be out of a job.
The sad part is that many employees have come to the rational and correct solution that the above is not true. Out of the people I've known, more have lost their jobs to the results of C-suite malfeasance (e.g embezzling, illegal behaviour) than have ever lost their jobs to their own actions.
Conversely, unless the organisation you work for is exceptionally incompetent, your own personal failures shouldn't put them out of business. Think about all the cancelled Google projects. If the devs that worked on them had just come into work and played Minecraft all day, Google would still be in business. My personal opinion is that, if the Google Reader devs had never delivered a product, Google would be better off today than it actually is because it wouldn't have such a devoted community angry at it for killing off a beloved product.
The navel gazing framework discussion is like selling your own lotto tickets. If someone's number actually comes, you're on the hook for millions of dollars and probably broke for life. However, a person with a risk taking mentality will recognise that the odds of someone winning the lotto is tiny and, barring that outcome, selling your own lotto tickets is free money.
I agree, unfortunately the trend over the last decade is for a lot of developers to want software-factory style jobs, and think that business is “not their problem”.
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.
I am not empowered to make decisions, I have nobody to discuss meaningfully with, and I'm told what to build perentorily but vaguely and often incorrectly. Will I be able to read the mind of my boss? Better to stall, complain, and avoid making mistakes.
I suffered through that kind of situation for much longer than I care to admit. I am now behind the curve in terms of skills development because of how stagnant the situation was.
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.
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.
I believe there is a form of PTSD that develops within toxic software development jobs and I wish it would receive more legitimate attention and treatment options.
I have tried to explain to my therapist why I have developed something like PTSD around peer reviews... yes, we all say "you are not your work" but that does not excuse being (dare I say) abusive in comments on PRs.
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.
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.
I’ve worked (burned out) under this. Eventually I realized that “debate everything” just meant the boss really loved to debate, because he could always “win.”
Maybe if it's 50% we can send SIGTERM so at least the host can try to make conclusion before closing off. But then if it's higher (66%? 80%?) then we do send SIGKILL.
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.
I'd love to ask anyone who's worked on present day Instagram/Facebook what the long term effects of data driven decision making is. My understanding is that it's been a toss up.
I think PG has a tweet a while back like "some decisions are so bad, no one in their right mind would agree to this if there wasn't data to back it up". More of less saying, you can find data to support any decision, so why even be data driven?
I'd say their experience is an outlier. They are not the norm.
I'm speaking from a 20 year background designing medical devices and other critical infrastructure. In my world, like with airliners, it's important to get decisions right or people can be killed. Therefore, data driven decisions.
Yes, if safety and livelihood are on the line, get the data and be sure.
But most companies have to implement purchase flows, marketing sites, software onboarding, etc. Examples like this are where folks are more likely to cherry pick data to justify whatever their biased to believing.
Yeesh, I don't know. I think we have enough data to decide the shape of the Earth, yet there are still Flat Earthers. Your approach works in an idealized world where everyone is perfectly rational and emotionless and all facts are perfectly knowable. That's really not the world we live in. This is basically a hardline stance at the extreme "endless debate" side: if literally anyone in the room is disagreeing, then you must not have enough data to make a decision yet? I don't see that working in practice.
A lot of decisions come from experience and expertise. There are hundreds of little data points that all come together in my brain when I make an engineering decision, and I can't even necessarily enumerate them all. It's exhausting to have to justify every decision to others. Gathering data on 100 approaches that don't work is just too expensive. Sometimes you should just let experts be experts and defer to them, even if they can't exactly say why.
>"It's exhausting to have to justify every decision to others"
You sound like a real pleasure /s
It's our job to. It's why they teach us to show our work. It's why we have building inspections. It's a necessary "evil". The sooner you accept, and embrace it, the more fun you will have in your day to day life, and more joy you will bring on others.
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.
I had such a great company social night, talking with an engineer who got his start here ~5 year ago.
They were taking about how they just want people to have a well formed idea of what to build, to be able to hand off clear expectations, and let him roll. For curiosity sake I started asking about other times: has there been a time where you've felt on the line, been the one who has to figure out what to do?
They paused for a bit & then said yeah, actually... They had been battlefield promoted after two higher ups on a team had left & it was just them running this product. They said they had little idea what they were doing but the company trusted them & let them hack through it. They loved that time. Finding out what to doz being given problems and the freedom to solve it was a highlight of their life, they said.
A lot of people don't want to play the game. Especially when we are forced to collaborate with non-technicals, it's incredibly hard to justify and explain ourselves & to share power & compromise with these people who lack competency to judge, assess, negotiate.
The title here omits the gods truth as an option: we the engineers know & can assess & you the business/product don't have the technical chops to debate, nor do you understand what is to be built. The premise presented is "debate vs do" as they say it, as though product and product alone understands do. But I think most engineers live in pain and dissonance and sadness, feel an incredible impedance and struggle, because most businesses/product have only the faintest fragmentary fake propped idea of what do is. It's a fiction. And it's up to engineers to cobble together some vaguely competent rendition of the fairy tale nonsense product tells itself it's come up with and that engineers need to just do.
The phrasing here could not be more slanted. Run, engineer, run, from the dented terrors that would think their product sensibilities have fully flushed out the idea, that think there is no cause for "debate" or sussing out how really to do a things that think only to "do" what the master product says is necessary.
Debating is another form of waiting. You're not waiting to be told, but you're waiting to reach consensus. As long as the decision makers have bias for action you won't get caught up in either debating endlessly or waiting to be told what to do. Finding out how long to "wait" in either incarnation is only learned through experience IMHO, using general principles such as "one way" vs "two way" doors, etc.
Where a bunch of corporate fascists took such umbrage over debate/exploration over how their corporate envisioned scenarios were to work that they started pursuing legal action? Against open source people making Home Assistant integration?
These people basically went thermonuclear in terms of cancelling possible debate & enforcing top down decision making. Utterly unwilling to listen or permit a single other opinion other than what their top-down management built.
I cannot think of a better company to serve as a warning sign for what to never ever do. Seeing yourself & your own vision of the product as God & any deviation or discrepancy or other opinion as something to be squashed. Usually lawyers aren't involved as Haier did in their quest to stop out undogmatic use, but alas this kind of managerial hubris & self importance from the product world seems all too typical & all too poisonous; an unwillingness to let anyone else explore bounds of possibility, lest it gets in the way of those egos assured they've built a perfect little terrarium for the users to play inside.
They calmed down eventually, with an incredibly useless & empty press release hinting that they were backing off. But this seems like one of the most powerful examples of a company chuffed up on hubris unwilling to permit even the hint of debates.
At some companies there are so many places where things can be changed or undone.
We had a simple avatar upload. Done this in every app we had ever made. It "broke". And I mean it didn't really break, but it changed enough where it might as well have.
Who changed it? Sales (aka the customer)? QA? Development? Design?
Does what you’re doing increase revenue, profits, market saturation, improve customer experience, whatever?
If it doesn’t don’t do it.
I don’t think it needs to be that hard.
Fire people who waste time that detracts from this mission.
Imagine you’re in close quarters combat as a soldier and your team lead is goofing off or your manager is focused on looking good. Don’t find yourself in that position. Don’t let your team get to that level of incompetence and failure.
Seriously? I have at least ten major projects on my wishlist that all meet those criteria and aren’t getting worked on, because time is finite. The question is not how to find something useful to do, it’s how to agree on what the most useful choice is.
> 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.