Debate is a good if you all have a shared idea of what constitutes 'good'. IE, simplicity, performance, whatever.
Balancing engineering cultures: Debate everything vs. just tell me what to build
11–20 of 128 posts
Re: Balancing engineering cultures: Debate everything vs. just tell me what to build
#12Culturally 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 ma…
Yup pretty much this but you need to grind that $0/day work that you see right problems.
Re: Balancing engineering cultures: Debate everything vs. just tell me what to build
#13This 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.
Re: Balancing engineering cultures: Debate everything vs. just tell me what to build
#14I 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.
Re: Balancing engineering cultures: Debate everything vs. just tell me what to build
#15Culturally 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 ma…
> 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 s…
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.
Re: Balancing engineering cultures: Debate everything vs. just tell me what to build
#16> 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
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.
Re: Balancing engineering cultures: Debate everything vs. just tell me what to build
#17Debating 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.
Re: Balancing engineering cultures: Debate everything vs. just tell me what to build
#18How about focus on the mission of the business?
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.
Re: Balancing engineering cultures: Debate everything vs. just tell me what to build
#19The 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.
Re: Balancing engineering cultures: Debate everything vs. just tell me what to build
#20The 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.