That's how it works in a nutshell. Lots of talkers out there. The people I know who do the real work are the ones at the bottom, and you don't know them because they keep their heads down and focus on writing code. The people that self-promote the most are the ones least capable.
Time spent coding is a zero sum. Leaders are needed to identify how to do use that energy and time. In terms of business success. This might be the #1 thing (granted I’m entirely speculating). Are your priorities correct and do the engineers know them? This is not that easy. People will argue endlessly over when to address tech debt, how much security is enough security, how much to deliver early vs fully formed, what features to build, When to bail on a half made feature, etc etc.
Looks like we found the person “building and leading amazing teams” in the thread. How could those lowly coders ever figure out how to secure a product?
People building projects don't tend to argue about tech debt and security unless they've had a leader make decisions that compromised their comfort levels. Quorum decision making in those circumstances keeps those things in check.
> Quorum decision making in those circumstances keeps those things in check.
Depends upon the composition of the quorum. If the quorum is mostly "eh it works, just ship it", jugaad, chabuduo, corner cutting engineers, then I've witnessed adverse results.
Conscientious engineering that delicately balances trade-offs is difficult to teach, and poorly discerned by most casual observers (even other conscientious engineers casually observing) in the short term.
