Nice, thanks for sharing. A few points stroke a chord. Specifically... The definition of engineering manager who doesn't know how to do stuff and it's solutio

Nice, thanks for sharing. A few points stroke a chord. Specifically... The definition of engineering manager who doesn't know how to do stuff and it's solution is very wishy-washy. Based on experience, this works in some contexts but not all. I think the author's hearth is in the right place, but the way it's explained is very short sighted. In other words this makes me think the author has never worked with an eng manager. Layering: good problem to solve, solution? In theory, but in reality this is also very difficult to balance (e.g. from experience, especially when moving above 150-200 ppl working in the same area). Too many meetings: very good problem. Solution? Partially meaningful. If you want to generalise, my take would be to make things async as much as possible. Collaboration between teams might be needed, and perhaps healthy. When you don't have collaboration you end up not knowing what's going on (i.e. isolating teams) and risking pulling meetings over and over. Software definition; mostly agree, but again, the solution is much more complex than what the author leads to believe. Also assumes you have testers and product will be happy to sit through each ticket revision. This problem is solved by anticipating these requirements way way earlier than that. Software delivery: are we talking about technical debt or what? If that's the case, the solutions (20%) make no sense. That's where you start diving into each single problem, breaking them down by priority, involving product and making sure things are tackled at the right time. The rest seems to be good.