The 20% that matters
Hey!
Welcome back to another week of musings.
I’m writing this using the airplane WiFi, hopefully it worked as you’re probably reading this. After a hectic week, I’m back home ready for Thanksgiving.
Was this forwarded to you? You can subscribe here!
Things I discovered in the past week
- I’m completely absorbed by 2666 by Roberto Bolaño. Look it up if you’re into that kind of literature.
- Not exactly a discovery, but I keep being amazed on how much Reflect notes aligns with my note-taking style.
I remember reading in Twitter that in large companies 80% of decisions don't matter, and as I've had to deal more and more with management and leadership, I think I arrived at the same conclusion.
This is especially important if you're doing large projects, and cannot really lose time over all details, and instead you need to create trust with people doing the work. If the choices were fatal, the "system" wouldn't allow them to happen or correct them with a sense of urgency.
Outcomes matter
I tend to care a lot about the details, at the beginning of my career I used to lose my cool over people choosing the "wrong" solution.
In practice this didn't matter because the solution was delivered, and the outcome was achieved but overtime the cost came back to bit us in the form of maintenance of a service nobody knew how it worked, or the original teammates left, etc.
If the outcome couldn't be achieve within certain parameters (e.g., timeline) then the solution would be a no-go from the start, or maybe too out there from a technology standpoint (e.g., we only use RabbitMQ, and you want to introduce Kafka without a good reason).
We shouldn't sweat the small stuff, and at big companies, like 80% of things are the small stuff.
Important vs Urgent
Sadly, the more you go up, the more people will bring you urgent problems. Or “escalations” because something is not being solved fast enough. And while it might be clear for you what’s your 20%, urgencies will come and you’ll have to react to them. Part of only choosing to 20% is having the bandwidth to take on these urgent tasks as they arise.
it’s like dev teams, you don’t want to allocate their 100% bandwidth, because there are always escalations or urgent bugs to fix.
Be effective
Another aspect of getting better to finding the 20% that matters is a good usage of your time. Not everything has to be solved by you, sometimes you have to report an issue (or create a ticket, etc) and let the process solve it.
More than finding the 20% that matters, my main pain point has been being able to let go of these tasks I care about. What has helped with letting go has been building trust with engineering managers to know who has follow through and who doesn’t.
Your turn!
Have you ever thought you’re working on the most important topics? How you choose what matters at a given point in time?
Happy coding!
website | twitter | github | linkedin | mastodon | among others