3 ms·

I think the problem isn't really what is being done to manage software devs, but that managers are trying to squeeze more productivity out of software teams whi

I think the problem isn't really what is being done to manage software devs, but that managers are trying to squeeze more productivity out of software teams which are insufficiently staffed and where higher level strategy is bad and the teams are setup to fail. And largely the "poorly performing" software dev teams are just a symptom of the problem and you can't rub any level of management onto the team in order to fix it. What I'd like to see is a methodology which produced an objective measure of how overloaded a software dev team was and which could be used to justify an increased headcount. I've never actually witnessed that come out of one of these processes.

nradov 5y ago
What does overloaded even mean? An agile program team has a certain velocity, and will work on backlog items in order of priority. The business always has the option to expand the team in order to increase velocity (perhaps with some diminishing returns). But if the business is short of capital, or the whole program isn't very valuable, then it is often preferable to just let the backlog grow.
dasil003 5y ago
Your first paragraph rings true, but I have to disagree that the second is the solution. I’ve seen engineering management play this game to justify headcount without acknowledging the strategic or product definition problems and it just leads to more chaos and pressure on the team. If engineering doesn’t have both a voice at the leadership level (for whatever scope is in question) and sufficient biz/product chops to find the right 80/20 path and team/ownership structure then headcount is just more grist for the failed project mill.