From 40 years of building software

Six patterns I keep seeing in software organizations

Most of these travel under other labels: talent shortage, alignment issues, prioritization problems. Recognizing the actual pattern saves you the third hiring round and the next tool migration.

Your company is not a software company

Manufacturing, logistics, services. When the software breaks, there's no product team. There's you.

Your company is a software company

Your own product, growing team. Yet delivery keeps stalling and critical knowledge lives in a few heads.

A talent shortage you're creating yourself

Roles stay open for months even though the market is full of capable people. Recruiting and procurement filter for exact stack match, years of industry experience, and immediate productivity. What gets filtered out: judgment, learning ability, systems thinking.

Typical picture: The job req reads like a parts order. Anyone who doesn't check every box gets screened out. The candidate pipeline looks clean on paper but doesn't add strength to the team.

Improvements that die on the vine

Better tests, cleaner architecture, modern tooling: technically sound, but impossible to push through. Questioning the status quo threatens the people who built it. The improvement fails on politics, not on engineering.

Typical picture: Initiatives start, deliver early results, then stall because they never gain internal backing or meet quiet resistance.

A team that's better than it looks

Good people, but everything takes too long. Too many interruptions, too much knowledge in individual heads. Permanent firefighting instead of planned work.

Typical picture: Adding headcount or meetings doesn't help. The friction is structural, not a people problem.

Systems that grew instead of being designed

The Excel macro that runs half the warehouse. The product whose core was written a decade ago. Everyone knows it can't stay this way. But nobody wants to touch it.

Typical picture: Small changes take disproportionately long. Whoever understands the code is irreplaceable. Whoever doesn't, won't go near it.

Too many initiatives, no clear picture

Too many things in flight at once, priorities shift constantly. Nobody has a reliable picture of what's actually driving progress and what's just generating activity.

Typical picture: New urgencies every week. The team reacts instead of working to plan. Progress feels random.

Decisions without solid ground

Technology investments have to survive the C-suite or the board. Without a shared picture, every proposal becomes a negotiation based on guesses.

Typical picture: The same topic gets discussed repeatedly because there's no common frame of reference and everyone evaluates it from their own angle.

AI delivers real value — when you know where to look

There's hardly a topic with more talk and less hands-on experience right now. Yet AI tools already deliver concrete results in daily work: faster code scaffolding, better research, shorter analysis cycles. The question isn't whether AI matters, but where it makes the biggest difference in your operation.

I've been building software where AI is a core part of the application for years — not as an experiment, but as the heart of the product. That's the background I bring when we figure out together which tools actually help your team.

1

Find the spots with the biggest leverage

Where does your team repeatedly spend time on tasks that good tools can shorten? That's where concrete value starts — measurable, not theoretical.

2

Let the team build its own experience

Hands-on experience beats any training slide. People who use tools in daily work develop judgment: what works, what doesn't, and when manual work is better.

3

Decide based on results

Not based on promises. Which tool reduced the error rate? Where did cycles actually get shorter? Solid results replace every big debate.

If you need a sparring partner who knows AI from practice, not from slide decks — these articles give a first impression.

Who's writing this

Stephan Schwab

Stephan Schwab. I've been writing code since 1981. No MBA, no consulting career track. I've written code, built systems, led teams — and broken and fixed more things than fit in any slide deck.

In the 90s I built one of the first internet service providers in Germany. After that I was where agile methods weren't a training topic but daily practice: XP coaching in Moscow, test-driven development during a 23-team transformation at a major insurer in Ohio, ATDD rollout at Huawei in China, my own software company in Panama. Six countries, three continents, always as part of the team — never as someone who shows slides and leaves.

I work in English, I've spent years in the US, and I understand how American companies operate. But I'm not a big consultancy that flies in a team for a week and hands you a report. I embed with your people, stay until the work is done, and transfer capability along the way. Same depth as the firms you know — without the overhead.

If you've read this far

You probably recognized something. Let's talk for 30 minutes — you tell me what's going on, I'll tell you honestly whether I can help. No deck, no sales pitch.

Schedule a conversation