The Intractable Problems
Hey!
Welcome back to another week of musings.
I went to Yosemite National Park with my wife for my birthday, and we had a great time! I also understood some of the John Muir quotes that people tend to mention.
"But in every walk with Nature one receives far more than he seeks."
I hope you had a restorative weekend as well!
Was this forwarded to you? You can subscribe here!
Things I enjoyed in the past week
- AI Coding Tools Underperform in Field Study with Experienced Developers. You may read about it if you're on social media more often than not, but this study shows there's a slowdown when using AI-based tools. I think it might be because we cannot achieve "flow", and instead we keep waiting for AI, which triggers a response to multitask.
- When the digital nomad dream turns sour, an article recounting the lives of neither holidaying nor living in the country, digital nomads are currently experiencing.
If you've been in a company long enough, you've likely noticed a set of problems that everyone knows about but don't get fixed, and that people build workarounds to keep being productive.
This set of problems doesn't fall neatly into the "squeaky wheel" category, which is more often than not solved relatively quickly. At our company, we used to keep a list of these issues under a wiki called "1000 Cuts". We kept this list up to date with things that nobody would fix for some reason. (This text is misaligned; these tests are flaky; etc) You get the idea.
Eventually, the number of issues became unmanageable (and over one thousand). People stop updating it, and it was demoralizing in a way because it's like we just keep accumulating problems, nobody's fixing them.
So it was seen as a big list of "losses".
Lost in the Noise
When you're in a start-up, focusing on the single most important thing and just getting more clients, achieving product-market fit. However, after a while, you eventually need to return to address some issues. A client may be large enough to tell you to fix something. However, once you're in a large company, all these lists of problems arise, and the PM will usually prioritize them against either acquiring new customers or retaining existing ones. If nobody in our customer base is complaining, then nobody takes a look at this, or if you cannot tell a story around revenue or keeping people on the site (for example, reducing churn).
It becomes a situation where many people are aware of it, and there's no owner. Some issues might be easy (move this one to the right, align this text to the center). Some of those. However, other problems might be of a vague type (we want to reduce latency, and build times take too long), and nobody owns those.
No-Owner or Committee Owned
What ends up happening is that if you have no owner or a committee that owns the problem, then it won't get solved. Why? Without an owner, there's nobody to take care of it and look after it. But if we have a community of people that care about this problem, nobody owns it. These sorts of groups of people discuss the issue and complain about the situation. Still, it's hard to make progress because nobody among them really feels the pressure to take action in terms of converting that issue into an actual plan.
The other thing is that nobody really wants to spend time outside of their usual work hours to fix something that might not even see the light of day, or something that nobody would notice, especially if it's hard to get promoted with these projects, etc.
What do we mean by intractable?
Let's say you pick a problem, and you say, "Hey, everyone, I care about this problem, and I want to make progress". However, halfway through, you realize you're missing some critical information about the system, or you need to ask other teams to take on additional tasks.
At other times, I see people volunteer to take on a problem, such as latency. But they come to realize a few things: the problem statement is vague, "we're slow", or there might not be enough data to analyze the issue (which pages are slow, funnel drops, etc), or they realize that they don't have the authority to ask for work from other teams.
They might be proactive enough to learn more about the domain, but what happens is that they become lost in the weeds of the problem and may forget halfway that they were trying to solve something.
What can we do?
If we care enough about a problem that nobody else seems to care enough to have progress, then sadly, what you need is more authority, even if borrowed.
You need to be at the intersection of domain knowledge of the problem space, authority, and genuine care about it.
Otherwise, you need to borrow authority, which means you need to dedicate time to making the issue tractable, i.e., take time out of your workweek or do a bit of extra work to come up with a plan, break it down, and so on. This is to present the case to leadership and obtain the necessary authority.
The complex piece is the effort you need to put in, and you might not get the borrowed authority in the end, because a leader, depending on the size of the organization, may have other people in a similar situation to yours, and they need to balance this. Finding issues that could share a solution is also beneficial for higher leverage.
Your turn!
Have you cared enough about a "non-important" problem to try and fix it? What methods have you used to address these issues? Let me know your thoughts by replying to this email!
Happy coding!
website | twitter | github | linkedin | mastodon | among others