Very much recognizable. But tbh, I don’t think Linear will help directly. It will help to visualize better and with less effort, but it only shows the issues that you described well. It’s the process that needs to change. IMO nobody should go directly to a single developer (though I’m that one most of the time…) It’s very easy to please, which will make it more easy for them next time, and less easy to say “not now” for you yourself. A well known pitfall….
Great insights on shadow work in engineering. The idea that much of this work happens behind the scenes and isn’t surfaced in tickets resonates with my experience. It would be helpful to see a short case study or metric example showing how lightweight tracking shifted priorities and freed up capacity. Do you have any practical tips for starting small without adding heavy processes?
Absolutely. I recently heard of an internal team that were performing around 65% of shadow work, which we refer to as shoulder tapping. All without a cost code, none of it getting billed and all of it contributing to the engineering team being “busy”. Solid infographic. I’m subscribing now.
A couple of points on the shadow backlog - 1. When reviewers comments are ignored multiple times with the delivery date as an excuse this can eat a growing amount of time - the codebase gets bigger and the same comments need to be made over and over sometimes you need a mandatory this does not go out the door until the review comments are fixed. 2. Static analysis and CI/CT can, if used correctly save a lot of time - especially if tools like pre-commit are used. These tools can remove a lot of the pain from reviews, (by forcing the developers to fix the issues before review), and can act as an independent, unbiased, metric for quality barriers, (maybe stiles would be a better word). Having had another developer complain to HR that my review was picking on him (and later finding out that a previous review of the same code a year earlier had raised word for word the same issues but from a different reviewer) - I can say that having such metrics can be vital.
Very much recognizable. But tbh, I don’t think Linear will help directly. It will help to visualize better and with less effort, but it only shows the issues that you described well. It’s the process that needs to change. IMO nobody should go directly to a single developer (though I’m that one most of the time…) It’s very easy to please, which will make it more easy for them next time, and less easy to say “not now” for you yourself. A well known pitfall….
Great insights on shadow work in engineering. The idea that much of this work happens behind the scenes and isn’t surfaced in tickets resonates with my experience. It would be helpful to see a short case study or metric example showing how lightweight tracking shifted priorities and freed up capacity. Do you have any practical tips for starting small without adding heavy processes?
Good question, I'll see if I can dig something like that :)
Absolutely. I recently heard of an internal team that were performing around 65% of shadow work, which we refer to as shoulder tapping. All without a cost code, none of it getting billed and all of it contributing to the engineering team being “busy”. Solid infographic. I’m subscribing now.
Thank you! Yeah, 65% is quite extreme
Pubic sector :-) Perhaps I should have said cross-charged rather than billed.
Love this!! Would love your thoughts on some of my stuff, follow me back I could DM you?
Where do you AI helping here, making the invisible visible. Or at least findable.
I’m thinking about recording and transcribing every on call meeting, on calls just thinking out loud, etc.
Great post!
A couple of points on the shadow backlog - 1. When reviewers comments are ignored multiple times with the delivery date as an excuse this can eat a growing amount of time - the codebase gets bigger and the same comments need to be made over and over sometimes you need a mandatory this does not go out the door until the review comments are fixed. 2. Static analysis and CI/CT can, if used correctly save a lot of time - especially if tools like pre-commit are used. These tools can remove a lot of the pain from reviews, (by forcing the developers to fix the issues before review), and can act as an independent, unbiased, metric for quality barriers, (maybe stiles would be a better word). Having had another developer complain to HR that my review was picking on him (and later finding out that a previous review of the same code a year earlier had raised word for word the same issues but from a different reviewer) - I can say that having such metrics can be vital.