A person fixing issues is generally valued more than someone who is anticipating them before hand — or better — anticipating them early enough to not introduce them into the system itself. It’s because the latter is very hard to measure.
That means me doing a lousy job at building something can pay someone else’s salary who later fixes it. My incentive in turn, is also to only fix issues and it is a vicious cycle. I’m not thinking of building solutions that make the problems irrelevant.
Is there a better way around, than actually fixing them? Yes, to disrupt the problem. To make it irrelevant.
Sounds familiar? Not in the domain of fixing a company’s software. Or maybe think again. Disruption redesigns systems. Only these systems are at a human level. They change society. They make entire industries irrelevant.
Similarly redesigning a company’s systems can disrupt the existing problems. A popup window being bug prone and having compatibility issues. But hey, does that popup window even need to be there?
Isn’t redesigning bad, you say? You wouldn’t redesign the wheel. But that’s where the misunderstanding lies. You would not reinvent the wheel, but you could redesign a particular aspect of your factory’s gear system.
Design is thinking. And when you think about something deeply, you ask questions. You think how. You think what. You even begin to question why.
Rethinking might not mean doing it all over again it means understanding what you already have and appreciating what works and what doesn’t. Then you attempt to amplify your understanding.
You improve the essentials and discard the inessential. Note, this is different from fixing issues, because fixing issues only involves the knowledge of the issue itself.
So next time you see a problem, wonder does the problem even deserve to exist. Fixing an issue in the system is like applying patches. Till when?