Here is what I think are several root causes of poor velocity<p><pre><code> 1. too much focus on hiring
2. lack of clear responsibilities
3. lack of management <-> line worker interaction
4. bad mentor <-> new grad ratios
5. bad product development to infra (build infra/infra infra/dev tools etc) ratios
6. mistaking prolific senior engineers for good senior engineers
7. letting senior engineers off the hook for maintenance
8. lack of some process
9. hiring specialists
</code></pre>
One can ask what sacrifices you make to hire good engineers. You might choose to make exciting infrastructure investments rather than a necessary investment. You might promise that the "good engineer" won't have to do incredibly boring work. You might hire people who have made a career out of avoiding the real high risk pain centers of a company and instead working on high visibility low risk problems. How much of which engineer's days will be sacrificed to interviews? The engineering concessions made towards the goal of hiring are likely an underrated root cause of poor velocity.<p>I watched the most festering pile of code at a company be hot potato-d between the vp of infra and vp of product. The CTO was checked out and not in touch with what was happening enough to know this was a problem. Neither VPs brought it up as a problem, because neither wanted responsibility and therefore the likely black mark by their names for the uphill battle that would result. The company deeply suffered because there was no advocate for the companies highest pain area because everyone with power, clout, or authority avoided responsibility for it.<p>When management gets insular, and management fails to solicit direct feedback for line workers, they can't be sure the picture they have in their head is what matches reality. This creates management level delusions about the state of their engineering org. We can see this played out in US vs Russian military structure. Management sends goals down and expects them adhered to. Failure results in punishment. This creates rigid planning and low agility. The US military instead gives lower levels large leeway to achieve higher level goals. It is the lower levels responsibility to communicate feasibility or feedback, and more importantly it is upper managements responsibility to adapt plans based on feedback. I was absolutely part of an "e-4 mafia" (<a href="https://www.urbandictionary.com/define.php?term=E4-Mafia" rel="nofollow">https://www.urbandictionary.com/define.php?term=E4-Mafia</a>) and I knew much better than my superiors what was happening, why it was happening, who was doing it, who could help doing it, and its likelihood of success because I was in the weeds. When I laughed directly at managers who told me their plans, they thought it was something wrong with me, not something wrong with their plans. That was half management failing, and half my inexperience in leading upwards.<p>Every new grad needs one mentor to prevent them from doing absolutely insane overly complicated things. If you do not have a level of oversight, complexity will bloom until it festers. A good mentor preventing new grad over complications can save an incredible amount of headaches. New grads should not be doing other new grads code reviews (for substantial work). Teams should not be comprised entirely of new grads and an inexperienced tech lead. New grads are consistently the largest generators of complexity.<p>I worked at a place where there was 1 person working on build infra. .2% of the company was devoted to making sure we had clean reliable builds. I estimate 5-15% of the engineering org quit due to pain developing software, which meant there was a lot of time spent interviewing people and catching them up rather than fixing problems. I don't know what the right ratio is, but I can say for sure that if you don't invest in dev tools/build infra etc, early enough, you will hit a wall and it will be damaging if not a mortal wound.<p>There are lots of engineers who code things to be interesting. They write overly complex code. They lay down traps in their code. It's rare for there to be a senior engineer who writes boring, effective, and, most importantly, simple code. Some of the code I've seen senior engineers write violates every principle of low coupling, no global state, being easy to test, etc. These people are then given new grads who learn to cargo cult their complexity until it gets to the point where someone says 'we have to re-write this from scratch.'<p>There is an anti-pattern where senior engineers get to create a service with no oversight, then give it to other people to maintain and build upon or "finish." Those teams seem to have low morale and high turnover. The people left on those teams aren't impressive and so it gets harder to hire good engineers for those teams. If a team is the lowest rung on the ladder, clearly evidenced by being given problems and being told to "deal with it," that will show to new hires only exacerbating the problem.<p>Some people hate process, it slows them down. Bureaucracy is (debate-ably) terrible. One design doc with a review can save quarters of work. Some process slows progress down now, for less road blocks later. If process is not growing at a rate of O(log(n)) or growing at a rate greater than O(log(n)), then there's probably gonna be some problems.<p>Lastly, while it's important to hire good people, it's also important to hire some specialists. Databases, infra, dev tools, build infra, platform/framework infra, various front-end things, traffic infrastructure. There are all types of specializations, and if you have a good "full stack" product engineer in the room without say a platform/framework specialist, you will get the product development perspective without the product maintenance perspective, and that has exactly the consequences you might expect. The earlier you get an advocate for say "build infrastructure," the more you are able to address future problems before they are major problems.