In my role I spend a huge amount of time on peer reviews and design reviews. Recently I had the privilege of being able to do design reviews for some interns who are here for summer internship. It was a ton of fun because here are people with fresh new ideas and fresh new perspectives, getting an opportunity to showcase their skills and learning. 

In this particular case, this was more than just assessing and critiquing; this was also trying to coach and guide them for their future careers. As I was talking to the interns, I realized I was preaching a similar lesson over and over. This lesson was, “Plan to be wrong”. I don’t necessarily mean that your code is broken or wrong, just that it is going to have to change. At some point your customer or user is going to look at what you’ve delivered and say, “No, that’s not really what I wanted.” So it’s not really that your solution is wrong, but more like be prepared to change it.

And I realized, what a great engineering lesson this is! It’s really all about agility, that you should plan your work to be small incremental changes that are easy to change. At some point your customer is invariably going to say, that’s not really what I wanted. So if you’re building a capability as a piece of code, be prepared to be able to change that code later quickly and easily. Be able to adjust the workflow or function. So this means write your code to be loosely-coupled and modular. Always have comments and hooks. Always have documentation that explains how to change something, add something, remove something, redeploy something.

So later that night I was sitting on the couch eating cookies and I suddenly realized, this concept can actually be applied at a greater level than engineering. This applies to business and management as well. (In addition to design reviews) I spent a large amount of my time doing strategic thinking and planning. Thinking about such things as trying to figure out what our strategic vision is, what our goal is, what our “north star” is, and then making actionable decisions on what we should be doing next. How to structure teams and organizations and processes that move towards that north star. And once I had that sudden realization, I saw how the same principle applies. I was spending a lot of time really focused on trying to “get it right” in the decision making. Instead, plan for it to be wrong. Plan for change. Plan that whatever actions you take to point towards that north star, that the direction will change and you will have to pivot. For example, can you teams change the project they are working on quickly? Can you shift to a new technology stack or paradigm? Can they train for a new skill or platform?

This now comes into play with all the strategic decisions and actions you take. Are you hiring a team of complementary diverse skillsets? Are you giving people time to train and learn new things, or even do non-structured exploration and research? Do you allow your teams to make decisions locally and adjust and pivot? Are you REALLY listening to your customers and figuring out both what they want but also what they need (and what they WILL need, 1 year, 2 years, or 5-10 years from now)?

Once you come to the realization that whatever you are doing is wrong and will need to change in 6 months, not only does it affect your strategic decision making, but also can relieve some risk because it means you are able to pivot if you’ve made a wrong decision.