3 ms·

The problem with "we all do this sometimes" is that no team ever gets to 75% of their backlog. And no manager is able to justify spending the extra few days to

by dcow 6y ago

The problem with "we all do this sometimes" is that no team ever gets to 75% of their backlog. And no manager is able to justify spending the extra few days to automate something correctly or "get it right" because there's always pressing product work to do. I've found it to be much more practical that the team lean into each other's strengths than to fool themselves into thinking you'll ever see "infrastructure automation and fix flaky tests" as the mantra for a few sprints. I guess a well oiled team could rotate positions around but then you tend to lose a coherent vision of what "right" is in any given domain because you don't have domain experts anymore since everyone has to be an omni-tool.

majormajor 6y ago
> And no manager is able to justify spending the extra few days to automate something correctly or "get it right" because there's always pressing product work to do. Product people aren't reviewing your code and infrastructure. The manager is responsible for the speed and quality of their team's delivery, so if they have the team devote some time to polishing their tools, they're just using their professional technical expertise to keep things running smoothly for the product folks. They do need to be good at it - not overseeing a bunch of feel-good but not-actually-that-useful rewriting and cleanup - but that's a question of competence more than responsibility. It's a very similar thing with rotating people. A manager is going to get into trouble sooner or later if they only ever have the same people work on the same systems. It's the short-term optimization, but not the long-term one. And that doesn't mean nobody can be an expert in an area, but it's bad if only one person is able to work in that area. A company that wouldn't let a technical manager make the call on that - who works on what, and how much to attention to pay to their tools - may as well have the devs report directly to the product manager. The manager has to stand up for that and not just be steamrolled.
bkor 6y ago
> And no manager is able to justify spending the extra few days to automate something correctly or "get it right" because there's always pressing product work to do. As-if the business side of things has any idea of how long something will take. Refactoring or doing some infrastructure work can just be tagged together with some other bits. For the business side of things it's more important to know when things will be ready and knowing that timeline. Further, a manager can explain that e.g. "the car needs maintenance". Business isn't against such things, but if the manager cannot switch from IT-speak to business language then it might seems that the business side won't get it.. but maybe it was the explanation that was lacking. Especially in sprints I noticed that it's understandable to everyone that not everything is finished in one sprint. Though if it happens to often, maybe just promise less.
- dcow 6y ago
  I know. I believe these things should be possible in theory. I rarely see them in practice. I attribute this to a unilateral lack of discipline.

by dcow 6y ago

majormajor 6y ago

> And no manager is able to justify spending the extra few days to automate something correctly or "get it right" because there's always pressing product work to do. Product people aren't reviewing your code and infrastructure. The manager is responsible for the speed and quality of their team's delivery, so if they have the team devote some time to polishing their tools, they're just using their professional technical expertise to keep things running smoothly for the product folks. They do need to be good at it - not overseeing a bunch of feel-good but not-actually-that-useful rewriting and cleanup - but that's a question of competence more than responsibility. It's a very similar thing with rotating people. A manager is going to get into trouble sooner or later if they only ever have the same people work on the same systems. It's the short-term optimization, but not the long-term one. And that doesn't mean nobody can be an expert in an area, but it's bad if only one person is able to work in that area. A company that wouldn't let a technical manager make the call on that - who works on what, and how much to attention to pay to their tools - may as well have the devs report directly to the product manager. The manager has to stand up for that and not just be steamrolled.

bkor 6y ago

> And no manager is able to justify spending the extra few days to automate something correctly or "get it right" because there's always pressing product work to do. As-if the business side of things has any idea of how long something will take. Refactoring or doing some infrastructure work can just be tagged together with some other bits. For the business side of things it's more important to know when things will be ready and knowing that timeline. Further, a manager can explain that e.g. "the car needs maintenance". Business isn't against such things, but if the manager cannot switch from IT-speak to business language then it might seems that the business side won't get it.. but maybe it was the explanation that was lacking. Especially in sprints I noticed that it's understandable to everyone that not everything is finished in one sprint. Though if it happens to often, maybe just promise less.

dcow 6y ago
I know. I believe these things should be possible in theory. I rarely see them in practice. I attribute this to a unilateral lack of discipline.