Joe Aillet Stadium
After kickoff, I stop and look around.
On game days, I try to find a minute after the game starts. The gates are quiet. Families are in their seats. Students are making noise. Somewhere, a kid is watching a favorite player in person for the first time.
A few minutes earlier, we were answering questions and solving the last problems. Now all of that has faded into the background. I can see what the work was for.
That is why I like ticketing. Selling the ticket matters, but the better part comes after someone walks through the gate. The ticket gave them a reason to be there. Everything else we build—an email, a web page, a student program, a smoother process—should make that decision easier.
The questions behind the work
The subject changes. My starting point rarely does.
- Why do we do it this way?
- Is there a better way?
- Can I learn enough to improve it myself?
The problem usually decides what I learn next.
I did not learn web development because I planned to become a developer. I learned after losing a job and having time to notice how often an idea stopped at “we would need someone to build that.” I wanted to know whether I could get it to a first version myself.
Data started the same way. An unscanned ticket looks like one attendance problem until you separate sponsor allocations, broker-held seats, and other account types. Then one number becomes several problems, each needing a different response. The useful part was not producing another report. It was changing the question we were asking.
Usually, I am not trying to master a new field. I am trying to learn enough to get unstuck.
That is also how I think about technology. If a new tool makes the work harder to explain or maintain, it probably has not solved much.
- AnalyticsBreaking attendance into smaller groups showed that unused tickets did not all have the same cause. That made the next conversation more useful than “we need a bigger crowd.”
- Digital workWhen fans kept needing help finding information, I started rebuilding the path instead of writing one more message explaining where to click.
I want to know what someone is good at—and where they want to go.
I often call myself a utility infielder. I am comfortable moving between responsibilities when the team needs it. I do not expect everyone I lead to work the same way.
If someone has an accounting background, I may give them more financial work. If they are comfortable with people, I may put them in front of customers. That helps the team now, but it is only half the conversation.
I also ask what they want to do next. Sometimes the right assignment is one they are already good at. Sometimes it is a task that gives them experience they do not have yet.
I do not always get that balance right. But I would rather adjust the work to the person than manage everyone from the same template.
A good first version should not need me forever.
I like making things, but I do not want to become the only person who knows how they work.
A useful reporting process is one someone else can run. A useful web page answers the fan before a phone call is necessary. A student program is healthier when its traditions survive the people who started it.
I am usually happiest with work that becomes ordinary: it solves the problem, people understand it, and eventually nobody remembers that it used to be harder.