Beginnings and Roadmaps
During the weekend, my mom returned home after spending three weeks with us. Yesterday I wasn’t feeling in a writing “mood,” but I wanted to keep to my promise of weekly writing practice, so here we’re!
I hope this writing doesn’t sound too uninspired, but I still think that’s life, especially if you’re trying to record thoughts week over week. I don’t know. Let me know how you feel about pushing through this sort of “rut” we find ourselves in from time to time.
As we start this new year, the team has been working on the year goals, alignment of OKRs, and all that jazz. Interestingly, it always makes me go into these introspection moments, but also, I’m not too fond of the whole rush to deliver the goals, feels like a juxtaposition.
During these reflective moments, I was thinking about how to avoid these “headless chicken” situations. Stumbling to work through all the documentation required to present, be reviewed, and approved.
Working in an enterprise has these moments of questioning why this process exists in the first place. Are we getting benefits that are tangible to individual contributors or edge managers?
Also, imposing most (or all) of the burden on managers to research, define, and present documentation of what they want to achieve in an arbitrary time frame.
The most challenging thing for me becomes as we embark on the journey that is a year, situations come up, and there’s no additional capacity to take on new things because we have “aligned” all of the people to this year’s goals.
Linear roadmaps are misleading without a crystal ball for seeing the future. A roadmap that recognizes the existence of risk as time goes on is more honest. But an effective PM needs to anticipate possible branches, too - and create clear criteria for following each path. pic.twitter.com/4InTKNGEsp
— Pavel Samsonov is also on Mastodon 🐀 (@PavelASamsonov) August 21, 2020
And not new in the sense of chasing shiny new objects, but events, like Log4j, general incidents, people leaving, etc.
Another dimension that makes it hard for our teams is that, in some cases, the chosen programs are bets that the company wants to embark on, and if the chance is not working during the year, then we discard it.
But in some (or most) cases, the teams have a limited pool of projects in the backlog because of the heavy lifting of documentation required to get approval.
So you’re one program down, and the people assigned get moved toward other programs. So as with any metric, teams may try to game it out of fear of losing people. Or go through with the program to ensure they succeed in their goals even if the bet is not paying.
The progressively detailed roadmap item
— John Cutler (@johncutlefish) May 22, 2022
no need to go deep until the last responsible moment pic.twitter.com/Z8RyObCSxG
As always, there’s ambivalence on these exercises at the end/beginning of a year. On the one hand, we want to focus and work to deliver the best customer outcomes. Still, on the other hand, it is less about experimentation, measuring, and iterating and more about trying to imagine a future where we succeed and everything works.
Please let me know what you think about roadmaps and planning in general.
Happy coding!
website | twitter | github | linkedin | mastodon | among others