We started Socratic because we were tired of engineering feeling like a black box.
We wanted to understand things like how well work was flowing, who was underwater, when work might finish, and what needed our attention.
Simple, essential stuff. But strangely, it was never easy. It was always a snarl of scripts and queries and manual data collection, then massaged into a slide or spreadsheet. The best “data” we could offer were charts showing the “velocity” of an invented unit of measure called “story points”, which were… well, it doesn’t matter. No one ever really knew what they were.
So. Our choices seemed to be:
a) Learn to love inertia. Keep on writing JQL statements and Python scripts. Keep on spreadsheeting roll-ups and reports. Hope that one day this would all magically, finally, produce more light than heat.
b) Start fresh. Simplify. Create the ideal views of work, then use machine learning, joined to our systems of record (i.e. Jira, GitHub), to deliver these insights.
Since hope isn’t a strategy, we went with (b).
What we wanted
Three things:
1. An end to empty ceremonies
Estimating is an empty ceremony.
Whether by story point, Fibonacci number, or wet finger in the air, estimating produces nothing more than a guess—yet it eats huge amounts of engineering time.
Forecasting? Same thing. How can anyone know when some project is likely to finish? There are too many variables at play.
Calculating point velocity as a means to talk about progress or productivity? No. These are just make-work jobs that say nothing meaningful or predictive about the way we work.
But these are the kinds of questions that are tailor-made for AI and machine learning.
2. Straight answers to simple questions
We wanted data to show us, instantly, what otherwise took a whole lot of sifting, sorting and discussion—or that wasn’t answerable at all. Answers to things like…
How long will it take to build this?
When will this project finish?
Where are our bottlenecks?
Is scope creep impacting progress?
Which objectives are stagnating?
Who’s overworked, and who has capacity?
Are we improving as an organization? Why or why not?
3. A clear way to demonstrate engineering productivity
Let’s demystify what software engineering does. At its essence, the job of product and engineering teams is to turn ideas into working software. The more ideas delivered, efficiently and at good speed, the better.
All we need is the data to show how much we’re getting done, how efficiently, and at what speed. And how this is changing over time. This data should be available to us instantly and automatically—no digging, no spreadsheeting—at any time, for any body of work.
What happens if we can free teams from empty ceremonies? What happens if we have data to show, automatically and in real-time, how work is flowing? What if people have data that helps them understand ways of working better?
Life, at least the work part of it, gets easier. Simpler. Smarter.
