Are we our own limits?
Hey!
Welcome back to another week of musings.
This was a slow weekend for me; I read a bit and journaled a bit more. Sometimes it's good to do nothing. I hope you had a wonderful weekend.
Was this forwarded to you? You can subscribe here!
Things I enjoyed in the past week
- The Enterprise Experience: A quick post on what the author has learned from working at a large enterprise for the last year.
- Easy will always trump simple: strive for simplicity, but keep in mind that easy will win if we don't have intention.
- I've been reading the poems of Alejandra Pizarnik, but I don't have a favorite yet. Took me long enough to discover her.
I've been searching for what is stopping us from delivering projects faster.
This search has been inspired by reading the book Move Fast and Fix Things by Frances Frei and Anne Morriss*. I'm not following their guide, so I'm currently tracking down problems, but keeping in mind to take action based on what I find.
The Usual Suspects
If you work in a relatively large organization, you'll find some common issues like:
- Not enough people
- Too much "Running the Business/Keep the Lights On (RTB/KTLO)" work
- Too many meetings
- Too many changing priorities
- Too many production fires.
I won't go too deep into each of these; some, like having more people, might seem useful at face value, but you can have too many people, and they would get bored and find other jobs, or start re-inventing the wheel to find stuff to do.
The Interesting Suspects
Other types of issues I encountered were people clinging to problems they had "solved" in a way that fixing them would undermine their productivity.
For example, there's a system that tracks that everyone is assigned work (i.e., tickets in Jira), and that's what everyone does, even if the work is not being done or completed within a sprint.
Another example is that every production change needs to be tracked. Instead of building a tool to track the updates of application secrets, they're tracked as part of the application release process, effectively piggybacking on that process. Therefore, "releases" need to be further categorized if we want to know what was released in a given month.
The Attachment
In many cases, people have sunk costs into the way they solved the problem.
I don't blame them; if anything, they played within the rules and managed to keep productive under pressure to deliver. But is your organization willing to take the productivity hit if we choose to solve the problem differently?
At other times, people fear that changing or even removing a process would affect their role in a meaningful way. What would I do if I didn't fix this piece of infrastructure daily?
Or thoughts like, I don't want to introduce this solution, because it would mean I'll have to dedicate a percentage of my team's time to managing it.
Your turn!
Have you thought what it would take for your team to deliver in half the time? Or solve production incidents in half the time? How to reduce the number of incidents in releases? Or have you never thought about this at all? Let me know your thoughts by replying to this email!
Happy coding!
*This post contains affiliate links. If you click on a link and make a purchase, I may earn a commission at no extra cost to you
website | twitter | github | linkedin | mastodon | among others