Author: Peter Round
The Statement
Slowing down can help teams achieve better (and often faster) outcomes in data and analytics. This is similar to racing, where a smooth and calm approach usually leads to quicker results.
The Go-Kart Moment
When racing go-karts, it’s easy to fall into the trap of believing that feeling fast equates to going fast. This often leads to overly hasty reactions, entering corners too fast, braking late, over-correcting, and fighting the kart throughout the race. From an outsider’s perspective, it looks messy and slow, even though it feels thrilling and intense from the driver’s seat.
A powerful question from a coach always stood out: “Does it feel fast or slow out on the track?” Almost every time, it felt slow and relaxed (like sitting in an armchair while the track flowed by). I found those were the laps when I recorded the fastest times. I was quickest when it felt effortless.
From Track to Tech
The same pattern appears in software or data engineering and business intelligence work. When teams feel like they are racing, jumping straight into tools, writing complex transformations, and rapidly creating dashboards, they often end up generating rework, misunderstandings, and technical debt. While it feels productive in the moment, delivery slows down later when defects, confusing logic, and missed stakeholder needs emerge.
When development feels calm and almost slow, something valuable is happening. Teams are investing time in understanding processes, clarifying user problems, agreeing on definitions, sketching data flows, and verifying assumptions with the intended users of the products. Although this work may seem overly simple, it tends to lead to cleaner solutions that are easier to maintain and can be more quickly extended in future iterations. The focus is on building the right thing in the right way!
What Slowing Down Looks Like
In practice, slowing down within BI and data teams might involve:
- Spending the initial phase shaping the question, planning, and refining processes instead of immediately jumping into tools. Technology should never come first.
- Pairing up on models before developing visualisations to ensure the data is clear and tells a compelling story.
- Establishing clear acceptance criteria and definitions by delving into essential use cases with stakeholders. Asking someone what they want is different from exploring their pain points or aspirations. It’s crucial to find the underlying “why.”
- Building simple versions initially and validating that they address the question or problem effectively, allowing teams to make quick adjustments through quick and constant feedback loops.
These practices rarely feel thrilling and exciting, and some stakeholders might shout ‘Just get on with it’ but what is ‘IT’? These practices quite often resemble that relaxed lap in the kart where everything seems under control, and nothing feels forced, yet the stopwatch reveals a different story.
Invitation to Reflect
I invite you to consider how this concept is reflected in your experiences. When have you seen a team in data or analytics (or software engineering) slow down to genuinely accelerate the progression of a solution, not just in the initial sprint?
What did that look like in practice?
If you are looking for assistance with your Data & AI projects, contact our friendly team for a no-obligation dicussion HERE