Early in my career, I have heard it many times personally and have given the admonition to my staff many times as well — be solution oriented! And the logic of that advice seems sound. We can be bombarded by so many problems in our work day that another problem being thrown at us is enough to throw us over the edge! We want perfect employees who simply come with solutions all the time to every problem.
We are trained to jump to conclusions (solutions).
This sounds great! The nirvana of the workplace. Unfortunately, for any complex organization, the premature jump to solutions is the cause of a great deal of waste and inefficiency.
How many times have your project requirements come in the form of a solution? How often do your business customers present you with the solution that they want you to implement, clothed in the wrapping of a ‘system requirement’? And when you invest the time, money and effort to deliver the said requirement, it didn’t actually satisfy what the business wanted in the first place.
But those are traditional waterfall problems you say. In our new world of Scrum, Kanban, SAFe, agile and lean principle-driven delivery models, certainly we have solved these issues?
This is not a methodology problem.
Unfortunately no.
In our rush to get things done, we can succumb to the rituals of Scrum (or pick your favorite delivery method) and create user stories that are simply an articulation of a solution or worse yet, a task to be completed. Reading through the user story you have no clue of what you are actually trying to solve. But you have the solution in intricate detail. Disguised as requirements or acceptance criteria of course.
In our conversations with one another, we can quickly get into inflammatory debates and arguments over whether the solution is the right one. Tempers flare and the wars begin on the elegance of the solution, whether or not it meets standards, disagreements of whether the solution is suitable, etc. We can be in arguments where we are not even sure what we are arguing about!
Ironically, the solution to this is to not be solution-oriented but to be problem-oriented.
As a leader, throw the team the problem for them to solve. That’s it. Simple. Resist the temptation to solve the problem and hand it down to the team.
Understand the problem. Articulate it clearly. Then have the team members who are directly affected by the problem swarm the problem together and come up with the solution.
Fundamentally, that is the DNA of a healthy, self-organizing workplace. Scale that practice in everything that you do.
A user story needs to outline the problem to be solved. Then the team pulls in the user story and works through the solution to the problem, thereby fully owning the resolution of the problem.
A conflict needs to start with the problem statement. Then the directly impacted team members work through the problem and solve it. Together. They jointly own the resolution of the problem. Since they are impacted by the solution, they should be the ones to determine the solution.
If this is so obvious, why aren’t we doing it?
Common sense, isn’t it? Understand the problem to be solved and jointly own the resolution of the problem.
In the demanding pace we encounter daily and the rush to get things done, we are tempted to just get the next urgent problem off of our plates. We are enticed by the quick solution. We jump to conclusions, isolate one another and spend so much time facing the consequences of skipping the necessary steps.
We have to slow down to speed up.
Conclusion
Be problem-oriented. Swarm it. Solve it. Watch your workplace thrive to new levels of throughput, velocity and harmony.
About Me
I’m Ken Akai, a Delivery Jedi. I am deeply passionate about application delivery and building high performing teams.
