3 ms·

This is incredibly useful advice that essentially everyone who gets to make decisions in this space hates This article makes sense to me as a developer and an

by advael 2y ago

This is incredibly useful advice that essentially everyone who gets to make decisions in this space hates This article makes sense to me as a developer and an occasional manager of developers and a former student of psychology and honestly if you meet and talk to people who do actual work in any capacity sometimes in your life and had any honest assessment of their day-over-day work over any appreciable period of this time you will have a hard time avoiding this conclusion But businesspeople and especially high-level investors are rewarded for ignoring it. I've been in a few C-suite and board meetings and while you occasionally see the folks there talk about their underlings, they tend to mostly talk about abstract measures of outputs, with "velocity" being a popular term in tech orgs in particular. If they mention a worker by name, they tend to be high-ranking, perhaps a manager, but usually they are getting a lot done fast, or used to be and now aren't. Seldom is the latter kind of conversation had with remorse, sympathy, or the slightest hint that the prior state was a direct cause Developers, especially experienced ones, often know what they need to get work done. They are often realistic about how much work to take on. They are incentivised to take on too much anyway, because the culture of business is fundamentally deeply broken As far as I can tell, there has been no point since the invention of factories and metrics at which this has not been true, the rule rather than the exception among the entire classes of owners and high-level managers. And what's worse is that often competent ones of these can get some clout by delivering results by realizing this, but as more of them are added to the decision-making process, their ability to resist this tide, either socially or through direct loss of power, diminishes

candiddevmike 2y ago
The worst is when a big issue is taking too long, some higher up wants it broken out into smaller tasks so they can be closed independently/faster. Eventually the issue becomes a fractal of issues assigned to multiple people and progress comes to a halt. Sometimes things take time, and can't be delegated.
- flerchin 2y ago
  9 engineers can't make a baby in a month.
  - baal80spam 2y ago
    PO: "Well, how about 3 months?"
- dmorgan81 2y ago
  > Sometimes things take time, and can't be delegated This is something I keep saying to our team, but we have some members who want to keep breaking things into more and more tickets. Their argument is it allows more bits to be worked on in parallel but I point out that it means context must be rediscovered by multiple people. Sometimes it’s okay for one ticket to be a large-ish do-it ticket and we don’t need a design+breakdown for every aspect of a feature.
- advael 2y ago
  I think the wisdom that headcount doesn't make a product faster has managed to reach some people, but somehow not the wisdom of don't burn out your people. Like no matter how much you talk about burnout, there is no adequate valve in play that enforces this as a true incentive. The very closest business people to having the worker perspective are "technical" startup founders (IE those founders doing the kind of work they may later measure their employees about), who take youth and energy into their passion project and by the time they burn out they have underlings, money, and power, or more often have simply failed out. In the former case they no longer need to be very productive in a labor-y sense that often and will remember a success story that was for them personally about unsustainable and generally unscalable hard work. In the latter case, they either have the support network to recover from their failure and maybe even try again. Those who fail to ever create a successful business are not taken seriously by businesses. Business people and investors who have not been technical founders are even less likely to "get" this on an experiential level, and may well get by on burning people out over and over, with each instance being excused as inevitable churn, conflict of personality, or generally speaking the fault of the employee. Since financiers care more about the short term and the appearance of "growth" rather than the long-term sustainability of the business, let alone the fates of the workers, burnout and slowing projects to a halt due to prioritizing being busy is an externality at best. As we can see basically all over the economy, the investor incentive barely can be said to align with that of the business, let alone its workers
- SkyPuncher 2y ago
  Thing is that advice probably tends to come from a good place. There’s actually a lot of evidence that smaller tasks lead to higher velocities
nine_zeros 2y ago
This is an astute observation. I have myself seen this at many employers now. It almost seems like execs and board members cannot think beyond the factory mindset. And layers and layers of management have no desire or incentive to pushback. Leading to the best engineers getting tired of the grind. The either burnout, or withhold their best, or stop caring, or just do enough to keep the ship running - all of which "appears" as a drop in "velocity". This leads to PIPs and firings from clueless manager that is only looking at Jira points to inform themselves. At some point, the entire organization moves away from the engineering and people mindset to the KPI-factory mindset with poor decisions everywhere due to self-interest - leading the organization to become a worse form of IBM. It really is astonishing to me to see it play over and over. It is clear that the upper echelons of execs and board members and upper management don't care enough about the company to sustain a good culture.

by advael 2y ago

candiddevmike 2y ago

The worst is when a big issue is taking too long, some higher up wants it broken out into smaller tasks so they can be closed independently/faster. Eventually the issue becomes a fractal of issues assigned to multiple people and progress comes to a halt. Sometimes things take time, and can't be delegated.

flerchin 2y ago
9 engineers can't make a baby in a month.
- baal80spam 2y ago
  PO: "Well, how about 3 months?"
dmorgan81 2y ago
> Sometimes things take time, and can't be delegated This is something I keep saying to our team, but we have some members who want to keep breaking things into more and more tickets. Their argument is it allows more bits to be worked on in parallel but I point out that it means context must be rediscovered by multiple people. Sometimes it’s okay for one ticket to be a large-ish do-it ticket and we don’t need a design+breakdown for every aspect of a feature.
advael 2y ago
I think the wisdom that headcount doesn't make a product faster has managed to reach some people, but somehow not the wisdom of don't burn out your people. Like no matter how much you talk about burnout, there is no adequate valve in play that enforces this as a true incentive. The very closest business people to having the worker perspective are "technical" startup founders (IE those founders doing the kind of work they may later measure their employees about), who take youth and energy into their passion project and by the time they burn out they have underlings, money, and power, or more often have simply failed out. In the former case they no longer need to be very productive in a labor-y sense that often and will remember a success story that was for them personally about unsustainable and generally unscalable hard work. In the latter case, they either have the support network to recover from their failure and maybe even try again. Those who fail to ever create a successful business are not taken seriously by businesses. Business people and investors who have not been technical founders are even less likely to "get" this on an experiential level, and may well get by on burning people out over and over, with each instance being excused as inevitable churn, conflict of personality, or generally speaking the fault of the employee. Since financiers care more about the short term and the appearance of "growth" rather than the long-term sustainability of the business, let alone the fates of the workers, burnout and slowing projects to a halt due to prioritizing being busy is an externality at best. As we can see basically all over the economy, the investor incentive barely can be said to align with that of the business, let alone its workers
SkyPuncher 2y ago
Thing is that advice probably tends to come from a good place. There’s actually a lot of evidence that smaller tasks lead to higher velocities

nine_zeros 2y ago

This is an astute observation. I have myself seen this at many employers now. It almost seems like execs and board members cannot think beyond the factory mindset. And layers and layers of management have no desire or incentive to pushback. Leading to the best engineers getting tired of the grind. The either burnout, or withhold their best, or stop caring, or just do enough to keep the ship running - all of which "appears" as a drop in "velocity". This leads to PIPs and firings from clueless manager that is only looking at Jira points to inform themselves. At some point, the entire organization moves away from the engineering and people mindset to the KPI-factory mindset with poor decisions everywhere due to self-interest - leading the organization to become a worse form of IBM. It really is astonishing to me to see it play over and over. It is clear that the upper echelons of execs and board members and upper management don't care enough about the company to sustain a good culture.