Long Term Goals
Hey!
Welcome back to another week of musings.
I hope you had an uneventful weekend. Welcome to baseball season! I'll be going to the stadium today.
Was this forwarded to you? You can subscribe here!
Things I discovered in the past week
- How to use value stream mapping to improve software delivery, this post is a good introduction to the value stream mapping exercise.
- Distrust Breeds More Distrust is a good post about why building trust is an important responsibility of a leader.
If you've been at a company long enough, or even if you've just joined and the company has been around for long enough, you'll either think or hear about how something should be fixed for the long term.
It can be things like the test suite taking too long, we should be releasing more often, or we have too many microservices, or our reliability is dropping. In many of these cases, someone might have tried to fix it somehow in the past but failed.
What is causing this issue?
Issues are sometimes complex, and no single root cause can be found. But generally, there's a large driver for the problem. For example, long test suite runs could be things like they're running serially, or one test depends on another, etc.
Is it getting worse?
With things like too many microservices, it might be getting worse over time. Other times, it might not get worse, but it also won't get better, e.g., when we cannot release more often; in this case, it is getting worse.
How much time do we have?
If it's worsening, how much time do we have for the show-stopper?
The time left will help us determine whether to defer or act. In many cases, these issues are not the "squeaky wheel," not urgent, and often not that visible. Leadership might ask why we must fix the build if we see new features coming on time.
We need to figure out a way to track this issue. We also need a plan or options to solve it if we defer.
One thing I've seen happen with deferred problems like the above is that no one tracks them, and we start deferring everywhere. Then, your databases are out of date when the log4shell issue is found, and you're trying to deliver your most ambitious feature.
Are we done, done, or done done done?
I heard this idea of "done, done, done" from this podcast. Still, in general, it means that we're "done" if we fix an immediate issue, we're "done done" if we fix the issue, and it won't come up again in the immediate future, and we're "done, done, done" if we never have to think about this as a problem again.
There are at least two solutions for important vs urgent: Immediate and fixing it for good.
In the case of microservices, you might enact a rule that says, "No more microservices can be created," or you might embark on a re-architecture journey and train to create more coarse-grained services, thus reducing the footprint overall and for the long term.
How do we talk about this?
As we become more senior in our roles, we must identify these issues and become accountable for scheduling and fixing them.
Aside from being a thankless job, the problem is that it's often hard to schedule them as they don't seem important right now. You'll need to become better at articulating why these problems matter, regardless of the type of solution. It would be best to have a succinct message with a monetary comparison. For example, "If we keep adding microservices at this rate, the cost of operations will double the revenue in 2 years".
Your turn!
Have you ever tried fixing one important but not urgent problem? Tell me how it went. Let me know by replying to this email!
Happy coding!
website | twitter | github | linkedin | mastodon | among others