Category: Leadership

Restoring Understanding

Restoring Understanding

JakeLeave a comment

I’ve mentioned before that my first computer was an Epson Equity I+. I got it in 1987 and, unfortunately, got rid of it in the early 2000s. That decision has haunted me ever since.

Well, until recently, when I acquired one and started restoring it.

The restoration has brought back a flood of memories. I can feel the understanding growing every day, like a ten-year-old learning his first computer. Everything is new and fascinating. There’s a race to learn, to explore, to figure it all out.

As I dig into it, I’m constantly amazed. I can almost see the problems through the engineers’ eyes as they designed the hardware and software. There’s simplicity inside the complexity. When something doesn’t work, there aren’t ten layers of abstraction hiding the answer.

You can reason about it end to end.

That experience has been oddly grounding.

Modern systems are incredible, but they’re also opaque. We stack frameworks on platforms on services until even experienced builders rely more on trust than understanding. When something breaks, we hunt symptoms instead of causes.

Restoring this machine reminds me what it feels like to know a system again.
To see how choices connect.
To feel confident not because something is new, but because it’s clear.

That mindset has been showing up in how I think about CoffeeBreak.

AI tools are powerful. The progress is real.
But power without understanding doesn’t eliminate work. It just moves it around. Often onto people, quietly.

Unlike this restoration, with CoffeeBreak I’m not trying to build something nostalgic.
I’m trying to build something coherent.

There’s a quiet confidence that comes from knowing how a system works all the way through.

That’s the feeling I’m chasing, whether I’m restoring an old computer or building something new.

☕

You Don’t Get to Skip the Work

You Don’t Get to Skip the Work

JakeLeave a comment

Here I am on a Sunday afternoon, watching the AFC Championship during a full-on snowstorm.

The Broncos are hosting the Patriots, and deep down part of me feels like Kansas City should be here. We’ve had a lot of success over the last decade. We’ve built something special. It’s easy, when that happens, to start believing this stage somehow belongs to you.

But that’s not how it works. Instead, the Chiefs sputter all year, and Patrick Mahomes tears the ligaments in his knee and the Chiefs are a footnote on the 2025 NFL season.

All of that is a big reminder that you don’t get to the next game based on last year’s stats. You earn it again, each year, in conditions that aren’t ideal. The Patriots are exemplifying that today. After a nearly 20-year dynasty and a recent trip into NFL oblivion, they’re back hoisting the Lamar Hunt Trophy once again.

That’s been on my mind as I work on CoffeeBreak.

Right now, I’m close. I can see the system. I can explain it. But I can’t quite get it to run end-to-end, on its own, without help.

In the past, I would have pushed harder. Added more features. Told myself it was “good enough” and that we’d clean it up later.

Experience has taught me to resist that impulse.

Right now, CoffeeBreak doesn’t need to do everything. It needs to do one thing really well, end to end, without excuses.

There’s no shortcut around that work. No entitlement. No reputation that carries you forward forever.

Not in football. Not in software.

And definitely not if you want the results to last.

Why I’m Waiting for One Thing to Work Really Well

Why I’m Waiting for One Thing to Work Really Well

JakeLeave a comment

This is probably overdue, but here we are.

The thing I’ve been indirectly writing about for the last few weeks has a name. It’s called CoffeeBreak. It’s an AI teammate designed to support the software development lifecycle, end to end.

I haven’t named it until now on purpose. Not because it’s a secret, but because the name isn’t the important part yet. The work is.

Over the years, I’ve learned that most software failures don’t come from ambition. They come from shipping something that almost works and asking users to fill in the gaps.

I’ve been feeling pressure lately. Not from investors or timelines, but from peers. People asking when they can try CoffeeBreak. That’s a good problem to have, and it’s also a dangerous one.

Right now, CoffeeBreak doesn’t need to do everything. It needs to do one thing, really well, end to end, without excuses.

I don’t want to ask people to imagine how it will work. I don’t want to say “ignore that part for now.” I don’t want users doing invisible work to make the system feel useful. And I certainly don’t want people to feel, “Pay no attention to the man behind the curtain” vibes.

I’ve shipped software fast before. I’ve cut corners before. And I’ve paid for it later with trust, rework, and long nights debugging or explaining why something behaved the way it did.

This time, I’m waiting until one workflow can stand on its own.
One task. One path. One outcome that doesn’t require hand-holding.

I’m close. I can see the shape of it now. But “close” isn’t the same as “ready,” and experience has taught me not to confuse the two.

When CoffeeBreak is ready to share, it won’t need caveats.
That’s the bar I’m holding myself to.

Letting People See the Work Before It’s Finished

Letting People See the Work Before It’s Finished

JakeLeave a comment

There’s a moment in building something where you have to decide who you’re optimizing for.

Early on, it’s just you. Then maybe a small set of ideas, sketches, or prototypes. Eventually, you reach a point where the work is real enough that keeping it completely private starts to hurt more than it helps.

I think I’m at that point now.

The Tension Between Polish and Learning

There’s a strong pull to wait until something feels “done” before letting anyone see it. Polished. Documented. Fully formed.

The problem is that polish often hides the most important feedback.

What I care about right now isn’t applause or adoption. It’s learning. I want to know where people pause, what they misunderstand, and which assumptions don’t survive first contact with reality.

That kind of insight doesn’t come from dashboards or signups. It comes from thoughtful eyes on unfinished work.

Choosing Who Gets to Look

I’m not interested in opening the floodgates yet. Early feedback shapes products, whether you want it to or not, and I’m being intentional about who helps shape this one.

Peers. Builders. People who understand tradeoffs. People who are comfortable saying, “This part feels off,” instead of just asking for features.

That’s who I want looking right now.

Comfortable, Not Rushed

Letting people see something before it’s ready isn’t about being early. It’s about being honest about where the work actually is.

I’m comfortable with people looking. I’m comfortable with it being incomplete. I’m comfortable saying, “This is close, but not finished.”

What I’m not interested in is rushing past that phase just to say it’s launched.

There will be a time to open the door wider. I’m not there yet.

But I’m close enough now that letting people see the shape of it feels like the right next step.

Why I'm Finally Ready To Build This Solution

Why I’m Finally Ready to Build This Solution

JakeLeave a comment

I’ve had ideas like this before.

Over the years, there have been plenty of moments where a new technology showed up and people rushed to declare that everything was about to change. Sometimes they were right. Sometimes they were early. Sometimes they were just obnoxious and faded out with the fad.

More than once, I chose not to act.

Not because I couldn’t build something, but because it didn’t feel like the right moment. The pieces weren’t there yet. Or the problem was still being solved well enough by humans. Or the solution would have created as many issues as it fixed.

My dad was a video engineer by trade. He was one of, if not the first, people in Kansas City trained to run a slow-motion reel-to-reel machine. His experiences with new and emerging technologies helped shape how I think about when to get involved, and when to sit on the sidelines.

When Chyron video technology began emerging in the 1960s and 1970s, it was used sparingly. My dad wasn’t trained on Chyron yet, but he had an idea. He took a small video camera, mounted it on a tripod, and pointed it at the scoreboard during a baseball game.

Later, he did the same thing for football and other sports.

That simple workaround helped change what viewers came to expect from televised sports. In a nine-inning baseball game, it’s nice to know the inning, the score, and the time at any moment. Today, those elements are permanently embedded on your screen, so normal you don’t even notice them. They’re expected.

My dad saw a technology that wasn’t being used in the best way possible, and he acted at the right moment.

Experience has a way of teaching you when to move. He was right.

It seems like just yesterday

It seems like just yesterday, but I’ve lived through multiple waves of tooling shifts myself. Each one promised to simplify software development. Each one delivered real gains, along with new kinds of friction.

What never really went away was the same underlying problem:
humans doing invisible coordination work between systems that don’t quite understand each other.

We learned to live with it. We staffed around it. We normalized it.

For a long time, that was the right call.

Why This Time Feels Different

What’s changed isn’t just the technology. It’s the combination of things finally lining up, and the growing awareness of the gaps that still need to be filled.

We now have systems that can reason just enough to participate in work, not just execute it. We have workflows that can adapt instead of forcing everything down a single happy path. And we’re finally talking openly about the cost of context switching, glue work, and human babysitting of software.

More importantly, we’ve learned what doesn’t work.

Blind automation doesn’t scale judgment. More tools don’t automatically create clarity. And faster output doesn’t guarantee better outcomes.

Those lessons matter.

Waiting Was Part of the Work

If I’m honest, part of being ready now comes from knowing what I don’t want to build.

I don’t want another system that just moves work faster without understanding it. I don’t want something that replaces human judgment instead of supporting it. And I don’t want to rush something into the world just because the timing feels exciting.

I waited until it felt necessary, not just possible.

Close, But Not Quite There Yet

I’m finally at a point where it feels okay to say that I’m building something. In truth, I have been for months.

I’ll be opening a beta soon. I can’t say exactly when yet. But I’m close enough now that the direction is clear and the product is taking its final shape.

For the first time in a long time, it feels like the right moment to act.

What I'm Paying Attention To As We Head Into The New Year

What I’m Paying Attention to as We Head Into the New Year

JakeLeave a comment

The stretch between Christmas and the New Year has always been a strange and useful pause.

The calendar hasn’t flipped yet, but the pressure eases just enough to think. Projects slow down. Meetings drop off. You get a little space to reflect without immediately turning that reflection into a plan.

This is usually when I take stock of what’s actually worth paying attention to.

Less Noise, More Signal

There’s no shortage of predictions right now. Every week brings another “AI will change everything” headline, another tool launch, another bold claim about the future of work.

Most of it is noise.

What I’m paying closer attention to is quieter:

  • Where teams are still struggling, even with better tools
  • Where automation helps, but also where it gets in the way
  • How often humans are still doing invisible glue work between systems
  • And which problems keep showing up no matter how advanced the tech gets

Those patterns matter more than any single product announcement.

The Gap That Keeps Showing Up

One thing I keep seeing is a growing gap between capability and clarity.

We have systems that can generate code, route work, summarize decisions, and automate entire workflows. But many teams are still unclear about why certain work exists, who should make which decisions, and when software should act versus pause.

More capability doesn’t automatically lead to better outcomes. In some cases, it just makes existing problems happen faster.

That’s the space I find most interesting right now.

What I’m Intentionally Not Rushing

There’s a strong pull at the start of a new year to rush toward answers.

I’m resisting that.

Some problems benefit from speed. Others benefit from sitting with them a little longer. Understanding how people actually work, where judgment shows up, and where things fall apart, takes time.

I’m okay with that.

Looking Ahead, Quietly

As we move into the new year, I’ll be sharing more of what I’m observing as these ideas take shape. Not polished conclusions, but real thinking in progress.

If you’re curious where that goes next, I’ve started talking out loud in a few places beyond this blog. You’ll find links on the site if you want to follow along.

No pressure. No sign-ups. Just conversation.

Sometimes the most useful thing at the start of a new year is simply paying attention.

Decades of tools, one way of thinking

A Peek Under the Hood, How I Think About Building the Next Generation of Dev Tools

JakeLeave a comment

When I first got into software, there were no libraries waiting for us. No package managers. No Stack Overflow. No copy-paste from GitHub.

If you wanted to build something, you built it. Top to bottom.

If I needed to talk to another system, I opened a socket. I connected via TCP. I handled the protocol. If something failed, I debugged it at the wire level. Applications were handcrafted end to end, and you were responsible for everything you shipped.

That experience shaped how I think about software to this day.

From Building Software to Assembling Software

As my career progressed and I started hiring engineers, I noticed something changing. We stopped teaching people how software works and started teaching them how to assemble it.

That’s not necessarily bad, but it does change the skill set.

When I built hiring assessments, one of the things I always tested was algorithms. Not because I expected everyone to be writing sorting routines every day, but because algorithms tell you how someone thinks. They reveal reasoning, tradeoffs, and how a person approaches a problem when there isn’t already a solution handed to them.

Over time, that kind of thinking became less emphasized. We got very good at wiring packages together. We got worse at understanding what was actually happening underneath.

That shift matters more than most people realize.

Automation Isn’t New, Context Is

Long before AI entered the conversation, I used to tell teams the same thing over and over. I can automate almost anything, but we need to start with people.

You let humans run the process first. You iron out the edge cases. You understand where things break. Then you automate the boring, repeatable parts and kick the exceptions back to humans.

That model has worked for me for decades.

What’s new now isn’t automation. What’s new is that software can finally understand a little bit of context. Not perfectly, but enough to participate instead of blindly executing instructions.

That distinction is everything.

The Real Cost of Babysitting Software

At one company, I had a peer who was incredibly good at keeping things running. Customers were happy. Issues were handled quickly. From the outside, everything looked fine.

When he eventually left, I dug into the system and realized how much time had been spent babysitting instead of fixing root problems. Not because he didn’t care, but because there simply weren’t enough hours in the day.

The company didn’t push for deeper fixes because the work was getting done. In reality, they were paying a premium for reactive support instead of investing in durable solutions.

That experience stuck with me.

Software that constantly needs human babysitting isn’t efficient. It’s expensive. And worse, it hides the real cost behind “everything is working.”

How My Thinking Has Changed

Today, I care less about features and more about intent.

Where does intent originate?
How is it preserved as work moves through systems?
What happens when that intent becomes unclear?
And when should software act versus pause and ask for help?

These questions matter more to me now than which framework is trending.

Some principles I won’t compromise on anymore:

  • Tools should preserve intent, not just produce output.
  • Automation without context just accelerates the wrong outcomes.
  • Humans are not a failure mode, they are part of the design.
  • Software should adapt to people, not force people to adapt to it.

Why This Is Finally Possible

For most of my career, software was deterministic because it had to be. That made context preservation incredibly hard.

Now we have systems that can reason, summarize, adapt, and operate with uncertainty. We can design workflows that branch. That pause. That escalate. That involve humans when confidence drops.

This doesn’t replace judgment. It finally gives judgment a place to live inside the system.

A Quiet Tease

I’m working on something that reflects all of this.

It’s shaped by decades of building software the hard way, watching teams struggle with invisible friction, and seeing how often people end up doing work that tools should have handled better.

I’m not ready to talk about it publicly yet.

But if modern dev tools feel powerful and exhausting at the same time, we’re probably thinking about the same problem.

More soon.

Rest in Peace, Coach

JakeLeave a comment

Still trying to get my head around the Chiefs loss in Super Bowl LV, this morning I get an alert on my phone that Marty Schottenheimer, long time coach of the Kansas City Chiefs, has passed away at the age of 77 due to complications of early onset Alzheimer’s Disease.

I wrote about the coach and his battle with this disease 5 years ago in my article titled “One Play at a Time“. Today it is very sad news to hear that he has passed away. I just wanted to write something to say, “Rest in peace” to him and think about his family at this time. Coach had a giant family in Chiefs Kingdom, and I know he will be missed by many.

To me, Marty was the epitome of a football coach. He looked like a coach. He sounded like a coach. You could watch the Chiefs play and always see the man coaching. He was constantly talking to players and trying to motivate them as men. He was a great coach. He won over 200 games in his career. He only had two losing seasons across a head coaching career with 4 NFL teams.

Marty was a good as it gets when it comes to being a coach, a leader, and a man. He was a leader of men. He will truly be missed. I will always remember him and think fond thoughts of the man that taught me the game of football. My dad got me into watching the 49ers in the 1980s. In the 1990s, my dad introduced me to Chiefs football with Marty, and my views on football were forever changed.

Rest in peace, Coach. You earned it.

Virtually Yours!

JakeLeave a comment

Due to the COVID-19 global pandemic we are all living through at this time, I’ve decided to grow my side hustle into a real business. The name of the company is Transcendent Software. Don’t feel obligated to click through or feel like I’m trolling you for my services. For some background, I originally started this business in 2009 to make some extra money and help some friends with different projects from time to time as things came up. My goal with my career in technology has always been to make the world a better place through the use of technology, so this fit right in with my personal mission statement.

One of the service offerings I am most excited about is a Virtual CIO / Virtual CTO Service. If you are not familiar with this, it is sometimes referred to as vCIO, Fractional CIO, Part-time CIO, or something close to that. The service is geared for small to mid-sized businesses. I would be able to serve as CIO or CTO for several companies at one time. We would agree to a fee and hour limitations, but I could help them out and eliminate the need for a full-time employee when it would be very cumbersome for them to take that salary on. The nice thing is that I would still fulfill every aspect of leading an IT department, but not be as involved in the day-to-day part of the business.

If you’ve been reading me for any time throughout my career and my several attempts at blogs, I have spent the better part of my career as a CTO (Chief Technology Officer). When I wasn’t that, I usually carried IT Manager or IT Director in my title, because the management side was part of my job for almost my entire career.

I started my career as a Software Engineer I, but within a year on the job I was really starting to design our systems, and very shortly after took the title Chief Software Architect. When I was given the responsibility of running the IT department as well, I was then IT Manager / Chief Software Architect and eventually Chief Technology Officer.

So, back to the Virtual CIO / Virtual CTO Service, I am very excited to be offering this service to small to mid-sized businesses. It gives me the opportunity to take what I’ve done for several companies over the years and be able to do it for even more companies in many different industries. I think the role can be applied into any business, even businesses you wouldn’t think would be in need of technology leadership. Another thing I am excited about is that eventually, it will allow me to bring on other resources to do the same role and keep pushing my mission of making the world a better place through the use of technology one vCIO gig at a time! I’m psyched and ready to go!

The Right Stuff

Jake1 Comment

I know it’s been a long time since I last posted, but I think it is relevant to discuss training and education, especially in software development. This has been a topic weighing on my mind a lot the past several years.

In the past 20 years since I made the leap into my career path, I have witnessed many changes in technology. The microprocessor and the internet have taken over nearly every facet of our daily lives. It is quite remarkable where we came from to where we are today, and to think it has only been that short of a time while I’ve been a professional.

When I first started writing software, we didn’t have the rich toolsets we have now. We had some very basic compiler suites, or command line compilation using a text editor to edit the source files. We also didn’t have the libraries available today. Most problems we had to solve from scratch. Finally, to top it off, we didn’t have Google to save the day when we needed that snippet of code to hybridize into our own solution. We had to know how to write algorithms to solve problems. The solutions weren’t handed to us, and we weren’t coddled to the answer via great tools that auto complete our lines of code, and format our code and give us instant feedback to errors or omissions without compilation and trial and error.

I may sound like an codgidy old man, and maybe I am, but I think having to solve problems from scratch taught my generation a lot about problem solving. I think this is the magic bullet that is missing from the college curriculum, work training programs, or coding bootcamps. I think all of those things are great, and there is some foundational stuff there, but these folks are missing out on algorithm design. This is the foundation for which all software works. You have to be able to solve problems. You can’t just rely on Google or great tools to solve them for you.

So, here I plead to anyone affiliated with these software development educational programs, spend some time on bubble sort or binary search. Teach your students about how to extract a subset of text from a string, or how to increment numbers exponentially. Spend some time on conditional logic, and order of operation. All of these things have value, and while pretty basic, they are the building blocks that we are skipping over to get to the cool IDE or the latest tool or JavaScript library.