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.
Balancing engineering cultures: Debate everything vs. just tell me what to build
21–30 of 128 posts
Re: Balancing engineering cultures: Debate everything vs. just tell me what to build
#22How 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…
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.
Re: Balancing engineering cultures: Debate everything vs. just tell me what to build
#23This 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 wh…
This is a great take.
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.
Re: Balancing engineering cultures: Debate everything vs. just tell me what to build
#24> 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?
Re: Balancing engineering cultures: Debate everything vs. just tell me what to build
#25Culturally 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…
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.
Re: Balancing engineering cultures: Debate everything vs. just tell me what to build
#26As 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.
Re: Balancing engineering cultures: Debate everything vs. just tell me what to build
#27This 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 wh…
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
Re: Balancing engineering cultures: Debate everything vs. just tell me what to build
#28How 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…
There are many cases (not all justified) where product work is too difficult to directly tie to financial outcomes, or, the lag time is very long
So then you get into all these murky waters of how to decide what to work on and how to go about it
Re: Balancing engineering cultures: Debate everything vs. just tell me what to build
#29Similar 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.
Re: Balancing engineering cultures: Debate everything vs. just tell me what to build
#30How 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…
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.
In my experience people usually spend to much time trying to figure out what is most important instead of just doing an important thing.