Okay, I’ve spent more than five years building sports schedules by hand, and I need to explain why watching software do this now is such a strange experience.
Because I know what’s hiding in those little boxes on the calendar.
You look at a game on a Tuesday night and, sure, two teams, a facility, a start time. How complicated could that be? Then you move it. And apparently that was the Tuesday you couldn’t move, for a reason that makes complete sense once somebody explains it, except now the other team’s next three weeks look different and you’ve accidentally made a perfectly reasonable decision that creates four more decisions.
I have spent a lot of my life in those four more decisions.
So yes, I’m honestly shocked by what we’ve been able to do with LeagueNav. We’ve produced schedules for real leagues, across adult recreation, junior hockey and youth sport. Work that I understand very personally, because for years I was the person sitting there trying to make the pieces fit.
At a high level, for the problems we’ve successfully tackled, we’ve solved the mathematical part well enough to put it to work. That’s a huge statement for me to be able to make. I also want to be precise about it: I’m talking about real scheduling problems we’ve handled, not declaring that every possible sports schedule is now a solved problem and everyone can go home.
Nobody gets to go home yet. We still have to figure out what people actually need.
And that is where this gets really interesting.
Take the word “fair.” I could spend an entire afternoon on that word. Fair to whom? Over what period? Does fair mean everyone gets the same thing, or everyone gets what they agreed to? What if one team actively wants the time another team hates? What if the league has a good reason for treating two groups differently?
These aren’t weird little edge cases you sweep up after building the product. This is the work. This is what running a league actually feels like.
And I say that with a lot of sympathy for the operator, because sometimes you’re being asked to explain a decision you’ve been making intuitively for years. You know why you do it. You might never have written it down. You might also discover, halfway through explaining it, that the rule you thought you had is actually three different rules depending on the situation.
Now imagine handing all of that to software and saying, “There. Make us a schedule.”
We have to get better at that handoff. Our team has to learn. We have to ask better questions, understand the consequences people care about, and recognize when we’ve misunderstood something rather than confidently configuring the wrong thing.
Which is why I keep coming back to the concept of a forward-deployed engineer. Someone close enough to the customer’s actual work to help turn what’s happening there into something the product can support.
We’re exploring what a version of that should look like for LeagueNav. Working alongside a league, understanding its scheduling choices, its configurations, the other workflows wrapped around all of this. Sometimes we may need to build something. Sometimes we may need to help make an existing choice clearer. I don’t want us deciding which one before we’ve understood the problem.
And I certainly don’t want every customer to become a separate software company we’re accidentally running. The interesting challenge is learning something specific with one league and turning that learning into a capability that helps the next one, while still respecting the reasons they operate differently.
That’s the part of this new era of SaaS I’m excited about. How much closer can the software get to the work? How much better can we become at understanding an organization without asking the people inside it to become software experts first?
AI gives us new ways to explore that. It doesn’t magically know the conversation you had with a captain three months ago, or which tradeoff your league is willing to make. Somebody has to bring that context into the process. Somebody has to stand behind the decisions.
There is still plenty we haven’t finished. Understanding incomplete requirements. Helping an operator see what a change will affect. Making the experience clear enough that they can confidently put the result in front of their teams. Those are areas we still have to keep earning, and I’m not going to pretend generating the schedule means we’ve finished the job.
Whether it’s an ice slot, court time or a field booking, there are people and commitments behind it. The vocabulary changes. The consequences are still real.
I think that’s why I find this so exciting and, honestly, a little ridiculous to get my head around. After five years of moving games around manually, we’ve reached a point where the mathematical work can actually be handled by the machinery we’re building.
And here I am, more convinced than ever that we need to get really, really good at working with people.