Say Yes Before You're Ready

Someone walks up to your desk with an idea. They think there's a better way to do something. They've been frustrated with the current process for a while. They don't know how to build software. They just know the problem.

That's how every enterprise app I've built started.

Not with a project charter. Not with a roadmap. With someone saying, "Hey, do you think we could build something for this?"

And me saying yes.

The first one

Years ago, we were using software to manage service calls and field dispatch. It was outdated, but it worked. Then the company that made it got acquired. The product got rolled into a much larger software package, one we didn't need 90% of. The cost to keep using the piece we did need went up significantly.

Someone came to me and asked if we could build it ourselves.

I said yes.

I had never built anything like it. I didn't know how I was going to make it work. But I knew I could figure it out.

That became TroubleTracker, a service call management system that replaced the vendor tool entirely. It handled customer lookup, hazard tracking, call lifecycle management, and field dispatch across two utility companies. It's still running.

What saying yes actually means

It doesn't mean you know how to do the thing. It means you're willing to figure it out.

Most developers wait until they feel ready. They scope the risk, check if they have experience with the stack, think about whether it's the right time. That caution is understandable. It also means a lot of good problems go unsolved.

When I said yes to TroubleTracker, I had to learn things I'd never touched before. I had to sit with people in operations and understand how they actually worked, not how I assumed they worked. That collaboration was as valuable as anything I wrote in code.

It kept happening

Once I said yes to one, it got easier to say yes to the next.

Each project brought a new problem I hadn't solved before. Each one pushed me into a domain or a technology I wasn't already comfortable with. Storm Center for real-time outage tracking. Reliability Event Manager for regulatory compliance reporting. Call Vault for archiving hundreds of thousands of customer interactions. Project Express to centralize access control across the company.

None of those were in my comfort zone when I started them. All of them are running today.

The pattern was always the same. Someone identified a cost savings or an operational problem. They brought it to me. I said yes. I learned what I needed to learn to build it.

The compounding effect

Twelve years of saying yes adds up.

Each project taught me something I used in the next one. Each collaboration with a different team gave me a better understanding of how the business actually worked. By the time AI became a real option for enterprise use, I had years of context about the problems worth solving and the people dealing with them.

That's how ALLETE GPT came together. Not because I woke up one day with an AI platform idea, but because someone came to me with a problem, and I said yes.

What this means if you're a developer

You don't need to wait until you feel qualified. The project is how you get qualified.

If someone brings you a problem and you can see a path forward, even a rough one, that's enough. Say yes. You'll figure out the rest. The discomfort of learning something new on the job is temporary. The application you ship is permanent.

The best skill I developed over those twelve years wasn't a technology. It was the habit of saying yes to problems I didn't fully know how to solve yet.

What this means if you lead a team

You probably have developers who would say yes if someone asked.

The ideas are often already there, sitting with the people closest to the operational problems. They know what's inefficient. They know what's expensive. They know what the current tools can't do. They just need someone to connect them with a developer and give the project room to happen.

That's where a lot of cost savings gets left on the table.