The Easiest Way to Not Do Something Is to Discuss?It
If you want to suffocate innovation and progress, keep on?talking.
Just do it.
Plan?—?Do?—?Check?—?Act.
Observe, Orient, Decide, Act.
There are tons of slogans, frameworks, and motivational quotes that promote action. Nevertheless, the business world is still full of talkers who talk, rather than doers who do: If you don’t want to do something, there is always a way out by initiating a huge discussion.
Some Real-Life Examples
Here are some real-life examples I experienced many times over in my daily entrepreneurial grind.
Monster Solution Rather Than Phased?Approach
How many times have you experienced a discussion about a solution that needs to fulfill hundreds of requirements, and solve the problems of dozen of stakeholders?
Irrespective if we are talking about an RFP, an internal project plan, or a new cool feature for your SaaS solution, people tend to over-specify solutions. And the more stakeholders you involve in the specification, the longer the discussions take. For every new stakeholder you add, somebody would rather discuss an additional aspect of the monster solution than take the first step of implementing the solution.
Start. A small first step is so much better than discussing aspects that maybe matter down the road.
That’s why I usually say, “Let’s cross the bridge when we get there.”
My colleagues probably hate me for it, but I’m convinced it is the right way to go.
Data Model Refactoring
In software engineering, the concept of refactoring means rebuilding existing functions in a better, more performant, more secure, and more scalable way. Refactoring is a common and necessary aspect of keeping software up-to-date in today’s fast-moving world.
However, when people start talking about data model refactoring, raise your eyebrows. Many times have I heard, “The new data model will make everything easier and better”, or even worse, “We can’t build that feature before we have refactored the entire data model.”
Refactoring an entire data model is like discussing a monster solution. That’s why we have chosen the approach of gradual refactoring. Whenever we build a new feature or improve an existing feature, we work in two phases:
In this way, we refactor things rather than only talking about refactoring. Albeit we might refactor in smaller steps.
Procurement, Legal and IT Come?Last
Let’s go back to the monster solutions described above. For the sake of the argument, let’s assume we finally, finally agreed with all the stakeholders and can start working on implementing the solution.
Enter procurement, legal, and IT. In large organizations, those players always come last, and rest assured they have yet another plethora of inputs, questions, and (non-functional) requirements.
领英推荐
Just when you thought that you have finally, finally finished discussing and could start doing, life throws a new challenge at you.
Ways Out of The?Trap
In today’s macroeconomic environment, we don’t have the time and resources to keep discussing endlessly. So how can we get out of the trap?
Phasing the?Monster
This is my biggest learning from years of working with large organizations. Instead of going for the all-encompassing “large-scale solution”, I’d heavily recommend going step-by-step. Some people call such an approach agile, modular, phased, or whatever.
It doesn’t matter. It only matters that people really go step-by-step and don’t just talk about going step-by-step.
The best way forward is often to start with a limited proof-of-concept (POC), and then gradually expand the solution from there.
Or to have the courage to stop after the POC, if the results show that the solution doesn’t deliver value.
Slashing Regulation
In large organizations, there are tons of internal and external regulations, telling people what can be done and what cannot be done.
Let me share a secret: The more regulations there are, the larger the probability that some of those regulations contradict each other. And as soon as regulations contradict?—?guess what?—?discussion emerges. And discussion is the enemy of action.
So I would suggest slashing as many regulations as possible, for the sake of achieving timely solutions rather than endless discussions about regulation.
One particular aspect to take into account is procurement regulations when you are following a POC / phased / agile approach. Many large organizations have pointless regulations prohibiting or complicating a phased procurement. Which leads to unnecessary discussions instead of action, of course.
Accepting To Do Things?Twice
This one is the most important lesson. Doers do, talkers talk. But when doers do, doers make mistakes. And doers draw learnings from POCs and first phases, which need to be taken into account for the second step.
Quite often, this means doing things twice. Whilst this might sound counter-productive, it is much more productive than contemplating the perfect solution forever: Because there ain’t no perfect solutions, but there are tons of good solutions that can be implemented fast and improved later.
Growing a company ?? in uncertain times ???? is like running a marathon?—?it demands grit, strategy, and resilience.
As a tech entrepreneur ??, active reserve officer ??, and father of three ??????, I share practical insights and experience on entrepreneurship and resilience in The Resilient Entrepreneur, my weekly newsletter.
When I’m not solving problems, I recharge and find inspiration in the breathtaking mountains ??? around Zermatt ????.
Subscribe to my newsletter The Resilient Entrepreneur for actionable insights?—?delivered every Friday afternoon!