How to get more engineering focused work on the roadmap?
The product managers in my org are pretty ambitious, and that, combined with the fact that we're a startup, leads to a lot of feature work. However, I wish we had more time to do engineering-oriented efforts like refactoring, adding automated tests, and others. The PMs say they want to do it, but this work never seems to be added to the sprint - Any ideas on how I can close this gap and get these types of projects added?
Discussion
(2 comments)- 2
2 years agoStaff SWE at Google, ex-Meta, ex-AmazonReserve 10-20% of the team’s capacity for this and PM doesn’t choose which tasks that uses, engineering does. If that doesn’t work and it is hostile and not collaborative, there are back doors like inflating estimates and sneaking the tech debt pay down in, or tying certain features to certain improvements because they are “tipping point” things that will take a bad module and make it totally insane without a refactor.
If there is an organizational resistance to investment in code health, it can be hard to prove the value. If you can demonstrate degrading velocity, maybe it will help. If you can show bug counts climbing, maybe it will help. This really does require a lot of sales, framing, and digging deep to find supporting data.
- 12 years agoRobinhood, Meta, Course Hero, PayPal
First, I recommend the following 2 discussions, which talk about making a case for these kinds of projects (perceived lack of impact is the most common cause behind this kind of work not getting traction):
- "How do you convey impact for non-product, technical efforts like adding tests and fixing crashes?"
- "What are the heuristics to plan the projects for the better engineering work stream?"
Something important to realize is that at a startup, these kinds of efforts are often times far from the most impactful thing you can do. I can totally understand the urge to write clean code and use great frameworks (I am one of those "relentlessly polish everything" type of engineers), but there are many times where you have to suppress that urge - It's important to be open to that possibility.
A middle ground can be doing incremental polish here and there, cleaning up the code in small to medium sized commits as you're doing feature work. This is something I talk about in-depth in this Q&A from a Microsoft engineer. Historically, I have found engineering responsibility work to be much more powerful when it's woven into feature work as opposed to being this completely separate thing that needs additional bandwidth. If you really want to make room for this, you can add a 10% "responsibility tax" to every task you estimate, so you have that extra time to improve code along the way.
+1 to everything Lee said as well - He's spot on as always. The most obtuse approach would be to add a ton of buffer to all feature work estimates so in every sprint, you accomplish all the agreed upon work 2-3 days early. You then use those 2-3 days to get in your engineering-focused work.
