I appreciate that this is long. You may have hopped on with your morning coffee, hoping to take in a few memes and hot takes before getting to work for the day. Then this monstrosity shows up.
Based on my beta readers' feedback of "too long" I've added things like a 2 minute summary at the top to try and let you know what you're in for, and a table of contents (sadly not working. it will when I republish on github) to hopefully let you skip to the bit that you're interested in.
You definitely don't have to read it all, especially as a front-line engineer but the leadership justification part is in there based on the pushback and "pressure testing" I've seen from people up and down the org chart.
As much as this IMO is an incremental shift in direction that should fit within a "normal" modified agile/scrum workflow, If you think about the cost of hopping onto a new workflow there's risk.
We're talking about an expensive bet here. Realistically your teams aren't going to know that this works for a quarter to a half. A long term shift in the way you do things takes time to sink in.
Costing out that bet on a team of 4 engineers an EM, PM and, Designer we're looking at say $20k/week/employee or between $2 and $4 million. You can fiddle the numbers around here since they're likely not going to get _nothing_ done but you get the idea.
Scale that to an organization and ... well it's a lot.
If leadership is going to allow you to adopt a whole new way of doing things, you're going to need a lot more rigour than just "trust me bro"
The size of the article in that respect is a feature, not a bug.
Leaders can hop off the train when they're satisfied that it's worth a try. The engineers can jump to the "just tell me what we're doing" bit.
I hope you read it all, have a robust discussion and really pressure test the ideas so I can refine the process. I'll take your accolades and your angry criticisms with equal excitement
(please be nice though, I really did try hard here).
alexc05•6mo ago
I appreciate that this is long. You may have hopped on with your morning coffee, hoping to take in a few memes and hot takes before getting to work for the day. Then this monstrosity shows up.
Based on my beta readers' feedback of "too long" I've added things like a 2 minute summary at the top to try and let you know what you're in for, and a table of contents (sadly not working. it will when I republish on github) to hopefully let you skip to the bit that you're interested in.
You definitely don't have to read it all, especially as a front-line engineer but the leadership justification part is in there based on the pushback and "pressure testing" I've seen from people up and down the org chart.
As much as this IMO is an incremental shift in direction that should fit within a "normal" modified agile/scrum workflow, If you think about the cost of hopping onto a new workflow there's risk.
We're talking about an expensive bet here. Realistically your teams aren't going to know that this works for a quarter to a half. A long term shift in the way you do things takes time to sink in.
Costing out that bet on a team of 4 engineers an EM, PM and, Designer we're looking at say $20k/week/employee or between $2 and $4 million. You can fiddle the numbers around here since they're likely not going to get _nothing_ done but you get the idea.
Scale that to an organization and ... well it's a lot.
If leadership is going to allow you to adopt a whole new way of doing things, you're going to need a lot more rigour than just "trust me bro"
The size of the article in that respect is a feature, not a bug.
Leaders can hop off the train when they're satisfied that it's worth a try. The engineers can jump to the "just tell me what we're doing" bit.
I hope you read it all, have a robust discussion and really pressure test the ideas so I can refine the process. I'll take your accolades and your angry criticisms with equal excitement
(please be nice though, I really did try hard here).
Feel free to reach out directly!