No matter how many lines of code we’ve coded or architectures we’ve designed, we occasionally get push back on changes we suggest. Usually this comes in the form of a statement such as “oh, that’s just a simple matter of programming, huh?” For those uninitiated, a Simple Matter of Programming (SMOP) is a phrase used to ironically indicate that a suggested feature or design change would in fact require a great deal of effort implying that the person proposing the feature underestimates its cost. We occasionally joke with teams about how long a change will take but we admittedly don’t know the system well enough after a couple days to provide estimates. Even teams with great engineers get estimates wrong more often than not. However, what we do know from lots of personal experience and having worked with over two hundred companies, are orders of magnitude and what things should be considered difficult and what things should be easy.
It is common for a company to think that splitting their systems into swim lanes or partitioning by the Y or Z axes would be incredibly difficult until we walk them through the logic of how to make the changes. Certainly these logical steps are a far cry from actual code changes but most of the time companies “get it” and before the day is over start agreeing that the changes are reasonable.
An exception to this occurred recently where a non-technical manager made the obligatory SMOP comment and then continued to resist our suggestions on how the changes might be accomplished. The engineers in the room “got it” and you could see them nodding in agreement about how changes could be made but the business leader refused to acquiesce. In the end this organization will not make the necessary changes to scale and will likely limit their future value because of this.
To me this makes the point about mindset. I learned during college that I could convince myself that a subject matter was easy and I could learn it quickly (programming) or that it was impossible and I was no good at it (foreign language). The difference wasn’t the difficulty of the subject matter but rather my mindset regarding each topic. Your organization is the same way and if you’re the leader, your teams take their cues from you about how easy or hard something is going to be. This isn’t a recommendation that non-technical business leaders make estimates for feature development but rather that you maintain an open mindset about situations and challenges. Sometimes the greatest revelations come from the darkest hours and what seemed impossible was a key differentiator that made all the difference.
Resist the urge to SMOP someone’s idea and be open about changes. Approaching things as an individual and an organization with an open mindset will benefit you immensely.