Caimito Agile Life - English Articles

Supply Chain Attacks: The Hidden Risk in Your Codebase

2026-03-09T00:00:00+01:00

When Trust Becomes a Vulnerability

09.03.2026, By Stephan Schwab

Every modern software project relies on hundreds or thousands of external dependencies. When one of those dependencies is compromised, the malicious code runs with full trust inside your systems — and your customers' systems. Supply chain attacks have brought down companies and eroded trust in entire ecosystems. Understanding this risk is no longer optional for anyone responsible for software delivery.

The Package That Changed Everything

"Your application might be secure. But what about the 1,247 packages it depends on?"

In early 2021, a security researcher demonstrated something terrifying. By uploading packages to public registries with names matching internal packages used by major corporations, he achieved code execution inside Apple, Microsoft, Tesla, and dozens of other companies. The attack worked because package managers automatically prioritized public packages over internal ones.

He didn’t exploit a bug. He exploited trust.

This wasn’t an isolated incident. The same pattern repeats across the software industry:

event-stream (2018): A popular NPM package with millions of weekly downloads was transferred to a new maintainer who added code that stole cryptocurrency wallets.
ua-parser-js (2021): Another widely-used NPM package was compromised, injecting cryptocurrency miners and password stealers into applications worldwide.
colors and faker (2022): A frustrated maintainer deliberately broke his own packages, crashing thousands of applications that depended on them.
SolarWinds (2020): Attackers compromised the build system of a network management company, inserting backdoors into software updates distributed to 18,000 organizations including US government agencies.

Each incident follows a similar arc: a trusted component is compromised, and the malicious payload spreads automatically to everyone who depends on it.

Why Supply Chain Attacks Work

"Attackers don't break into your house. They poison the water supply."

Traditional security thinking focuses on perimeters. Firewalls protect networks. Authentication protects systems. Code review protects repositories. But supply chain attacks bypass all of these because they arrive through the front door, wearing the uniform of trusted code.

When your build system fetches dependencies, it implicitly trusts that those packages contain exactly what their maintainers intend. That trust is recursive — the package you depend on has its own dependencies, which have their own dependencies, forming a tree that can include thousands of components.

A single compromised node in that tree compromises everything above it.

Modern applications amplify this risk. A typical JavaScript application might depend on 300-1,500 packages when you count the full transitive tree. A Python project might have 50-300. Each dependency is a potential entry point. Each maintainer is a potential target.

The Business Reality

For executives, this is fundamentally a risk management problem. And it’s one that traditional governance structures are poorly equipped to handle.

The exposure is enormous. If your company ships software — whether as a product, a SaaS application, or internal tools — you’re distributing code you didn’t write and can’t fully audit. That code runs with the same privileges as your own. A compromise in a logging library affects every service that uses it.

Detection is difficult. Malicious code in dependencies is designed to evade detection. It may activate only under specific conditions, lie dormant for months, or disguise itself as legitimate functionality. Standard code review processes rarely examine dependency updates with the same rigor as internal changes.

Response is expensive. When a supply chain compromise is discovered, the remediation effort can be massive. Every affected system must be identified, patched, and verified. Customer communications must be handled. Regulatory obligations may be triggered. The SolarWinds cleanup cost affected organizations hundreds of millions of dollars.

Reputation damage is severe. Customers don’t distinguish between “your code had a vulnerability” and “a library you used had a vulnerability.” The breach happened through your software. The responsibility is yours.

The NPM Ecosystem: A Case Study

"Your customers don't care whether the vulnerability was in your code or your dependencies. They trusted you."

The Node.js package ecosystem illustrates both the power and peril of modern dependency management.

NPM hosts over two million packages. Millions of developers depend on it daily. The ecosystem’s openness has fueled extraordinary innovation — anyone can publish a package, and anyone can use one.

That same openness creates attack surface.

Packages are often maintained by individuals with no security resources. Transfer of ownership is trivially easy. Typosquatting (publishing malicious packages with names similar to popular ones) is a constant threat. And the interconnected nature of JavaScript development means a single compromised package can reach millions of applications within hours.

Consider what happens when you run npm install:

Your package.json specifies direct dependencies
Each dependency specifies its own dependencies
Version ranges allow automatic updates
Pre-install and post-install scripts execute arbitrary code
The entire tree is fetched and executed without human review

At any step, a compromise can occur. And the developer running the command may never know.

The AI Opportunity: Write It Yourself

"The boring utility library that saved you two days of work? AI can now generate that in ten minutes — without the supply chain risk."

For years, the calculus was simple: why spend two days implementing date parsing, CSV handling, or string manipulation when a well-tested library exists? The time saved justified the dependency added.

Generative AI changes this equation dramatically.

Tasks that once took hours or days — implementing a left-pad function, parsing a specific file format, handling common data transformations — now take minutes. You describe what you need, review the generated code, write tests, and you’re done. No dependency added. No supply chain risk introduced. No maintainer to trust.

This doesn’t eliminate the need for dependencies. Complex libraries encoding deep domain expertise — cryptography, database drivers, machine learning frameworks — still make sense. You want battle-tested implementations for security-critical code.

But for the hundreds of small utilities that accumulate in a typical project? The ones that exist because someone didn’t want to write thirty lines of straightforward code? Those are now candidates for in-house implementation. Every dependency you don’t add is attack surface you don’t create.

The irony is rich: AI, often discussed as a security risk, may prove to be one of the most effective defenses against supply chain attacks — by making it practical to simply write more of your own code.

Practical Defenses

The goal isn’t to eliminate dependencies — that would mean abandoning the productivity gains that modern ecosystems provide. The goal is to manage the risk intelligently.

Lock your dependencies. Use lock files (package-lock.json, Pipfile.lock, Gemfile.lock) and commit them to version control. This ensures reproducible builds and prevents silent updates.

Pin specific versions. Avoid version ranges that automatically pull in new releases. Treat dependency updates as explicit changes requiring review.

Audit regularly. Tools like npm audit, pip-audit, and Snyk can identify known vulnerabilities in your dependency tree. Integrate them into your CI/CD pipeline so every build is checked.

Scan your containers. Container images bundle your application with its entire dependency tree. Tools like Trivy, Grype, Clair, and commercial offerings from Docker, AWS, and Google can scan images for known CVEs before deployment — and continuously monitor running containers. A vulnerability in a base image or installed package triggers an alert, not a breach.

Generate and maintain SBOMs. A Software Bill of Materials documents exactly what’s in your deployable artifacts. Tools like Syft, CycloneDX, and SPDX generators create machine-readable inventories. When a new CVE is announced, you can immediately identify which systems are affected rather than scrambling to audit.

Minimize your attack surface. Every dependency is risk. Before adding a package, ask: Can we implement this ourselves? Is this maintained? What does its dependency tree look like?

Verify integrity. Use package integrity checking (npm’s package-lock.json includes integrity hashes). Consider using a private registry that mirrors only approved packages.

Monitor for compromises. Subscribe to security advisories for critical dependencies. Use tools that alert on unexpected changes in package behavior or ownership. Services like Socket.dev analyze packages for suspicious behaviors — install scripts that phone home, obfuscated code, unexpected network access.

Review dependency updates. Treat updates to dependencies with the same rigor as internal code changes. Automated tools like Dependabot, Renovate, and Snyk can flag suspicious modifications and provide context for review.

Organizational Responsibility

"Every dependency you add is code you're responsible for but didn't write and probably won't audit."

Technical defenses are necessary but insufficient. Supply chain security requires organizational commitment.

Make it a board-level concern. The potential impact of supply chain attacks — financial, regulatory, reputational — merits executive attention. Ensure leadership understands the exposure and funds appropriate defenses.

Invest in tooling. Software composition analysis (SCA) tools, dependency scanning, and private registries cost money. That investment is insurance against catastrophic loss.

Train developers. The people closest to the code need to understand the risks and the practices that mitigate them. Security awareness isn’t just about phishing emails.

Establish policies. Define what sources are acceptable for dependencies. Set standards for vetting new packages. Create processes for responding to discovered vulnerabilities.

Maintain an inventory. You can’t secure what you don’t know about. Software Bills of Materials (SBOMs) provide visibility into what your applications actually contain.

The Uncomfortable Truth

No defense is complete. The nature of supply chain attacks means that a sufficiently sophisticated adversary can eventually find a way in. A determined attacker targeting the maintainer of a package you depend on may succeed. A state-sponsored operation may compromise infrastructure you have no visibility into.

The goal is not perfection. The goal is resilience.

Build systems that detect compromise quickly. Design architectures that limit blast radius. Practice incident response before you need it. And accept that dependency on external code — which is unavoidable in modern development — carries inherent risk.

Moving Forward

"Trust is essential to software development. Managing the risks of that trust is essential to staying in business."

Supply chain attacks exploit the trust that makes modern software development possible. Every library downloaded, every package installed, every framework adopted represents an act of faith — faith that maintainers are competent and honest, that distribution channels are secure, that the code does what it claims.

That faith has been violated enough times to demand action.

For technical teams, this means adopting practices that reduce exposure without abandoning the productivity benefits of shared code. For business leaders, it means recognizing supply chain security as a strategic concern requiring investment and attention.

The next major supply chain attack is not a matter of “if” but “when.” The question is whether your organization will be among those who prepared — or among those who wished they had.

Modernizing Legacy VBA with AI and the Swiss Cheese Model

2026-03-07T00:00:00+01:00

When Legacy Code Is the Business

07.03.2026, By Stephan Schwab

When your business runs on a decade-old application with VBA customizations that nobody fully understands, modernization is not optional — it is survival. Success requires using AI for knowledge extraction from legacy VBA, building Java test suites for validation, and applying the Swiss cheese model to ensure your new implementation produces exactly the same results. Because almost right means business failure.

Somewhere in your organization, there is a business application. It has been there for fifteen years. It started as off-the-shelf software, but the vendor exposed VBA for customization, and your organization took advantage of it. What began as simple automation grew into business-critical logic, and now runs pricing decisions worth millions. The person who wrote these customizations retired in 2019. The documentation is the code itself — if you can call it documentation.

This is not a hypothetical scenario. I see similar situations regularly. The VBA customizations that calculate insurance premiums in a policy management system. The accounting software with VBA scripts that reconcile international payments. The CRM platform where VBA automates complex lead scoring. All business-critical. All irreplaceable. All terrifying.

"The person who wrote it retired in 2019. The documentation is the code itself."

When organizations finally decide to modernize these systems, they face a fundamental problem: nobody knows exactly what the system does. They know what it is supposed to do. They know what buttons to press. But the actual logic — the edge cases, the special handling, the quirks that accumulated over years of patches — exists only in the code.

Why Modernization Fails

Most legacy modernization projects fail for one simple reason: the new system does not produce the same results as the old one.

"Almost right means completely wrong when money is involved."

This sounds obvious. Of course the new system should match the old one. But matching is harder than it appears. A pricing calculation that differs by 0.3% might seem acceptable until you realize that 0.3% on ten thousand transactions per day compounds into significant revenue discrepancy. Finance notices. Auditors ask questions. Trust evaporates.

The problem is not technical capability. Modern developers can build elegant systems. The problem is knowledge extraction. How do you capture what the legacy system actually does, including all the undocumented behaviors that have become business requirements simply because they have been happening for years?

AI as Your Knowledge Extraction Partner

This is where AI becomes genuinely useful — not as a replacement for developers, but as an archaeological assistant that never gets bored reading terrible code.

VBA written in 2008 by a finance professional who learned programming from trial and error has a particular character. Variables named temp2, finalFinal, and thisOneWorks. Functions that span 400 lines. Copy-pasted blocks with subtle variations. Comments that say “don’t touch this” without explaining why.

"AI is an archaeological assistant that never gets bored reading terrible code."

An AI assistant can read through this code and extract meaning that would take a human developer days to piece together. Feed it a 2000-line VBA module and ask: “What business rules are encoded in this function?” The AI will identify the calculation steps, note the conditional branches, and describe the logic in plain language.

This workflow is particularly effective in IDEs like VS Code where you can maintain a running dialogue with the AI. You can ask it to analyze specific code sections and document its findings into a separate markdown file — creating a structured investigation log. This file essentially becomes your navigation chart, highlighting ambiguous logic, hardcoded constants, or strange dependencies that need further investigation.

But here is the critical point: the AI’s interpretation is a hypothesis, not a verified fact. The AI might misunderstand obscure VBA syntax. It might miss context that only makes sense if you know the business domain. It might confidently explain logic that the original author got wrong, and that wrongness has become the expected behavior.

You cannot trust the AI’s output directly. You need validation.

Building the Test Harness

The solution is to build a comprehensive test suite before writing a single line of replacement code. Not tests that verify your understanding of what the system should do — tests that capture what the system actually does.

This requires running the legacy system with known inputs and recording the outputs. Every scenario. Every edge case you can identify. Every combination of parameters that the business uses in practice.

@ParameterizedTest
@MethodSource("legacyCalculationTestCases")
void newCalculation_MatchesLegacyOutput(
    CalculationInput input,
    LegacyOutput expectedOutput) {
    
    var result = newCalculationEngine.calculate(input);
    
    assertEquals(expectedOutput.getPremium(), result.getPremium(), 0.0001);
    assertEquals(expectedOutput.getTax(), result.getTax(), 0.0001);
    assertEquals(expectedOutput.getFees(), result.getFees(), 0.0001);
}

AI tools accelerate this harness construction. Instead of manually determining which inputs cover all code paths, feed the VBA logic to an AI assistant. Ask it to identify boundary values and conditional triggers. It will spot that line 403 checks for transactions over $10,000 and suggest a test case for $10,001. It can also generate the Java data structures (DTOs) directly from VBA Type definitions, handling the tedious syntax translation instantly.

We can go further. Under human supervision in a constant dialog, it can build the tests in a TDD fashion. Instead of attempting to understand the entire system at once, you use the AI to incrementally discover rules and lock them down with tests. This interactive process keeps the human in control — verifying the logic — while the AI handles the heavy lifting of syntax and structure.

Sometimes, executing the legacy VBA is difficult due to environmental dependencies. In these situations, the AI can analyze the logic structure to generate sensible synthetic test data. It identifies the necessary input combinations to trigger specific paths, allowing you to build comprehensive test scenarios even when the original runtime environment is fragile.

The test cases come from the legacy system. Run the VBA with these inputs, capture those outputs, store them as your validation baseline. Now you have an oracle — a source of truth that defines correct behavior not by specification but by observation.

Essentially, we are building a model of the old system at this point. We are not yet designing the new architecture; we are creating a high-fidelity behavior map of the legacy application. This executable model becomes the requirements specification that no written document could ever equal.

"Tests capture what the system actually does, not what you think it should do."

This approach has a name in testing circles: characterization tests, or sometimes golden master tests. You are characterizing existing behavior, not specifying new behavior. The legacy system is the specification.

The Swiss Cheese Model for Validation

Here is where the Swiss cheese model becomes essential. James Reason developed this model to explain how accidents happen in complex systems. The idea is simple: every defensive layer has holes, like slices of Swiss cheese. An accident occurs when the holes align, allowing a hazard to pass through all layers.

"Every validation layer has holes. Stack enough layers and the holes stop aligning."

This requires a psychological shift. Humans in general are trained to seek perfection — the correct answer, the bug-free function, the complete specification. Complexity and ambiguity feel like failures. But in legacy modernization, seeking a single “perfect” validation method is a trap. It leads to analysis paralysis.

We must accept that every tool and every layer will be flawed. The AI will misinterpret some logic. The test data will miss a scenario. The shadow run will fail to catch a seasonal edge case. Accepting this imperfection is not defeatism; it is the statistical reality of complex systems. By acknowledging that no single layer is trustworthy, we are forced to build resilience through redundancy.

In legacy modernization, the hazard is incorrect behavior slipping into production. Each validation layer catches some problems but misses others. The solution is not to find the perfect layer — it is to stack multiple imperfect layers so their holes do not align.

Layer 1: AI-assisted code analysis. Have the AI explain what each VBA function does. Review its interpretation. Ask follow-up questions. Build a mental model of the system.

Layer 2: Input/output capture. Extract real calculation examples from the legacy system. Not synthetic test cases — actual historical inputs and their corresponding outputs.

Layer 3: Characterization tests. Build the Java test suite that runs your new implementation against the captured baselines. Every failing test reveals a behavioral difference.

Layer 4: Shadow running. Deploy the new system alongside the old one. Run real transactions through both. Compare outputs continuously. Alert on any discrepancy.

Layer 5: Staged rollout with rollback. Process a subset of live transactions with the new system. Monitor for discrepancies. Increase the volume only when confidence is high.

Layer 6: Business validation. Have domain experts review sample outputs. Do the numbers make sense? Do edge cases behave correctly? Trust their intuition — they have been using this system for years.

No single layer is sufficient. AI interpretation might miss subtleties. Characterization tests might not cover rare edge cases. Shadow running might not exercise every code path. But stack all six layers, and the probability of a significant defect reaching production drops dramatically.

The Knowledge Transfer Outcome

There is a secondary benefit to this approach that often proves more valuable than the modernization itself: explicit knowledge.

"The test suite becomes the documentation that never existed."

The legacy VBA encoded business rules implicitly. Nobody could articulate these rules without reading the code. Now you have a test suite with hundreds of documented examples. The AI-generated explanations, reviewed and corrected, become prose documentation. The characterization tests become executable specifications.

When the next developer joins the team, they do not need to reverse-engineer a VBA module. They can read the tests. They can see exactly what inputs produce what outputs. They can understand the business rules through examples rather than through archaeological excavation.

Practical Steps to Begin

If you are facing a legacy VBA modernization project, here is where to start:

Inventory and assess. List every VBA module, form, and macro. Note which ones are business-critical versus convenience utilities. Identify the highest-risk components — those that handle money, compliance, or customer data.

Extract knowledge with AI. Feed the critical VBA code to an AI assistant. Ask it to explain the business logic. Use the dialog in your IDE to document findings in a file that will guide further investigation. Mark areas of uncertainty.

Capture the oracle. Run the legacy system with representative inputs. Record every output. Build your golden master dataset.

Build the test harness. Create the Java test suite. Verify that running the captured inputs through the legacy system produces the captured outputs. This sounds circular, but it validates your capture process.

Incremental replacement. Rewrite one function at a time. Run the characterization tests after each change. Mismatches are defects until proven otherwise.

The key is patience. Rushing this process invites the very failures that make legacy modernization notorious. Each layer of validation takes time to implement. That time is an investment in confidence.

The Real Risk Is Doing Nothing

Organizations often delay legacy modernization because the risk feels high. What if the new system breaks something? What if we lose functionality? What if customers notice problems?

"The risk of modernization is visible. The risk of stagnation is silent — until it is catastrophic."

These concerns are valid. But they must be weighed against the risk of doing nothing. The VBA developer who maintains the system is retiring. The vendor’s platform is approaching end-of-support. The audit requirements are becoming stricter. The business is growing faster than the legacy customizations can handle.

The risk of modernization is visible and manageable. The risk of continued stagnation is silent until it becomes catastrophic — the day the application corrupts, the day the only person who understands it leaves, the day an auditor asks for documentation that does not exist.

Conclusion

Modernizing legacy VBA is not a technology problem. It is a knowledge extraction problem with a validation requirement that demands defense in depth.

AI accelerates the extraction phase. Java tests provide the validation framework. The Swiss cheese model ensures that no single failure mode can compromise the outcome.

The alternative — rewriting based on assumptions about what the system should do — is how modernization projects fail. Same results is the only acceptable standard when business continuity depends on the outcome.

The application that runs your business deserves better than hope. It deserves layers of validation so robust that confidence replaces anxiety. Start building those layers today.

The First Synthesis

2026-03-06T00:00:00+01:00

Previously: "The Slow Adoption" — Katja started logging daily. Mariana joined, skeptical but willing. Hassan logged because he wanted proof he was drowning. Lukas announced hiring ten more developers to “go faster,” and Katja wrote the truth down anyway.

Monday, 07:54 — Katja’s Office

"Three people logged. The report still reads like a crime scene."

Katja expected the first synthesis to be thin.

A polite summary. A cute dashboard. A suggestion to “align stakeholders.”

The kind of output that lets leadership feel productive without changing anything.

Monday morning hit her with something else.

Navigator didn’t ask how she felt.

It didn’t care about her intentions.

It took the words three exhausted people typed between meetings and emergencies, extracted patterns, showed her the shape beneath.

The shape looked like reality.

Katja clicked the report.

It opened with a warning, blunt as a slap:

Synthesis Confidence: LOW (3 contributors)
Pattern Strength: MEDIUM (high repetition across days)
Recommendation: Expand logging to increase coverage.

Three contributors.

And still, repetition.

Katja scrolled.

📋 Summary

Observed Actions:

Deployment dependency surfaces repeatedly across CTO, Development, and DevOps logs. Pattern: Hassan acts as serialized bottleneck for all staging resets, production releases, and environment configuration. Manual process creates queue; work waits regardless of readiness.
Quality gates bypassed under deadline pressure documented multiple times. Pattern: QA identifies issues pre-release; leadership overrides; known bugs ship; team scrambles post-launch. Reactive firefighting becomes normalized rhythm.
Requirements clarity breakdown visible in mid-implementation context switches. Pattern: Development begins work based on initial understanding; Product changes direction or fails to answer clarifying questions; rework loops accumulate.
Meeting time displacing productive work flagged by multiple roles. Pattern: Status updates, alignment sessions, and cross-functional reviews consume build/test/implementation time. No clear outcome differentiation between necessary coordination and performance theatre.

Tooling and System State:

Manual deployment process remains chronic friction point. No automation, no self-service capability. Single operator creates systemic delivery constraint.
Staging environment instability requires frequent intervention. Reset requests queue behind single person.

Relation to Organizational Context:

Hiring announcement (“ten more developers”) appears in logs alongside existing absorption capacity concerns. Pattern suggests adding headcount without addressing systemic blockers may amplify coordination overhead rather than delivery capacity.
Cross-department communication breakdown visible in conflicting information and duplicate clarification requests.

🎯 Recommendations:

Immediate: Evaluate DevOps capacity and deployment automation. Single-person bottleneck creates predictable delivery constraint regardless of development throughput.
Short-term: Examine requirement definition and change control process. Repeated mid-implementation uncertainty suggests upstream clarity deficit.
Structural: Review quality gate override patterns. Current rhythm (predict failure → ship anyway → scramble) suggests misaligned incentives or insufficient evidence presentation.
Hiring context: Address systemic blockers before adding headcount. Current environment shows limited absorption capacity for additional contributors.

Her throat tightened.

The report didn’t say “your process is maturing.”

It said: you’re stuck, you’re blind, you keep stepping on the same rake and pretending it won’t hit your face this time.

She scrolled back up and stared at one line that made her laugh, once, without joy.

Multiple independent sources describe the same blockers across different roles and departments.

Multiple independent sources.

Katja stared at the screen.

She could already hear Lars dismissing it. Carmen mocking it. Claudia asking whether it would leak.

But the report wasn’t a person.

You couldn’t intimidate it.

You couldn’t charm it.

You couldn’t guilt it into changing its story.

Her calendar pinged.

08:30 — Lukas / Hiring check-in.

Perfect.

She printed the report.

Paper. Physical. The kind of truth you can’t minimize or scroll past.

You hold it, or you throw it away.

08:33 — Lukas’s Office

"He didn’t argue. That’s how she knew it landed."

Lukas stood when Katja walked in.

His office was a glass box above the open floor. Soundproof on paper. Still vibrating with eighty people pretending.

The blinds were half down. Morning light cut stripes across his desk, made it look cleaner than it was.

He had that posture again. Tall, tight, ready to win. Arms crossed, one finger tapping his bicep like a countdown.

On the desk: a half-drunk espresso, a neat stack of hiring printouts, and his laptop open to a spreadsheet with numbers that looked like promises.

Katja didn’t sit.

She put the printed pages on his desk. Paper against glass. Soft slap.

Lukas looked down.

“What’s this?”

“The first weekly synthesis.”

Lukas’s eyes flicked to the heading.

He didn’t pick it up.

Katja waited.

A full ten seconds.

Then Lukas sighed, like he was doing her a favor, and took the pages.

He read.

Katja watched his face.

First minute: skepticism. Second: irritation. Third: something shifted. His jaw softened. His eyes stopped scanning for ammunition and started absorbing truth.

He read like a man who’d just caught himself in a lie.

He reached the section about “Visible Tradeoff.”

He read it twice.

Meeting time is displacing build and test time.

Lukas’s mouth twitched.

“Is this… accurate?” he asked, voice quieter than she’d heard in weeks.

Katja felt her shoulders drop by a fraction.

“It’s incomplete,” she said. “Only three people. But it’s accurate.”

Lukas flipped to the page about Hassan.

Hassan as dependency / bottleneck (8 mentions).

He rubbed his forehead.

“Eight mentions in seven days,” he muttered.

Katja didn’t soften it.

“One person. Eighty-five people. Forty-seven manual steps.”

Lukas’s eyes sharpened.

“That number again.”

“It’s always been that number,” Katja said. “We just didn’t write it down where you’d have to look at it.”

Lukas exhaled.

A long, slow breath.

“Okay,” he said.

Then, quietly: “Fuck.”

Katja watched him.

He didn’t say it like theatre.

He said it like realization.

Lukas put the report down.

No dramatic slam.

No table hit.

Just paper.

He looked up.

“What do we do first?”

Katja blinked.

He hadn’t asked “who’s responsible?”

He hadn’t asked “how do we spin this?”

He’d asked the only adult question.

Katja took a breath.

“We reduce the single points of failure,” she said. “We stop bypassing QA. And we stop hiring like headcount is oxygen.”

Lukas’s eyes flashed.

“We already announced the hiring.”

Katja’s voice went flat.

“Then you announced a train wreck. We can still choose the speed of the impact.”

Lukas stared at her.

For a second, she thought he’d snap back into ego.

Instead, he nodded.

“Get Tomasz and Hassan in here,” he said. “Ten minutes.”

Katja turned to leave.

At the door, Lukas spoke again.

“And Katja?”

She looked back.

“Don’t let me bullshit my way out of this,” he said.

Her mouth twitched.

“Try me.”

09:12 — Hassan’s Corner

"He didn’t want praise. He wanted relief."

Hassan read the report standing against a whiteboard covered in two years of architecture that never got built. Red marker ghosts from 2024. Blue marker hope from 2025. Both fading under fluorescent hum.

He read like a teacher checking a list of his failures.

Then he hit the line: single point of failure.

He laughed. Sharp. The air conditioning vent rattled above them. Someone three rows away turned, looked, turned back.

Not happy. Not amused. Just tired, cracked, finally seeing himself reflected back.

“So it’s official,” Hassan said. “I’m the bottleneck.”

Katja leaned against his desk. It was clean. Suspiciously clean. Like someone who needed order because the chaos was all inside the terminal. “You were the bottleneck last month too. We just kept pretending it was a ‘communication issue.’”

Hassan held up the pages. Too white against his faded hoodie. “This is what you wanted? Proof?”

“I wanted visibility,” Katja said. “Proof came with it.”

Hassan’s eyes went distant.

The screensaver on his second monitor flickered. A terminal window full of red text. Failed build. Retry in 30s.

“Do you know what people do when they think you’re a tool?” he asked.

Katja didn’t answer. She watched the retry count tick up. 28… 29… 30…

Hassan answered anyway.

“They throw work at you. They don’t plan. They don’t ask. They just assume you’ll catch it.”

His phone buzzed.

It vibrated against the hard veneer of the desk. Violent. Needing attention.

He glanced.

Another ping.

Lars Pedersen Hey, quick question…

He didn’t even read it.

He set the phone face down. The silence that followed felt heavy.

“I need one thing,” Hassan said.

Katja braced. The hum of the server rack in the corner seemed to get louder.

“Two hours a day,” he said. “Protected. No meetings. No emergencies unless the building is on fire. Two hours where I automate the pipeline. Every day. For the next month.”

Katja nodded slowly.

She looked at the whiteboard again. At the faded blue lines that could have been a pipeline if they’d ever given him time.

“That’s reasonable.”

Hassan’s mouth twisted. Not a smile. Just the gap between a promise and a paycheck.

“Reasonable doesn’t matter. Lukas has to allow it.”

Katja tapped the report.

“He’s reading. For real this time.”

Hassan stared at her.

“If he takes this away,” he said, voice low, “I’m done. I’m not dying for someone else’s urgency addiction.”

Katja’s stomach tightened.

“Noted,” she said.

Hassan turned back to his terminal.

Then, almost as an afterthought: “Tell Mariana she wrote a good log. The one about reaction time. That’s real.”

Katja blinked.

Hassan didn’t look up.

He just started typing.

14:26 — Leadership Sync

"Data doesn’t end arguments. It just changes what you’re allowed to pretend."

The conference room was too small for twelve egos. Glass walls on three sides. Visible to the whole studio. A fishbowl where the fish were usually trying to eat each other.

Katja brought printed copies again.

Because the first time had worked.

Because you can’t alt-tab away from paper. You can’t minimize it. It sits there, physical and accusing on the table.

The department leads stared at the pages like they were poison. Half-read. Flipped over. Pushed away as if the data might stain their sleeves.

Lars was the first to speak. He looked perfect, of course. Black t-shirt, expensive watch, hair that had never known a bad day. He tapped the paper with a manicured fingernail.

“This is based on three people,” he said, and his voice had that designer purity to it. Smooth. Reasonable. Condescending. “It’s not representative.”

Priya, sitting two seats down, didn’t even look up from her laptop. She was typing. Furious, rhythmic clicks.

“Then log,” she said. “Make it representative.”

Carmen smiled without warmth. It was a smile that showed teeth but no eyes. “He doesn’t log. He performs.”

Lars’s eyes flashed. “Excuse me?”

Carmen’s Spanish came out sharp. Like a knife hitting a plate. “No te hagas el inocente.”

Lukas held up a hand. Palm open. Stop.

“Enough,” he said.

He didn’t shout. That changed the room. Usually there was shouting. Usually this meeting ran loud and went nowhere. The silence that followed hung heavy.

Claudia flipped through the pages, frowning. Her bracelet chimed against the table surface. Ting. Ting.

“‘Meeting time displacing build time’,” she read aloud. “Is this… a dig at us?”

Katja didn’t blink. She sat very still. Hands folded on her own copy of the truth.

“It’s an observation,” she said. “If you feel attacked, maybe ask why.”

Daniel cleared his throat. He looked uncomfortable. He usually looked uncomfortable, but today he looked like he might actually speak.

“The QA bypass mention,” he said quietly. “That’s real. It keeps happening.”

Elif leaned forward. She smelled like cigarettes and stress. “And the deployment friction is real. Players don’t care that we’re ‘almost ready.’ They just see broken events.”

The door opened. Tomasz arrived late.

Hair uncombed. Eyes red. Wearing the same hoodie from yesterday. He smelled like stale Club-Mate and the inside of a server room.

He dropped into a chair and stared at the report. He didn’t touch it. He just looked at the headline.

“Finally,” he muttered.

Lukas looked at him. “Finally what?”

Tomasz tapped the page with a shaking finger. Not from fear. From caffeine.

“Finally a thing that doesn’t care about our politics,” he said. “It’s the same blockers every day. It’s not a story. It’s a loop.”

Lars scoffed. He leaned back, putting distance between himself and the unwashed developer. “Or it’s just Development complaining.”

Mariana wasn’t in this meeting, but her words showed up anyway.

Katja pointed to the section where her log had been quoted. Text on paper. Indisputable.

Running on five hours of sleep. Reaction time is shit.

Carmen exhaled hard. She looked at Lars. Then she looked at Tomasz.

“That’s not complaining,” she said. “That’s a warning.”

The room went quiet. The hum of the air conditioning seemed to get louder. Someone’s phone buzzed on the table. Ignored.

Lukas held the report in both hands. Weighty.

He looked around the table. Face to face. Eye to eye.

“For two years,” he said, “I’ve been asking you for status.”

No one moved. Even Lars stayed still.

“And you’ve been giving me performance,” Lukas continued. “And I rewarded the best performers.”

Katja watched Lars stiffen. His perfection cracked just a little.

Claudia’s mouth tightened.

Lukas looked down at the report again.

“This is ugly,” he said. “But it’s honest. And I want more of it.”

Lars opened his mouth. Reflexive defense.

Lukas didn’t let him. He slammed the paper down. Not hard. Just final.

“Department leads log daily,” Lukas said. “Mandatory. Thirty seconds. If you can’t do thirty seconds, you’re not leading anything.”

Chairs shifted. Sharp inhales. The sound of comfort dying.

Good. Let them be offended.

Katja felt it. Momentum.

Not comfort. Terrifying, actually. But movement.

Movement was enough.

Thursday, 19:12 — Katja’s Apartment

"Leadership discovered the truth. Now it had to survive contact with reality."

Katja sat on her couch with Turing pressed into her side and Lovelace judging from the armrest.

The apartment smelled like cold coffee and burnout. No smoke. No broken glass. No headline. Just yesterday’s mug on the counter. A hoodie on the chair because folding it required energy she didn’t have. The faint, stale heat of a laptop that spent too many evenings being her second office.

Outside, the city kept doing what it always did. Trams whining at corners. Somebody’s bass leaking through a wall like a bad neighbor and a worse DJ.

Katja let her head sink back for three seconds.

Three seconds was what leadership thought “logging” should cost. Thirty seconds, if they felt generous.

She scratched Turing behind the ears and felt the soft, insistent pressure of him pushing back. Warm. Real. Unimpressed by org charts.

Lovelace blinked slowly, the way cats do when they think you’re being ridiculous.

Fair.

The meeting still sat in her chest. The offended sounds. The chairs. The moment Lukas stopped performing and watched people flinch.

Momentum. Terrifying.

The kind that only happens when someone stops performing and starts deciding.

She opened Navigator.

The second synthesis was already forming.

Same signals. Same blockers. Same story, louder.

The difference was subtle.

More voices.

More overlap.

More repetition.

The same signals, louder.

She scrolled with one thumb, slow enough to pretend she was calm. She wasn’t.

Hassan as bottleneck.

Waiting.

Manual deploy.

Requirements churn.

And now a new one.

Hiring / onboarding risk.

Ten new developers.

It sounded like relief in a board deck. It sounded like load in real life.

Katja could already see it. The first week: cheerful introductions, passwords that didn’t work, access requests nobody answered because “the process,” and Hassan being dragged into every tiny thing because he was the only one who could unblock anything.

The second week: frustration. The third: resignation.

And all the while, the leaders congratulating themselves for “moving fast.”

Katja’s phone buzzed.

Turing’s ears twitched. Lovelace didn’t move, which was somehow worse.

Slack.

A message from Lukas.

Lukas Weber New hires start Monday. I want Hassan protected time. I want an onboarding plan. I want you in the board call at 09:00. Don't let me bullshit. Bring the report.

Katja stared at the message.

Protected time.

He’d actually written it. Not “we should take care of him.” Not “we’ll figure something out.”

Words that could be measured. Words that could survive a calendar.

She felt her stomach drop.

Board call. Now.

Not next quarter. Not after the dust settled.

Fuck.

Board calls don’t want nuance. They want certainty. They want hiring to be a magic spell and execution to be a personality trait.

Navigator didn’t offer magic. It offered evidence.

Evidence tended to make powerful people angry.

She opened her notebook.

The pen hovered.

For a second she wanted to write something polite. Something safe. Something that would keep her employed.

Then she remembered the sound of comfort dying.

Good.

Wrote one line.

If he wants the truth, give him the truth.

Then she opened a new log entry.

And typed.

- Lukas finally read the synthesis.
- He mandated dept lead logging.
- Board call Monday.
- Ten new developers arrive whether we’re ready or not.
- This is the part where the system either changes, or it breaks us.

She hit send.

Turing purred.

Lovelace blinked slow, unimpressed.

Katja leaned back.

For the first time in a long time, she wasn’t guessing.

She was watching.

And that made the fear sharper.

Because now she could see what was coming.

Next Episode: "Boardroom Physics" Lukas brings the synthesis to the board. The numbers don’t care about optimism, and investors don’t care about excuses. Katja tries to explain absorption capacity without sounding like she’s asking for permission to slow down. Meanwhile, ten new developers walk in Monday morning, and the company discovers what onboarding looks like when your foundation is already on fire.

El Regreso

2026-03-05T00:00:00+01:00

Rain Over Mexico City

Rain hammered the windows of the taxi as it crawled through evening traffic on the Periférico. Valentina Reyes pressed her forehead against the cool glass, watching water stream down in rivulets that distorted the city lights into abstract patterns.

Five years. Five years since she’d left this city, this traffic, this overwhelming density of humanity and noise and life. MIT had been clean, orderly, predictable. Boston winters had been brutal, but at least they made sense.

Mexico City made no sense. It never had. That’s why she’d loved it.

“Primera vez en la ciudad, señorita?” the driver asked, catching her eye in the rearview mirror.

“No,” Valentina said softly. “I grew up here. Iztapalapa.”

His eyebrows rose slightly — she’d seen that reaction before. MIT credentials, professional clothes, English-accented Spanish. Nobody expected Iztapalapa.

Her phone buzzed. Her mother.

¿Ya llegaste, mija?

Valentina’s stomach clenched like someone had reached in and squeezed. Her thumb hovered over the keyboard, trembling. How do you tell your dying mother you’re not ready? That you left five years ago because you couldn’t bear to watch this city break her father, and now you’re coming back to watch it take her too?

Almost there, mamá. Rest. I’ll come see you tomorrow.

She sent it before she could overthink. Before the guilt could paralyze her again.

The taxi pulled up in front of a modern glass building in Santa Fe. LogiMex Systems. Third floor. She’d memorized the address from Don Rodrigo’s email.

Valentina, your father was like a brother to me. When I heard you were coming home, I knew — you belong here. We need you.

She paid the driver, grabbed her laptop bag, and stood in the rain for a moment, looking up at the building.

Her mother’s voice echoed in her memory, from years ago, before the diagnosis, when she’d first gotten the MIT scholarship: “Mija, you show them what we’re made of. You show them.”

Valentina squared her shoulders and walked into the lobby.

"Five years since she'd left this city. Now she was back."

El Patriarca

Don Rodrigo Mendoza’s office occupied the corner of the third floor, with floor-to-ceiling windows overlooking the city. The rain had intensified, turning the view into a watercolor of lights and motion.

He stood when Valentina entered, and for a moment she saw her father in his face — the same weathered dignity, the same hands that had built something from nothing.

“Valentina.” His voice was warm, tinged with emotion. “Look at you. Your father would be so proud.”

He came around the desk and embraced her, not the polite handshake of a CEO meeting a new hire, but the hug of a man who’d carried guilt for fifteen years.

“Thank you for the opportunity, Don Rodrigo,” Valentina said, stepping back, professional armor in place.

“No,” he said firmly. “Thank you for coming back. Sit, please.”

She settled into the leather chair across from his desk. Rain drummed against the windows.

“Your mother,” he said quietly. “How is she?”

“Brave,” Valentina answered, the word catching slightly. “Too brave.”

Don Rodrigo nodded, understanding more than she’d said. He reached for a photograph on his desk — a woman with kind eyes, laughing at some long-ago moment.

“My Esperanza. Six years now.” He set it down gently. “The grief doesn’t get smaller. You just grow bigger around it.”

Valentina felt tears threatening and forced them back. She wasn’t here to cry. She was here to code.

“Tell me about the system,” she said, changing the subject with mechanical precision.

Don Rodrigo’s face shifted into business mode. “Twenty-five years old. AS/400. Héctor Villanueva — you’ll meet him tomorrow — built it practically by himself. It runs logistics for 200 companies across Mexico, Colombia, Peru, the United States.”

“And now?”

“And now it’s dying.” He turned his monitor toward her, showing a spreadsheet. Red everywhere. “Three major clients gave notice last month. Cloud competitors are eating our lunch. We need to modernize. SaaS. APIs. All the things I don’t fully understand but know we need.”

Valentina leaned forward, scanning the numbers. “This is salvageable. The business logic — if it’s been running for 25 years, it’s solid. We refactor, we containerize, we—”

“Valentina.” Don Rodrigo held up a hand, smiling. “I hired you because I believe you. But there’s something you need to understand. This isn’t just code. It’s people. Héctor built this system. Mando, Rafa — they’ve given their lives to it. They’re terrified.”

“Terrified of what?”

“Of being obsolete. Of being replaced. Of watching everything they built get thrown away by kids with MIT degrees.”

The words landed like a punch. Valentina sat back.

“I would never—”

“I know,” Don Rodrigo said gently. “But they don’t. Not yet.” He stood, walking to the window. “My nephew Patricio — you’ll meet him Monday — he has a different approach. He’s bringing in a consultant. A German. Stefan Richter. Developer Advocate, whatever that means.”

“I know what it means,” Valentina said. “It means someone who writes production code embedded in teams. Someone who understands the reality, not just the theory.”

Don Rodrigo turned, surprised. “You approve?”

“Depends on the person. But the role? Yes. We’ll need someone who can bridge the gap. Between the veterans and the new architecture. Between the technology and the business.”

“Good.” Don Rodrigo returned to his desk. “Because you’ll be working closely with him. Patricio announces the hire at tomorrow’s all-hands meeting.”

Valentina nodded. Rain continued its steady rhythm against the glass.

“One more thing,” Don Rodrigo said, his voice dropping. “Your father. What happened at TransMex. If you ever want to talk about it—”

“I don’t,” Valentina said quickly. Too quickly.

Don Rodrigo studied her face, then nodded slowly. “The offer stands. Always.”

"This isn't just code. It's people."

The Server Room

After the meeting, Valentina wandered the office. Most people had gone home — it was past 8 PM — but she wasn’t ready to face her empty apartment yet. The one she’d rented sight-unseen, furnished in that anonymous way that said “temporary.”

She found the server room by accident, following the sound of humming machines down a back corridor.

The door was ajar.

Inside, a man sat on the floor, his back against an AS/400 rack, shoulders heaving with the ugly, gasping sobs of someone who had forgotten how to cry gracefully. Snot ran down his face. His body convulsed with each breath like something inside him was tearing loose — twenty-five years of repressed grief finally finding its way out through every pore.

Valentina’s stomach clenched so hard she nearly doubled over. She should leave. Give him privacy. But something about the absolute brokenness in his posture — the way he’d folded into himself like a man whose skeleton had finally given up, like a father burying his own child — made her step inside instead.

“Are you okay?”

The man’s head snapped up. He was in his fifties, graying hair wild and uncombed, face a mess of tears and snot and raw devastation, eyes so bloodshot they looked like open wounds. He scrambled to his feet, mortified, scrubbing at his face with hands that shook so violently he could barely control them.

“Chingada madre — who the hell are you?”

“Valentina Reyes. I start Monday. I’m sorry, I didn’t mean to—”

“Reyes?” His voice cracked like glass. “Antonio’s daughter?”

She nodded, surprised he knew.

“Héctor Villanueva.” He extended a hand, then realized it was trembling so badly he couldn’t control it and lowered it, humiliated. “Your father… he was a good man. I’m sorry.”

“Thank you.”

An awkward silence settled between them. The servers hummed their electronic lullaby.

“Were you… are you okay?” Valentina asked again, gentler this time.

Héctor laughed — a raw, ugly sound that scraped out of his throat. “No. No, I’m not fucking okay.” He gestured wildly at the machines surrounding them. “I built this. Twenty-five years. My blood. My marriage. My goddamn life. My wife used to say I loved these machines more than I loved her.” His voice shattered. “And you know what? Maybe she was right. Because now she’s gone and I’m still here, crying in a server room like a pathetic old man while they bring in consultants and kids with fancy degrees to tell me everything I created is garbage.”

“It’s not garbage,” Valentina said immediately. “If it’s run 200 companies for 25 years, it’s brilliant.”

“Is it?” Héctor’s face contorted with something between rage and despair. “Then why is everyone leaving? Why does Patricio look at me like I’m a dinosaur waiting to die? Like I’m already dead and just too stupid to lie down?” His voice cracked on the last words, and something in his chest seemed to collapse. “God, I’m so tired. I’m so goddamn tired of fighting.”

Valentina’s heart twisted. She stepped closer. “Because the world changed around it. That’s not your fault. That’s just… time.”

“Easy for you to say.” He wiped his nose with the back of his hand, dignity abandoned. “You’re what, thirty? You have time. I’m fifty-two years old. Fifty-two. Who the fuck is going to hire a fifty-two-year-old AS/400 developer? I can’t even get an interview. I tried. Three months ago, when I saw where this was heading. Not one callback. Not one.”

“LogiMex is,” Valentina said firmly. “We’re not throwing this away, Héctor. We’re transforming it. And I need you to help me.”

He looked at her, disbelieving. “You need me?”

“Nobody knows this business logic like you do. Nobody knows where the bodies are buried, where the edge cases are, where the genius is hiding in the code. I can write Python and TypeScript all day long, but I don’t know this. You do.”

Tears welled in his eyes again. “I haven’t written anything but RPG in twenty years.”

“So we’ll learn together.” Valentina smiled. “I’ll teach you Docker. You teach me why this works. Deal?”

Héctor stared at her for a long moment. Then, slowly, he nodded.

“Deal.”

They shook hands in the server room, surrounded by the humming machines that held 25 years of someone’s life.

Outside, the rain finally began to ease.

"Nobody knows this business logic like you do."

The One Who Waited

Monday morning arrived with brutal sunshine. Valentina dressed carefully — professional but not corporate, approachable but not informal. The balance mattered.

The all-hands meeting was scheduled for 10 AM in the main conference room. She arrived early and found a seat near the back, observing.

The veterans clustered together — Héctor, another older man with weary eyes who must be Mando, a third who radiated bitterness. The new generation sat scattered — a stylish woman who screamed money, a charming guy who screamed trouble, a quiet young woman with kind eyes.

And then there was Diego.

She knew him instantly, even though he’d changed. Filled out. Grown into his height. The skinny kid from the neighborhood who used to fix computers for beer money was now a confident man in a flannel shirt and well-fitted jeans.

He was staring at her.

Their eyes met across the room. His heart stopped. Literally — a skipped beat, a void in his chest that left him gasping. His face registered shock, recognition, and something raw and desperate — something that looked like five years of sleepless nights and unanswered prayers crashing into him all at once.

She smiled slightly. Gave a small wave.

His hands stopped working. The coffee slipped from his suddenly nerveless fingers.

The cup shattered on the floor, spraying dark liquid across the tile like a crime scene. Every head in the room turned. Diego’s face went from pale to crimson in the space of a heartbeat, his stomach dropping through the floor, his whole body frozen in that particular mortification of a man whose cool had just exploded all over his shoes.

“Shit. Fuck. Mierda. I’m… sorry. I’m sorry.” His hands were shaking as he dropped to his knees, desperately mopping at the mess with napkins that disintegrated on contact.

His voice cracked on the apology, and Valentina felt something twist in her chest. Five years, and he still couldn’t hide anything from her.

The kind-eyed woman — Mari, she’d introduce herself later — rushed to help him clean up. Diego kept glancing at Valentina, then away, then back, like he couldn’t quite believe she was real.

Valentina felt her own heart racing. They’d been friends, once. Before MIT. Before she’d left everything behind.

Before she’d left everyone behind.

The door opened and Patricio Mendoza strode in. Designer suit, expensive watch, hair gelled to perfection. He carried himself like someone desperate to be taken seriously.

“Good morning, everyone.” His voice was practiced, MBA-polished. “Thank you for being here. As you know, we’re facing challenges. Major challenges. But challenges create opportunities.”

He clicked a remote. A slide appeared: “LogiMex 2.0: World-Class Transformation.”

Valentina resisted the urge to roll her eyes.

“I’m pleased to announce,” Patricio continued, “that we’ve secured the services of Stefan Richter, a Developer Advocate from Germany with extensive experience in legacy system modernization. He’ll be joining us next week to lead our technical transformation.”

Murmurs rippled through the room. Héctor’s jaw tightened.

“Additionally,” Patricio said, smiling in Valentina’s direction, “we’re bringing on new talent. Valentina Reyes, MIT graduate with five years experience at Nexus Logistics Technologies in Boston. She’ll be our lead on the SaaS refactoring.”

All eyes turned to her. She nodded, professional smile in place.

Diego was still staring.

After the meeting ended, Valentina found herself surrounded by introductions. Mari — warm and welcoming. Camila — assessing her with shrewd eyes. Sebastián — charming but hollow. Mando — kind but cautious. Rafa — openly hostile.

And then Diego appeared at her elbow, hovering, nervous.

“Vale,” he said quietly. “It’s really you.”

“It’s really me, Diego.”

“I… when did you… I didn’t know you were coming back.”

“Neither did I, really. It happened fast.”

He nodded, processing. His hands were in his pockets, shoulders slightly hunched — the defensive posture of someone protecting themselves.

“How’s your mom?” he asked, and the gentleness in his voice hit her like a fist to the sternum, knocking the breath right out of her.

Something cracked in her chest. Tears threatened to spill, and she had to swallow hard, the lump in her throat so tight it hurt.

“Not great,” Valentina managed, her voice barely above a ragged whisper. “That’s why I came back.”

“I’m sorry. She’s… she’s a strong woman. I always liked her.”

“She always liked you too.” Valentina smiled, remembering. “Remember when you fixed her laptop? She made you three meals’ worth of tamales.”

“Best tamales I ever had,” Diego said, and for a moment his whole face lit up.

The moment stretched between them — not awkward exactly, but weighted with five years of silence.

“I should get to work,” Valentina said finally.

“Yeah. Me too.” Diego hesitated. “Maybe we could… get coffee sometime? Catch up?”

“I’d like that.”

He nodded, smile breaking through properly now. “Good. That’s… good.”

He walked away, glancing back once before disappearing around a corner.

Mari materialized at Valentina’s side. “That,” she said knowingly, “is a man who’s been carrying a torch for five years.”

“We’re friends,” Valentina said automatically.

“Mm-hmm,” Mari said, not believing her for a second. “Keep telling yourself that, amiga.”

"A man who's been carrying a torch for five years."

The German Arrives

The week passed in a blur of onboarding, codebase archaeology, and carefully navigating veteran developer egos. Valentina spent hours with Héctor, learning the intricacies of the RPG code. She spent equal hours with Diego, who walked her through the infrastructure — such as it was.

He’d built what he could on a shoestring budget. Jenkins running on a closet server. Git repos that were more hope than strategy. Deployment scripts held together with duct tape and prayers.

“I know it’s a mess,” Diego said apologetically on Thursday afternoon.

They were in his “DevOps corner” — a desk crammed with monitors in the back of the office.

“It’s not a mess,” Valentina said, studying the Jenkins dashboard. “It’s a miracle. You built this alone?”

“Nobody else cared about automation. They thought I was wasting time.”

“You weren’t.” She pointed at his deployment frequency chart. “Look at this. You’re deploying to test every day. That’s better than half the companies in Silicon Valley.”

Diego blushed. “It’s not that impressive.”

“Yes,” Valentina said, meeting his eyes, “it is.”

The moment hung between them. Diego looked like he wanted to say something, but the words wouldn’t come.

Valentina’s phone buzzed. Don Rodrigo.

Stefan arrives tomorrow. 2 PM. Can you pick him up from the airport? I’d consider it a personal favor.

She texted back agreement and showed Diego the message.

“The German,” Diego said neutrally.

“The Developer Advocate,” Valentina corrected.

“What’s the difference?”

“Hopefully? Everything.”

Friday afternoon, Valentina stood in the arrivals area at Benito Juárez International Airport, holding a sign that said “RICHTER.”

The man who emerged from customs didn’t look like a consultant. No expensive suit, no wheeled briefcase, no air of superiority. He wore jeans, a plain blue button-down, and carried a weathered backpack. His hair was graying at the temples, his face lined with experience and something heavier — grief, maybe, or exhaustion.

He saw her sign and walked over.

“Valentina Reyes?” His English carried a slight German accent.

“Stefan Richter. Welcome to Mexico City.”

They shook hands. His grip was firm but not performative.

“Thank you for coming to get me,” he said. “I know you must be busy.”

“Don Rodrigo asked. And I wanted to meet you before Monday’s chaos.”

“Wise.” He followed her toward the parking area. “Tell me truthfully — how bad is the situation?”

Valentina considered sugarcoating it. Decided against it.

“The code is solid but ancient. The infrastructure is held together by one DevOps engineer and divine intervention. The business is bleeding customers. The veterans are terrified. The new hires are arrogant. And Patricio Mendoza has no idea what he’s actually bought when he hired you.”

Stefan stopped walking. Looked at her appraisingly. Then he smiled — the first real smile she’d seen from him.

“Good. Then we have a chance.”

“A chance?”

“If you’d told me everything was fine, I’d know you were lying. Truth is the only starting point worth having.” He resumed walking. “Tell me about the people. Not the code. The people.”

As they drove through Friday afternoon traffic back toward Santa Fe, Valentina told him. About Héctor crying in the server room. About Diego building miracles from nothing. About Mando’s quiet steadiness and Rafa’s bitter brilliance. About Mari’s warmth and Camila’s armor and Sebastián’s charming hollowness.

Stefan listened without interrupting, asking occasional clarifying questions.

When she finished, he was quiet for a long moment.

“You care about them,” he observed.

“They’re people, not resources.”

“Yes,” Stefan said softly. “They are.”

They pulled up to his hotel. Stefan grabbed his backpack, then paused.

“Valentina. Thank you for your honesty. And for caring. This work — transformation — it fails when people treat it like code that happens to involve humans. You understand it’s humans that happen to involve code.”

“I learned that from my father,” Valentina said. “He was a truck driver. Fixed his own rigs. He always said: take care of the people, and the people take care of the machine.”

“Your father was wise.” Stefan stepped out, then leaned back in. “I look forward to working with you. I think we’re going to do good work together.”

He disappeared into the hotel.

Valentina sat in the parking lot for a moment, processing.

Her phone buzzed. Diego.

How’d it go? Is he an asshole consultant or an actual human?

She smiled and texted back: Actual human. I think we got lucky.

"Truth is the only starting point worth having."

Secrets in the Office After Dark

Sunday evening. Valentina sat in her mother’s hospital room, holding her hand while she slept. The monitors beeped their steady rhythm. The IV dripped. Time moved differently here.

Her mother’s eyes fluttered open.

“Mija. You’re still here.”

“Where else would I be?”

“Living your life.” Her mother squeezed her hand weakly. “How is the new job?”

“Good. Challenging. I met a man who knew papá. Don Rodrigo Mendoza.”

Her mother’s expression shifted slightly. Something Valentina couldn’t read.

“Don Rodrigo is a good man,” she said carefully.

“He speaks highly of papá.”

“Your father…” Her mother’s voice caught. “Your father was the best man I ever knew. Remember that, Valentina. Whatever anyone tells you. He was good.”

“Mamá, what—”

“Promise me.” Her grip tightened with surprising strength. “Promise me you’ll remember that.”

“I promise.”

Her mother relaxed back into the pillows, eyes drifting closed again. “Good. That’s good, mija.”

Valentina sat there long after her mother fell back asleep, wondering what secrets lived in those words.

Monday morning. Stefan’s first day.

The conference room was packed. Patricio stood at the front, beaming with self-satisfaction. Don Rodrigo sat at the table’s head, watching everything with those penetrating patriarch eyes.

Stefan entered simply. No fanfare. He shook hands with Don Rodrigo, nodded at Patricio, then turned to face the room.

“Good morning. I’m Stefan Richter. I’m here to help. Not to tell you what to do. Not to impose some framework. Not to replace anyone. To help.”

He let that sink in.

“I’ve spent the weekend reviewing your code. I’ve read Héctor’s architecture documentation — brilliant work, by the way.” He nodded at Héctor, who looked stunned. “I’ve looked at Diego’s deployment pipeline. I’ve studied your customer complaints and feature requests.”

Stefan pulled up a slide. It showed a single sentence:

“We will measure success by how much capability we transfer, not how much we do ourselves.”

“This is my only goal,” Stefan said. “When I leave Mexico City, you should be able to continue this work without me. If you can’t, I’ve failed.”

Silence in the room. This was not what they’d expected.

Rafa broke it. “Pretty words, German. But I’ve seen consultants before. You all say this. Then you charge a fortune, document nothing, and leave us with a mess.”

Stefan looked at him directly. “You’re right to be skeptical. Consultants have earned that reputation. So here’s what I propose: I will write production code alongside you. Every line I write, one of you reviews. Every decision I make, we make together. And everything — every pattern, every technique, every tool — I will document and teach.”

“Why?” Rafa challenged. “Why would you train your own replacement?”

“Because I’m not here to build a career,” Stefan said quietly. “I’m here to build capability. The sooner you don’t need me, the sooner I can go home to my daughter.”

He clicked to the next slide. A photo of a young girl, maybe ten years old, laughing on a swing.

“Sophie. She’s in Berlin with her mother. She’s sick. She needs treatments I can’t afford on a German salary. So yes, I’m doing this for money. But I’m good at this because I care about getting home.”

The room shifted. The honesty was disarming.

Héctor spoke up, voice rough. “What do you need from us?”

“Patience,” Stefan said. “Honesty. And trust. In that order.”

After the meeting, as people dispersed, Valentina found herself walking out with Stefan and Diego.

“That was risky,” Valentina said. “Showing them Sophie.”

“Was it?” Stefan glanced at her. “Or was it necessary? They needed to see me as a person, not a consultant.”

“It worked,” Diego said. “Even Rafa looked less murderous by the end.”

“Only less,” Stefan said dryly. “I’m under no illusions. I’ll have to earn every inch of trust.”

They reached the elevators. As the doors opened, Patricio appeared from a side hallway.

“Stefan. A word?”

Stefan nodded to Valentina and Diego. “I’ll catch up with you both later.”

In the elevator, Diego said quietly, “I like him.”

“Me too,” Valentina agreed.

“That thing about his daughter. That’s real pain.”

“Yeah.” Valentina thought of her mother, sleeping in a hospital bed. “It is.”

Diego looked at her. Really looked.

“Vale. If you ever need… I mean, I know about your mom. If you need someone to talk to. Or just… sit with. I’m here.”

“Thank you, Diego.” She reached out, squeezed his arm. “That means a lot.”

The elevator dinged. Doors opened. They stepped out.

Behind them, through the glass walls of a conference room, they could see Patricio talking animatedly at Stefan. Stefan’s face was neutral, giving nothing away.

“I wonder what that’s about,” Valentina murmured.

“Nothing good,” Diego said. “Patricio only gets that intense when he’s trying to control something.”

They were right to worry.

"I'm here to build capability, not a career."

The Call

That evening, Patricio sat in his office long after everyone had gone home. The city lights glittered below. His desk was immaculate — nothing out of place, everything controlled.

"Always interested, Patricio."

He opened his laptop. Navigated to an encrypted email.

Typed: The German is here. Too soft. Too slow. We need results faster. Are you still interested?

The reply came within minutes.

Always interested, Patricio. Send me the details. I’ll be on the next flight.

— Bruno Cavalcanti

Patricio stared at the email for a long moment. Then he clicked send on the invitation.

Behind him, through the window, storm clouds gathered over Mexico City.

Next Episode: "Primeros Pasos" Stefan begins workshops on TDD and CI/CD. The veterans resist. Valentina becomes his unlikely ally, translating not just language but culture. They work together on a "Hello World" deployment. It succeeds — their first victory. But Rafa explodes in grief over his dead son. And Patricio makes a fateful call: "Bruno, it's time."

Why Electricians Have Authority and Developers Don't

2026-03-03T00:00:00+01:00

When the Light Turns On, the Argument Ends

03.03.2026, By Stephan Schwab

Electricians work with objective pass/fail states, codified standards, and inspectable outcomes. Software developers work with fuzzy requirements, subjective success criteria, and invisible complexity. This difference explains why everyone has opinions about software but nobody argues with the electrician.

"Nobody hires consultants to transform how the electrician terminates connections."

A friend recently asked me why electricians don’t suffer the same problems software developers face. An electrician does an installation, it either works or it doesn’t, and that’s the end of the story. Nobody tries to control narratives about electrical work. Nobody schedules meetings to discuss whether the wiring is “aligned with business objectives.” Nobody hires consultants to transform how the electrician terminates connections.

When it comes to software, everyone has opinions. Project managers, executives, stakeholders three levels removed from the work, that guy in marketing who once built a WordPress site. They all feel qualified to weigh in on how the work should be done.

Why the difference?

The Gift of Objectivity

"The light turns on or it doesn't. There's no meeting to discuss whether it's 'on enough.'"

Electrical work enjoys something software development desperately lacks: objective pass/fail states.

Either the circuit is wired correctly or it isn’t. Either the light turns on or it doesn’t. Either the breaker trips when it should or it doesn’t. There’s no meeting to discuss whether the light is “on enough” or whether the circuit is “aligned with the strategic vision.”

Standards are codified in law. Color codes, cable types, breaker sizes, grounding requirements, protection schemes — all written down, tested, and enforced. Inspectors check compliance against explicit criteria. The variability of requirements is small. A 20-amp circuit feeding kitchen outlets is a 20-amp circuit feeding kitchen outlets. The electrician doesn’t get halfway through the job and hear “actually, we’ve decided it should also make coffee.”

This objectivity gives electricians something precious: authority. When the electrician says “that’s not up to code,” the conversation ends. There’s no negotiation, no alternative interpretation, no stakeholder alignment session. The code is the code.

The Curse of Subjectivity

"Fast enough for whom? Good enough compared to what?"

Software development operates in a different universe. Requirements are fuzzy, constantly changing, and often internally contradictory. One stakeholder wants speed, another wants stability, a third wants features that conflict with both. The requirements document — if one exists — was outdated before the ink dried.

What does success even mean? “Fast enough.” Fast enough for whom? Under what load? On what hardware? “Good enough.” Good enough compared to what? “Maintainable.” By what future team with what unknown skills?

There’s no universally enforced codebook. Sure, there are standards — coding conventions, security guidelines, architectural patterns — but none carry legal weight. Nobody inspects your repository and issues citations.

"Using an app makes people think they understand how it's built."

Here’s where it gets worse: everyone uses software daily. Your CEO uses an iPhone. Your marketing director uses Slack. Your board members use email. This familiarity creates an illusion of understanding. Using an app makes people think they understand how it’s built. It’s like believing you understand automotive engineering because you drive a car.

The cost of software mistakes is often delayed, invisible, or shifted. That architectural shortcut taken to hit a deadline? It won’t hurt until eighteen months from now when the team tries to add a feature. The security vulnerability? Silent until exploited. The technical debt? Accruing interest in the background, payable by some future developer who wasn’t in the room when the decisions were made.

The Visibility Problem

"You can't point to code the way you can point to a junction box."

When an electrician finishes work, you can see it. Wires terminate at boxes. Conduit runs along walls. Breakers sit in panels with labels. A non-electrician might not understand the details, but they can observe that work happened and roughly grasp what it does.

Software development produces invisible artifacts. Code lives in repositories that stakeholders never visit. Architecture exists as boxes and arrows on diagrams that approximate reality. The actual work — the logic, the data structures, the error handling, the edge cases — is hidden from view.

This invisibility creates a vacuum that narratives fill. When you can’t see the work, you need someone to tell you about it. And once you need stories about the work, you’ve opened the door to competing stories. Suddenly everyone has a narrative. The deadline narrative. The technical debt narrative. The “we just need to try harder” narrative. The “developers are too slow” narrative.

You can’t point to code the way you can point to a junction box and say “look, that’s what we built, that’s where we are.” Software status is always mediated through interpretation.

The Power Vacuum

"If nobody can verify whether software is 'good,' then whoever controls the narrative controls the perception of quality."

The combination of subjectivity and invisibility creates a power vacuum — and power vacuums get filled.

If nobody can objectively verify whether software is “good,” then whoever controls the narrative controls the perception of quality. Stakeholders want control because software affects their domain. Marketing wants features that support campaigns. Sales wants features that close deals. Finance wants predictability. Operations wants stability.

None of these stakeholders can evaluate the technical work directly. But they can evaluate narratives. They can judge whether the project “feels” on track. They can assess whether developers seem “responsive” to business needs.

This is why so much software development becomes performance. Status meetings aren’t about status — they’re about controlling perception. Demos aren’t about functionality — they’re about creating confidence. Velocity metrics aren’t about measuring productivity — they’re about providing something countable to put in slides.

What Electricians Don’t Face

"Nobody asks the electrician to estimate how many outlets they can install in a two-week sprint."

Electricians don’t face management frameworks. Nobody implements Scrum for electrical installations. Nobody asks the electrician to estimate how many outlets they can install in a two-week sprint and then tracks velocity over time. Nobody restructures the electrical contracting company into tribes and squads.

Electricians don’t face fashion cycles. There’s no thought leader circuit advocating that we fundamentally rethink how wires connect to terminals. Nobody sells certifications in the latest breakthrough approach to running conduit. The work changes when technology changes — when LED replaced incandescent, when smart home systems emerged — not because someone needed a book deal. As I explored in Management Frameworks and the Proximity to Snake Oil, the incentive structures in software consulting favor selling process over verifiable outcomes.

Electricians don’t face the assumption that speed requires shortcuts. When a building needs electrical work faster, you hire more electricians or pay overtime. You don’t ask the existing electricians to skip the grounding or use thinner wire. The code won’t allow it. The inspector won’t pass it. The building won’t function safely without it.

The Escape Route

"Objective signals that don't require interpretation."

So what can software development learn from electrical work? Not everything transfers — software genuinely is more complex and variable — but some things do.

Create objective signals. Continuous integration that passes or fails. Automated tests that execute or break. Deployment pipelines that either deliver working software or don’t. These aren’t perfect — they still require judgment about what to test and measure — but they’re more objective than status meetings and confidence votes.

Make work visible. Not through slides and reports — through working software. Deploy frequently so stakeholders can see what exists, not just hear about it. When the feature runs in production, the narrative competition ends. Either users can do the thing or they can’t.

Codify standards. Internal coding standards, architectural decision records, security requirements with automated enforcement. These won’t carry legal weight, but they establish expectations that reduce the space for interpretation.

Acknowledge what can’t be fixed. Some subjectivity is inherent to software. Requirements will change because the world changes. Success criteria will stay fuzzy because businesses operate in fuzzy environments. You can’t eliminate this — you can only stop pretending it doesn’t exist. Honest uncertainty is better than false precision.

The Core Difference

"Electrical work is fact-driven. Software development becomes narrative-driven."

Electrical work stays fact-driven, inspectable, and unaffected by fashion or management frameworks. The light turns on. The circuit is protected. The code compliance sticker goes on the panel.

Software development becomes narrative-driven because the work is invisible. Opinion-ridden because quality is hard to judge early. Management-controlled because measurable engineering discipline is often missing.

The next time someone asks why developers face interference that electricians don’t, you have the answer: electricians work with objective reality. Developers work in a narrative vacuum that everyone wants to fill.

The solution isn’t to become electricians — software genuinely is different. The solution is to create enough objective signals that the narrative vacuum shrinks. When the deployment pipeline is green, when production metrics show users completing their tasks, when the code passes every automated check — those become the facts that limit how much opinion can intrude.

Not every argument will end. But some will. And that’s a start.

Skip the Framework Cycle: A Case for Technical Capability

2026-02-28T00:00:00+01:00

The Alternative Nobody Sells You

28.02.2026, By Stephan Schwab

Organizations reach for management frameworks when delivery hurts. But the pain is usually a capability gap, not a process gap. Invest in the people doing the work — help them build genuine engineering discipline — and the framework becomes unnecessary. Here's the cycle that unfolds when organizations reach for process instead, and the exits available at every stage.

Before we map the framework adoption lifecycle, let’s be clear about what actually works: teaching the people who build software how to build it better.

Test-driven development. Continuous integration that actually catches problems. Trunk-based development instead of branch hell. Specifications you can execute. Small batches. Fast feedback. These practices — taught by people who’ve done them, embedded in daily work — fix the problems that make delivery painful. They create the visibility, quality, and predictability that frameworks promise but never deliver.

No vendor sells this because there’s nothing to sell. No certifications to renew. No transformation roadmaps to bill against. No recurring license fees. Just patient work that compounds over time.

The framework lifecycle that follows isn’t inevitable. It’s what happens when someone decides “we need a process” instead of “we need to get better at this.” Understanding the pattern helps you see where you are — and find the exit before you’ve wasted years.

⤴️ Stop before you sign Before you sign that contract with the framework vendor, try something radical: spend the money on people who actually know how to build software. Not consultants who'll teach new meeting formats — developers who've shipped. Embed them with your struggling teams. Let them show, not tell. Within weeks your teams will be deploying more often. Within months, fewer bugs escape. And here's the part that'll surprise you: your developers will be happier. They'll want to show you what they've built. That never happens with framework rollouts.

A Word for the Managers

"Control in software comes from capability, not from process."

If you’re a non-technical leader reading this, I’m not here to make you feel stupid. You’re not the villain.

You’ve got a board asking why projects slip. Competitors shipping faster. Developers speaking a language you don’t fully understand. When a vendor shows up with case studies and a transformation roadmap — of course you listen. What else are you supposed to do?

Nobody taught you what actually makes software teams work. Business school didn’t cover it. The consultants had certifications to sell. So you reach for what’s available: structure, process, oversight. The problem is that software doesn’t respond to those tools the way other work does. Control in software comes from capability, not from process.

The pattern I’m about to describe isn’t meant to shame you. It’s meant to show you what’s actually happening — so you can make different choices. Every phase has an exit. The exits don’t require you to become technical. They require you to invest differently.

The Pattern That Keeps Repeating

"The specific framework changes, but the stories follow the same beats."

Conferences, speaker dinners, late-night hotel bars. The honest moments when practitioners compare notes. The specific framework changes — waterfall to Scrum, Scrum to SAFe, SAFe supplemented with OKRs — but the stories follow the same beats.

(Waterfall was never meant to be a thing. Winston Royce’s 1970 paper presented it as flawed. The industry read the diagram and skipped the warning. We’ve been doing that with methodologies ever since.)

When hundreds of independent accounts paint the same trajectory, you’re looking at a pattern. Understanding where you are helps you find the exit.

Phase 1: Pain and Salvation Shopping

"We need a proven framework to fix delivery."

Every framework adoption begins with genuine pain. Projects run late. Quality is inconsistent. Stakeholders feel disconnected from engineering. Nobody knows what will ship or when.

The pain is real. But so is the fear behind the search for solutions.

Put yourself in the VP’s shoes for a moment. The board wants answers. Competitors seem to ship faster. The engineering team speaks a language you don’t fully understand, and they keep asking for things you can’t evaluate — more time, more people, less “interference.” Your career is on the line. You need something you can point to. Something that shows you’re taking action.

When a consultant arrives with case studies, certifications, and a transformation roadmap — that’s a lifeline. It’s defensible. If it doesn’t work, you followed best practices. If it does work, you’re the hero who modernized the organization. The framework isn’t just a solution; it’s career insurance.

The language shifts accordingly. “We lack alignment.” “We need common practices.” “We need to scale what works.” These phrases signal organizational solutions because organizational solutions are what non-technical leaders know how to buy and defend.

Nobody’s being cynical here. The VP genuinely believes this will help. The consultant genuinely believes they’re providing value. The vendor genuinely believes their framework works. Everyone’s acting in good faith — and the trap is already set.

As I explored in Management Frameworks and the Proximity to Snake Oil, the structural incentives favor selling process models over verifiable outcomes.

⤴️ Exit available here Before signing the contract: ask for verifiable outcomes from reference customers. Not "improved morale" or "better alignment" — cycle time, deployment frequency, defect rates. If the vendor can't provide numbers, that tells you something. Consider investing half that budget in technical coaching instead.

One more thing: some frameworks actively undermine good technical practices. They’re built on the assumption that software development is manufacturing — predictable, repeatable, controllable through process. Watch what happens when a team wants to pair program instead of attending status meetings. Watch what happens when developers want to refactor before adding features. The framework’s defenders will find reasons why those practices “don’t fit the model.”

If software development is complex — requiring judgment, skill, and constant adaptation — then you can’t scale it through process standardization. You need capability. And capability is harder to sell.

Phase 2: Framework Adoption Theater

"If we implement it correctly, results will follow."

The New Org Chart
Scrum Masters, Product Owners, Release Train Engineers, Solution Train Engineers, Agile Coaches, Enterprise Agile Coaches, Lean Portfolio Managers, Value Stream Engineers, Epic Owners, Iteration Managers, Delivery Managers, Agile Program Managers, Chapter Leads, Tribe Leads, Guild Coordinators, Transformation Leads, Change Agents, DevOps Evangelists, Platform Advocates, Site Reliability Engineers, Cloud Architects, Technical Program Managers, Agile Delivery Leads, Flow Managers, Value Stream Architects, Business Agility Consultants, Kanban Coaches, Lean Coaches, OKR Champions, Continuous Improvement Leads, Enablement Coaches — and people whose job is to coordinate the coordinators.

Rollout begins with genuine optimism. New roles appear — look at the box to the right for a sample. That’s not a parody. Those are real job titles from real transformation initiatives, and most organizations adopt a dozen or more of them. Ceremonies fill calendars. People get new titles, new responsibilities, new reasons to feel important.

This matters psychologically. The framework creates winners. The newly certified Scrum Master who was stuck in a dead-end QA role now has a career path. The project manager who feared obsolescence is now a Release Train Engineer. The consultant who spent years learning the methodology finally has paying clients. These people have real stakes in the framework’s success — their mortgages depend on it.

Teams dutifully rename things. User stories replace requirements. Sprints replace milestones. Story points replace time estimates. The vocabulary changes comprehensively.

But beneath the new terminology, the engineering remains largely unchanged. The same code gets written the same way. The same integration pain occurs. The same defects escape to production.

Here’s the tragedy: many people in the room know this. The senior developers see it. Some of the coaches see it. But saying so is career suicide. The framework has executive sponsorship. Millions have been spent. Questioning it publicly means questioning the judgment of people who control your future.

So everyone performs. Activity increases visibly. Outcomes don’t change measurably. And nobody with power wants to hear that.

This gap between ceremony and capability is where management frameworks diverge from what actually fixes software teams. The framework provides structure for coordination — coordination that might not even be needed. Many organizations adopting heavy frameworks are too small to require them. Teams building one-off internal tools or maintaining stable products rarely need cross-team synchronization ceremonies. But the framework doesn’t ask whether coordination is your bottleneck. It assumes coordination is everyone’s bottleneck, because coordination is what it sells. Meanwhile, the framework doesn’t teach test-driven development, doesn’t establish continuous integration discipline, doesn’t refactor legacy architecture, doesn’t build deployment automation.

⤴️ Exit available here The ceremonies are running. Now ask: what technical practices changed? If teams adopted new meeting formats but the same code gets written the same way, pause the rollout. Redirect resources to one team. Give them a technical coach, not a process coach. Watch what happens to their deployment frequency and defect rate. Let evidence guide expansion. Remember: they're called frame-works for a reason. The frame exists to hold something. If yours is empty — if you've got the ceremonies but not the technical practices — you bought a picture frame without the picture. The good news: it's not too late to fill it. I saw both paths at Nationwide Insurance.

2008: I put my laptop on a manager's desk and said, "When you want to deliver software, call me." That night, a different team wired $10,000 to bring me on remotely.

2009: I came back on-site. After one Sprint — two weeks — we presented to a room full of stakeholders. We'd built an underwriter app using the walking skeleton pattern: enterprise login working, PDF generation working, the whole end-to-end flow in place. The room went quiet. They'd expected a plan, maybe some mockups. Instead they got software they could log into and use. Same organization. Different choice. Different outcome.

Phase 3: Metrics Pressure and Compliance Mode

"People aren't doing it properly."

When results fail to materialize, the pressure flows downhill.

The executive who sponsored the transformation can’t admit it’s not working. Their reputation is attached. So when the board asks why delivery hasn’t improved, the answer has to be “implementation challenges” or “cultural resistance” — not “the framework doesn’t address our actual problems.”

If the framework is correct by definition, any failure must be human failure. Metrics become weapons. Velocity becomes a performance indicator. Sprint commitments become contracts. Dashboards multiply — not for insight, but to identify who’s not complying.

Teams respond rationally. Story points inflate. Definitions of done soften. Green dashboards proliferate while actual delivery capability remains unchanged. Nobody’s lying, exactly. They’re surviving.

More governance appears. Change advisory boards. Architecture review committees. Approval chains. Each layer adds friction while providing the illusion of control. The organization is now reaching for process when it needs sight.

⤴️ Exit available here If you're adding metrics layers, stop and ask: are we measuring what we actually care about? Velocity is noise. Story points are internal fiction. Even raw time estimates become fiction once people learn where to cut corners to finish within the constraint. Instead: how long from idea to customer hands? How often do defects escape to production? Are customers using what we ship? These questions don't require framework compliance — they require visibility into reality.

Phase 4: Reality Collision

"Why isn't this working?"

Eventually, reality becomes undeniable. A major release fails publicly. A critical deadline slips catastrophically. A key customer escalates to the board. The comfortable fictions collapse.

This is often the most painful moment for the leaders involved. The executive who championed the transformation faces a brutal choice: admit the approach was wrong, or double down. Admitting failure means losing face — possibly losing their job. It means acknowledging that millions were spent on something that didn’t work. It means the people who warned them were right.

Most people can’t do that. Not because they’re bad people, but because human psychology doesn’t work that way. We protect our self-image. We rationalize. We find external explanations. “The teams weren’t ready.” “We didn’t have enough executive support.” “The culture wasn’t right.” Anything but: “I made a mistake.”

The problems were always there: monoliths requiring coordinated releases, test data that takes weeks to set up, build processes taking days instead of hours. The framework papered over them with activity. Now they’re visible — described as “dependencies,” “QA bottlenecks,” “technical debt.” Safe language that blames systems, not decisions.

This is a decision point. The organization can acknowledge that the real work — engineering capability building — remains undone. Or it can double down on the framework.

Most organizations double down. Because the people making the decision are the ones who’d have to admit they were wrong.

Here’s a face-saving alternative: let a tool tell the story. When Caimito Navigator surfaces that deployment frequency dropped while ceremony overhead doubled, or that the teams ignoring the framework ship three times faster than the compliant ones — the data becomes the messenger. Nobody has to confess personal failure. The evidence simply makes the next step obvious. Leaders who couldn’t admit “I was wrong” can say “the data shows we need to adjust.” Same pivot, preserved dignity.

🚨 Critical exit point This is your best opportunity. The pain is undeniable. The framework defenders are momentarily quiet. This is when investment in engineering capability actually lands. Find the teams that work despite the dysfunction. Ask them what they'd need to spread their practices. Fund that. Not more process — more capability. Better yet: use the same data that revealed the problem to justify the investment. When the numbers show that high-performing teams deploy ten times more frequently with half the defect rate, the business case writes itself. The CFO doesn't need a philosophical argument about craftsmanship — they need evidence that the investment pays off. Let the tool make that case. The window closes quickly.

Phase 5A: The Double-Down (Common Path)

"We need stricter implementation — or another layer."

Doubling down feels logical — and that’s the trap.

The executive thinks: “The framework must work — look at the case studies! Other companies succeeded. The methodology is proven. So the problem must be us. We need more discipline, more coordination, more oversight.”

This reasoning protects everyone’s ego. The vendor wasn’t wrong. The consultants weren’t wrong. The executive who signed off wasn’t wrong. The only thing wrong is execution. And execution can be fixed with more control.

Process layers multiply. A transformation office appears — staffed by people whose jobs depend on the transformation continuing. Centralized planning increases. Approval requirements grow. New middle roles emerge to coordinate the coordination.

Watch what happens to the people who built careers on the framework. The Agile Coaches double down on coaching. The Scrum Masters add more ceremonies. The SAFe consultants propose SAFe extensions. Nobody whose livelihood depends on the framework will ever tell you the framework is the problem.

Teams lose autonomy. Decision cycles lengthen. The organization becomes slower even as it adds more people explicitly tasked with making it faster.

And the best engineers start updating their resumes. They’ve seen this before. They know how it ends. The ones who can leave, do. The ones who stay learn helplessness — a rational response to an irrational environment.

Fatigue sets in across the organization. Eventually, someone suggests that perhaps a different framework would work better. The cycle prepares to restart — and nobody acknowledges that they’re about to repeat the same mistake with a different vendor.

Phase 5B: Local Rebellion (Also Common)

"Ignore the noise; deliver."

While official processes multiply, something interesting happens in the corners of the organization.

Some teams quietly do what’s necessary to actually ship software. Usually it’s a small group with a trusted manager who provides cover. They set up test automation the framework doesn’t require. They adopt trunk-based development despite official branching policies. They harden their CI pipelines. They slice work smaller than the prescribed story formats. They pair and mob to share knowledge the framework doesn’t transfer.

These teams succeed despite the framework, not because of it. And they pay a psychological price for it.

Their manager lives in constant fear of being “found out.” They have to perform compliance in public while practicing competence in private. They attend the ceremonies, fill in the dashboards, use the vocabulary — and then go back to doing what actually works. It’s exhausting. It builds cynicism. And it creates a quiet resentment toward the people who imposed this theater.

The developers on these teams become cynics too. They learn that leadership doesn’t actually want to know what works. Leadership wants compliance and plausible deniability. The developers protect themselves by never volunteering information, never suggesting improvements, never making waves. They do good work — but only in the shadows.

These teams become the “high performers” that leadership studies and tries to replicate. The replication efforts focus on the visible artifacts — the team structure, the meeting cadence, the tools — while missing the invisible reality: these teams succeed because someone gave them permission to ignore the official nonsense.

⤴️ Exit available here You have high-performing teams. Protect them. Don't standardize them into compliance. Instead, ask them to teach. Pair their engineers with struggling teams. Let them demonstrate practices, not present slides. Capability transfers through doing, not through frameworks about doing. What these teams discovered — often without anyone teaching them — is what belongs inside the frame. TDD, continuous integration, trunk-based development, small batches. The practices that make the framework optional. Learn from them. Invest there.

Phase 6: The Two-Speed Organization

"Some teams are high-performing; replicate them."

Organizations often stabilize in this two-speed state. A few teams deliver reliably. Most teams remain compliance-driven. And the politics get ugly.

The high-performing teams become both heroes and villains. Heroes because they ship. Villains because their success asks an uncomfortable question: if they can do it, why can’t everyone?

Pressure builds to “standardize” — typically by imposing the compliant teams’ practices on the high performers. The stated goal is consistency. The real goal is removing the embarrassing comparison.

This usually destroys the high performance without elevating the struggling teams. Everyone becomes equally mediocre.

The alternative — understanding why the winners win and investing in that capability broadly — requires acknowledging the framework was never the differentiator. Few executives can make that admission.

⤴️ Exit available here Resist the pressure to standardize by dragging high performers down. Standardize by lifting everyone up. The investment required is real: technical coaching, protected time for practice improvement, patience while capability builds. But it's cheaper than another framework cycle — and it actually works. Here's the irony: frameworks built on genuine lean principles — not the manufacturing-mindset bastardizations — actually make room for this. They're called frame-works for a reason. The frame is supposed to be filled with sensible technical practices. The investment goes there. Most organizations buy the frame and forget to fill it.

Phase 7A: The Turning Point

"We need capability, not ceremony."

Some organizations reach a genuine turning point. Leadership recognizes that what matters isn’t the framework but the underlying engineering and product learning capability.

Investment shifts explicitly to practices that actually change outcomes: TDD adoption with real coaching support. Pairing and mobbing as default working modes. CI/CD pipelines that enable multiple deployments per day. Refactoring as a continuous discipline rather than a periodic event. Small batches measured in hours, not weeks. Direct customer feedback loops that bypass the ceremony pipeline.

The framework doesn’t disappear. It becomes optional scaffolding — useful for some coordination purposes, ignored where it adds friction without value.

This phase is recognizable by its symptoms: fewer meetings, more technical work visible, faster integration cycles, fewer defects escaping to production. Teams talk about practices, not processes.

Phase 7B: Framework Replacement Cycle (Also Common)

"This framework was wrong; the new one will fix it."

The alternative to genuine capability building is simply starting over with a different framework.

New vocabulary replaces old vocabulary. New consultants replace old consultants. New training replaces old training. New metrics replace old metrics.

The codebase issues remain. The integration pain persists. The testing gaps endure. The architecture constraints continue.

The cycle restarts from Phase 1, often with leadership convinced that “this time is different.” After all, they learned from their mistakes with the previous framework.

What they learned, typically, is to avoid the specific failure modes of the old framework. What they didn’t learn is that the framework was never going to fix what ails them.

Phase 8: The Mature State

"Frameworks are tools, not identity."

A few organizations reach a stable mature state. They’ve learned to select practices based on constraints — flow requirements, quality needs, discovery challenges, architectural realities — rather than framework loyalty.

Governance exists but stays lightweight. Engineering discipline is strong and self-sustaining. Continuous improvement happens through direct feedback and experimentation, not ceremony cycles.

These organizations don’t discuss which framework they follow. They discuss what outcomes they’re pursuing and what practices best serve those outcomes.

They’ve internalized that software development is design work, not a manufacturing process to be optimized through better workflow management.

Recognizing Where You Are

"The lifecycle isn't destiny. Exit points exist at every phase."

The lifecycle isn’t destiny. Organizations can exit at multiple points. But exiting requires recognizing where you are.

If you’re in Phase 1: Question the diagnosis. Is this really a process problem? What specific engineering capabilities are missing? What would change if you invested in technical practices instead of organizational structure?

If you’re in Phase 2 or 3: Measure what matters. Not velocity or sprint completion — but cycle time from idea to production, defect escape rate, deployment frequency, and whether customers actually use what you ship.

If you’re in Phase 4: This is the opportunity. The real problems are visible now. Resist the temptation to add more process. Ask instead: what technical capabilities would actually address these constraints?

If you’re in Phase 5A: The double-down is failing. Look for the quiet rebels in 5B. They know what actually works.

If you’re in Phase 6: Study the high performers honestly. Not their ceremonies or tools — their engineering practices. Invest in spreading that capability, not standardizing the dysfunction.

Even AI Knows This Story

Ask any AI assistant to describe “the typical lifecycle of management framework adoption in software organizations.” The response will mirror what I’ve described here — because this pattern appears so frequently in the training data that any large language model has absorbed it. The cycle is that predictable.

The Stories Behind the Pattern

All of this sounds heavy. It is heavy. Careers derailed. Trust destroyed. Good people trapped in bad systems. Years wasted.

But here’s the thing: it also makes for great drama. And drama, sometimes, is easier to absorb than analysis.

Some of us have been turning these patterns into fiction — telenovela-style stories set in software companies. If you’ve made it this far and feel like you need a drink, the stories might be a better choice. They’ll make you laugh. They might make you angry. And somewhere between the romantic tension and the boardroom betrayals, the lessons sink in differently.

La Startup takes place in Bogotá. A fintech company that started with genuine innovation is now drowning in dysfunction. The lead developer has vanished. An Italian Agile consultant is selling snake oil to anyone who’ll listen. Don Hernando, the cattle rancher who bet his legacy on this startup, brings in a German Developer Advocate to find out what’s really happening. The question isn’t whether the company will survive. The question is whether anyone will tell the truth before it’s too late.

Código del Destino is set in Mexico City. LogiMex Systems built an empire on AS/400 legacy systems — for 25 years, their logistics software powered trucking companies across Latin America. Now they must modernize into SaaS or die. The same German Developer Advocate arrives to guide the transformation. But the patriarch’s ambitious nephew has other plans. Enter Bruno Cavalcanti: a Brazilian consultant with a seductive framework and a trail of destroyed companies behind him. There’s forbidden love at an equestrian club, veteran developers terrified of obsolescence, and a family legacy that might not survive the transformation. The framework lifecycle plays out in real time, but you’ll care about the characters first.

Both stories show what the analysis can only describe. The fear in a developer’s eyes when they realize their expertise is being discarded for someone else’s methodology. The quiet moment when a leader finally admits they made a mistake. The cost of silence. The possibility of redemption.

If the pattern in this article feels familiar, the stories might hit differently. Sometimes fiction is just truth with better dialogue.

The Alternative Path

"The answer was always skill. Craft. Understanding."

The lifecycle isn’t a prison. At any phase, organizations can exit by doing something radical: going back to basics.

This means investing in actual engineering capability. Test-driven development. Continuous integration with real automated testing. Trunk-based development. Executable specifications. The practices that high-performing teams have used for decades — the ones that management frameworks don’t even touch.

AI is now an accelerator for this path. Developers who understand fundamentals find AI tools extraordinarily powerful. The AI handles boilerplate and infrastructure glue. This frees developers to focus on what matters: understanding the problem, designing elegant solutions, ensuring quality.

A developer who understands HTTP, HTML, and CSS can use AI to generate exactly the frontend code they need — without the JavaScript framework that brings update hell, supply chain vulnerabilities, and thousands of lines of unknown code. A developer who understands SQL can use AI to write precisely the queries they need — without the ORM that hides what’s actually happening.

The path exists. The tools are better than ever. What’s required is the courage to admit that frameworks were never the answer. The answer was always skill. Craft. Understanding.

A Companion Role, Not a Critic

"You don't have to wait for catastrophe."

I share this pattern not to mock organizations caught in it. The pressures are real. But understanding the lifecycle helps. When you recognize Phase 3 emerging, you can choose differently. When Phase 4 arrives, you can seize the opportunity instead of retreating to Phase 5A.

Framework cycles eventually end. Not because organizations give up, but because they finally build the engineering capability that makes the framework optional.

There’s a cynical joke in our industry: “Organizations are most ready to learn when they have a near-death experience.” Don’t be like them. You don’t have to wait for catastrophe. The exit points are marked. The path is clear. Start walking.

The Slow Adoption

2026-02-27T00:00:00+01:00

Previously: "The All-Hands Disaster" — The post-mortem meeting turned into a circular firing squad. Katja realized leadership had no visibility into reality. At 02:00, she signed up for Caimito Navigator. By Friday, three people were logging.

Thursday, 08:26 — Katja’s Office

"If I can’t see reality, I’m just another loud idiot with a title."

Katja had learned to work in the gaps.

Not the healthy kind of gaps. Not the ones you take because you planned your day like a grown-up.

The gaps you steal between a Slack fire and a calendar ambush.

A build was running. Her laptop fan was screaming, the machine hot enough that she’d moved her coffee mug away from the vent. Somewhere in the open office, someone laughed like sleep was still a thing. The fluorescent lights buzzed overhead, too bright for her tired eyes. Her neck ached from hunching over her keyboard since 07:30.

Katja opened Navigator, her fingers moving automatically to the familiar bookmark.

No dashboard. No forms. No faux-psychology questionnaire asking how she felt about her journey.

Just a blank text box and a cursor. Simple. Almost too simple.

She typed fast, the way you type when you’re afraid you’ll be interrupted, her fingers flying across the keys.

- Standup devolved into blame again.
- Waiting for final assets, again.
- Hassan paged at 03:00, again.
- I spent 45 minutes explaining to Lukas that “faster” is not a mood.

She stared at the lines for half a second, her stomach twisting slightly.

They looked stupid. Small. Petty. Like complaining instead of leading.

But they were true. And that had to count for something.

Katja hit send before she could second-guess herself.

A second later, Slack lit up with a notification sound that made her jaw clench.

Lukas Weber Need you in 10. Conference room. Hiring plan.

Of course. Of fucking course.

Katja closed her eyes, her shoulders sagging. Counted to three. Breathed. Opened her eyes.

Another day. Another attempt to catch signal in a room full of noise.

10:11 — One-on-One With Mariana

"You’re wearing Sepultura to a CTO meeting. Respect."

Mariana walked in late by exactly two minutes, hair still damp from a shower, laptop under one arm, and a black T-shirt screaming SEPULTURA in cracked white print. She smelled faintly of coffee and cigarette smoke.

Katja’s mouth twitched.

Mariana noticed immediately, her eyes narrowing. “What?”

“Nothing.” Katja nodded at the shirt. “Sepultura. Bold choice for a one-on-one.”

Mariana shrugged. “It’s just a shirt.”

“It’s not just a shirt.” Katja leaned back. “I’ve got an Opeth vinyl collection that takes up an entire shelf. My ex used to call it my ‘sad Swedish men corner.’”

Mariana blinked. Then laughed, quick and surprised. “Opeth? Seriously?”

“Don’t judge me.”

“I’m not judging.” Mariana sat down, grin fading back into her usual guarded expression. “Okay. Why am I here? Besides music taste confession.”

Katja slid her laptop around, the screen’s reflection catching in Mariana’s eyes.

Navigator was open. A single text box. Nothing else.

Mariana squinted, leaning forward. “That’s it?”

“That’s it.”

Mariana stared like she was waiting for the second screen to load, her brow furrowing. “Where’s the… I don’t know. The framework? The questions? The ‘rate your happiness from one to ten’ bullshit?”

Katja’s smile turned sharp. “Exactly. None of that.”

Mariana leaned forward. “So what does it do?”

“You write what happened. In your words. Short. Honest. No performance.”

Mariana’s eyes narrowed. “And then?”

“And then the system synthesizes it weekly. It turns chaos into something you can actually talk about.”

Mariana sat back, arms crossing defensively over the Sepultura logo. “Sounds like another management tool.”

“It’s a reality tool,” Katja said, holding her gaze. “Management tools are for pretending. This is for catching what’s actually happening before it turns into another 2.1-star week.”

Mariana looked unconvinced, her jaw set. “And who sees what I write?”

“You write whatever you want to share,” Katja said. “Everyone logs, and the system creates a factual weekly report with recommendations and conclusions. It catches the stuff that keeps biting us while Lukas thinks we’re ‘moving fast.’”

Mariana’s jaw clenched at the name, a muscle twitching beneath her cheekbone.

Katja watched her for a moment, then leaned forward slightly. “Mariana. You know that all-hands? Half the room knew what was wrong. The other half had power. That’s a broken system. I can’t fix it blind.” Her voice was quieter now, almost pleading.

Mariana exhaled through her nose. “Fine. I’ll try it. But if this becomes HR theatre, I’m out.”

“Deal.”

Mariana took the laptop, her fingers hesitating over the trackpad before clicking into the text box. She stared at the empty cursor for a long moment, then typed with two fingers like she was suspicious of the keyboard, hunting and pecking deliberately.

- Inventory fix merged, but QA can’t validate because test environment is still broken.
- Waiting for art assets for the new tutorial flow.
- Got asked to “just quick change” requirements in the middle of implementation.
- I’m tired.

She paused, her finger hovering over the backspace key, then deleted the last bullet with three quick taps.

Katja noticed, her eyes tracking the movement. “Leave it.”

Mariana shook her head, not looking up. “No. That’s not data. That’s complaining.”

“It’s still true,” Katja said quietly. “And it matters. But write it how you can live with it.”

Mariana’s fingers hovered over the keyboard, frozen for a moment, then replaced it with something more clinical.

Running on five hours of sleep. Reaction time is shit.

She hit send, her finger clicking harder than necessary.

For a second, she looked almost embarrassed, her cheeks flushing slightly as she pushed the laptop back toward Katja.

Katja nodded once. “Welcome to the cult.”

“Don’t call it a cult,” Mariana said.

“Fine. Welcome to the only honest thing we’ve tried in months.”

11:42 — Hassan’s Corner

"If I’m the blocker, I want it written down. By everyone."

Hassan’s desk looked like a crime scene.

Empty energy drink can, the aluminum dented. Two cold coffees in mismatched mugs, one with a lipstick stain that definitely wasn’t his. A notepad full of IP addresses and half-legible Arabic swearing in fading blue ink. The air around his workspace smelled like stale caffeine and the particular stress-sweat that came from overnight pager duty.

Katja didn’t ask when he slept. The answer would just make her angrier.

She tapped the edge of his monitor gently. “You got a minute?”

Hassan didn’t turn around, his eyes fixed on the terminal displaying a scrolling log of errors. “If the servers give me one.”

Katja waited until the alert sound stopped, a shrill beep that made her wince.

He leaned back, rubbed his face hard with both hands, the gesture pulling at his skin. Dark circles shadowed his eyes. “Okay. Minute. Go.”

“I want you logging in Navigator.”

Hassan blinked. “You want me to write diary entries now?”

“Not a diary. Reality. You’re in every conversation, Hassan. You’re everyone’s dependency and nobody’s planning around it.”

Hassan’s mouth pulled into something that wasn’t quite a smile. “So you want to prove I’m drowning.”

“I want to stop pretending you’re not.”

He stared at her for a long beat. Then: “Fine.”

He opened the site, the screen reflecting in his tired eyes. The same empty text box.

“No prompts?” he asked, one eyebrow raising slightly.

“No prompts.”

Hassan started typing with the calm precision of someone who’d long stopped believing in miracles, his fingers moving steadily across the keyboard.

- Pager at 03:07 for CPU spike. Root cause: analytics job running on wrong schedule.
- Asked to set up staging parity again. No time, no help.
- Got pulled into three meetings about hiring. Still on call.
- Everyone wants releases faster. Nobody wants to maintain the pipeline.

He hit send without hesitation.

Then he looked at Katja like she was the one being tested, his eyes sharp despite the exhaustion. “If this becomes a feel-good dashboard, I’ll burn it down.”

Katja nodded, meeting his gaze steadily. “Same.”

Hassan turned back to his terminal, his shoulders already hunching back into their defensive posture. “Also, tell Lukas to stop promising release dates in marketing meetings.”

“Already tried.”

Hassan laughed once, short and bitter. “Then write that down too.”

Friday, 16:08 — Leadership Meeting

"Another tool. Another meeting. Another way to avoid the real problem."

The leadership meeting smelled like stale coffee and fake optimism. The conference room’s air conditioning hummed unevenly, making one side of the room cold while the other stayed stuffy.

Katja stood at the whiteboard, marker in hand though she hadn’t written anything yet. Lukas sat at the head of the table, hands folded, spine straight, looking like a man who’d decided he was going to win through sheer willpower.

Around them: Lars with his designer glasses and his permanent calm, tapping a pen against his notebook. Carmen with her arms crossed, eyes daring anyone to call her department slow. Claudia already halfway through her phone, thumb scrolling. Daniel looking tired enough to cry, his hands wrapped around a coffee mug like it was the only thing keeping him upright.

Katja didn’t bother with slides. Her PowerPoint days were over.

She opened Navigator on her laptop, then turned the screen so everyone could see. The simple interface looked almost embarrassingly basic on the conference room’s large monitor.

“Here’s the interface,” she said, her voice steady. “You write what happened. Short. Honest. Blockers and outcomes. That’s it.”

Lars squinted at the screen, then at her, his pen pausing mid-tap. “And the value is… what? We already have Jira.”

Katja looked at him directly, holding his gaze. “Jira is where work goes to die. This is where reality goes to live.”

Carmen snorted, the sound sharp in the quiet room. “Sounds like therapy.”

“It’s not therapy,” Katja said, her voice sharpening. “It’s evidence. Weekly synthesis. Trends over time. Repeated blockers. Hidden dependencies.”

Claudia finally looked up from her phone, her expression skeptical. “So you want everyone to do more admin?”

Katja’s patience frayed, her hands tightening on the edge of the table. “Thirty seconds a day. While your build runs. While your render exports. You’re already losing hours to rework you could prevent with visibility.”

Daniel cleared his throat. “I’d do it.”

Carmen stared at him like he’d betrayed the tribe.

Lukas leaned forward. “I’m not mandating it company-wide,” he said. “Yet. But I want department leads to try. For two weeks. Then we review.”

Lars spread his hands in a gesture of helplessness. “I don’t have time to write logs. I’m designing an entire monetization overhaul.”

Katja’s voice went cold, each word deliberate. “If you don’t have thirty seconds to tell us what’s blocking you, you’re not leading. You’re performing.”

The room went quiet. Someone’s phone buzzed on the table, ignored. The air conditioning hummed louder in the sudden silence.

Carmen muttered in Spanish, low enough that only Katja caught it, her voice barely above a whisper. “Qué fastidio…”

Claudia sighed heavily, dropping her phone on the table with a soft thunk. “Fine. I’ll try. But if this shows up in some investor report, I swear to God.”

“It won’t,” Katja said firmly.

Hassan, sitting near the door like he was ready to escape at any moment, said flatly, his voice carrying the weight of too many broken promises: “If it does, I’m quitting.”

Lukas held up a hand, palm out. “It stays internal. That’s the point.”

Katja watched their faces, reading the skepticism in their tight jaws and folded arms.

One maybe. Two reluctant. The rest already dismissing it.

Most of them still saw it as a tool. Another burden. Another checkbox.

Not as a mirror. Not as the thing that might finally show them what they kept refusing to see.

Friday, 18:23 — “We’re Hiring Ten Developers”

"Speed is not headcount. Speed is flow."

The announcement hit Slack like a grenade at 18:23 on a Friday evening.

Lukas Weber We're accelerating. Hiring 10 additional developers immediately. Funding is secured. This is how we go faster.

Reactions exploded underneath within seconds.

Rocket emoji. Fire emoji. A few claps from people who didn’t understand what this actually meant.

And then the quieter reactions — the ones Lukas didn’t see.

Mariana sent Katja a private message:

Mariana Santos Ten? We can't even onboard one without chaos.

Hassan’s message was shorter.

Hassan Al-Rashid lol

Katja didn’t reply to either message. Her hands were shaking slightly as she closed Slack.

She walked straight into Lukas’s office without knocking, her footsteps sharp on the hardwood floor.

He looked up from his laptop, already annoyed, his jaw setting. “I knew you’d come.”

Katja didn’t sit. She stood in front of his desk, hands at her sides, forcing them to stay still. “We can’t onboard ten developers.”

“We can,” Lukas said, closing his laptop with a soft snap. “We have money. We need speed.”

Katja felt something in her chest tighten, her breathing shallow. “Money buys contracts. It doesn’t buy absorption capacity. Tomasz is already breaking. Hassan is underwater. Mariana’s one bad week away from telling you to go to hell.” Her voice was rising despite her efforts to stay calm.

Lukas’s jaw flexed. “So what do you propose? We do nothing?”

“I propose we stop confusing hiring with delivery,” Katja said. “And I propose you look at what’s already coming out of Navigator.”

Lukas leaned back. “Three people writing bullet points.”

“Three people writing the truth,” Katja snapped. Then she forced her voice down. “Even with three, the same things keep showing up. Waiting. Interruptions. Dependencies. Hassan. Rework. Meeting time.”

Lukas’s eyes narrowed, his hands flat on the desk. “Are you saying don’t hire?”

“I’m saying: if you hire, you also fund onboarding. Documentation. Mentorship time. Reduced scope. Otherwise you’re just pouring water into a bucket with a hole and calling it growth.” She could hear her pulse in her ears.

Lukas stood up slowly, deliberately. He was taller than her, and he used it the way men like him always used it — as pressure. He came around the desk, closing the distance between them.

“We’re hiring,” he said, his voice final. “I’ll talk to HR. We’ll ‘make an onboarding plan.’ But we need speed. The board wants progress.”

Katja’s hands curled into fists in her pockets, nails biting into her palms.

“Then you’ll get activity,” she said quietly, her voice barely controlled. “Not progress.”

Lukas stared at her, his face hardening. “You’re being dramatic.”

Katja laughed once, sharp and bitter. “I watched Carmen almost punch Lars last week. Dramatic is the company. I’m just documenting it.”

She turned and left before she said something that would get her fired, her footsteps echoing down the hallway.

Back at her desk, she opened Navigator again, her hands still shaking slightly from the confrontation. Her coffee had gone cold. The office was quieter now, most people already gone for the weekend.

The cursor blinked, steady and patient.

Katja typed, her fingers finding the keys with angry precision.

- Lukas announced hiring 10 developers to “go faster.”
- Told him we can’t absorb that without scope reduction and mentorship time.
- He overruled.
- This will hurt.

She hit send, the small confirmation message appearing briefly.

Across the room, Mariana stared at her screen for a long moment, then opened her own log with a few sharp clicks.

Hassan, without looking up from his terminal, the glow illuminating his exhausted face, muttered in Arabic: “Ya rab…” and typed too, his fingers moving mechanically.

Three people. Three tiny voices writing truth into the void.

Eighty-two ignoring it. Eighty-two still believing status meetings told them reality.

And the noise still screaming, drowning out everything that mattered.

Next Episode: "The First Synthesis" Katja receives the first weekly Navigator synthesis. Even with only three consistent loggers, the signals are impossible to ignore: single points of failure, constant waiting, and a leadership team burning hours in status theatre. Lukas reads it in silence — and realizes he's been steering blind.

Nuevo Amanecer

2026-02-26T00:00:00+01:00

Previously: "La Verdad" — The board meeting brought all secrets to light. Don Hernando confessed his mistakes and restored Sebastián as CEO. Alejo's betrayal was exposed — $847,000 from competitors — and he was fired. Isabella revealed she'd been documenting everything, protecting the company. Sebastián and Isabella finally admitted their love. But as one threat ended, another emerged: a mysterious player recruited Alejo to sabotage FinPulso's pilot and force a desperate acquisition. The game is far from over.

Dawn at FinPulso

Thursday, May 15. 5:47 AM. FinPulso office.

The team has been here all night. Not because anything is broken — the system runs flawlessly now, automated deployments humming every few hours like clockwork. They’re here because today is the day.

Ninety days ago, they launched the pilot program with three credit unions: Cooperativa San Rafael in Medellín, Credicali in Cali, and Unión Financiera del Valle. 47,000 members. Real people with real money who trusted a startup to handle their financial lives.

Today, the members vote on whether to continue.

Sebastián and Isabella arrive together, his arm draped around her waist in the casual intimacy of people who’ve stopped hiding. She leans into him as they walk through the door, and he kisses the top of her head without thinking about who might see.

"Nice of you two to show up."

Three months of navigating this relationship—the late nights that became mornings, the stolen moments in empty conference rooms, the slow realization that what they have is real—has changed them both. They’re softer with each other now. More open.

They had built something real. Today they would learn if it was wanted.

Camila notices them first, a knowing smile playing on her lips. “Nice of you two to show up.”

Isabella grins, unapologetic. “Traffic was terrible.”

“I bet it was,” Diego mutters, but he’s smiling too. In the past three months, the team has learned to stop pretending about many things. Including this.

Camila stares at the analytics dashboard. “First results should start coming in at 6:00 AM when Medellín opens.”

Diego sits beside her, equally tense. “The system can handle the load. We tested it.”

“I know.” She doesn’t look away from the screen. “But people aren’t systems. They’re unpredictable.”

Sebastián pulls Isabella down onto the couch that used to hold the ping-pong table. She settles against him, his arm around her shoulders, her hand resting on his chest. They’ve learned to be honest about many things in the past three months. Including this.

“Whatever happens,” she says quietly, her fingers tracing idle patterns on his shirt, “we built something we can be proud of.”

“I know.” Sebastián’s voice is tight. He presses a kiss to her temple, breathing in the scent of her shampoo—familiar now, comforting. “But I want people to actually use it. I want the taxi drivers and the shopkeepers and the people in Soacha to have the same tools that rich people in Rosales take for granted.”

Stefan sits at the back of the room, his laptop open to the monitoring dashboards. He flew in from Panama yesterday. “For what it’s worth,” he says, “you’ve built a delivery capability that most companies would envy. Fast feedback, low risk, high trust. That’s not nothing.”

“It’s not enough if nobody wants the product,” Camila says.

“Then you’ll learn what to build next,” Stefan replies. “That’s what the capability is for.”

Don Hernando arrives at 5:55 AM, Laura behind him. The old rancher looks different now — still imposing, but there’s a softness around his eyes that wasn’t there three months ago.

“Any news?” he asks.

“Five minutes,” Sebastián says.

The patriarch settles into a chair. “I called Miguel’s mother last night. Told her about what Isabella said. About how I wished he was something he wasn’t.” His voice cracks slightly. “She said she’d been waiting twenty years for me to realize that.”

Laura puts a hand on his shoulder.

“She said Miguel would be proud of what we’re doing now. The honesty. The actual engineering.” Don Hernando looks at Sebastián. “I think she’s right.”

The clock hits 6:00 AM.

The Numbers

Camila’s screen refreshes.

“Cooperativa San Rafael is reporting.” Her voice is barely a whisper. “Member survey results coming in.”

They all crowd around her laptop. A simple question: “Do you want to continue using FinPulso for your financial services?”

The numbers update in real time.

Yes: 73%
No: 18%
Undecided: 9%

The room is silent.

“That’s…” Diego starts, then stops. “That’s really good.”

“Wait for the others,” Camila says, but her voice is shaking.

6:15 AM. Credicali reports.

Yes: 81%
No: 12%
Undecided: 7%

Isabella covers her mouth. Tears in her eyes.

6:30 AM. Unión Financiera del Valle.

Yes: 69%
No: 22%
Undecided: 9%

Sebastián does the math in his head. “Combined, that’s 74.3% adoption across all three unions.”

“Mariana said we needed 65%,” Diego says. “We beat it by almost ten points.”

They had built something people actually wanted.

For a moment, nobody moves. Nobody breathes. The numbers glow on the screen like a verdict from God.

Then Camila lets out a sound — half laugh, half sob, half primal scream — and the dam breaks. She’s crying, laughing, her whole body shaking so hard she can barely stand. Diego pulls her into a fierce hug, and he’s crying too, tears streaming down his face as he rocks her back and forth.

“We did it,” she gasps into his shoulder. “Oh God, oh Dios mío, we actually fucking did it.”

Isabella buries her face in Sebastián’s chest, her shoulders heaving with sobs. He holds her so tight it hurts, one hand tangled in her hair, his own tears dripping into it. He’s making sounds he didn’t know he was capable of — ugly, broken sounds of relief.

Don Hernando rises slowly from his chair. The old patriarch — the man who buried his son, who risked his fortune on a dream, who learned too late to listen — crosses himself with trembling hands. His lips move in silent prayer. When he opens his eyes, tears roll down the weathered grooves of his face.

“Gracias a Dios,” he whispers. “Gracias a Dios. Gracias, Miguel. Gracias.”

Laura pulls him into an embrace. For once, he lets her.

Stefan watches them from the edge of the room. His own eyes are suspiciously bright. He wipes them quickly, pretending it’s the early-morning light. This is why he does this work. Not for the code. For moments like this — when people realize they can actually achieve what they thought was impossible.

The celebration is interrupted by Sebastián’s phone buzzing. A text from Mariana:

Mariana I saw the numbers. Call me in one hour. We need to discuss Series B.

He shows it to the team. More tears. More hugs.

But then another notification. This one from an unknown number:

Unknown Congratulations on the pilot. Unfortunately, your success has created a problem. Check your email. Time-sensitive offer. Respond within 24 hours or the offer expires — along with FinPulso's viability. You have no idea who you're dealing with.

Sebastián’s face goes pale.

The Offer

The email is from VentureCapital Global Partners. A firm Sebastián has never heard of.

The subject line: Acquisition Offer — $45M — Final and Non-Negotiable

He opens it. The team gathers around.

Dear Mr. Duarte,

Congratulations on your successful pilot program. Your technology shows promise, and your team has demonstrated capability.

VCGP is prepared to acquire FinPulso in its entirety for $45 million USD. This represents a 3x return for your Series A investors and a significant payout for all stakeholders.

Terms:

All-cash transaction

90-day close

Current management team retained for 12-month transition

No employee layoffs for 6 months

This offer expires in 24 hours. If not accepted, VCGP will pursue alternative strategies to enter the Colombian fintech market, including partnerships with your direct competitors and aggressive customer acquisition campaigns that will render your business model obsolete.

We look forward to your response.

Regards, Marcus Chen Managing Director, VCGP

“That’s a good offer,” Diego says slowly. “Three times return for the investors.”

“It’s also a threat,” Isabella says. “Accept or we’ll destroy you.”

Don Hernando is reading over Sebastián’s shoulder. “Who is VCGP?”

Stefan is already searching. “VentureCapital Global Partners. Singapore-based. Portfolio includes fintech companies across Asia and Latin America. Known for aggressive acquisition strategies.” He scrolls. “And here’s the interesting part — their Director of Strategic Acquisitions for Latin America, hired three months ago: Alejandro Vega.”

The room goes cold.

“Son of a bitch,” Sebastián says. “This is Alejo’s revenge.”

“No,” Stefan says, still reading. “This is Alejo’s job. VCGP doesn’t want revenge. They want FinPulso. The threat is real — they have the capital to make your lives very difficult if you refuse.”

Success had made them a target.

“What do we do?” Camila asks.

Sebastián looks at his team. Three months ago, they would have panicked. Made rash decisions. Lied to themselves about their options.

Now, he says the words that would have been unthinkable then: “We get expert advice. We don’t decide in a vacuum.”

The War Room

8:00 AM. Emergency video call.

On screen: Mariana, two other Vulcano Capital partners, a mergers and acquisitions lawyer, and a fintech consultant who specializes in valuations.

Mariana has already seen the VCGP offer. “Talk to me about what you want,” she says.

Sebastián glances at his co-founders. Isabella nods encouragement.

“Three months ago, I would have said we want to be the biggest fintech in Latin America. But that was ego talking.” He takes a breath. “What we actually want is to keep building tools that help ordinary people. We want autonomy to make technical decisions based on engineering reality, not board politics. And we want to work with people we trust.”

“Then don’t take the offer,” Mariana says simply.

“But the threat—” Diego starts.

“Is largely bluster,” the fintech consultant interrupts. “VCGP’s model is to buy promising companies, strip out costs, and flip them within three years. They’re good at it, but they’re not operationally creative. If you refuse, they’ll move on to easier targets.”

The lawyer chimes in. “The non-compete and transition clauses in their offer are concerning. Twelve months of retained management sounds good, but it really means twelve months where you can’t leave while they change everything you built. By month thirteen, you’ll be fired and prohibited from competing.”

Don Hernando leans forward. “So it’s a trap.”

“It’s a standard acquisition,” the lawyer corrects. “But yes, for founders who care about their product, it’s effectively a trap.”

Mariana looks at Sebastián. “Here’s what I’m prepared to offer: Vulcano Capital will lead a $12 million Series B at a $60 million valuation. That’s higher than VCGP’s offer. We’ll take two board seats. You maintain operational control. And we’ll support expansion to two more cities over the next year.”

“Why?” Sebastián asks. “VCGP is offering cash now. We’re still unproven.”

“Because in twenty years of investing, I’ve learned that culture and capability beat features and funding every time. You’ve built both. That’s rare.” She smiles. “Also, your pilot numbers are better than you think. 74% adoption in three months? Most fintech companies would kill for that.”

“What about VCGP’s threats?” Isabella asks.

“Let them come,” Mariana says. “They’ll burn money trying to acquire customers in a market where you already have trust and working relationships. You’ll deploy faster, learn faster, and adapt faster. That’s your moat.”

The consultant nods. “She’s right. Delivery capability is a competitive advantage. VCGP will be stuck in their acquisition integration process for six months while you ship improvements weekly.”

Stefan speaks for the first time. “You have a choice. Sell to Alejo’s employer and watch them optimize away everything you built. Or keep building, accept that growth will be slower, and trust that doing things right compounds over time.”

Sebastián looks at Isabella. She squeezes his hand.

“We’re not selling,” he says.

The Response

11:00 AM.

Sebastián sends the reply to Marcus Chen at VCGP:

Dear Mr. Chen,

Thank you for your offer. After careful consideration with our team and investors, we have decided to decline.

FinPulso will remain independent and continue building financial tools for underserved communities in Colombia. We wish VCGP success in finding alternative opportunities.

Please give our regards to Mr. Vega. We hope his new role brings him the success he’s seeking.

Regards, Sebastián Duarte CEO, FinPulso

He hits send before he can second-guess himself.

Ten minutes later, his phone rings. Unknown number. He answers.

“Sebastián.” Alejo’s voice. Smooth as ever. “You’re making a mistake.”

“Maybe. But it’s our mistake to make.”

“VCGP offered you a fortune. You’ll never see an offer that good again.”

“Probably not,” Sebastián agrees. “But we’ll still have the company. And we’ll still be able to look our users in the eye.”

There’s a long pause. Then, surprisingly, Alejo laughs. It’s not his usual calculated sound. It’s something almost genuine.

“You know what? Good for you. I mean that.” His voice cracks — just barely, but Sebastián hears it. The perfect mask slipping for just a moment. “I spent ten years optimizing for the exit. For the big payout. And you know what I have to show for it?” A hollow laugh. “A job working for people who see me exactly the way I saw FinPulso — as an asset to be extracted and discarded. I’m nothing to them. Just another pendejo who thought he was smarter than the game.”

"You're making a mistake. But it's your mistake to make."

“Alejo—” Sebastián starts.

“Don’t. I made my choices. You’re making yours. Just…” He pauses. “Tell Isabella she was right. About the notebook. About protecting what matters. I should have done that instead of trying to own it.”

The line goes dead.

Isabella, who’s been listening, has tears in her eyes. “Do you think he meant that?”

“I think he’s starting to realize what he lost,” Sebastián says. “Whether he does anything about it is up to him.”

The Celebration

7:00 PM. Cerro de Monserrate.

The entire team — all fifteen of them now, including three new developers hired in the past month — takes the funicular up to the mountain that overlooks Bogotá. The city sprawls below them, a sea of lights as the sun sets.

Don Hernando arranged for a private dinner at one of the restaurants. Nothing extravagant, but good food and the best view in Colombia.

“A toast,” the old rancher says, standing with his wine glass. “Three months ago, I stood in front of you and admitted I was wrong. That I’d taken something beautiful and nearly destroyed it with my ego.”

“Don Hernando—” Sebastián starts.

“Let me finish.” The patriarch’s eyes are wet. “Today, you proved that honesty works. That doing things right works. That caring about the people you serve works. My son Miguel believed that. I didn’t listen. But you did. And because of that, forty-seven thousand people have better financial tools than they had yesterday.”

He raises his glass higher. “To FinPulso. To building things that matter. And to the people brave enough to tell the truth even when it’s hard.”

“Salud!” the team echoes.

Below them, the city glowed. Above them, the stars emerged. Around them, trust.

They eat. They laugh. Stories are told — the all-night debugging sessions, the first successful deployment, the moment Camila’s risk-scoring algorithm went live and actually worked.

As dessert arrives, Stefan stands. “I have an announcement.” He looks uncomfortable, which is unusual for him. “I’m leaving FinPulso.”

The table goes quiet.

“Not because anything is wrong,” he says quickly. “Because everything is right. You don’t need me anymore. Camila is ready to be lead developer. Diego is handling architecture. You have practices, you have discipline, you have trust. My job here is done.”

Camila looks stricken. “But—”

“There’s a startup in Buenos Aires,” Stefan continues. “Healthcare technology. They’re in crisis. Making all the same mistakes FinPulso made six months ago. They need help.” He smiles. “And I think I can offer them what they need.”

Don Hernando nods slowly. “A man who fixes things and then moves on. I respect that.”

“Will you come back?” Camila asks, voice small.

“For the launch party when you hit a million users? Absolutely.” Stefan raises his glass. “To the next chapter. For all of us.”

Diego also stands. “I have news too.” He glances at Camila. “MiPago has offered me a position. Head of Engineering.”

The table stiffens. MiPago. The competitor.

“I’m taking it,” Diego continues. “Not because I’m leaving FinPulso behind. Because I want to prove that what we built here — TDD, continuous deployment, honest technical conversations — works everywhere. MiPago needs that. And…” he smiles, “I want to beat you in the market fairly. No espionage. No shortcuts. Just better engineering.”

Sebastián stands and extends his hand. “May the best team win.”

They shake. Former enemies. Current rivals. But also friends who learned the same hard lessons.

Three Months Later

August 20. FinPulso office. 3:00 PM.

The deployment dashboard shows the day’s twentieth deployment. The pipeline is a well-oiled machine now. Changes flow from idea to production in hours, not weeks.

Camila, now officially Lead Developer, reviews a pull request from one of the new team members. She leaves comments that are both technically precise and encouraging — lessons learned from Stefan.

Isabella is on a video call with credit unions in Barranquilla and Santa Marta. Expansion phase two. The pilot program there launches in two weeks.

Sebastián types the final sentences of his quarterly report to the board:

We are not the fastest-growing fintech in Latin America. We are not the most funded. But we are building something sustainable — technology that works, culture that learns, and relationships based on trust rather than promises.

This quarter: 73,000 active users. 1.2 million transactions processed. Zero production outages. Deployment frequency: 8.7 per day. Team satisfaction: 4.3/5.

Next quarter goals: Expand to two more cities. Launch mobile app. Begin work on international remittance features that our users have actually asked for.

We’re not chasing the billion-dollar exit. We’re building a company that our users need and our team believes in. That’s enough.

He reads it back, the numbers hitting him emotionally. Zero outages — a miracle three months ago. Deployment frequency up from 0.5 per day to 8.7. Defect escape rate down to 2%, user adoption at 74%. These aren’t just metrics; they’re proof of redemption. Proof that the lies, the burnout, the betrayals led to something better.

Camila walks by, sees him staring at the screen. “The report?”

“Yeah.” He turns to her. “Look at these numbers. We went from crashing demos to this. Because of you. Because of Diego. Because we finally did it right.”

She smiles, but her eyes are serious. “It’s not just the numbers. It’s that we trust them now. No more faking it for investors.”

Diego joins them, reading over Sebastián’s shoulder. “Defect rate at 2%. That’s… real quality.”

Pipe grunts from his desk. “About time we stopped breaking shit every other day.”

The team gathers around, sharing the metrics like a victory. Isabella checks her phone. “User feedback survey just came in. 4.8/5 satisfaction. They love the new features.”

For the first time, the success feels earned. Not promised, not inflated — built.

His phone buzzes. An email from an address he doesn’t recognize: m.vega.personal@gmail.com

He opens it.

Sebastián,

I’m writing from a personal account because VCGP monitors everything I send from work. They’re planning another run at FinPulso in Q4. Different strategy this time — they’re going to fund a competitor with your exact feature set and undercut you on pricing.

I thought you should know. Not because I owe you anything. Because Isabella was right — some things matter more than winning.

I quit VCGP yesterday. I’m not sure what’s next. But it won’t be this.

Take care of the company. It deserves better than what I tried to turn it into.

— Alejo

Sebastián reads it twice. Then forwards it to Mariana with a note: New threat. Let’s talk strategy.

No panic. No lies. Just information flowing to the people who need it.

He looks around the office. Camila explaining something to a junior developer. Isabella laughing on her call. The deployment dashboard showing another successful release.

This was what success actually looked like. Not perfect. But real.

This is what success looks like. Not the billion-dollar exit. Not the magazine covers. Just a team that knows what they’re building, why it matters, and how to do it right.

The deployment pipeline triggers another build. Green lights cascade down the screen.

His email pings. From an address he recognizes immediately: alejandro.vega@personal.com.

Subject: You should know something

Sebastián,

I quit VCGP yesterday. I saw their plans for the next acquisition attempt — it’s not what I thought I was signing up for.

They’re planning a coordinated regulatory complaint campaign combined with negative press. Make it look like FinPulso is unstable, then acquire during the crisis at a lower valuation.

I couldn’t be part of it. Whatever we were to each other, you built something worth protecting.

Watch for articles about “fintech risk” in the next few weeks. Be ready.

— Alejo

Even villains can choose to change the story.

Sebastián reads it twice. Forwards it to Isabella, Don Hernando, and Stefan.

The predators are still circling. But now he knows how to see them coming.

Isabella appears beside his desk. “Dinner tonight? There’s a new place in Chapinero.”

“As long as we don’t talk about FinPulso,” he says.

She laughs. “Deal. Though you know we will anyway.”

“Probably.” He saves the board report. “But at least now when we talk about it, we’re telling the truth.”

She kisses his cheek. “That’s progress.”

Outside the window, Bogotá continues its chaotic dance. The city that doesn’t care about their small victories. The city that will always have more problems to solve.

And somewhere in that city, forty-seven thousand people are using an app that actually works. Built by a team that actually cares. Deployed by a system that actually delivers.

That’s not nothing.

That’s everything.

The Email

One year later. Sebastián’s inbox.

From: investor-relations@unicorn-ventures.com Subject: Partnership Opportunity — $100M+ Series C Interest

Dear Mr. Duarte,

Unicorn Ventures has been following FinPulso’s growth with great interest. Your expansion to eight Colombian cities and consistent delivery metrics demonstrate exactly the kind of disciplined execution we look for.

We’d like to discuss leading a $100M+ Series C round to fund your expansion into Mexico, Peru, and Chile. Our portfolio includes successful fintech exits in three continents.

However, we have concerns about your current technical leadership structure and deployment practices. Our experience suggests that continuous deployment creates unnecessary risk for consumer financial products. We’d want to implement more controlled release processes as a condition of investment.

Are you open to a conversation?

Some choices define who you are. Some money isn't worth it.

Sebastián reads it. Remembers the lessons of the past eighteen months. Remembers what happens when you let investors override technical judgment.

He types his reply:

Thank you for your interest. However, our deployment practices are non-negotiable — they’re the foundation of everything else we’ve built. If that’s a problem, we’re probably not the right fit.

If you’re interested in learning why continuous deployment actually reduces risk rather than increasing it, I’m happy to have that conversation. But we won’t change our engineering practices to accommodate investment terms.

He hovers over send. Takes a breath. Clicks.

Isabella reads over his shoulder. “That might have just cost us a hundred million dollars.”

“Or it saved us from becoming something we’re not.” He turns to face her. “We good?”

She smiles. “We’re good.”

Season One Complete. The telenovela may be fiction, but the delivery principles are real.

The deployment dashboard shows another successful release. Number 3,247 since they rebuilt the system.

Outside, the sun sets over Bogotá. Inside, the work continues.

Some stories don’t end. They just find a sustainable rhythm and keep going.

Lessons from the Code

This story explored real challenges in software delivery through the lens of telenovela drama. Behind the affairs, the betrayals, and the board meetings lie genuine patterns we see in startups every day:

The Bus Factor — Diego's disappearance in Episode 1 exposed what happens when knowledge lives in one person's head. FinPulso learned to pair, document, and distribute expertise.

The Investor Dilemma — Don Hernando loved his son but didn't understand engineering. Alejo manipulated that gap. Real alignment requires executives who ask technical questions and developers who speak business language.

Framework Theater vs. Real Practice — Velocity charts and burn-down diagrams gave the illusion of progress while actual delivery suffered. Stefan didn't bring methodology — he brought TDD, CI/CD, and honest feedback loops.

The Cost of Lies — Every fabricated status report, every hidden problem, every "we're on track" when they weren't — it all compounds. Truth creates short-term pain but long-term trust.

Technical Debt as Organizational Debt — The codebase mirrored the culture: fragile, undocumented, dependent on heroes. Fixing the code required fixing how people worked together.

Sustainable Pace — The team saved FinPulso not through heroics but through daily discipline. Small deployments. Fast feedback. Incremental improvement. Sustainable beats spectacular.

Evidence Over Opinions — Sebastián won the final Series C negotiation not by arguing but by showing deployment frequency, user satisfaction, and defect rates. The numbers tell the story.

And beneath it all: Integrity. Not perfection — the team made mistakes constantly. But they learned to admit them, fix them, and move forward.

That's what software delivery is really about. Not the pitch deck. Not the funding round. The daily choice to build something real.

What Happened to Agile?

2026-02-24T00:00:00+01:00

The Frameworks Are Alive, But Something Died

24.02.2026, By Stephan Schwab

Scrum Alliance reports 1.5 million certificates issued. Scaled Agile has trained over a million professionals across 20,000 enterprises. PMI, the Agile Alliance, and dozens of certification bodies continue to run conferences, sell training, and expand globally. By every organizational metric, the management frameworks for software development are thriving. Yet something significant happened roughly a decade ago. Teams outside the USA can learn from it without repeating the experiment.

The Problem These Frameworks Were Created to Solve

The industry adopted exactly what Royce warned against, then named it after his paper.

In the 1980s and 1990s, most software projects followed “waterfall” — a sequential process borrowed from manufacturing. Analysts gathered requirements for months. Architects designed the complete system. Developers built it. Testers found the defects. Years later, software reached users.

The term “waterfall” comes from Winston Royce’s 1970 paper “Managing the Development of Large Software Systems.” But Royce presented the sequential model as a flawed approach. His paper warned that this method “is risky and invites failure” and advocated for iterative development with feedback loops.

The industry adopted exactly what Royce warned against, then named it after his paper.

In 1985, the U.S. Department of Defense institutionalized this misreading in DOD-STD-2167, requiring “sequential phases of a software development cycle.” It took the DoD nearly a decade to reverse course. In 1994, MIL-STD-498 explicitly encouraged “evolutionary acquisition and iterative and incremental development.”

Iterative development isn’t a recent invention. Gerald Weinberg documented teams using incremental approaches as early as 1957 at IBM. The practices that became “agile” weren’t discoveries — they were recoveries.

The manifesto, published in 2001, captured this insight in four value statements. Scrum provided a rhythm of short iterations. Extreme Programming emphasized technical practices: test-driven development, pair programming, continuous integration. Kanban focused on visualizing work and limiting work-in-progress.

The question is what happened between that original insight and today’s certification industry.

Who Actually Needed These Frameworks?

The practices that rescued C3 were discontinued — not because they failed, but because they didn't fit management culture.

Small teams building software products never needed elaborate process frameworks. A team of five developers working directly with customers, shipping weekly, doesn’t need Scrum ceremonies to stay aligned. They don’t need SAFe’s coordination layers because there’s nothing to coordinate.

The frameworks emerged for large organizations with many teams, complex interdependencies, and layers of management far removed from actual work.

The Chrysler Comprehensive Compensation (C3) project proves disciplined engineering works even inside large corporations. Started in 1993 as a payroll system for 87,000 employees, by 1996 the project had yet to print a single paycheck after three years of traditional development. Kent Beck was brought in and, with Ron Jeffries, introduced the practices that became Extreme Programming.

Within roughly a year of adopting XP, the system went live. It worked. Engineering practices — not a management framework — turned a failing project into a functioning system.

DaimlerChrysler cancelled the project in 2000 after acquiring Chrysler. A manager announced at the XP conference that DaimlerChrysler had “de facto banned XP.”

The practices that rescued the project were discontinued. Not because they failed, but because they didn’t fit the acquiring organization’s management culture.

The Original Crisis That Never Ended

Each failed methodology creates the market for its successor.

The “software crisis” was named at the 1968 NATO Software Engineering Conference in Garmisch, Germany. Software projects consistently ran over budget, over schedule, and often failed to work at all. As explored in Bridging the Great Divide, the fundamental misunderstanding between technical and non-technical people dates back to this same moment.

Edsger Dijkstra, in his 1972 Turing Award lecture:

“The major cause of the software crisis is that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.”

Software development isn’t manufacturing. It’s design work that doesn’t scale the way production lines do. Adding more people often makes projects later, not faster.

Large organizations responded with industrial management techniques: more documentation, more phase gates, more separation between thinking and doing. DOD-STD-2167 and its commercial imitators institutionalized exactly the approach practitioners knew didn’t work.

The ongoing software crisis — never resolved, still producing the same failure rates documented in the 1960s — creates perpetual demand for new process solutions. Each failed methodology creates the market for its successor. (For more on the proximity of management frameworks to snake oil, see the earlier article.)

The irony is that the original Agile Manifesto was written by practitioners explicitly rejecting management-centric approaches. They valued “individuals and interactions over processes and tools.” The opposite of what the certification industry eventually sold.

The Timeline of Disillusionment

"The Agile Industrial Complex imposing methods upon people is an absolute travesty." — Martin Fowler, 2018

Dave Thomas, one of the seventeen original Agile Manifesto signatories, in his 2014 article “Agile is Dead (Long Live Agility)”:

“The word ‘agile’ has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products.”

The public statements of the people who created these approaches:

2009: Ken Schwaber, co-creator of Scrum, leaves the Scrum Alliance after disagreements over “assessments, certification, and a developer program.” He founds Scrum.org the following year.

2013: Schwaber calls SAFe “unSAFe at any speed”:

“The boys from RUP (Rational Unified Process) are back. Building on the profound failure of RUP, they are now pushing the Scaled Agile Framework as a simple, one-size fits all approach to the agile organization.”

2014: Dave Thomas declares “Agile is Dead” and proposes retiring the term entirely.

2018: Martin Fowler, in his Agile Australia keynote:

“Our challenge at the moment isn’t making agile a thing that people want to do, it’s dealing with what I call faux-agile: agile that’s just the name, but none of the practices and values in place.”

And:

“The Agile Industrial Complex imposing methods upon people is an absolute travesty.”

2018: Ron Jeffries publishes “Developers Should Abandon Agile”:

“I would like the world to be safe for developers… it breaks my heart to see the ideas we wrote about in the Agile Manifesto used to make developers’ lives worse, instead of better.”

He recommends developers “detach their thinking from any particular named ‘Agile’ method” and coins “Dark Agile” and “Dark Scrum” to describe imposed, compliance-focused implementations.

These aren’t fringe critics. These are the architects of the original movement.

What Changed

The original manifesto values:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

The certification industry discovered that the right side sells better. Processes can be packaged. Tools can be licensed. Documentation can justify billing. Plans create contracts.

The left side — individuals, interactions, collaboration, responding to change — requires judgment and context. It resists standardization. It doesn’t scale as a product.

The industry built elaborate frameworks around the right side while claiming the mantle of the left.

Why This Matters Outside the USA

The framework commercial machine expanded globally with roughly a five to ten year lag. SAFe rollouts in Europe accelerated between 2015 and 2020. The same trajectory American software teams experienced is now repeating internationally.

Teams who haven’t yet committed to a framework purchase can observe what happened without paying for the lesson.

The 17th and 18th State of Agile reports show that 42% of organizations now use hybrid models, mixing agile practices with traditional approaches. Teams discovered that dogmatic adherence to any framework produces worse outcomes than thoughtful adaptation to context.

The Distinction That Matters

The frameworks remain useful as diagnostic tools. Scrum’s ceremonies can reveal dysfunction. SAFe’s architectural patterns can expose integration friction. Kanban’s visualization can surface bottlenecks.

The problem emerges when the framework becomes the goal rather than the lens. When “doing Agile” replaces “delivering value.”

The relevant question isn’t “Which framework should we adopt?” but “What specific capability do we need to develop?”

What Engineering Excellence Requires

"You aren't an agile programmer. You're a programmer who programs with agility." — Dave Thomas

When the manifesto authors describe what actually works, they return to technical practices: test-driven development, continuous integration, refactoring, pair programming, small batch delivery.

These practices don’t require certification. They don’t scale as consulting products. They require disciplined application over time.

Martin Fowler’s 2018 critique identified three challenges:

Fight the “Agile Industrial Complex”
Raise the importance of technical excellence
Organize around products, not projects

Notice what’s missing: framework selection, scaling patterns, governance structures. The path forward isn’t more methodology. It’s better engineering.

A Practical Stance

Engineering practices that produce observable outcomes: shorter lead times, lower defect rates, faster recovery from incidents, genuine user adoption. These metrics don’t care which framework you claim to follow. As discussed in Management Frameworks Don’t Fix Software Teams, frameworks diagnose symptoms while developers remove root causes.

When evaluating any proposed practice or transformation: “What will we be able to observe, in production, that we cannot observe today?”

If the answer involves dashboards, reports, or confidence votes rather than working software in users’ hands, you’re purchasing labels rather than capability.

The frameworks aren’t dead. But the semantic content that once made “Agile” useful has migrated elsewhere: into the quiet practices of teams who ship frequently, respond to evidence, and measure success by what their users actually experience.

For teams outside the USA now navigating these decisions: the ceremony doesn’t produce the outcome. The engineering practice does.

A caution: the same market dynamics that commercialized Agile will likely produce “post-Agile” alternatives targeting developing markets. Different branding, same business model — certifications, transformations, consultant dependencies. The lag between USA adoption and global expansion creates arbitrage opportunities. Skepticism toward the incumbents shouldn’t translate into trust for their critics-turned-competitors.

See for Yourself First

Before signing contracts with transformation consultants, consider observing what’s actually happening.

Most executives making decisions about software delivery have limited visibility into the work itself. They receive status reports, confidence votes, and velocity charts — none of which reveal whether software is reaching users or whether teams are struggling with integration friction, unclear requirements, or technical debt.

Caimito Navigator synthesizes what your teams are actually doing — from daily logbooks and delivery signals — into weekly insights that any non-technical manager can understand. No framework purchase required. No certification needed. Observed facts about your delivery reality.

The service includes conversations with experienced practitioners who can help interpret patterns and suggest targeted improvements. No buying pressure, no upselling to transformation programs.

Many organizations discover that their teams already know what’s broken. They just need someone to surface that knowledge to decision-makers who can remove obstacles. Sometimes the most valuable intervention isn’t a new process — it’s visibility into the process you already have.

The Gray Beard and the Machine

2026-02-21T00:00:00+01:00

When Twenty-Seven Years Feels Like a Liability

21.02.2026, By Stephan Schwab

Martin had been writing software for twenty-seven years when the machine arrived. At first it felt like replacement — another cycle of the industry discarding experience for something cheaper and faster. But what he discovered, alone at his desk one evening, changed everything he believed about his own obsolescence. This is a story about fear, about identity, and about what happens when the thing you thought would destroy you becomes the thing that reminds you who you are.

The message appeared in the team chat on a Tuesday morning: “Exciting news! We’re rolling out GitHub Copilot to all engineering teams. Training sessions start Thursday.”

Martin stared at the words. Around him, the open-plan office hummed with the usual sounds — keyboards, murmured conversations, someone’s phone buzzing. He was fifty-three years old. His hair had gone gray at the temples a decade ago and had since surrendered entirely. He had written his first program in BASIC on a Commodore 64, had survived the transition from mainframes to PCs, from desktop to web, from monolith to microservices. He had outlasted technologies that younger developers had never heard of.

But this felt different.

The Training Session

Thursday came. Martin sat in the back of the conference room, arms crossed, watching the enthusiastic young developer from the platform team demonstrate how the AI could generate entire functions from a comment.

“Watch this,” she said, typing: // function to validate email addresses using RFC 5322

The AI wrote thirty lines of code in seconds. The room made appreciative noises.

Martin felt something cold settle in his chest. It wasn’t the code itself — he could have written that function, probably better, with proper edge case handling. It was the speed. The effortless, mechanical speed.

For twenty-seven years, his value had been tied to knowing things. Knowing how memory allocation worked. Knowing why that legacy module behaved strangely on Thursdays. Knowing the difference between what the documentation said and what the system actually did.

Now a machine could summon that knowledge in milliseconds.

The room made appreciative noises. Martin felt something cold settle in his chest.

The Quiet Weeks

He didn’t use Copilot at first. He told himself it was principle — that he wanted to understand the code he wrote, not just accept suggestions from a statistical model. But late at night, when the apartment was quiet and his wife was asleep, he admitted the truth to himself.

He was afraid.

Afraid that if he tried it, he would discover he was already obsolete. That the decades of accumulated knowledge, the patterns burned into his nervous system, the instincts that let him smell a bug before the tests even ran — that all of it was now worthless. That a junior developer with an AI could outproduce him in an afternoon.

He watched his younger colleagues embrace the tool with the casual confidence of people who had never known a world without Google. They paired with the AI the way they paired with each other — naturally, without existential crisis.

Martin felt like a man watching his own funeral.

The Integration That Wouldn’t Die

Three weeks later, he was assigned to fix an integration with a payment processor. The integration was twelve years old, written by a contractor who had left no documentation and had apparently harbored a deep suspicion of comments. The code was a labyrinth of nested conditionals, magic numbers, and variable names like temp2 and finalFinal.

The junior developers had already tried. One had spent a week adding logging statements. Another had attempted to refactor the module and introduced a subtle bug that only manifested in production, three days after deployment, on transactions above €10,000.

Martin sat down with the code on a Friday afternoon. The office emptied around him. He barely noticed.

By midnight, he had mapped the control flow in his head. Not on paper — in his head, the way he had always done it, building a mental model of the system the way a chess player sees positions. He knew where the bug lived now. He could feel it, the way a doctor feels wrongness in an X-ray before they can articulate why.

But proving it would take hours of tracing values through the maze.

He looked at the Copilot icon in his editor. He had disabled it weeks ago. His cursor hovered over the settings.

The Conversation

He enabled it. Not because he had accepted anything. Because he was tired, and the bug was urgent, and he needed help.

He typed a comment: // this function calculates the retry delay but the documentation says exponential backoff while the implementation looks linear

The AI responded with an analysis. It was wrong — it had misread the nested loop structure — but it was wrong in a useful way. It forced him to articulate why it was wrong, which clarified his own thinking.

He corrected it. Asked a follow-up question. Got another partial answer.

It was like talking to a very fast, very knowledgeable junior developer who had no intuition and perfect recall. Someone who could fetch any fact instantly but couldn’t smell the bug.

He could smell the bug. He always could. That hadn’t changed.

What changed was that now he had a partner who could run alongside him, verifying his hunches at machine speed, checking edge cases he didn’t have time to trace manually, suggesting patterns he might have forgotten from frameworks he hadn’t touched in years.

By two in the morning, he had the fix. Not because the AI had found it — it hadn’t, couldn’t — but because the AI had done the mechanical work while he did the thinking.

By two in the morning, he had the fix.

The Morning After

He sat in the empty office as the sky lightened. The fix was committed. The payment processor was working.

He felt strange. Lighter.

For weeks, he had believed that the AI was his replacement — a cheaper, faster version of himself that would render his experience worthless. But that wasn’t what had happened. What had happened was that the AI had amplified his experience. The patterns he had spent decades building were still valuable, perhaps more valuable than ever. The AI had no patterns. It had probabilities. It could generate code that looked right but was subtly wrong in ways that only experience could detect.

The machine needed him. Not his keystrokes — those were cheap now. His judgment. His intuition. The thing he had built over twenty-seven years that no training dataset could replicate.

The machine hadn't made him obsolete. It had reminded him what he was for.

The Integration That Wouldn’t Die, Continued

"The machine needed him. Not his keystrokes — those were cheap now. His judgment."

The following Monday, the team lead asked how he had fixed the integration so fast. Martin hesitated.

“I used Copilot,” he said. The words felt strange in his mouth. “Not to write the code. To think out loud. It’s like having a very fast rubber duck that can also look things up.”

The junior developer who had introduced the production bug looked at him with an expression Martin couldn’t read at first. Then he recognized it: relief. The older developer wasn’t fighting the future. He was adapting.

“Can you show me how you use it?” the junior asked.

Martin nodded. And for the first time in months, he felt like he had something to teach that mattered.

For the first time in months, he felt like he had something to teach that mattered.

What Actually Changed

The fear didn’t disappear entirely. It never does. There will be another technology next year, and another the year after, and one of them might finally be the one that makes his skills truly obsolete. The industry is not kind to those who stand still. This pattern has repeated every decade since 1969 — the tools change, but the need for human judgment persists.

But Martin had stopped standing still. He had remembered something he had forgotten in the panic of the announcement: his value had never been typing speed. It had been the ability to look at a system and understand it, to see patterns that tools could not see, to make decisions that algorithms could not make.

The AI accelerated everything except the things that mattered most. And those things — judgment, intuition, the accumulated wisdom of twenty-seven years — those had become more valuable, not less.

The machine hadn’t made him obsolete. It had reminded him what he was for.

For the Gray Beards Reading This

"The machine hadn't made him obsolete. It had reminded him what he was for."

If you are reading this and you recognize yourself in Martin’s fear, I want to tell you something that might sound patronizing but is meant sincerely: you have something the machine does not have.

You have spent decades building a model of how software actually works — not how it’s supposed to work, but how it fails, how it surprises, how it behaves when the documentation lies. You have developed an instinct for wrongness that no statistical model can replicate. You have seen enough production incidents to know that the most dangerous code is the code that looks correct.

The AI is a powerful tool. It can help you work faster, check your assumptions, suggest patterns you might have forgotten. But it cannot do your job. It can generate code at machine speed, but it cannot evaluate that code with human judgment.

Your judgment is not obsolete. It is, if anything, more essential than ever — because now there is more code being generated, and someone has to decide if that code is trustworthy.

That someone is you.

The End (Which Is Not an Ending)

Martin still has moments of fear. He sees announcements about new AI models that can pass coding interviews, that can debug production issues, that can architect systems. Each announcement brings a small pulse of the old dread.

But he also sees the junior developers struggling with the code the AI generates, missing the subtle bugs, trusting the machine when they should be questioning it. He sees the production incidents caused by AI-generated code that no one reviewed carefully. He sees the gap between generating code and understanding code.

And he knows that gap is where he lives. It’s where he has always lived. The tools change, but the gap remains.

He is fifty-three years old, and he is learning new things. Not because he has to, but because he wants to — because the AI has removed the drudgery and left the interesting parts. The parts that made him fall in love with software in the first place, back when he was seventeen and the Commodore 64 was new. That intrinsic motivation — the curiosity and pride that no management framework can manufacture — is what the machine cannot replicate.

The gray beard is still here. And he’s not going anywhere.

The All-Hands Disaster

2026-02-20T00:00:00+01:00

Previously: "When Players Revolt" — The Wednesday update launches, but a rushed database migration script wipes 4,847 player inventories. App Store rating crashes to 2.1 stars. Emergency weekend war room. Lukas asks Katja: "Why didn't I know about this earlier?"

Monday Morning, 09:00 — Main Event Space

"This company has 85 people and we can't ship a simple feature without catastrophe?"

The main event space — usually reserved for monthly all-hands and investor presentations — held all 85 people uncomfortably. Folding chairs had been arranged in rough rows facing a single table where Lukas Weber sat, laptop closed, jaw set. The department leads sat in the front row: Katja Müller (CTO), Tomasz Kowalski (Head of Engineering), Lars Pedersen (Game Design), Carmen Delgado (Art & Animation), Hassan Al-Rashid (DevOps), Daniel Schmidt (QA), Elif Yılmaz (Live Ops), Claudia Hartmann (Marketing), and Priya Sharma (Analytics).

Behind them, the rest of the company. Developers. Artists. Support staff. Everyone who’d worked through the weekend fixing the catastrophe. Everyone who knew exactly what had gone wrong and was waiting to see if leadership would acknowledge it.

The update had launched Wednesday. By Friday, the App Store rating had cratered to 2.1 stars. The weekend had been an all-hands emergency response. Now, Monday morning, everyone looked like they’d aged five years in five days.

Lukas stood. The room fell silent immediately.

“Last week’s update was a disaster.” His voice carried to the back row. “2.1 stars. Seventeen thousand one-star reviews. Player retention down 23% in four days. Support tickets up 340%. Our investors are asking questions I can’t answer.”

He paused. Let that sink in. Eighty-five people watching him.

“So I called this meeting to understand what happened. What went wrong. Who knew what, when.” He looked at the department leads in the front row. “We’re going to figure this out. Together.”

Mariana, sitting in the third row next to Anton, felt her stomach tighten. This was going to be bad.

Lukas addressed Lars first. “Game Design owns the feature spec. What went wrong?”

Lars Pedersen stood, turned to face the room with his Danish composure and architectural glasses. “We delivered complete design documentation three weeks ahead of schedule. Every wireframe, every user flow, every interaction pattern. If Development couldn’t implement what we documented—”

“That’s bullshit.” Katja was on her feet before she could stop herself. “Half the assets didn’t arrive until two days before code freeze. Requirements changed four times—”

“Because Development kept finding problems we had to work around!” Lars spun toward her, face flushed.

Carmen Delgado shot up from her seat. “¡Coño!” She was moving toward Lars now, finger pointing. “You changed the design twice, tío. Twice! We threw away finished work!”

“Those were clarifications—”

“¡Mierda!” Carmen was right up in his face now, close enough that Lars stepped back. “Clarifications? You redesigned the entire tournament flow three days before deadline!”

“The focus groups—”

“What focus groups?” Her hands were shaking. “¡Joder! We never had focus groups! You’re making shit up to cover your ass!”

From the development section, Anton called out in Russian-accented English: “He’s making shit up!”

Someone from Art shouted: “He changed it three times!”

“The design had to evolve—” Lars started.

“Evolve?” Tomasz was standing now. “You call changing core functionality evolution? We rebuilt half the backend to accommodate your ‘evolution.’”

Elif stood up from the front row. “Kahretsin! I can’t deploy anything because releases take two days minimum!”

“That’s because everything’s manual!” Hassan’s voice, usually quiet, carried across the room. “يا خرا! (Ya khara!) Forty-seven manual steps. If one fails, I start over!”

Daniel pushed his glasses up. “QA flagged the tournament bug. Leadership overrode us!”

“We had a deadline!” Lukas’s voice rose.

“Porra!” Mariana was on her feet now, couldn’t stop herself. “Your deadline! We told you it wasn’t ready. I flagged that bug in code review!”

The room exploded. Multiple people standing. Voices overlapping, crescendoing. Carmen and Lars were face-to-face, shouting in Spanish and Danish-accented English, and for a second it looked like Carmen might actually swing at him. Developers on their feet arguing with designers. Art team surrounding Carmen, backing her up. Someone from Support threw a water bottle — it missed Lars and hit the wall.

“Fuck this!” Anton’s voice boomed from the back. “We’re not doing this shit again!”

Katja stood frozen in the front row, mouth open, watching the company tear itself apart in real time. This wasn’t a meeting anymore. This was a riot waiting to happen.

SLAM.

Lukas’s hand hit the table so hard his laptop jumped.

Silence crashed down like a guillotine.

Everyone froze. Eighty-five people holding their breath.

Lukas’s voice was ice-cold. “Everyone who is not a department lead — leave. Now.”

The room sat frozen for three seconds.

“I said OUT. Department leads stay. Everyone else, you’re dismissed.”

Slowly, people stood. Mariana caught Katja’s eye as she filed toward the door. The CTO’s face was pale. This was about to get worse.

The development team clustered in the hallway outside. Anton leaned against the wall, arms crossed. “That’s going to be a bloodbath.”

“They’re going to blame each other for the next hour,” Mariana said. “Then Lukas will yell, and nothing will change.”

Sofia, the junior developer, looked anxious. “Should we go back to our desks?”

“And pretend we didn’t just watch leadership fall apart in public?” Mariana shook her head. “Nah. I’m getting coffee. Anyone want anything?”

09:23 — Main Event Space (Department Leads Only)

"Now that we don't have an audience, let's try this again. What. The fuck. Happened?"

The room felt larger with only ten people in it. More exposed. Lukas remained standing at the table while the nine department leads spread out in the front row, no longer a unified leadership team but individuals bracing for interrogation.

Lukas’s hands were shaking. Not with fear. With rage.

“Now that we don’t have an audience,” his voice was dangerously quiet, “let’s try this again. What. The fuck. Happened?”

Nobody spoke.

“I’ll start with you, Lars. Game Design owns the feature spec. What went wrong?”

Lars spread his hands, that infuriating Danish calm still intact. “I already said—”

“No audience now. Truth, not performance.”

Lars’s jaw tightened. “We delivered complete documentation. If there were changes, they were responses to technical constraints Development discovered late. Not my fault they can’t implement what I design.”

The vein in Katja’s temple started throbbing.

“Oh fuck off.” Katja’s voice was flat. “You changed the tournament flow three days before deadline. Three days. We had to rebuild the entire backend validation system.”

Carmen was out of her chair. “¿Otra vez con esto? No podemos animar conceptos que no existen, joder.” She didn’t bother switching to English. “Lars cambió el diseño dos veces. Dos. Veces. We threw away finished work.”

Lars spun on her, standing now too. They were three feet apart. “Those were clarifications based on user feedback—”

“What user feedback?” Carmen’s face was red. “You made it the fuck up! Every time! You sit in your office having ‘visions’ and we have to scramble!”

“Elif,” Lukas cut in. “Live Ops. What’s your perspective?”

Elif looked dead inside. “I have three events ready to launch. Been ready for two weeks. Can’t deploy them because Development takes two days minimum for any release. If nothing breaks.” She looked at Tomasz. “You gonna tell him why, or should I?”

Tomasz’s Polish accent got thicker when he was pissed. “Everything is manual. No CI/CD. No automation. Hassan runs forty-seven steps by hand. By. Hand. Like we’re living in 2010.”

Hassan spoke quietly, which made everyone listen. His voice was steady but his eyes were bloodshot, dark circles underneath like bruises. “Forty-seven steps. If I fuck up step twelve, I start over from scratch. Last release took eight hours because the build kept failing.” His hands were flat on the table, fingers trembling slightly.

“Why don’t you automate it?” Lukas asked.

Hassan laughed. Actually laughed. “With what time? I’m one guy supporting 85 people. I spent last weekend keeping production alive. Week before that, onboarding new hires. Before that, debugging why staging keeps crashing.” He looked directly at Lukas. “You want automation? Give me time or give me another developer.”

“We’re hiring—”

“You’ve been saying that for three months.”

Daniel pushed his glasses up. “We flagged the tournament bug. Mariana flagged it in code review. I flagged it in QA. Both times, leadership said ship it anyway because we had a deadline.” He looked at Katja. “You were in that room.”

Katja felt her stomach drop. “You said we couldn’t delay—”

“Don’t put this on me,” Lukas shot back. “You said it was an edge case.”

“It was flagged as potential edge case with incomplete testing data!”

“It crashed the entire tournament!”

Priya closed her laptop with a sharp snap that echoed in the tense room. Everyone turned. Her face was composed but her knuckles were white where they gripped the laptop edge.

“I warned you.” Her voice was cold, each word precise. “Eight weeks ago. Monthly retention dropped from 71% to 63%. Session duration down 18%. I sent three detailed reports. Nobody responded. I put dashboard links in Slack. Zero clicks. I presented at leadership meetings. No follow-up.” She looked around the room, making eye contact with each person. “I’ve been screaming that we’re bleeding users, and you all kept arguing about whose fault it is while ignoring the data showing what’s actually happening.”

Silence. Heavy. The kind of silence where everyone knows she’s right and hates her for saying it out loud.

“So whose deadline was it, Lukas? Because the numbers said fix what you have before shipping new broken shit.”

Claudia jumped in. “I paused €50K in ad spend last week. You know why? Because I’m not burning acquisition budget when our product hemorrhages users. Every euro bringing in new players is wasted if they quit after a week because the game’s fucked.”

“So Marketing’s giving up?” Lars’s voice dripped sarcasm.

“Marketing’s being realistic. What’s your excuse for designing features nobody asked for?”

“Nobody asked for—? We have literal player surveys showing—”

“Surveys you wrote leading questions for!”

“That’s not—”

“Both of you, shut up.” Tomasz’s voice cut through. He’d been silent until now, watching with the detached interest of someone who’d already mentally checked out. “You want to know what happened? I’ll tell you what happened. We have 147 tickets in our backlog. 89 marked critical. 42 marked urgent. Development has been working 60-hour weeks for three months because every department thinks their stuff is the most important. We don’t have time to fix technical debt. We don’t have time to automate deployments. We don’t have time to write proper tests. We’re in constant fire-fighting mode because leadership keeps saying yes to everything without asking if we can actually deliver it.”

He looked at Lukas. “You asked what went wrong? Everything went wrong. And it went wrong because this company has 85 people and zero shared understanding of what’s actually happening. Everyone’s optimizing for their department. Nobody’s optimizing for the product. Nobody even knows what everyone else is doing.”

The room exploded.

Carmen shot to her feet screaming at Lars in rapid Spanish. Lars screaming back in Danish-accented English. Elif standing, yelling about deployment timelines. Daniel slamming his hand on the table defending QA. Hassan’s voice rising, infrastructure constraints nobody was listening to. Claudia and Priya both shouting that their warnings had been ignored.

Katja watched Lars grab his coffee cup — for a second she thought he was going to throw it at Carmen.

Tomasz stood up, chair scraping loud. “This is fucked. We’re fucked. All of us.”

Lukas stood up. “ENOUGH!”

Silence crashed down like a guillotine.

“This company has 85 people,” Lukas said, his voice shaking with anger or exhaustion or both. “85 people. And we can’t ship a simple feature without catastrophe. We can’t have a meeting without it turning into a fucking circular firing squad. Every one of you has excellent reasons why this isn’t your fault. Every one of you can point to someone else who failed first.”

He looked around the table. “You know what that tells me? It tells me none of you actually knows what’s happening outside your own department. You’re all flying blind and pretending you can see.”

Nobody argued. What could they say?

Lukas closed his laptop. “We’re done. I want written post-mortems from each department by end of day. Facts, not blame. We’ll try this again tomorrow.”

He stood. “Get out.”

People filed out in uncomfortable silence.

Katja was the last to leave. She paused at the door, looked back at the empty conference room. The table was covered in coffee cups and discarded notes and the wreckage of nine intelligent people who couldn’t see the same reality.

She’d been CTO for two years. She’d never felt more powerless.

Monday Evening, 22:34 — Katja’s Apartment, Kreuzberg

"What if leadership could see reality without interrogating teams?"

Katja sat at her desk, facing the window overlooking the courtyard. The apartment was dark except for her monitor’s glow. Turing, her gray tabby, had given up trying to get her attention and was now asleep on the couch. Lovelace, the orange one, sat on the desk watching her with judgmental cat eyes.

She’d been staring at the ceiling for three hours. Sleep wasn’t coming. Every time she closed her eyes, she saw that conference room. Heard the accusations flying. Felt the helplessness of watching reality dissolve into competing narratives until truth became unknowable.

Tomasz was right. Nobody knew what was actually happening. Status meetings were theater. Weekly reports were selective truth-telling. Jira tickets were wish lists, not reality. She was CTO, and she couldn’t answer the simplest question: what’s blocking us?

Not with confidence. Not with evidence. Just guesses and secondhand information filtered through whoever was willing to complain the loudest.

At 22:47, she opened her laptop and typed into Google:

organizational intelligence for software teams

The first page was the usual suspects. Jira. Asana. Monday.com. Project management tools she already had. They tracked tasks, not reality. She needed something different.

She refined the search:

see what’s actually happening software delivery

More results. Agile dashboards. Burndown charts. Velocity metrics. All measuring activity, not truth. All requiring manual updates nobody had time for.

She tried again:

evidence-based delivery visibility

Now she was getting somewhere. An article from a delivery consultant: “Stop asking teams what’s wrong. Start observing what’s actually happening.”

She clicked through. The article described an approach she’d never encountered: daily logs from practitioners, automated synthesis, pattern detection across departments. The tool was called Caimito Navigator.

The key phrase hit her like cold water:

“What if leadership could see reality without interrogating teams?”

She sat back. Read the article again, slowly this time.

The concept was simple. Practitioners log daily. Just type what happened. Takes 30 seconds while the compiler runs or tests execute. Short entries, plain language, no process overhead. The system synthesizes these logs weekly, showing patterns leadership can’t see from status meetings. Cross-department blockers. Repeated impediments. Systemic issues hiding in individual frustrations.

Evidence instead of opinions. Patterns instead of anecdotes. Reality instead of theater.

She checked the time. 23:16. Too late to call anyone. Not too late to keep reading.

Two hours later, at 01:23, she’d read six case studies, watched three demo videos, and filled two pages of her notebook with questions. The approach made sense. More than that — it made sense for exactly the dysfunction she’d witnessed today.

The meeting had failed because everyone had different information. Lars thought he’d delivered clear designs. Carmen thought Lars kept changing requirements. Development thought they were blocked by missing assets. Art thought they were blocked by unclear specs. Everyone was telling their truth. None of them could see the full picture.

What if there was a way to see all those truths at once? To detect when “Lars changed requirements” showed up in logs from three different departments? To quantify “Development is blocked by Art” and see if it was daily reality or occasional friction?

Her phone buzzed. A Slack message from Tomasz:

Tomasz Kowalski still awake?

Katja Müller yeah. you good?

Tomasz Kowalski no. thinking about quitting. for real this time. żona wants me to. kids don't even know who i am anymore

Katja Müller fuck. i don't want you to quit. but i get it

Tomasz Kowalski today was so fucked. everyone screaming. nobody knows anything. we're flying blind and pretending we can see

Katja Müller i know. trying to figure out how to fix it

Tomasz Kowalski good luck with that. gonna try sleeping. doubt it'll work

Katja Müller night

She set the phone down and looked at her screen. Caimito Navigator’s signup page was open. Free trial. 30 days. No credit card required.

Fuck it.

She clicked “Start Trial” and filled out the form. Company name: Pixel Spree. Role: CTO. Team size: 85. Primary challenge: “Nobody can see reality through status meeting theater.”

The confirmation email arrived immediately. Welcome to Navigator. Here’s how to write your first daily log.

She opened a new entry. The interface was dead simple. Just a text box. No dropdowns, no categories, no process overhead. Just type. The cursor blinked steadily in the empty field.

Katja started typing, her fingers moving faster as the words poured out.

Disaster post-mortem this morning. 9 dept leads screaming at each other for an hour. Development blames Art. Art blames Design. Design blames Development for “not understanding the vision.” Live Ops can’t deploy shit because releases take 2 days minimum. Hassan drowning — he’s ONE person for 85. QA flagged the tournament bug, leadership (me included) said ship it anyway. Priya’s been screaming about player churn for 8 weeks, we all ignored her. Everyone has different information. Zero shared visibility. Status meetings are performance art. Can’t see what’s actually happening. Can’t tell chronic issues from one-offs. Flying blind.

She hit save. The system acknowledged her first log.

Great start. Keep logging daily. After a week, you’ll start seeing patterns. After a month, you’ll wonder how you ever operated blind.

Katja looked at the time. 02:07. She should sleep. Her neck ached. Her eyes burned. But sleep felt impossible with her mind still racing.

But first, she needed to do one more thing.

She opened Slack, the green icon glowing in her dock. Found Lukas’s DM.

Katja Müller you awake?

No response. Of course not. Normal people slept at 2 AM.

She typed anyway.

Katja Müller found something. think it might help. can we talk tomorrow morning? early? usual place?

She hit send, closed the laptop with a soft snap. If he saw it before morning, great. If not, she’d catch him at the office. Her shoulders sagged with exhaustion.

Turing jumped onto her lap, warm and solid. Lovelace remained judgmental from the desk, green eyes unblinking in the dark.

Now she could sleep.

Her phone buzzed on the coffee table, the screen lighting up the dark room.

Lukas Weber 8:30. café.

She smiled in the dark, the tension in her shoulders easing slightly. At least she wasn’t alone in this.

Tuesday Morning, 08:23 — Café Naschmarkt, Corner Table

"I think I found something. But it requires you to trust me."

Lukas was already at their usual table when Katja arrived, americano half-finished, iPad propped up displaying what looked like a financial model. The café smelled like fresh bread and roasted coffee. Morning light streamed through the front windows. He looked up when she sat down, taking in her rumpled clothes and the dark circles under her eyes.

“You look like shit.”

“Didn’t sleep.” Katja ordered an espresso from the passing waiter, her voice rough. “Spent half the night researching.”

“Researching what?”

“How to un-fuck what happened yesterday.”

Lukas closed the iPad. “I’m listening.”

Katja pulled out her laptop, opened Navigator, turned the screen. “Yesterday failed because everyone had different information. Nine people, nine versions of reality, zero shared truth. We’re making decisions blind.”

“Status meetings—”

“Are bullshit.” Katja cut him off. “People report what makes them look good or what they think you want to hear. It’s theater.”

“So what’s your solution?”

Katja turned the laptop toward him. “This. Caimito Navigator. Teams log daily. Just type what happened. 30 seconds while the compiler runs. System synthesizes it weekly, shows patterns we can’t see from meetings.”

Lukas scrolled through the demo. “Another tool?”

“Not a tool. Intelligence. It’s not tracking tasks, it’s tracking reality.” She pulled up a case study. “Hamburg company, 120 devs, same shit we have. They logged for four weeks. Patterns emerged. DevOps team mentioned as blocker in 60% of logs. They hired two more people. Deployment speed tripled.”

“We already know Hassan’s drowning.”

“We think Hassan’s drowning because he’s loud about it. What about the blockers people stopped mentioning? The chronic shit we only notice during disasters?” She held his eyes. “If everyone yesterday had been logging for a month, we’d have data. How often Lars actually changes requirements. How often Art is truly blocked. Evidence instead of accusations.”

Lukas was quiet for a long moment, his fingers drumming slowly on the table. The espresso arrived, steam rising in a thin curl. Katja didn’t touch it. Her hands were folded in her lap, gripping each other tightly.

“Who logs?” he finally asked, his voice careful.

“Everyone who wants to. It’s not mandatory. But the more people log, the more complete the picture.”

“Sounds like more overhead we don’t have time for.”

“30 seconds a day. While the compiler runs or tests execute. Just write what happened. No structure, no categories.”

“And you think this will fix our problems?”

“No.” Katja’s honesty surprised even herself. “This won’t fix anything. But it’ll let us see what needs fixing. Right now we’re operating blind. We’re making decisions based on whoever shouts loudest in meetings. This gives us a way to see reality.”

Lukas picked up his coffee, drank, set it down. “How much does it cost?”

“Free for 30 days. After that, depends on team size.”

“You already signed up, didn’t you?”

“Last night. Wrote my first log at 2 AM.”

A small smile. “What did it say?”

“That yesterday’s meeting was a circular firing squad and nobody actually knows what’s happening in this company.”

“Accurate.” He looked at the screen again. “Okay. Try it. Start with whoever’s willing. Report back in two weeks.”

“Not a month?”

“Two weeks. If I don’t see value by then, we drop it.”

Katja closed her laptop. “Fair enough.”

They sat in silence for a moment. Outside, Berlin was already in full swing. Trams rattled past, their bells clanging. Morning commuters rushed by with their second coffee, breath visible in the cold February air. The city had been awake for hours, moving with the oblivious momentum of something too big to notice individual disasters.

“Yesterday broke something,” Lukas said quietly, not looking at her. “In that room. Between all of us.” His voice was heavy with something that sounded like grief.

“I know.”

“We can’t keep operating like this.”

“I know.”

“If this doesn’t work—”

“Then we try something else. But we have to try something.” Katja finished her espresso. “Because you’re right. We can’t keep operating like this. Something has to change.”

Lukas nodded slowly. “Keep me posted.”

She stood, gathered her laptop. “I will.”

Walking back to the office, Katja felt something she hadn’t felt in months: a small, fragile hope. Not that Navigator would solve everything. Not that logging would magically fix systemic dysfunction.

But hope that maybe, finally, they could start seeing reality clearly enough to know what needed fixing.

That was enough. For now.

Tuesday Afternoon, 15:47 — Development Floor

"Another management tool to fix management problems."

Mariana looked up from her code when Katja appeared at her desk. The CTO looked wired on caffeine and desperation, her eyes too bright, her movements jerky.

“Got a minute?”

Mariana saved her work, her fingers pausing on the keyboard. “Yeah. What’s up?”

Katja pulled up a chair, the wheels scraping against the floor, and angled her laptop toward Mariana. “Trying something new. Caimito Navigator. Daily logs, pattern detection. Takes 30 seconds. Just write what happened while you’re waiting for stuff to compile.” Her words came out fast, rehearsed.

Mariana skimmed the interface. Her expression: not impressed. “Another management tool.”

“I know—”

“Do you though? Yesterday was a complete shitshow and now you’re here asking us to do more work so you can have better dashboards.”

“30 seconds. While you’re waiting for the compiler. Just type what happened. No structure.”

“To tell you stuff you should already know if you actually talked to us.”

Direct hit. Katja didn’t flinch. “You’re right. I should know. But I don’t. Status meetings are performance. Jira’s a wish list. Yesterday proved nine people can sit in a room and have completely different versions of the same reality.”

Mariana leaned back, arms crossed. “So you want me to log so you have better data for meetings I’m not invited to.”

“I want patterns visible. When you’re blocked by Hassan four days straight, it shows as a pattern, not just you complaining. When requirements change mid-sprint, we see how often it actually happens versus how often it feels like it happens.”

“And then what? You’ll fix it?”

“Honestly? Don’t know.” Katja’s bluntness surprised both of them. “But I can’t fix what I can’t see.”

Mariana studied her. The CTO looked genuinely wrecked. Not just tired — everyone was tired. This was deeper. The kind of exhaustion that came from watching your authority become meaningless. Her eyes were bloodshot. Her hands trembled slightly when she gestured. There was a coffee stain on her shirt she probably hadn’t noticed.

“Fine.” Mariana said, her voice softening slightly. “Two weeks. If it’s bullshit, I’m out.”

“Fair.”

Katja showed her how to set up an account, walked through the interface. It was simpler than Mariana expected. Just a text box. No dropdowns, no category tags, no process overhead. Type what happened, hit save, AI does the rest.

After Katja left, Mariana stared at the empty log entry, the cursor blinking accusingly. Her coffee had gone cold. She could hear the usual office sounds — keyboard clatter, muffled conversations, someone’s phone ringing. She started typing, the words coming faster than she expected.

Code review for payment integration. Flagged 3 race conditions. Investigated last week’s tournament crash — root cause was EXACTLY what I flagged before launch. Nobody surprised, everyone pissed. Hassan needed staging reset, he’s drowning. Unclear requirements on payment retry logic. Product hasn’t answered my questions from Thursday. We keep shipping known bugs because deadlines > quality. QA flags shit, we override, players suffer, we scramble. Repeat forever.

She hit save.

The system acknowledged: Thanks for logging. Keep it up. Patterns become visible through consistency.

Mariana closed the laptop and returned to her code.

She didn’t expect miracles. But maybe — just maybe — someone would finally see what was actually happening.

That would be something.

Monday Evening, Feb 24, 19:23 — Katja’s Apartment

"Three people logging. One week of data. Already, patterns."

Katja sat cross-legged on her couch, laptop balanced on her knees, Turing purring beside her, warm against her thigh. The apartment was quiet except for the soft rumble of her cat and the distant hum of traffic. She’d been logging for a week now. Mariana had joined on Tuesday. Hassan had signed up Wednesday after Katja explained it might help quantify his blocker status.

Three people logging. One full week of data.

The first weekly synthesis had just arrived in her inbox, the notification chiming softly in the stillness.

She pulled up the synthesis Navigator had generated, her heart beating faster. It was preliminary — the system warned that real patterns needed weeks, not days — but even preliminary synthesis was illuminating:

📋 Summary

Observed Actions:

Hassan (DevOps) repeatedly mentioned as blocker across multiple logs. Pattern: deployment requests queue behind single person; manual process creates serialized bottleneck affecting Development and Live Ops.
Requirements clarity issues surfaced in multiple contexts. Pattern: mid-sprint changes and unanswered questions from Product create rework loops.
QA approval bypassing documented multiple times. Pattern: deadline pressure overrides quality gates, known bugs ship to production, team scrambles post-launch.

Tooling and System State:

Manual deployment process documented as chronic friction point. No automation, no self-service capability.
Staging environment resets require Hassan intervention — further congestion at single point of failure.

Relation to Organizational Context:

Cross-department communication breakdown visible in conflicting priorities and information asymmetry.
Decision-making pattern: deadlines prioritized over quality signals, then reactive firefighting when predicted issues materialize.

🎯 Recommendations:

Immediate: Evaluate DevOps capacity. Single-person bottleneck creates systemic delivery friction.
Short-term: Examine requirement definition process. Repeated mid-sprint uncertainty suggests upstream clarity issues.
Structural: Review quality gate override process. Pattern of ignoring QA flags then scrambling post-launch suggests misaligned incentives.

It was preliminary. It was incomplete. It was three people out of 85.

But it was also the clearest picture of reality Katja had seen in months. Her chest felt tight with something between hope and relief.

No percentages. No dashboards. Just patterns synthesized from actual daily experience, written in plain language that anyone could understand.

Hassan wasn’t mentioned as a statistic. He was described as what he actually was: a single person carrying the entire company’s deployment capability, with predictable consequences.

She added Lukas as an observer to the Navigator workspace. The system sent him an automatic invite. Then she opened her email, fingers hovering over the keyboard for a moment before she started typing.

Subject: Navigator — First weekly synthesis

One week. Three people (me, Mariana, Hassan).

First synthesis just came in. Hassan showing up as chronic bottleneck across all logs. We suspected this. Now we have evidence.

Added you as observer. Check the synthesis directly. You can ask the AI questions about patterns if you want deeper analysis.

This is THREE people. Imagine 20. Imagine 40.

Want to expand. Get dept leads logging. Not mandatory but strongly encouraged. Two weeks, then review.

—K

She hit send before she could second-guess herself.

The reply came eight minutes later.

From: Lukas Weber
Subject: Re: Navigator — First weekly synthesis

Do it. Present at Friday leadership meeting. Show them this. See who’s willing to try.

—L

She closed her laptop and looked out the window. The Kreuzberg courtyard was dark, lit only by scattered apartment windows glowing warm against the February night. Somewhere in those apartments, people were living normal lives. Relationships. Hobbies. Sleep. Things that didn’t consume every waking hour.

She couldn’t remember the last time work hadn’t consumed everything. Her neck ached. Her eyes burned. But for the first time in weeks, the exhaustion felt different. Less like drowning, more like… swimming toward something.

But maybe — just maybe — they were starting to find a way out of the noise.

One log at a time.

Turing stretched beside her, claws extending briefly before settling back into a purr. Outside, a tram rattled past on Oranienstraße, its bell clanging faintly in the distance.

Next Episode: "The Slow Adoption" Katja logs daily. Mariana joins, skeptical but willing. Hassan starts tracking his underwater status. Most department leads ignore it—another management tool. Then Lukas announces hiring ten more developers to go faster. The patterns in Navigator tell a different story.

La Verdad

2026-02-19T00:00:00+01:00

Previously: "El Regreso" — Luciana was revealed as the spy, but her tears were real — Marco had manipulated her, stealing her credentials to access FinPulso's systems. Diego brought unexpected news: MiPago wants to collaborate, not compete. But as the team celebrated small victories, a new threat emerged. Someone with deep pockets is reaching out to Alejo, promising another chance. The game isn't over.

The Gathering Storm

Monday, 7:45 AM. FinPulso office.

The conference room has been transformed. Don Hernando demanded it. The usual startup casualness — bean bags, motivational posters, the ping-pong table visible through the glass — is gone. In its place: formal chairs, water carafes, leather-bound folders at each seat. Like a courtroom.

Sebastián arrives first. His hands shake as he arranges his presentation materials. Deployment metrics. Test coverage graphs. The pipeline dashboard showing their progress. Evidence of change.

But he knows what this meeting really is: a trial.

This was the day that would decide everything.

Isabella enters, looking exhausted. “I couldn’t sleep.”

“Neither could I.”

She sits beside him. For a moment, they’re just two people who built something together and watched it nearly fall apart.

“Sebastián—” she starts, then stops. “Whatever happens today, I want you to know that I’m proud of what we built. Not the lies. Not the fake demos. The real thing. The idea that people in Soacha and Kennedy and Bosa could have the same financial tools as people in Rosales.”

“We’re not dead yet,” he says.

“No. But we might be by lunch.”

The elevator dings. Camila and Diego arrive, carrying laptops. Behind them, Stefan. And then Don Hernando, his leather boots clicking on the polished floor, Laura three steps behind him with her ever-present notebook.

Mariana Ríos is the last to arrive. The investor. The woman whose $15 million is on the line. She’s accompanied by two other Vulcano Capital partners — both men, both looking grim.

“Where’s Alejo?” Don Hernando demands.

As if summoned, the CFO appears. Perfectly dressed. Perfectly composed. His smile is warm and unconcerned.

“My apologies. Traffic on the Autopista.” He takes his seat at Don Hernando’s right hand. The power position.

Mariana doesn’t smile back. “Let’s begin.”

The First Truth

Don Hernando stands. The patriarch. The man who built empires with his bare hands.

“I called this meeting because I owe you the truth. All of it.” His voice is steady, but his hands grip the table. “Six months ago, I stood in a different room and made promises. A working platform. A million users. Expansion to Mexico and Peru.”

He pauses. The silence is heavy.

“We have none of those things. We are not where I said we would be.”

Mariana’s face is unreadable. “We’re aware of the delays. What we want to know is why — and what’s being done.”

“Sebastián will explain the technical situation,” Don Hernando says. “But first, I need to say something I should have said months ago.” He turns to his co-founder. “Sebastián, I took your company. I took your title. I thought I knew better because I’d built businesses before. I was wrong. A cattle ranch is not a software company. And a leader who demands obedience is not what developers need.”

"I took your company. I was wrong."

Sebastián’s eyes widen. He wasn’t expecting this.

“I want to propose a change,” Don Hernando continues. “Effective immediately, Sebastián Duarte returns to the role of CEO. I will remain as chairman and primary investor. But the company needs a leader who understands it. Not a rancher who thinks code is like cattle.”

The room is stunned. Mariana looks impressed. The other board members exchange glances.

But Alejo’s smile has frozen on his face like a death mask. His fingers grip the armrests so tightly his knuckles go white. For just a moment — a fraction of a second — something ugly flickers behind his eyes. Raw, murderous rage.

Then the mask snaps back into place.

“Don Hernando,” the CFO says smoothly, “perhaps we should discuss this privately before making such significant—”

“No.” The old man’s voice is steel. “I’ve made enough decisions in private. I’ve hidden enough. This is being done in the light, where everyone can see.”

Sebastián stands slowly. His legs feel unsteady but his voice is clear. “I accept. But I have conditions.”

“Name them,” Don Hernando says.

“Full technical autonomy for the development team. No more promises to investors about features until engineering signs off. And—” he looks at Alejo, “—complete financial transparency. Every contract. Every payment. Everything on the books.”

“Agreed,” Don Hernando says.

Alejo’s jaw tightens. “Some of our arrangements are commercially sensitive—”

“Then we’ll sign NDAs,” Mariana interrupts. “But I want to see them too. All of them.”

The CFO’s mask slips for just a moment. The calculation in his eyes is visible to everyone.

“Of course,” he says. “Transparency is important.”

But everyone in the room knows: the game just changed.

The Technical Truth

Sebastián’s hands are steadier now. He opens his laptop, projects the screen.

“Here’s where we actually are.”

The dashboard appears. Green pipelines. Test coverage at 87%. Deployment frequency: 6.3 per day. Lead time: 42 minutes from commit to production.

“These metrics are from the past six weeks,” he says. “We rebuilt the platform from the ground up. Every feature is tested. Every deployment is automated. Every change is visible.”

He clicks to the next slide. “This is what we had six months ago.”

The contrast is brutal. Manual deployments. No tests. Lead time measured in weeks.

“The gap between those two states is the truth we’ve been hiding. We weren’t delayed by bad luck or external factors. We were delayed because we didn’t build it right the first time. Because I let pressure override discipline. Because I made promises I couldn’t keep and then lied to cover it up.”

Isabella is watching him with something like wonder.

“But here’s the other truth,” Sebastián continues. “In the past six weeks, we’ve deployed 267 times. We’ve fixed 89 bugs. We’ve added seven real features that users actually need. All without downtime. All without drama. Because we finally started doing it right.”

Diego leans forward. “The platform you saw in demos six months ago? Most of it was smoke and mirrors. What you’re looking at now is real. Smaller. But real.”

Mariana studies the dashboard. “What’s your current user count?”

“Twelve thousand,” Sebastián admits. “Not a million. But they’re real users. Real transactions. Real money moving through the system safely.”

“And the AI-powered risk assessment feature?” one of the other board members asks.

The room goes quiet.

Sebastián takes a breath. “There is no AI. There was a team in Venezuela doing manual reviews. We paid them through a shell company to hide the truth.”

"There is no AI. There never was."

The explosion is immediate.

“You lied to us?” The board member’s face is red. “You committed fraud!”

“Yes,” Sebastián says simply. “We did. I did. And I can’t undo it. All I can do is tell you the truth now and show you we’re fixing it.”

Mariana raises a hand. The room quiets.

“Show me the actual AI replacement plan.”

Camila stands. The junior developer. The one no one expected.

“I built it.” Her voice is quiet but firm. “Rule-based risk scoring using transaction patterns and user behavior. It’s not machine learning, but it works. We’ve been testing it in production for three weeks. Accuracy is 94% compared to the manual reviews.”

She projects her own screen. Clean code. Comprehensive tests. Documentation that actually explains what the system does.

“The AI was always a distraction,” she continues. “What users need is safety and speed. This gives them both. And unlike the AI story, it’s actually true.”

Stefan, watching from the back of the room, smiles.

The Financial Truth

Mariana turns to Alejo. “What’s the burn rate?”

The CFO pulls up his own spreadsheet. Perfect columns. Perfect formulas.

“Our monthly burn is $340,000. At current runway, we have 14 months before we need additional capital.”

“And the Venezuelan team?”

“Terminated as of last week,” Alejo says smoothly. “A cost savings of $18,000 per month.”

“Show me the contracts,” Mariana says.

“They’re in my office—”

“No. Show me now. You have them digitally.”

The tension is a physical thing. Alejo’s smile is still in place, but there’s sweat at his hairline.

“Mariana, I don’t think this is the appropriate venue—”

“I’m the lead investor and a board member. Show me the contracts.”

Laura, from her position behind Don Hernando, clears her throat softly. “If I may?” She holds up her tablet. “I have copies of all FinPulso’s contracts. Including the ones stored on Señor Vega’s personal laptop.”

Every head turns toward her.

“Laura—” Alejo’s voice is dangerous now. “Those are confidential—”

“They’re company property,” Don Hernando says. “Stored on company servers. Which you access through your company laptop. Show them, Laura.”

The assistant projects her screen. A folder structure appears. And there, buried in subdirectories with innocent names, are files that shouldn’t exist.

“Consulting Agreement — MiPago Strategic Services — $50,000 per month.”

“Advisory Retainer — Banco Atlántico — $35,000.”

“Information Services — VentureLink Panama — $25,000.”

Isabella gasps. “These are our competitors.”

“Not competitors,” Alejo says quickly. “Industry contacts. Market research. This is standard—”

“This is fucking espionage,” Diego says flatly. “You’ve been selling our roadmap. You piece of shit.”

The perfect smile was finally cracking.

Mariana’s voice is ice. “How long?”

Laura scrolls. “First payment was nine months ago. Total received: $847,000.”

The number hangs in the air.

“That’s more than your annual salary,” Don Hernando says slowly. “You’ve been paid more by our competitors than by us.”

Alejo stands abruptly. “This is a witch hunt. Those contracts are perfectly legal. I disclosed them—”

“To whom?” Mariana demands. “Show me the disclosure forms.”

Silence.

“You didn’t disclose anything,” she says. “You’ve been systematically looting this company while positioning yourself to flip it. The MiPago merger discussions Diego mentioned? You weren’t representing FinPulso. You were representing yourself.”

The CFO’s mask is completely gone now. What remains is cold calculation.

“FinPulso was going to fail anyway,” he says. “I was creating a soft landing. A merger would have saved jobs. Saved the investors’ money. Don Hernando would have walked away with something instead of nothing.”

“And you would have walked away with everything,” Isabella says. “CEO of the combined company. Control of the technology. All of it.”

Alejo’s eyes find hers. “I offered you a place in that future. You said you’d think about it.”

The room goes silent. All eyes on Isabella.

The Heart’s Truth

Isabella stands slowly. Her hands are shaking, but her voice is steady.

“You did offer me that. Dinners at the best restaurants. Promises of power. Weekends in Cartagena where you painted pictures of what we could build together.”

Sebastián’s face goes pale.

“And I was tempted,” she continues. “Not by you, Alejo. By the idea of finally having a seat at the table. Of being more than the girl from Kennedy who got lucky.”

"I was tempted. But then I remembered why I came here."

She reaches into her bag and pulls out a small notebook. The kind she’s always carried.

“But then I remembered why I came to FinPulso. Not for power. Not for money. Because I met a guy at a tech meetup who showed me sketches of an app that would help my father — a taxi driver — manage his money better. Who said that financial services shouldn’t just be for rich people.”

She looks at Sebastián. “That guy was you. And somewhere along the way, we forgot that person existed. We forgot what we were actually trying to build.”

Tears are running down Sebastián’s face.

“So I started documenting everything,” Isabella continues. “Every suspicious meeting. Every contract Alejo tried to hide. Every moment when we chose the impressive over the honest.” She hands the notebook to Mariana. “It’s all in here. Dates. Names. Amounts. Everything you’ll need for the lawyers.”

Alejo’s face is ashen. “You were spying on me?”

“No. I was protecting the company you were destroying. There’s a difference.”

Don Hernando is staring at Isabella with something like awe. “Why didn’t you come to me?”

“Because I wasn’t sure you’d believe me over him. You loved Alejo. He reminded you of your son.”

The old man flinches as if struck. “How did you—”

“Everyone knows, Don Hernando. Laura talks when she’s had wine. You brought Alejo in because he had the confidence your son never showed. The business sense you wished your boy had developed. You saw in Alejo what you missed in Miguel.”

Laura’s hand covers her mouth. The secret that was never really secret.

“But Miguel wasn’t a businessman,” Isabella says gently. “He was a programmer. A dreamer. Like Sebastián. And maybe if you’d loved him for who he was instead of wishing he was something else, he’d still be here.”

The truth about his son, finally spoken aloud.

The silence is absolute. Don Hernando sits like a statue, his weathered face frozen. Then, slowly, he lowers his head into his hands.

“You’re right,” he whispers. “Dios mío, you’re right.”

Laura moves to his side, one hand on his shoulder. The patriarch is weeping.

After a long moment, he looks up. His eyes find Sebastián.

“You’re nothing like Alejo. You’re exactly like Miguel. And I’ve been punishing you for it instead of seeing it as the gift it is.”

Sebastián crosses the room. The young CEO and the old rancher embrace. Two men carrying different griefs, finally understanding each other.

The Consequences

Mariana closes Isabella’s notebook. “Alejo Vega, effective immediately, you’re terminated for cause. You have one hour to clear your office. Security will escort you. If you’re on company property after that, we’ll call the police.”

“You can’t do this—”

“I can and I am. Don Hernando, as primary shareholder, do you concur?”

“Sí.” The old man’s voice is steel again. “Get out of my sight.”

Alejo grabs his phone, his laptop bag. His hands are shaking — not with fear, but with fury. At the door, he turns back.

“You’re all fools.” His voice is a snarl now, the cultured smoothness stripped away to reveal something feral underneath. “Every goddamn one of you. You think honesty pays the bills? You think your pretty deployment metrics mean shit when you have twelve thousand users instead of a million?”

He’s trembling. A vein pulses at his temple.

“This company is still failing. You’ve bought yourself what — three months? Six? I’ll be watching from my new position when FinPulso becomes a cautionary tale. And when it does, when you’re all scrambling for jobs and trying to explain this disaster on your resumes —” his lips curl into something that isn’t quite a smile — “remember that I tried to save you. And you were too goddamn stupid to let me.”

He leaves. The door closes. The room exhales collectively.

Mariana turns to the team. “He’s not entirely wrong. Your numbers are bad. Your burn rate is unsustainable. You have a lot to prove.”

“We know,” Sebastián says.

“But—” she allows herself a small smile, “—I’ve been in this business twenty years. And I’ve learned something: companies with bad numbers and good culture can be fixed. Companies with good numbers and bad culture can’t. You have a real team now. Real practices. Real honesty. That’s worth something.”

“What happens next?” Don Hernando asks.

“We have a pilot program starting,” Diego says. “Small credit unions in Medellín and Cali. If they adopt FinPulso for their members, we’ll have 50,000 real users in three months.”

“And if they don’t?” one of the board members asks.

“Then we’ll have learned what doesn’t work,” Camila says. “And we’ll try something else. That’s what the deployment pipeline is for. Fast feedback. Fast adaptation.”

Stefan, who’s been silent this whole time, finally speaks. “The technical foundation is solid now. Twelve thousand users or a million — the system can handle it. The question isn’t capability anymore. It’s market fit. Product truth. That’s Isabella’s domain.”

All eyes turn to the product lead.

“The credit union pilot is the right move,” she says. “Not because it’s impressive. Because it’s honest. These institutions serve exactly the people we originally wanted to help. If we can’t make their lives better, we have no business existing.”

Mariana nods. “Three months. Show me real adoption from the pilot. Show me that these users actually prefer FinPulso to their current solutions. Do that, and we’ll talk about the next round of funding.”

“And if we can’t?” Sebastián asks.

“Then we’ll have an orderly wind-down instead of a catastrophic failure. You’ll be able to hold your heads up. Your team will get good references. And maybe someone will acquire the technology.” She pauses. “But I don’t think it will come to that. I think you’re finally doing what you should have been doing all along — building something real.”

The Aftermath

Two hours later. The conference room is empty except for Sebastián and Isabella.

Outside the windows, Bogotá continues its chaotic dance. The city doesn’t care about their small drama. The traffic still snarls. The street vendors still call out. Life goes on.

“I almost went with him, you know,” Isabella says quietly. “Alejo. The power he offered was real.”

“Why didn’t you?”

“Because I remembered what my father taught me.” Her voice breaks on the word father. Tears stream down her face, but she doesn’t wipe them away. “He drives a taxi sixty hours a week. His back is ruined. His hands shake from the steering wheel. But he’s never stolen a fare. Never lied about the meter. Never took the easy path even when we couldn’t afford medicine for my mother.”

She draws a shaky breath. “He says, ‘Mija, you can lose everything except your word. Once that’s gone, you’re not a person anymore. You’re just a ghost pretending.’ And I will be damned if I become a ghost for you, Alejo. Or for anyone.”

The city didn't care about their small drama. But they cared about each other.

Sebastián turns to face her. “Isabella, I have to tell you something. I’ve been trying to find the courage for two years, and after today, I can’t keep pretending—”

“I know,” she says.

“You know?”

“Sebastián, everyone knows. Camila knows. Diego knows. Even Don Hernando knows. You’re not subtle.”

His face flushes. “Oh.”

“The question is, are you going to actually say it? Or are we going to keep dancing around this for another two years?”

He takes her hand. Her fingers interlock with his. His heart is pounding so hard he’s sure she can hear it.

“I love you.” The words tumble out, raw and unpolished. His eyes are wet. His hands are trembling. “I love you, Isabella. I have since the day you yelled at me for approving a feature without user research. You were so fierce, and so right, and I stood there thinking — Dios mío, I’ve been waiting my whole life to meet someone who cares this much. Who fights this hard. Who tells me I’m wrong and makes me want to be better.”

He wipes his eyes with the back of his hand, laughing shakily.

Isabella laughs too — a wet, wonderful sound. “That’s the most engineer love confession I’ve ever heard, pendejo.”

“Is that a no?”

“It’s a yes, you idiot.” She pulls him close, her hands finding his face. “It’s been yes for months.”

She kisses him.

"Why did we wait so long?"

Not the tentative brush of first kisses. Not the polite press of colleagues crossing a line. This is months of tension shattering — desperate, hungry, real. Her fingers tangle in his hair. His hands find her waist, pulling her against him until there’s no space between them.

They stumble backward, his shoulders hitting the brick wall of the rooftop structure. She presses into him, her body warm and solid and here, finally here. He kisses her like he’s been drowning and she’s air — deep, gasping, unable to stop.

Her hands slide under his jacket, mapping the shape of him through his shirt. His fingers trace her spine, feeling her arch into his touch. When they finally break apart, both breathing hard, her lipstick is smeared and his shirt is rumpled and neither of them cares.

“Mierda,” he breathes against her mouth. “Why did we wait so long?”

“Because you’re conflict-avoidant and I was being professional.” She kisses him again, softer this time. “But fuck professional. I’m tired of pretending I don’t want this.”

“What do we do now?”

“Right now?” She straightens his collar, her fingers lingering on his neck. “We go back downstairs and finish saving the company. Tomorrow…” She smiles, and it’s full of promise. “Tomorrow, we figure out what this looks like. But Sebastián? I love you too. Even though you approve features without user research.”

They stand there, foreheads pressed together, hands clasped, looking out over the city. The crisis isn’t over. The company isn’t saved. But for this moment, the truth has made something good possible.

The Shadow

Midnight. A private club in Parque de la 93.

Alejo sits across from a man in an expensive suit. The stranger’s face is in shadow, but his voice is educated, confident.

“They humiliated you.”

“Yes.”

“You want revenge.”

“I want what I’m owed.”

The stranger slides a document across the table. “My clients are prepared to offer you a position. Director of Strategic Acquisitions for our Latin American technology portfolio. Starting salary: $400,000. Plus performance bonuses.”

Alejo’s eyes scan the contract. It’s real. It’s generous.

“What do you want in return?”

“Information. You know FinPulso’s weaknesses. You know Mariana’s strategy. You know exactly how to make their pilot program fail.” The stranger leans forward. “We don’t want revenge. We want acquisition. When FinPulso is desperate — really desperate — we’ll make an offer. A lowball offer. And you’ll help us ensure they have no choice but to accept.”

A new game. The same old hunger.

Alejo looks at the shadowed face. “Who do you work for?”

“Does it matter? You want back in the game. We’re offering you the pieces. Play or don’t play.”

The former CFO picks up the pen. Pauses.

For just a moment, something in him hesitates. He thinks of Don Hernando’s face when the truth about Miguel came out. He thinks of Sebastián and Isabella, holding hands by the window. He thinks of Camila’s quiet competence, proving that doing things right matters.

He thinks of the man he might have been.

Then he signs.

“When do I start?”

The stranger smiles. “You already have.”

Next Episode: "Nuevo Amanecer" Three months later. The pilot program faces its moment of truth. Users must choose: stay with what they know, or trust FinPulso with their financial futures. The team has done everything right — but will it be enough? And when a new threat emerges, they'll discover whether the culture they've built can withstand the pressures of real success. Some endings are just new beginnings in disguise.

Web Components: The Framework-Free Renaissance

2026-02-17T00:00:00+01:00

Building Modern UIs Without the Framework Tax

17.02.2026, By Stephan Schwab

Modern browsers now support everything needed to build sophisticated, reactive web interfaces without React, Vue, or Angular. Web components, custom elements, shadow DOM, and native event systems let developers create modular, reusable UI pieces that communicate elegantly — and AI assistants can help you master these patterns faster than ever before.

The Shift That Already Happened

Something remarkable occurred while many developers weren’t watching. The web platform itself became capable of doing what frameworks were invented to do.

"The browser has become the framework. We just haven't fully noticed yet."

Custom Elements let you define your own HTML tags with their own behavior. Shadow DOM provides encapsulation that keeps component styles and structure isolated. Templates and slots offer composition patterns. And perhaps most importantly, the native event system provides a robust mechanism for components to communicate without tight coupling.

These aren’t experimental features. They’ve been shipping in every major browser for years. The question is no longer whether they work, but why more developers haven’t embraced them.

Freedom from the Upgrade Treadmill

Every framework carries hidden costs. There’s the initial learning curve, certainly. But there’s also the ongoing maintenance burden: major version upgrades that break things, deprecated patterns you must migrate away from, build tooling that needs constant updating.

"When your component is just HTML, CSS, and JavaScript, there's nothing to upgrade except your own code."

Web components built on platform standards sidestep this entirely. The browser vendors have committed to backward compatibility in ways that framework maintainers simply cannot. Code written to web standards a decade ago still works today. That’s not true of code written for Angular 1, or React class components, or Vue 2’s options API.

For organizations building products that need to run for years, this stability matters enormously. It’s one less thing that can break, one less dependency that can become a security vulnerability, one less abstraction layer between your code and the runtime.

Components That Talk to Each Other

The elegance of web components becomes most apparent when you consider how they communicate. The native Custom Events system provides everything you need for sophisticated component interaction.

A component deep in your UI hierarchy can dispatch an event that bubbles up through the DOM tree:

this.dispatchEvent(new CustomEvent('item-selected', {
  detail: { itemId: this.selectedId, metadata: this.itemData },
  bubbles: true,
  composed: true
}));

Any ancestor component — or the application shell itself — can listen for and respond to that event. There’s no need for a global state store, no prop drilling, no context providers. The DOM itself becomes your communication infrastructure.

"The DOM has always been an event bus. We just forgot how to use it."

Components can also communicate downward through attributes and properties. When a parent changes an attribute, the child’s attributeChangedCallback fires, giving it a chance to respond. For more complex data, properties allow passing objects and arrays directly.

This creates a natural, predictable flow: data down through properties and attributes, events up through the bubbling system. It’s the same pattern React popularized, but using web standards instead of library abstractions.

Learning Through Building

Here’s something that surprises many developers: you don’t need to master every detail of the Web Components specification before you can build useful things. The basics are remarkably accessible.

A minimal custom element looks like this:

class TaskCard extends HTMLElement {
  connectedCallback() {
    this.innerHTML = `
      <div class="task">
        <h3>${this.getAttribute('title')}</h3>
        <p>${this.getAttribute('description')}</p>
      </div>
    `;
  }
}
customElements.define('task-card', TaskCard);

That’s a working component. It’s not production-ready — it lacks reactivity, encapsulation, and proper lifecycle handling — but it demonstrates how accessible the entry point is. You can iterate from this simple beginning toward more sophisticated implementations as your understanding grows.

AI as Your Pair Programming Partner

"The best way to learn web components is to build them — and AI makes experimentation nearly frictionless."

This is where modern AI assistants transform the learning experience. You can describe what you want a component to do, receive a working implementation, and then ask questions about the parts you don’t understand. The AI can explain why composed: true matters for events that need to cross shadow DOM boundaries. It can show you the difference between connectedCallback and constructor. It can help you refactor toward better patterns as your requirements evolve.

You don’t need to read the entire MDN documentation on Web Components before building your first real component. Instead, you can learn by doing, with an AI partner that understands the specification deeply and can answer questions in context.

This approach — building first, understanding deeply second — works remarkably well with web standards. The patterns are simpler than framework patterns because there’s less abstraction. When something doesn’t work, the debugging surface is smaller. When you want to understand why something works, there are fewer layers to peel back.

A Practical Architecture

Consider a realistic scenario: a dashboard with multiple independent panels that need to respond to a shared filter.

Without frameworks, you might structure this with a simple event-driven architecture:

// FilterPanel dispatches when criteria change
this.dispatchEvent(new CustomEvent('filters-changed', {
  detail: { dateRange: this.selectedRange, categories: this.selectedCategories },
  bubbles: true
}));

// Dashboard shell listens and broadcasts to children
document.addEventListener('filters-changed', (e) => {
  document.querySelectorAll('[data-filterable]').forEach(panel => {
    panel.applyFilters(e.detail);
  });
});

Each panel component implements its own applyFilters method. The panels don’t know about each other. The filter component doesn’t know about the panels. The dashboard shell provides minimal coordination. Components can be developed, tested, and reused independently.

"Loose coupling isn't just elegant architecture — it's faster development and easier maintenance."

This same pattern scales. As you add more panels, they simply implement the expected interface. As you add more event types, the coordination logic grows proportionally, not exponentially.

Shadow DOM: Encapsulation That Actually Works

One of the most practical benefits of web components is shadow DOM encapsulation. Your component’s styles don’t leak out, and global styles don’t leak in (unless you explicitly allow them).

class StyledCard extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({ mode: 'open' });
  }
  
  connectedCallback() {
    this.shadowRoot.innerHTML = `
      <style>
        .card { padding: 1rem; border-radius: 8px; background: #f5f5f5; }
        h3 { margin: 0 0 0.5rem 0; color: #333; }
      </style>
      <div class="card">
        <h3><slot name="title"></slot></h3>
        <slot></slot>
      </div>
    `;
  }
}

Those styles affect only this component. You can use simple, semantic class names without worrying about collisions. You can refactor styles without fear of breaking something elsewhere.

This is encapsulation that actually encapsulates. It’s what CSS Modules, CSS-in-JS, BEM, and countless other approaches have tried to achieve — built directly into the platform.

When Frameworks Still Make Sense

Web components aren’t always the right choice. If your team already knows React deeply and moves quickly with it, there’s real value in that shared expertise. If you’re building something that will be maintained by developers who expect framework patterns, web components might create friction.

"The best technology choice is the one that fits your team, your timeline, and your constraints."

For new projects, though — especially smaller teams or solo developers building products that need to run for years — web components deserve serious consideration. The reduced complexity, improved stability, and smaller bundle sizes create real advantages.

And there’s an interesting hybrid path: many frameworks now work well with web components. You can introduce custom elements gradually into an existing React or Vue application. You can wrap web components in framework-specific bindings. Migration can be incremental rather than revolutionary.

Getting Started Today

The path to building with web components is surprisingly short:

Build a simple component. Something with a template, maybe an attribute or two. See how it mounts to the DOM.
Add interactivity. Handle events within the component. Update the DOM in response. Experience the directness of working without virtual DOM abstraction.
Implement communication. Have one component dispatch a custom event. Have another listen for it. Feel how naturally the event system handles component coordination.
Encapsulate with shadow DOM. Add scoped styles. Use slots for composition. Appreciate how encapsulation simplifies your mental model.
Iterate and expand. Build more components. Let AI help when you encounter unfamiliar territory. Learn the lifecycle callbacks as you need them.

Each step teaches something useful. Each component you build adds to your understanding. And unlike framework knowledge that might become obsolete, your understanding of the web platform will compound for years.

The Renaissance Is Here

We’re in an interesting moment. The platform has caught up to — and in some ways surpassed — the capabilities that made frameworks essential a decade ago. The tooling exists. The browser support is universal. The patterns are well-documented.

"The future of web development might look more like its past: standards-based, interoperable, and built to last."

What’s been missing is momentum. Developers gravitate toward what’s popular, and frameworks have dominated mindshare for so long that many never seriously evaluated the alternative.

But trends shift. The JavaScript ecosystem’s complexity has become a recognized problem. The appeal of simpler, more stable foundations grows as developers tire of churn. AI assistants make learning new approaches faster and less intimidating.

Web components offer something valuable: a way to build modern, sophisticated interfaces with technology that will still work decades from now. For developers willing to explore beyond the framework mainstream, there’s a quieter, more elegant path waiting.

The tools are ready. The browsers are ready. Perhaps it’s time to rediscover what the web platform can do.

Beyond the Solo Developer Myth

2026-02-14T00:00:00+01:00

The Collaboration Advantage in Software Delivery

14.02.2026, By Stephan Schwab

Pair programming has been around since the ENIAC days, yet it remains misunderstood and underutilized. This article explores the proven styles of collaborative coding—from traditional pairing to mob programming—and examines how AI assistants are changing the equation. Not by replacing human collaboration, but by introducing new dynamics that demand fresh thinking about knowledge transfer, learning, and sustainable delivery.

The mythology of the lone genius developer—hunched over a keyboard at 3am, single-handedly shipping miraculous code—persists in our industry. It makes for compelling storytelling. It’s also largely fiction.

Jean Bartik, one of the ENIAC programmers, said it plainly: “Betty Snyder and I, from the beginning, were a pair. And I believe that the best programs and designs are done by pairs, because you can criticize each other, and find each others errors, and use the best ideas.” This was in the 1940s. Before the word “program” was even established. They invented programming itself as a collaborative practice.

So why, eight decades later, do so many organizations still treat collaboration as optional, expensive, or a sign that developers lack independence?

The Traditional Pairing Styles That Actually Work

"Pairing isn't about two people doing one person's work. It's about two perspectives producing better outcomes than either could alone."

The comprehensive work from Birgitta Böckeler and Nina Siessegger at Thoughtworks documents what effective pairing looks like in practice. Not theory. Practice. Here are the styles that work:

Driver and Navigator

The classic approach. One person (the driver) writes code while thinking tactically—focused on the immediate lines, syntax, and details. The other (the navigator) thinks strategically—watching for larger patterns, potential obstacles, upcoming decisions.

The key is role switching. Regularly. If one person drives for hours while the other watches passively, you’re doing it wrong. The energy comes from both people actively participating, each bringing a different cognitive mode to the work.

Ping-Pong Pairing

This works brilliantly when you have a clearly defined task that lends itself to test-driven development. Developer A writes a failing test. Developer B writes the implementation to make it pass. Then Developer B writes the next failing test, and Developer A implements. Back and forth. Red-green-refactor in a rhythm.

It forces disciplined TDD. It keeps both people engaged. And it naturally distributes knowledge because both developers touch both tests and implementation.

Strong-Style Pairing

“For an idea to go from your head into the computer it MUST go through someone else’s hands.”

This style is particularly effective for knowledge transfer. The experienced person navigates. The novice drives. The navigator guides without taking over. The driver trusts the navigator even when understanding is incomplete, with questions deferred until after implementation.

It borders on micro-management, which is exactly why you shouldn’t overuse it. But for initial onboarding, for transferring specific technical knowledge, it’s remarkably effective. The goal is active learning by doing, not passive watching.

Pair Development (Beyond Just Coding)

"Development of a feature requires planning, research, documentation, and coding. Pairing should encompass all of it."

This is less a technique and more a mindset shift. A user story lifecycle includes planning, research, exploration, documentation—not just typing code. Pairing through all those activities keeps both people invested in the outcome.

When you hit unknowns, split up to research different angles. Define the questions you need to answer, timebox the exploration, then reconvene to share findings. This respects different learning paces while maintaining shared ownership.

Mob Programming and Ensemble Programming

Sometimes two isn’t enough. Sometimes the whole team should be in the room.

Mob programming (also called ensemble programming to avoid the negative connotations of “mob”) extends the pairing concept: everyone works on the same thing, at the same time, on the same computer. One person drives. The rest navigate.

Sounds chaotic. Done well, it’s the opposite.

Woody Zuill, who pioneered this approach, describes it as “All the brilliant people working on the same thing, at the same time, in the same space, on the same computer.” The benefit isn’t speed—it’s alignment. Complex decisions get made with everyone present. Knowledge spreads instantly. No one is blocked waiting for someone else to finish.

Use it for:

Kicking off complex features where multiple perspectives prevent costly misunderstandings
Resolving architectural decisions that affect the whole system
Onboarding new team members into unfamiliar codebases
Working through gnarly legacy code where collective memory is required

Don’t use it for:

Straightforward implementations that one or two people can handle
Tasks where the approach is already well understood
8 hours a day (exhausting and wasteful)

The Thoughtworks article notes that rotations every 2-3 days in regular pairing help prevent knowledge silos, but too-frequent rotations create excessive context switching. The same principle applies to mob sessions. Use them intentionally, not as default.

AI as a Pairing Partner: The New Dynamics

"AI doesn't replace the navigator. It changes what the navigator needs to focus on."

Now we arrive at the part that’s genuinely new. AI-powered coding assistants — the ones that integrate directly into your editor, offering real-time code suggestions, completions, and refactoring — have introduced a different kind of collaboration dynamic.

What Changes

When an AI assistant sits in your development environment, it handles certain navigator functions automatically:

Suggesting completions based on context
Generating boilerplate that follows established patterns
Offering alternative implementations
Catching syntax errors before you run the code

This is real. Developers report measurable productivity gains on routine coding tasks. But that’s not the interesting part.

The interesting part is what this frees the human navigator to do.

What the Human Navigator Still Owns

A human pairing partner provides things AI cannot:

Judgment about business value: Is this the right problem to solve?
Architectural intuition: Will this decision create technical debt?
Domain knowledge: Does this implementation match how the business actually works?
Learning transfer: Can you explain why we’re doing it this way?
Emotional support: Is your pair frustrated, stuck, or burning out?

AI assistants are excellent at pattern matching. They’re trained on millions of code examples. But they don’t understand your product strategy, your users’ pain points, or the constraints your team operates under.

The Risk: Erosion of Learning

Here’s where it gets problematic.

A junior developer pairing with a senior developer learns not just what to code, but why certain approaches work and others don’t. They see decision-making in real time. They ask questions. They absorb tacit knowledge about the domain and the codebase.

A junior developer pairing with an AI assistant gets fast answers. They get working code. But they miss the learning journey.

If we’re not careful, AI assistants become a crutch that prevents developers from building the judgment required for senior-level work. GitHub Copilot can suggest a correct implementation. It cannot explain the trade-offs, the historical context, or the alternatives that were considered and rejected.

This is why AI-assisted development works best when:

The developer already has solid fundamentals
There’s still human pairing happening regularly for knowledge transfer
Teams explicitly carve out time for learning, not just shipping

AI as Productivity Multiplier, Not Replacement

The framing that matters: AI assistants are tools that amplify what skilled developers can accomplish. They don’t replace the need for collaboration or mentorship.

Used well, they handle repetitive patterns so humans can focus on higher-level problems. Used poorly, they create a generation of developers who can ship code but can’t explain why it works.

Making Collaboration Sustainable

"Pairing requires vulnerability. It's exhausting. It's also the fastest path to a resilient team."

The Thoughtworks article identifies something crucial: pairing is hard because it requires showing that you don’t know something, that you’re uncertain, that you made a mistake. In an industry obsessed with the myth of the 10x engineer, that’s uncomfortable.

But as Brené Brown’s research shows, vulnerability is the birthplace of innovation and change. Teams that can be vulnerable with each other—that can say “I don’t understand this” or “I think we’re going down the wrong path”—are the teams that build great software.

Practical measures to make it work:

Don’t pair 8 hours a day. Six hours maximum. Build in breaks. Reserve time for email, meetings, individual learning.
Rotate pairs regularly, but not so frequently that you lose continuity. Every 2-3 days is often effective.
Use the Pomodoro technique to enforce breaks and keyboard switching.
Agree on core pairing hours so people can manage their calendars.
Create psychological safety where asking questions is normal, not a sign of weakness.

The organizations that get this right don’t treat pairing as a process imposed from above. They treat it as a skill to be learned, practiced, and continuously improved.

The Uncomfortable Truth About Code Review

Many teams avoid pairing because they already have code review. Formal approval workflows. Two sign-offs required. Process enforced.

Here’s the problem: code reviews after the fact are often superficial. The coder defers a few decisions thinking the reviewer will catch problems. The reviewer trusts the coder’s diligence and doesn’t look too closely. The sunk cost fallacy kicks in—nobody wants to cause rework on something already “done.”

Pairing gives you code review in real time, when it’s still cheap to change direction. Four eyes on the code as it’s written. Immediate feedback. Continuous small corrections instead of big rework cycles.

For teams practicing trunk-based development and continuous integration (as documented in the State of DevOps reports), delayed code reviews actively undermine flow. You want small changes integrated frequently. Work sitting for days in review queues creates friction, not safety.

Pull requests have their place—they’re essential for open source contributions where trust must be earned and review latency is unavoidable. But in-company teams working from a shared trunk should pair by default and commit directly.

When Not to Pair

"Not every line of code requires two people. But dismissing pairing wholesale is a mistake."

Be pragmatic. Some tasks genuinely don’t benefit from pairing:

Well-defined boilerplate following established patterns (though even here, pairing might reveal that the boilerplate is a design smell)
Trivial bug fixes where the problem and solution are obvious
Individual learning time when someone needs to explore a concept deeply

Junior developers particularly need some solo time to build confidence that they can solve problems independently. Constant pairing without breaks can create dependency rather than growth.

The key is making pairing the default while being intentional about exceptions. Not the other way around.

What This Means for You

If you’re a developer:

Practice pairing. Get comfortable with the vulnerability it requires.
When using AI assistants, stay engaged. Don’t let them think for you.
Rotate between different pairing partners to spread knowledge.

If you’re a tech lead or manager:

Create environments where pairing is normal, not exceptional.
Don’t measure productivity by vanity metrics—individual commit counts, story points closed, or other numbers that reward solo heroics over collaborative quality.
Invest in psychological safety—pairing doesn’t work in fear-based cultures.

If you’re an executive:

Understand that pairing is not “two developers doing one job.”
It’s an investment in quality, knowledge sharing, and team resilience.
The short-term cost is real. The long-term return is higher.

Jean Bartik and Betty Snyder figured this out in the 1940s. Eight decades later, the lesson remains: the best code comes from collaboration, criticism, and the willingness to use each other’s best ideas.

The solo developer myth dies hard. But it’s time to let it go.

El Regreso

2026-02-13T00:00:00+01:00

Previously: "Desde Cero" — Six weeks into the recovery, FinPulso hit its hundredth deployment. Hernán, the resistant veteran, finally embraced collaboration. But Camila discovered something troubling: someone inside the company has been feeding information to an external source. The commits don't lie. Someone they trusted has been a spy all along.

The Confrontation

FinPulso office. Saturday, 9:30 AM.

Camila and Diego wait in the empty conference room. The evidence is spread across the table — commit logs, access records, the external IP address that traces back to a VPN registered in Panama. Not Alejo’s location. Someone else’s.

Stefan arrived twenty minutes ago. He’s been reading in silence, his expression unreadable.

“The code changes are subtle,” Stefan says finally. “Logging that looks like debugging. Transaction summaries that could be performance monitoring. Someone who knows how to hide in plain sight.”

“Someone who’s been here from the beginning,” Diego adds. “Someone we invited into every meeting. Every planning session. Every celebration.”

The elevator doors open. Footsteps approach.

Luciana Ortiz enters the conference room, her Instagram-perfect composure faltering when she sees the three of them waiting.

“You asked me to come in on a Saturday.” Her voice is carefully light. “This must be important.”

"This must be important."

Camila slides the commit log across the table. “These changes were made from your account. Over the past six weeks. Logging code that sends transaction data to an external server.”

Luciana’s face goes pale. She reaches for the papers, reads the first page, then the second. Her hands are shaking.

“I didn’t write this code.” Her voice is barely a whisper. Her hands are shaking so badly the papers rattle.

“It’s your account,” Diego says, and his voice is granite. “Your credentials. Your commit signature.”

“I didn’t—” Luciana’s breath catches. Her face goes white, then gray, then something terrible. “Oh God. Oh Dios mío.” She presses her hand over her mouth like she’s going to be sick. “Marco.”

The name comes out strangled. Her whole body is trembling now.

Stefan leans forward. “What about Marco?”

“He borrowed my laptop. Multiple times. Said he needed to check something, review some documentation. I never thought—” Her voice breaks. “He has my passwords. I gave them to him. Because I trusted him. Because I was stupid enough to believe—”

She can’t finish the sentence. The woman who always has the perfect angle, the perfect lighting, the perfect story — she has no story for this.

The Truth

10:15 AM.

They’ve moved to Don Hernando’s office. The old man sits behind his desk, his face carved from stone. Laura stands in the corner, watching everything, saying nothing.

Luciana is crying. Not the performative tears of someone seeking sympathy — the raw, ugly tears of someone whose world has collapsed.

“Marco approached me eight months ago,” she says. “At a networking event. He was charming. Sophisticated. He said he was consulting for companies across Latin America, that he had connections in Europe, that he could help my career.”

“And you believed him,” Don Hernando says.

“I wanted to believe him.” Luciana wipes her eyes. “He made me feel special. Important. Like I was more than just the marketing girl at a struggling startup.”

"I wanted to believe him."

“So you gave him access to our systems.”

“I gave him my heart. The access was just…” A sob rips out of her throat. Mascara runs down her cheeks in dark rivers. “I didn’t know what he was doing. I didn’t know he was sending data to anyone. I thought he was just—” She laughs, and it’s an ugly sound. “I thought he loved me. Me. The stupid little marketing girl who was so desperate for attention she handed her passwords to the first man who called her beautiful.”

Her voice rises, cracking. “I am such a fucking idiota.”

Stefan speaks for the first time. “The logging code is sophisticated. Not something an Agile consultant would typically write.”

“Marco isn’t just a consultant,” Diego says quietly. “I’ve been doing some research. He’s connected to a network of investors who specialize in distressed acquisitions. They identify struggling companies, accelerate their failures, then buy the pieces for pennies.”

The room absorbs this.

“Alejo,” Don Hernando says. It’s not a question.

“They know each other from banking circles. Marco was brought in to destabilize us. Luciana was just—”

“A tool,” Luciana finishes bitterly. “A useful idiot with a pretty face and no self-respect.”

Don Hernando is quiet for a long moment. Then:

“Everyone makes mistakes, señorita. The question is what you do next.”

The Proposition

11:30 AM.

While Luciana composes herself in the bathroom, Diego pulls Camila aside.

“There’s something else. Something I’ve been waiting to tell you until we dealt with this.”

“More bad news?”

“Actually… I’m not sure what it is.” Diego pulls out his phone, shows her a message thread. “Elena Vargas. She’s the CTO at MiPago. Our biggest competitor.”

Camila reads the messages. Her eyebrows rise.

“She wants to meet? Why would the competition want to talk to us?”

“That’s what I asked.” Diego scrolls to the latest message. “Read her answer.”

"She wants to meet? Why would the competition want to talk to us?"

Camila reads aloud: “‘We’ve been watching FinPulso’s recovery. What you’ve accomplished in two months is more than we’ve managed in two years. We have market reach but can’t execute. You can execute but need market reach. Perhaps we should stop pretending to be enemies.’”

She looks up at Diego.

“Is this real?”

“I worked with Elena years ago. Before either of us joined our current companies. She’s genuine. Smart. Not like the MiPago leadership we’ve heard about.”

“And what does she want?”

“A meeting. Off the record. To explore whether there’s a path that doesn’t involve destroying each other.” Diego pauses. “She specifically asked for you.”

“For me?”

“She said, ‘I want to talk to whoever built your deployment pipeline. That’s the person who actually understands what you’ve achieved.’”

Camila doesn’t know what to say. Three months ago, she was a junior developer whose ideas were ignored. Now the CTO of their largest competitor is asking to meet her.

The Warning

2:00 PM.

Stefan finds Camila on the rooftop terrace. She’s staring at the Bogotá skyline, her notebook open but empty.

“Diego told me about MiPago’s offer,” he says, settling into a chair beside her.

“It’s not an offer yet. It’s a conversation.”

“Conversations become offers. The question is whether you’re ready for what comes after.”

Camila turns to look at him. “What do you mean?”

“If you meet with Elena Vargas, and the conversation goes well, you’ll have a decision to make. Not just for the company — for yourself.” Stefan’s voice is thoughtful. “You’ve built something remarkable here. In a few months, you’ve transformed how FinPulso delivers software. But that transformation has made you visible. Valuable. Other companies will notice.”

"That transformation has made you visible. Valuable."

“You think they’ll try to recruit me?”

“I think you need to know what you want before someone else tells you.” Stefan smiles faintly. “When I was your age, I let other people define my success. Bigger titles, bigger salaries, bigger responsibilities. I chased what they wanted until I forgot what I wanted. And then I broke.”

“Your burnout.”

“My burnout. It took losing everything to realize that what I actually valued was the work itself. The craft. Helping teams build things that matter.” He meets her eyes. “What do you value, Camila? Not what FinPulso values, not what the investors value. What do you want?”

Camila is quiet for a long moment.

“I want to build things that work,” she says finally. “I want to be part of a team that cares about doing it right. I want to keep learning from people who know more than I do.” She pauses. “And I want to prove that the way we do things — the tests, the deployments, the collaboration — isn’t just faster. It’s better. For everyone.”

Stefan nods. “Then that’s your compass. Whatever Elena Vargas proposes, whatever Don Hernando decides, whatever Alejo tries next — that’s how you navigate.”

The Shadow’s Move

Somewhere in Bogotá. 4:00 PM.

Alejo’s phone has been ringing all morning. Marco, increasingly frantic. The data pipeline has gone dark. Something has changed.

Alejo doesn’t answer. Instead, he places a call of his own.

“Mariana,” he says when she picks up. “Thank you for taking my call.”

“I almost didn’t.” Mariana’s voice is cold. “You were removed from the board for a reason.”

“For politics. Not for performance.” Alejo keeps his voice smooth, confident. “I’m calling because I have information. About FinPulso’s future. Information the board should consider before making any… permanent decisions.”

"I have information the board should consider."

Silence on the line.

“I’m listening,” Mariana says finally.

“MiPago is preparing an acquisition offer. They’ve been in contact with Diego Vargas — who, you’ll recall, left FinPulso under questionable circumstances and is now somehow trusted with rebuilding the company.”

“Diego returned to help. The circumstances are documented.”

“Are they? Or is he a Trojan horse, preparing the way for a competitor takeover?” Alejo lets that hang. “The German consultant leaves for Panama. The junior developer suddenly becomes technical lead. Diego — who worked for the competition for three months — is welcomed back like a prodigal son. And now MiPago wants to ‘collaborate.’”

“These are coincidences, Alejandro. Not evidence.”

“Perhaps. But do you want to risk $15 million on perhaps?” Alejo’s voice drops, becomes almost intimate. “I’m not asking to return to the board. I’m asking for a meeting. One hour. Let me show you what I’ve discovered. Then you can decide for yourself who’s really looking out for FinPulso’s interests.”

The silence stretches.

“One hour,” Mariana says. “Monday. My office.”

Alejo smiles. The hook is set.

The Meeting

Sunday, 3:00 PM. Café Cultor, Chapinero.

Elena Vargas is not what Camila expected.

She’s older — early forties — with gray streaking through her dark hair and the weathered confidence of someone who has shipped software through multiple economic crises. She wears no jewelry except a simple wedding band. Her laptop bag looks like it’s survived a war.

“Thank you for coming,” Elena says, shaking Camila’s hand. “I know this is unusual.”

“That’s one word for it.” Camila sits across from her, Diego beside her. Stefan declined to attend — “This conversation is about you, not me.”

“Let me be direct.” Elena opens her laptop, turns it to face them. “Six months ago, MiPago was winning. We had three times your market share. We had bank partnerships you couldn’t match. We were supposed to crush FinPulso by Christmas.”

"Six months ago, we were supposed to crush you by Christmas."

“What happened?” Diego asks.

“We couldn’t ship. Every feature took six months. Every deployment required a war room. Every bug fix broke something else.” Elena shakes her head. “We have forty developers. You have twelve. And somehow you’re deploying daily while we’re still planning quarterly releases.”

“We almost collapsed,” Camila says. “The demo disaster. You must have heard.”

“I heard. And then I watched you recover. Watched you actually fix the problems instead of hiding them. Watched you build something real.” Elena leans forward. “That’s when I realized: we’re not competing with your product. We’re competing with your process. And we’re losing.”

Camila and Diego exchange glances.

“So what are you proposing?” Camila asks.

“I don’t know yet. That’s why I wanted to talk.” Elena closes her laptop. “Maybe a partnership — our distribution, your technology. Maybe a merger. Maybe just sharing knowledge. Maybe nothing at all.” She meets Camila’s eyes. “But I’m tired of pretending we’re doing this right when we’re not. And I think you might be the only people in Bogotá who actually know how to build software.”

The Choice

Sunday, 8:00 PM.

Don Hernando listens to Camila’s report in silence. Diego fills in details. Stefan observes from his usual corner.

“So our competitor wants to surrender,” Don Hernando says finally.

“Not surrender. Collaborate.”

“In my experience, there’s little difference.” The old man rises, walks to his window. “When I was young, the cattle barons of the Llanos would sometimes propose ‘collaboration.’ Shared grazing rights. Mutual assistance during droughts. It always ended the same way — the weaker partner absorbed by the stronger.”

"In my experience, collaboration and surrender are little different."

“With respect, patrón,” Camila says, “we’re not cattle ranchers.”

Don Hernando turns, surprised.

“The software industry doesn’t work like the Llanos. The resources aren’t finite. If we help MiPago improve their delivery, it doesn’t take anything from us — it proves that what we’ve built has value beyond FinPulso. It proves that the process matters.”

“And if they simply steal our methods? Use them against us?”

“Then we’ll have helped improve fintech for Colombian users. Which is what we said we wanted to do in the first place.”

Don Hernando studies her. The junior developer who built a working system in secret. Who saved the company when the demo crashed. Who is now telling the old patriarch how the world works.

“You’ve changed,” he says quietly. “The girl who hid her project for three months because she was afraid no one would listen — she wouldn’t speak to me like this.”

“Maybe I learned that speaking up is safer than staying silent.”

“Maybe.” Don Hernando almost smiles. “What does Stefan think?”

Stefan stirs. “I think sustainable competitive advantage doesn’t come from secrets. It comes from capability. If FinPulso’s capability is strong enough, sharing it only makes you stronger. If it isn’t…” He shrugs. “Then you’ll find out sooner rather than later.”

The Ally

Monday, 9:00 AM.

Isabella finds Luciana in the empty marketing office. She’s been packing her desk — photos, awards, the carefully curated artifacts of a career built on appearances.

“Don Hernando didn’t fire you,” Isabella says.

“He should have.” Luciana doesn’t look up. “I let Marco use my credentials to spy on the company. It doesn’t matter that I didn’t know. I was stupid. Reckless. I cared more about a man’s attention than my own judgment.”

“That’s not stupidity. That’s being human.”

Luciana finally meets Isabella’s eyes. “You never liked me.”

“No. I didn’t.” Isabella sits on the edge of the desk. “You were everything I taught myself not to be. Obsessed with image. Chasing approval. Willing to compromise for the right Instagram story.”

"You were everything I taught myself not to be."

“So why are you here?”

“Because I’ve also learned something these past months. About judgment. About second chances.” Isabella pauses. “You have information about Marco. About how he operates, who he’s connected to, what he’s really after. That information is valuable. And if you want to make things right, using it might be the place to start.”

Luciana is quiet for a long moment.

“He’s still in contact with Alejo,” she says finally. “I saw messages on his phone. Alejo is planning something — something big. He’s been meeting with people, building alliances. I think he wants to come back.”

“Come back how?”

“I don’t know. But Marco was supposed to help create the conditions. Destabilize FinPulso from inside. Make the investors lose confidence.” Luciana’s voice hardens. “He used me for that. And I’m going to make sure it doesn’t work.”

Isabella extends her hand. “Then maybe we can work together after all.”

The Metrics Milestone

Monday, 10:00 AM. FinPulso office.

The team gathers in the conference room for the first time since the pilot agreement. Don Hernando approved the collaboration with MiPago, and now it’s time to review the initial results.

Camila stands at the whiteboard, marker in hand. The room is quiet, expectant.

"The defect rate has fallen from 18% to 4%. That's real progress."

“Since we implemented the recovery plan,” she begins, “our metrics have improved significantly. Deployment frequency is up 300% — we’re now averaging 12 deployments per week. Production outages have dropped to zero in the last month.”

She writes the numbers on the board: Deployment Frequency: 12/week Outages: 0

Diego nods. “The defect rate has fallen from 18% to 4%. That’s real progress.”

Defect Rate: 4% (down from 18%)

Pipe, usually gruff, allows himself a small smile. “The legacy systems are stable. No more midnight firefights.”

Isabella leans forward. “User satisfaction is up 25%. The credit unions are actually using the platform now, not just testing it.”

User Satisfaction: +25%

Sebastián watches the numbers accumulate. His voice is quiet when he speaks. “These aren’t just metrics. They’re proof that what we did — the honesty, the rebuilding — it worked. We stopped pretending and started delivering.”

Don Hernando, sitting in his usual chair, nods slowly. “Numbers tell the truth. And these numbers say we’re on the right path.”

The room is silent for a moment, absorbing the weight of their achievement. For the first time, the future feels possible.

The Threat

Monday, 2:00 PM. Mariana’s office.

Alejo arrives in his best suit, carrying a leather portfolio filled with carefully prepared documents. Evidence, he calls it. Proof of Diego’s duplicity, Camila’s inexperience, Stefan’s hidden agenda.

Mariana listens. Reads. Asks questions.

And then she leans back in her chair.

“This is impressive work, Alejandro. Very thorough.”

“Thank you.”

“There’s just one problem.” Mariana slides a folder across the desk. “We already know everything you’ve told me. And we know something you don’t.”

"We already know everything you've told me."

Alejo opens the folder. Inside are bank records. Meeting schedules. Email transcripts. A detailed timeline of his secret negotiations with MiPago — not Elena’s collaboration proposal, but the hostile acquisition he’d been planning before his removal from the board.

“Where did you get this?”

“Does it matter?” Mariana’s voice is ice. “You weren’t just advising MiPago on how to compete with us. You were planning to engineer our failure so you could buy the pieces. You were going to destroy Don Hernando’s investment, take control of the company, and sell it to the highest bidder.”

“That’s not—”

“Save it.” Mariana stands. “The board has already reviewed this material. As of this morning, your shares are frozen pending legal review. If you attempt to contact any FinPulso employee, investor, or partner, we’ll pursue criminal charges.”

Alejo’s mask finally cracks. The smooth confidence, the practiced charm — it falls away, revealing something desperate underneath.

“You can’t do this. I’m still a shareholder. I have rights.”

“You have lawyers. Use them.” Mariana walks to the door and opens it. “This meeting is over.”

The Path Forward

Monday, 6:00 PM.

The team gathers in the conference room. Not for a crisis meeting — for something rarer. A planning session. A conversation about what comes next.

Camila stands at the whiteboard, marker in hand. Beside her is a diagram: FinPulso’s current capabilities on one side, MiPago’s market position on the other. In the middle, a question mark.

“Elena Vargas has proposed a pilot project,” Camila says. “Three months. We help their team adopt our deployment practices. They give us access to their bank partnerships. At the end, we evaluate whether a deeper collaboration makes sense.”

“And if it doesn’t?” Sebastián asks.

“Then we’ve learned something about how other companies work. And they’ve learned something about how we work.” Camila pauses. “Either way, we’re stronger.”

Not a war room anymore. A strategy session.

Don Hernando speaks from his usual chair. “My instinct says this is a trap. That MiPago is playing us.”

“Your instinct has been wrong before, patrón,” Diego says quietly. “With respect.”

“Yes. It has.” The old man looks around the room. At Camila, who saved his company. At Diego, who returned when he could have stayed away. At Pipe, who finally stopped fighting and started building. At Isabella, who kept notes on Alejo when everyone else was fooled. At Sebastián, his co-founder, who is learning to lead instead of hide.

“Perhaps,” Don Hernando says, “it’s time I trusted a different instinct. Yours.”

He looks at Camila.

“Set up the pilot. But carefully. And keep Stefan involved — at least by phone. I want someone with experience watching for traps we might miss.”

Camila nods. “I’ll reach out to Elena tonight.”

The Return

That night. Stefan’s finca, Panama.

The call comes through just as Stefan is settling onto his terrace, aguardiente in hand, horses grazing in the field below.

“She did well,” Camila’s voice says through the phone. “Luciana. She gave us everything she had on Marco and Alejo. Isabella is helping her put together a formal statement.”

“And the MiPago proposal?”

“Don Hernando approved the pilot. Three months, focused on deployment practices.”

Stefan smiles. “You convinced him.”

“I don’t know what convinced him. Maybe exhaustion. Maybe age. Maybe he’s finally learning that he doesn’t have to control everything.”

The news from Bogotá was good. His work there might finally be taking root.

“Or maybe,” Stefan says, “he’s learning that the people closest to the work understand it best. And that trusting them isn’t weakness — it’s wisdom.”

Camila is quiet for a moment.

“When are you coming back?”

“For the pilot? I’ll be there. But Camila—” He pauses. “You don’t need me the way you did. You know that, right?”

“I know.” Her voice is soft. “But I’m glad you’ll be there anyway.”

“So am I.”

He hangs up. The sun is setting over Panama, painting the sky in oranges and purples. Somewhere in Bogotá, a team is learning to build software the right way. And somewhere in a lawyer’s office, Alejo is realizing that his game is finally, truly over.

Or so they hope.

The Final Move

Midnight. Unknown location.

Alejo’s phone buzzes. A message from a number he doesn’t recognize.

Unknown Mariana thinks she's won. She hasn't.

Alejo Who is this?

Unknown Someone who shares your interests. And has resources you don't.

Alejo What resources?

Unknown Vulcano Capital invested $15 million in FinPulso. But we're not the only ones watching. There's another investor. Bigger. And they're very interested in what happens next.

Alejo What do they want?

Unknown A meeting. Tomorrow. Come to the address I'm sending.

Alejo Why should I trust you?

Unknown Because you have no other options. And because we want the same thing you want.

Alejo Which is?

Unknown FinPulso. All of it. And we're willing to pay.

Alejo had lost the battle. But the war was just beginning.

Alejo stares at the message. His empire has crumbled. His schemes have been exposed. His allies have abandoned him.

But someone new is reaching out. Someone with money. Someone with plans.

The smile that spreads across his face is not the smile of a defeated man. It’s the smile of a predator who has just caught a new scent.

He types a reply:

Alejo Send the address.

Next Episode: "La Verdad" All secrets come out. The board convenes for a final reckoning. Confrontations that have been building for months finally explode. And in the aftermath, relationships are tested, alliances shift, and everyone at FinPulso must face the truth about who they are and what they're willing to fight for.

When Players Revolt

2026-02-12T00:00:00+01:00

Previously: "The Crunch That Never Ends" — Three months into perpetual crunch, Tomasz threatens to quit, Mariana flags a critical inventory bug, and Lukas overrides her warning: "Ship it anyway." The update launches Wednesday.

Wednesday, 08:12 — Launch Morning

"We fixed the bug. Six hours, no corners cut. It's solid."

The development floor had the nervous energy of launch day. That particular hum of anxiety mixed with caffeine. Monitors showed dashboards — server metrics, player count, error rates — glowing in the morning dimness. Anton stood at his desk, coffee in hand, refreshing the deployment status page every thirty seconds. His knee bounced involuntarily. Sweat dampened the back of his neck despite the office air conditioning.

Mariana sat beside him, laptop open to the production logs. Her eyes burned from too little sleep — they’d worked until 23:00 last night finishing the inventory fix. Six hours of careful refactoring, proper validation, unit tests for every edge case. No corners cut. Not this time. Her hands were steady on the keyboard, but her stomach churned with that pre-launch dread that never quite went away.

“Deployment’s at 94%,” Anton said. His accent thickened when he was anxious — Russian baseline, Berlin casual, gaming English all blending together. “Two minutes.” He set his coffee down with a hand that trembled slightly.

“It’ll be fine,” Mariana said. She sounded more certain than she felt. Her mouth was dry. “We fixed the bug. Properly. It’s solid.”

Hassan joined them, laptop under one arm, looking like he’d slept in his clothes. He probably had. Dark stubble shadowed his jaw. His eyes were bloodshot. “Deployment pipeline cooperating today?”

“So far.” Anton pulled up the error dashboard, green status indicators filling the screen. “No red flags yet.”

“Yet,” Hassan repeated. He set his laptop down with a soft thunk, opened a terminal. Black screen, green text. “Give it ten minutes. Something always breaks.”

“Cheerful as always,” Mariana said.

“Realistic,” Hassan corrected. He started tailing production logs, lines of text scrolling past. “Three months doing this. Something always breaks.”

The deployment status changed: COMPLETE — 08:14:23 CET

Anton exhaled loudly, shoulders dropping. “We’re live.” Relief evident in his voice.

They watched the dashboards like soldiers watching the horizon for incoming fire. Player count climbing. 127 concurrent users. 208. 341. Morning rush in Europe, players checking the new update. Numbers ticking up in real-time.

Error rate: 0.02%. Normal. Server load: nominal. Database queries: smooth. Green. All green.

“Looking good,” Anton said. His voice carried cautious hope.

Mariana felt the knot in her stomach loosen slightly. The tension in her shoulders eased. Maybe this time would be different. Maybe fixing it properly actually worked.

Her phone buzzed. Lukas in the team channel:

Lukas Weber Update is live! Great work everyone. Marketing push starts 09:00. Let's make this one count. 🚀

Emoji and all. Lukas loved a launch. Performative enthusiasm.

Mariana refreshed the error dashboard. Still green. 412 concurrent players now. No inventory corruption errors. No silent data loss. The validation she’d added was working exactly as designed — catching edge cases, logging them, preventing the disaster she’d predicted.

“I think we actually did it,” she said quietly, almost afraid to jinx it.

Anton grinned, some of the tension finally leaving his face. “Told you. Russian development, Brazilian QA, Syrian infrastructure. Unstoppable.”

Hassan didn’t smile. He was staring at his terminal, brow furrowed, jaw tight.

“What?” Mariana leaned over, pulse quickening. “What’s wrong?”

“Nothing,” Hassan said slowly. “That’s the problem. It’s too quiet.”

“Maybe things actually work when we fix them properly,” Anton said.

“Maybe,” Hassan said. But he didn’t look convinced.

Thursday, 09:47 — The First Cracks

"273 tickets. All saying the same thing."

Marcus Thompson was drinking his third coffee of the morning when the support ticket count hit triple digits. The bitter liquid had gone cold an hour ago, but he drank it anyway. He’d been watching the counter climb since 08:00 — first a trickle, then a stream, now a flood. His monitor glowed with angry red notification badges.

273 tickets. All saying the same thing. His pulse quickened. Chest tightened.

My inventory is gone.
All my items disappeared after the update.
Years of progress just vanished.
WTF happened to my gear???

He opened the internal Slack with hands that had started to shake slightly from too much caffeine and rising panic.

Marcus Thompson @Katja @Anton @Mariana - We have a problem. 273 support tickets about inventory loss. Players saying all items disappeared after yesterday's update.

Anton Mikhailovich Petrov That's impossible. We fixed the inventory bug. Validation is working.

Mariana Santos Let me check production logs.

Marcus Thompson Check fast. App Store reviews are coming in. Not good.

Marcus opened the App Store with a sense of dread. Their game’s rating had been 4.2 stars on Tuesday. Yesterday it was 4.1. This morning…

2.8 stars.

His stomach dropped. The number glowed on his screen, accusatory.

And dropping. He watched it tick down to 2.7 as he stared.

The recent reviews section was a nightmare. His throat went dry:

⭐ “Update deleted my entire inventory. 500+ hours of gameplay GONE. Uninstalling.”

⭐ “How do you ship an update this broken? Do you even test?? Absolute trash.”

⭐ “I spent money on gems and now everything I bought is GONE. Refund or I’m reporting to Apple.”

⭐⭐ “Game was fun before this disaster update. Fix it or lose your players.”

Marcus’s phone rang. Claudia, head of marketing.

“Tell me you’ve seen the App Store ratings,” she said without preamble.

“Just checked. It’s bad.”

“It’s catastrophic. We pushed €25K in ads yesterday. Players download, see 2.8 stars, uninstall immediately. Our conversion rate dropped 67% overnight.” Her Italian accent sharpened with stress. “Marcus, what the fuck happened? We launched yesterday. Everything was fine.”

“Everything looked fine,” Marcus corrected. “But players are reporting massive inventory loss. Development’s investigating now.”

“How long to fix?”

“I don’t know. I’m support, not development.”

“Find out. I’m pausing all ad spend until we stabilize the rating. But if we go below 2.5 stars, we’re talking weeks of recovery. Months, maybe.”

She hung up.

Marcus pulled up the support dashboard. 312 tickets now. The count was accelerating.

His desk phone rang. Then his mobile. Then another Slack notification.

The flood had started.

10:23 — Mariana Finds the Truth

"We fixed the new code. But the migration script..."

Mariana had the production logs open across three monitors. Player IDs, inventory queries, error traces filling every screen. The validation code she’d written was working perfectly — no errors, no edge cases triggered. Green across the board.

So why were thousands of players reporting inventory loss? The disconnect made her skin prickle.

She filtered the logs by timestamp, fingers flying across the keyboard. Wednesday 08:14 — deployment completed. Wednesday 08:15 to 09:00 — normal operation. Wednesday 09:00 to 10:00 — first support tickets appeared.

But the inventory errors hadn’t started at deployment. They’d started later. Hours later. The pattern didn’t make sense.

She pulled up the database migration logs. Scrolled down. Her pulse quickened.

And there it was. Her breath caught.

[2026-02-12 09:03:47] Running migration: inventory_schema_v2.sql
[2026-02-12 09:03:49] WARNING: NULL values detected in legacy player_inventory.item_data
[2026-02-12 09:03:49] Applying default value: [] (empty array)
[2026-02-12 09:03:52] Migration complete: 4,847 rows updated

Her stomach dropped. The coffee she’d drunk earlier threatened to come back up. Cold sweat broke out across her forehead.

The bug wasn’t in the new code. It was in the database migration. The script that ran automatically after deployment to update the old schema to match the new one. The thing they’d been too rushed to review.

Someone had written a migration that assumed all legacy inventory data was valid. When it found NULL values — corrupted data from months of tech debt — it “fixed” them by setting inventory to an empty array.

Wiping thousands of players’ items in the process.

She opened the migration file. Read the SQL. And found the comment at the top:

-- Migration script v2.1
-- Author: Anton Petrov
-- Date: 2026-02-10
-- Note: Quick fix to handle legacy NULL values. Defaulting to empty array.
-- TODO: Investigate why NULLs exist in production. Low priority.

Mariana Santos @Anton - The inventory bug. It's not the validation code. It's the migration script. Line 47. You're setting NULL inventory values to empty arrays. That's wiping player data.

Anton Mikhailovich Petrov Блядь.

Anton Mikhailovich Petrov Fuck. I added that as a safety check. I didn't think...

Mariana Santos How many players?

Anton Mikhailovich Petrov Migration log says 4,847 rows.

Mariana Santos 4,847 players just lost everything.

Anton Mikhailovich Petrov Can we rollback the migration?

Mariana Santos Not without rolling back 24 hours of live gameplay for everyone. And we don't have backups that granular.

Hassan Al-Rashid Who approved this migration?

Anton Mikhailovich Petrov I wrote it Monday. Deployed it with yesterday's release. Nobody reviewed it. We were rushing.

Hassan Al-Rashid Because Lukas demanded Wednesday launch.

Mariana Santos And now 4,847 players paid the price.

11:34 — War Room

"Why didn't I know about this earlier?"

Lukas called the emergency meeting in Conference Room A. The big one, glass walls, everyone could see them from the open floor. Fishbowl visibility. The entire development team watching through transparent walls.

Katja, Marcus, Elif, Anton, Mariana, Hassan, Claudia, and Lukas himself. The damage control team. They filed in silently, the air thick with tension. Someone had forgotten to crack a window — the room smelled stale, recycled air and stress sweat.

Lukas stood at the head of the table, laptop showing the App Store page. 2.1 stars now. The number glowed accusingly. Fifty-three new one-star reviews in the last hour. His jaw was set, knuckles white where he gripped the laptop edge.

“Explain,” he said. Voice cold. Controlled.

Mariana spoke first. “Database migration script. Written Monday during the rush to fix the inventory validation bug. It defaulted NULL values to empty arrays. 4,847 players affected. All inventory data lost.”

“Can we restore it?”

“No,” Hassan said flatly. “We don’t have backups at that level. Player inventory is gone.” Each word landed like a hammer.

Lukas’s jaw tightened. A vein pulsed in his temple. “How did this get into production?”

Anton raised his hand slightly, like a student confessing to breaking a window. His face had gone pale. “I wrote the migration. Nobody reviewed it. We were moving too fast.” His voice cracked slightly on the last word.

“You wrote code that deleted player data and didn’t have anyone review it?”

“I wrote a migration script to handle edge cases I didn’t understand,” Anton corrected. “Under time pressure. While trying to ship on your Wednesday deadline. No, I didn’t have time for review. You told us to ship, so we shipped.”

The room went silent.

Lukas turned to Katja. “Why didn’t I know about this earlier?”

Katja stared at him. “You did know. Mariana flagged the inventory bug six days ago. I told you it was critical. You said ship anyway.”

“I said fix it and ship.”

“We fixed the validation code. But we didn’t have time to audit the entire system. That’s what happens when you compress six days of work into thirty-six hours.”

“I’m not accepting that.” Lukas’s voice was cold. Ice. “This is development’s responsibility. You deploy code, you own the outcome.”

Mariana laughed. Sharp, bitter. The sound cut through the tension like breaking glass. Heat flooded her face — anger, frustration, exhaustion all boiling over. “We own the outcome? We told you this would happen. I flagged the bug. Katja escalated it. Anton and I worked until 23:00 fixing what we could. And now you’re standing here asking why you didn’t know?” Her hands were shaking. She pressed them flat against the table.

“Mariana—” Katja started.

“No.” Mariana stood abruptly, chair scraping against the floor. The sound echoed in the silent room. “I’m done pretending this is normal. We knew this update was risky. We knew we were rushing. We knew corners were being cut. Everyone in this room knew. And we shipped it anyway because Lukas said Wednesday was non-negotiable.” Her voice was steady now, cold with fury.

She turned to Lukas. “You want to know why you didn’t know? Because you don’t listen when we tell you. You hear ‘this is risky’ and you hear ‘make it work anyway.’ So we make it work. Until it doesn’t. And then you ask why nobody warned you.” Her chest heaved. Adrenaline made her hands tremble.

Lukas’s expression was unreadable. Stone. When he spoke, his voice was quiet. Dangerous. “Get out.”

“What?” The word came out strangled.

“Get out of this meeting. You’re clearly too emotional to be productive.”

Mariana stared at him. Blood pounded in her ears. Then at Katja, who said nothing — wouldn’t even meet her eyes. Then at Anton, Hassan, Marcus — all of them silent, looking down, looking away.

She grabbed her laptop with shaking hands and left, the door handle cold under her palm.

The glass door closed behind her with a soft click that felt deafeningly loud. Through the window, the development floor watched — fifty pairs of eyes tracking her walk of shame.

14:17 — Damage Control Plan

"This isn't a PR crisis. This is an existential crisis."

After Mariana left, the room stayed silent for exactly eleven seconds. Then Elif spoke.

“We need a plan. Immediately.”

Lukas nodded. “Agreed. Options?”

“First,” Elif said, “we need to stop the bleeding. Marcus — how bad is support?”

“427 tickets and climbing. Players are furious. Some threatening chargebacks, refunds, reporting us to Apple.”

“How many affected players are paying users?” Claudia asked.

Elif pulled up her analytics dashboard. “Migration affected 4,847 accounts. Of those, 1,203 made in-app purchases in the last 90 days. Average spend: €47 per user. Total affected revenue: approximately €56,500.”

“Fifty-six thousand euros of paying players just had their progress deleted,” Claudia said quietly. “This isn’t a PR crisis. This is an existential crisis.”

Lukas rubbed his temples. “What do we offer them?”

“Full inventory restoration if we can,” Elif said. “If we can’t — and Hassan says we can’t — then compensation. Gems, premium currency, exclusive items.”

“How much?”

“Enough that they don’t request refunds. Figure €30 per affected player minimum.”

“That’s €145,000,” Lukas said.

“Cheaper than losing them permanently,” Elif countered. “These are paying users. Retention value over 12 months is €180 per player. If we lose them, we lose €870,000 in future revenue.”

Lukas was silent for a moment. Then: “Do it. Compensation package by end of day. Marcus, draft the support response. Elif, coordinate with marketing on the public statement.”

“And development?” Katja asked quietly.

“Emergency fix. All hands. Cancel everything else. I want this solved by Monday.”

“That’s three days,” Hassan said. “We don’t even know if it’s fixable.”

“Then work the weekend and find out.”

Anton spoke carefully. “Lukas, the team is exhausted. We’ve been crunching for three months. Now you want another weekend—”

“I want the problem fixed before we lose more players. Is that clear?”

Anton’s jaw tightened. But he nodded.

“Good.” Lukas closed his laptop. “I want hourly updates. Development works around the clock until this is resolved. No excuses.”

He left.

The remaining team sat in silence.

Katja looked at the faces around the table. Hassan, dark circles under his eyes, wedding ring glinting as he closed his laptop. Anton, staring at nothing, probably replaying the migration script in his head. Marcus, already drowning in support chaos.

“I’ll go talk to Mariana,” Katja said quietly.

Nobody responded.

16:53 — Katja and Mariana

"When does this stop being my problem?"

Katja found Mariana on the rooftop terrace, smoking a cigarette she’d bummed from someone in marketing. Mariana didn’t smoke. But today, apparently, she did. Her hands trembled as she brought it to her lips.

“I didn’t know you smoked,” Katja said.

“I don’t.” Mariana took another drag, coughed — harsh, hacking. Her eyes watered. “But I also don’t usually get kicked out of meetings for telling the truth.”

Katja sat on the concrete ledge beside her. The stone was cold through her jeans. Berlin stretched out below them — Prenzlauer Berg rooftops, construction cranes scattered across the skyline, the TV tower in the distance like a needle piercing gray sky. February wind cut through her jacket, biting at exposed skin. She pulled her collar tighter.

“He shouldn’t have kicked you out.”

“But you didn’t stop him.”

“I should have.”

Mariana crushed the cigarette under her shoe. “Katja, I need you to be honest with me. Are we actually going to fix this? Or are we just going to patch it with enough duct tape and premium currency to make the players shut up until the next disaster?”

“I don’t know.”

“That’s what I thought.” Mariana pulled her jacket tighter against the wind. “I’ve been here eighteen months. First year was great — small team, smart people, solving interesting problems. Last six months? It’s been crisis after crisis. And every time, the answer is work harder, move faster, ship anyway.”

Lukas Weber Where's Mariana? Need her on the emergency fix team.

“Do you? Because from where I’m sitting, you know it’s broken but you keep playing along. You escalate issues to Lukas, he overrules you, and then you tell us to make it work anyway. So what’s the point of having a CTO who won’t actually fight for development?”

The words landed hard. Katja had no defense. Because Mariana was right.

“I’m trying,” Katja said quietly.

“Are you? Or are you just trying to keep everyone happy while the whole thing burns down around us?”

Katja had no answer.

Mariana stood abruptly. “I’m going home. Tell Lukas if he wants me working this weekend, he can apologize for kicking me out of that meeting. Otherwise, I’ll see everyone Monday.” Her jaw was set, eyes red-rimmed.

“Mariana—”

“When does this stop being my problem, Katja?” Mariana’s voice cracked, tears threatening to spill. “I flagged the bug. I did the work. I fixed what I could. And now players are furious, the game is review-bombed, and I’m the one getting yelled at for being ‘too emotional.’ When do I get to say this isn’t my fault?” Her hands were fists at her sides, nails digging into palms.

She left before Katja could respond, footsteps echoing on the concrete stairs.

Katja sat alone on the rooftop terrace as the sun dropped lower over Berlin, painting the sky in shades of bruised purple and orange. The city hummed below — traffic, construction, sirens, life continuing regardless of whether a gaming studio was collapsing under its own dysfunction. The wind picked up, carrying the smell of exhaust and distant rain.

Her phone buzzed. Lukas.

Lukas Weber Where's Mariana? Need her on the emergency fix team.

Katja stared at the message. Then she turned off her phone and sat in the cold for another twenty minutes.

Saturday, 02:47 — The War Room Never Ends

"We're not fixing the system. We're just patching the symptoms."

The development floor at 02:47 on a Saturday morning had the surreal quality of a place that should be empty but wasn’t. Fluorescent lights hummed overhead, too bright for the late hour. Empty coffee cups littered every surface. The air smelled like stale pizza and desperation. Anton sat at his desk, fifth coffee of the night — the mug read “git commit -m ‘final final FINAL’” — staring at database queries until they blurred. His eyes burned. Hassan was beside him, scrolling through server logs, shoulders hunched with exhaustion. Across the room, Nikos and Dimitri argued in Greek about rollback strategies, voices hoarse and frustrated.

Mariana had come in Friday evening. Not because Lukas apologized — he hadn’t. But because the team needed her. And despite everything, she still cared about the work. Still cared about the players whose data they’d destroyed.

She stood now at the whiteboard, mapping the data corruption with fingers stained red from dry-erase markers. Red markers for affected players. Blue for potential recovery paths. Green for confirmed lost causes. The colors bled together at the edges.

Most of the board was red. So much red.

“We can recover approximately 40% of affected inventories,” she said. Her voice was hoarse from hours of meetings. “Players who made purchases in the last 7 days — we have transaction logs. We can rebuild their items from receipts.”

“And the other 60%?” Anton asked.

“Gone. Unless we have backups we don’t know about, or Hassan pulls a miracle from the database transaction history.”

Hassan didn’t look up from his laptop. “No miracles. Transaction history only goes back 72 hours. Anything older is rotated out. It’s gone.”

Lukas Weber Update? Are we on track for Monday deploy?

Mariana Santos We'll have partial recovery by Monday. 40% of affected players. The rest are permanent data loss. Compensation package ready. Full postmortem report by Tuesday.

Lukas Weber Why only 40%?

Mariana Santos Because we don't have the infrastructure to do better. This was in my original bug report. Insufficient backups, no staging environment, compressed timeline. All predictable outcomes.

Lukas Weber I need better than 40%.

Mariana Santos Then build a time machine. Otherwise, this is reality.

She underlined the last point twice.

“We’re not fixing the system,” she said. “We’re just patching the symptoms. Next month it’ll be something else. Different bug, same cause.”

“So what do we do?” Hassan asked.

“I don’t know.” Mariana capped the marker. “But I know working until 03:00 on a Saturday fixing a disaster we predicted a week ago isn’t the answer.”

Lukas Weber I need better than 40%.

Mariana Santos Then build a time machine. Otherwise, this is reality.

She put her phone face-down on the desk with more force than necessary. The screen cracked against the surface.

The development floor was quiet except for the hum of servers — that constant mechanical drone that never stopped — and the click of keyboards. Outside, Berlin slept. Streetlights cast orange halos through the windows. Inside, the team that had warned about this disaster worked through the night fixing it anyway. Because that’s what they always did.

Hassan closed his laptop with deliberate care. His movements were slow, weighted with exhaustion. “I’m going home. My wife is barely speaking to me. I’ve been here 19 hours. Monday we’ll finish what we can.” Dark circles shadowed his eyes. He looked ten years older than he had on Wednesday morning.

“Lukas said—” Anton started.

“I don’t care what Lukas said.” Hassan stood, grabbed his jacket. “He doesn’t get to decide when my marriage falls apart. I’ll be back Monday. The database will still be broken then.”

He left.

Anton looked at Mariana. “He’s right, you know.”

“I know.”

“So why are we still here?”

Mariana stared at the whiteboard — red markers, blue hope, green reality. “Because if we’re not here, it doesn’t get fixed at all.”

“And if we are here, we burn out and quit like Tomasz.” Anton shut his laptop. “I’m going home too. Girlfriend’s birthday is Sunday. I already missed Valentine’s Day for the last crisis. Not missing this.”

One by one, the team left. Nikos and Dimitri, still arguing in Greek as they headed for the elevator. Linnea, mascara smudged under her eyes. Sofia, carrying her shoes because her feet hurt too much to wear them.

By 03:30, only Mariana remained, staring at the whiteboard full of problems she couldn’t solve alone. The office felt cavernous in the silence. Empty desks stretched in every direction. The server fans hummed. Her reflection stared back from the dark windows — haggard, hollow-eyed.

Her phone buzzed one more time. Not Lukas. Katja. The screen’s glow illuminated her face in the darkness.

Katja Müller Go home. Please. This can wait until Monday.

Mariana Santos Can it? Or will Monday just be another crisis because we didn't work hard enough this weekend?

Katja Müller Mariana. Go home.

Mariana looked at the empty development floor. The cold coffee cups. The whiteboards full of half-solutions. The disaster that everyone saw coming but nobody could stop.

She grabbed her jacket and left.

Monday, 10:15 — The Aftermath

"We shipped partial recovery. 1,947 players restored. 2,900 permanently lost."

Monday morning standup had the hollow atmosphere of soldiers after a lost battle. Everyone present. Everyone exhausted. Nobody making eye contact. The development floor smelled like old coffee and defeat. People shifted their weight, avoided looking at each other. The energy was flat, dead.

Lukas stood at the front of the development floor, hands in his pockets, expression unreadable. “Update on the inventory recovery?”

Anton spoke. “We shipped the recovery package Sunday night. 1,947 players got their inventory back from transaction logs. The other 2,900 are permanent losses. They’re getting compensation — €35 in premium currency plus exclusive items.”

“App Store rating?”

“Recovering,” Claudia said. “2.4 stars now. Slowly climbing. We issued a public apology, compensated affected players, and paused all marketing spend. Estimated revenue loss for February: €47,000.”

Lukas nodded slowly. “And the root cause?”

Silence.

Katja finally spoke. “Database migration deployed without review during compressed timeline. Underlying causes: no staging environment, insufficient backup strategy, pressure to ship regardless of identified risks.”

“Who’s responsible?”

More silence.

Anton raised his hand. “I wrote the migration. I own it.”

“You wrote it under time pressure I created,” Lukas said quietly. Everyone looked up, surprised. “Katja escalated the inventory risk a week ago. I overrode her. This disaster happened because I prioritized launch date over development concerns.”

The floor was dead silent.

“Moving forward,” Lukas continued, “we’re implementing mandatory code review for all database migrations. Hassan gets budget for proper staging environment. And we’re hiring a second DevOps engineer immediately.”

Hassan spoke carefully. “That’s good. But it doesn’t fix the core problem.”

“Which is?”

“We keep saying yes to everything. 147 priorities, all marked critical. Teams working 60-70 hour weeks for three months. People burning out. This inventory disaster is a symptom. The disease is we’re trying to do too much too fast with too few people.”

Lukas was quiet for a moment. Then: “Noted. Katja, let’s discuss capacity planning this afternoon.”

He left.

The standup dissolved. People drifted back to their desks, the crisis not quite resolved but at least temporarily contained.

Mariana sat at her desk, staring at her laptop. The recovery code was deployed. The compensation was sent. The players were angry but slightly less angry. The App Store rating was slowly recovering.

Everything was back to normal.

Which meant nothing had actually changed.

Her phone buzzed. Elif.

Elif Yılmaz Coffee? Need to talk.

Mariana Santos When?

Elif Yılmaz Now. Café down the street. My treat.

Mariana grabbed her jacket. As she headed for the elevator, she passed Katja’s office. The CTO was on a call, gesturing with one hand, stress visible even through the glass.

Trying to fix a system that didn’t want to be fixed.

Mariana wondered how long Katja would last before she burned out too.

Next Episode: "The All-Hands Disaster" Lukas calls an emergency all-hands meeting Monday morning. Nine department leads. One brutal interrogation. Everyone blames everyone else in a circular firing squad. And Katja realizes: nobody actually knows what's happening across departments. They're all flying blind.

When Discovery Collides with Process

2026-02-10T00:00:00+01:00

The Quiet Friction Nobody Talks About

10.02.2026, By Stephan Schwab

Technical teams constantly discover better ways of working — through practice, through new tools, through the kind of learning that only happens when hands touch code. But management frameworks assume stability, not discovery. When a team finds a faster path and the framework says "that's not how we do it here," a quiet tension begins. This isn't about frameworks being wrong. It's about what happens inside people when organic insight meets institutional constraint.

Discovery Is Constant

"We are uncovering better ways of developing software by doing it and helping others do it."

The opening line of the Agile Manifesto isn’t a historical statement — it’s a present-tense declaration. Uncovering. Not “we uncovered” or “we will uncover.” The process of discovering better ways never stops.

In 2025 and 2026, this discovery has accelerated dramatically. AI coding assistants have changed how developers explore unfamiliar codebases. What once required days of careful reading now happens in hours of directed conversation with a model that has seen millions of patterns. Teams working with legacy systems find themselves extracting business rules at speeds that would have seemed implausible two years ago.

But AI is only one vector. Teams also discover through practice — a pairing session that reveals a simpler approach, a retrospective insight that changes how work flows, a new testing technique that catches defects earlier. The specific discovery matters less than the pattern: people doing the work find better ways.

Frameworks Assume Manufacturing

"Frameworks optimize for repeatability. Discovery optimizes for adaptation."

Most management frameworks carry an implicit assumption: software development is fundamentally a production process. Work enters. Defined steps occur. Product emerges. The framework’s job is to make those steps visible, predictable, and controllable.

This assumption made some sense when the primary challenge was coordination at scale. If you have hundreds of people who need to move in roughly the same direction, standardized processes reduce chaos. The framework becomes a shared language, a coordination mechanism, a way to ensure that Team A’s output fits Team B’s input.

But software development is design work, not manufacturing. The “product” that emerges from development is a design — a set of decisions about structure, behavior, and trade-offs. Those decisions benefit from learning. And learning means changing how you work based on what you discover.

Frameworks rarely accommodate this. The iteration cadence stays fixed. The prescribed meetings remain immutable. The role definitions don’t flex. When a team discovers that a recurring ceremony has become stale theater, the framework doesn’t say “stop doing what doesn’t work.” It says “the process is mandatory.”

The Moment of Tension

Consider a concrete scenario. A team working on legacy modernization discovers that AI-assisted code analysis lets them extract business rules directly into executable specifications. Previously, they followed the framework-prescribed flow: analysts interview stakeholders, write requirements documents, hand documents to developers, developers implement, testers verify against the documents.

The new approach is faster and more accurate. The AI reads the legacy code. Domain experts validate what it finds. Executable tests capture the verified rules. The requirements document — that intermediate artifact the framework mandates — becomes an obstacle rather than an aid.

"The discovery doesn't fit the container. Now what?"

What happens next reveals the tension:

The team could suppress the discovery. Keep using the old flow because that’s what the framework requires. This wastes the insight and the potential efficiency gain. It also creates cognitive dissonance — people know a better way exists but aren’t allowed to use it.

The team could work around the framework. Officially follow the prescribed flow while actually using the new approach. This creates shadow practices — real work happening invisibly while visible work becomes theater for process auditors.

The team could challenge the framework. Propose that the discovery become the new standard. This requires political capital, risks being labeled as “resistant to the process,” and often fails because frameworks have institutional defenders.

None of these options feels good. Each carries psychological weight.

The Mental Cost of Constraint

"Knowing a better way and being forbidden to use it is exhausting."

The tension isn’t abstract. It shows up in specific ways:

Cynicism develops. When process requirements override practical improvement, people stop believing that the organization cares about outcomes. They learn that compliance matters more than results. This cynicism is corrosive — it spreads through teams and survives long after specific frustrations fade.

Engagement drops. The Agile Manifesto’s first value — individuals and interactions over processes and tools — recognizes something fundamental about motivation. People do better work when they have agency. Framework constraints that override discovered improvements remove agency precisely where it matters most.

Trust erodes. When a team discovers something valuable and management’s response is “that doesn’t fit our process,” the implicit message is clear: your judgment doesn’t matter. Repeated enough times, this message destroys the trust that effective collaboration requires.

Talent leaves. Skilled practitioners have options. Organizations that systematically suppress improvement become places that skilled people leave. What remains is a workforce selected for compliance rather than capability.

Why Leaders Choose Frameworks Anyway

"The framework provides an answer to 'what are they doing down there?'"

Understanding this tension requires empathy for the people who mandate frameworks. They aren’t villains. They’re responding to legitimate needs with the tools available to them.

Visibility is a real need. Executives responsible for outcomes need to understand what’s happening. When they can’t see into engineering work — when it feels like money goes in and sometimes software comes out — the anxiety is genuine. Frameworks promise to make the invisible visible.

Accountability structures require consistency. When something goes wrong, someone asks “what happened?” Frameworks provide vocabulary for that conversation. “We followed the process” is an answer. “We adapted based on what we learned” sounds like an excuse, even when it’s the truth.

Fear drives conservatism. Allowing teams to adapt based on discovery means trusting them to make good decisions. That trust feels risky. What if they make bad decisions? What if different teams diverge so far that coordination becomes impossible? What if the flexibility becomes chaos? The framework constrains these fears by constraining the teams.

The alternative isn’t obvious. Following the Agile Manifesto’s values — genuinely valuing individuals over process, genuinely responding to change — requires a different kind of organizational capability. It requires leaders who understand enough about the work to evaluate adaptation without prescribing it. Many organizations lack this capability, so they substitute process for understanding.

A Path Through the Tension

The tension doesn’t have a clean resolution. Frameworks exist because real organizational needs exist. Discoveries happen because software development is learning work. Pretending either side of this equation doesn’t exist just pushes the conflict underground.

But some approaches reduce the friction:

Make discoveries visible — and explorable. When a team finds a better way, that insight needs to reach decision-makers. But here’s the uncomfortable truth: the people who mandated the framework often can’t easily admit it needs changing. Public acknowledgment feels like losing face. Tools like Caimito Navigator can help here. Navigator synthesizes patterns from daily logbooks and delivery signals, surfacing what teams are actually discovering. Its built-in observer role lets managers and executives read reports and explore these insights through AI chat — privately. They can ask questions, test assumptions, and understand implications without anyone watching. A leader can quietly investigate whether that mandated ceremony really has become theater, see the evidence, and reach their own conclusions before any public conversation happens. This private exploration removes the fear that blocks organizational learning. Over time, leaders who’ve already convinced themselves become advocates for adaptation rather than defenders of the status quo.

Distinguish governance from prescription. Organizations need visibility into delivery health — whether work is flowing, whether quality is acceptable, whether investments are producing outcomes. They don’t need to prescribe exactly how work happens. Deep insight into delivery patterns — the kind that reveals not just what’s happening but why — serves governance without constraining method. When leaders can see that a team’s adaptation is producing better flow and fewer defects, they don’t need to mandate process compliance. The evidence speaks for itself.

Create explicit space for adaptation. Some framework implementations acknowledge that local adaptation is necessary. Teams can experiment within boundaries. Successful experiments can spread. This isn’t the same as full autonomy, but it’s better than rigid prescription.

Build leadership fluency. The deepest solution is leaders who understand enough about software work to evaluate adaptation intelligently. When a CTO can assess whether a team’s discovery is genuine improvement or rationalized corner-cutting, the need for rigid process decreases. This fluency takes time to develop, but it changes what’s possible.

The Values Were Always the Answer

"Responding to change over following a plan."

The Agile Manifesto’s four values anticipated this tension. Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan.

These values don’t prohibit process, documentation, contracts, or plans. They establish priorities. When discovery reveals a better way, the values say: adapt. When the process says one thing and the learning says another, favor the learning.

But values require trust. Trust that teams will use their judgment well. Trust that adaptation won’t become chaos. Trust that people genuinely want to deliver value, not just avoid work.

Many organizations can’t extend that trust. The fear is too strong, the past experiences too painful, the leadership capability too thin. So they buy frameworks instead. And the frameworks, designed to be adoptable by organizations that lack trust, embed that distrust into their structure.

The result is the quiet tension that technical teams live with daily. Knowing better ways exist. Knowing the framework doesn’t allow them. Wondering whether to suppress, subvert, or fight.

None of those choices should be necessary. But until organizations learn to govern through visibility rather than prescription, until leaders develop the fluency to evaluate adaptation rather than mandate process, the tension will persist. The best practitioners will keep discovering better ways. The frameworks will keep constraining them. And the friction between discovery and process will continue to burn energy that could have gone into building software that matters.

AI as Your Legacy Code Archaeologist

2026-02-07T00:00:00+01:00

When the Business Logic Lives in Scattered VBA Macros

07.02.2026, By Stephan Schwab

Decades of business logic hide in customized VB6 applications where every customer installation has unique VBA code. Traditional approaches — reading documentation, interviewing users, manual code review — consume months and still miss critical rules. AI models trained on millions of code patterns can now assist domain experts in excavating these buried business rules, turning the undocumented into the understood. This isn't about replacing human expertise; it's about augmenting it with tireless, pattern-recognizing assistance.

The Hidden Treasure Problem

Consider a personnel scheduling application built in VB6, used by several hundred customers across Germany. At its core: 28,000 lines of VBA code implementing the logic for shift planning, time tracking, and — crucially — compliance with German Tarifverträge.

Tarifverträge are collective bargaining agreements that govern working conditions in German industries. They specify everything from maximum shift lengths to mandatory rest periods, from overtime calculations to holiday entitlements. But here’s the complexity: these rules differ by industry, by region, sometimes by individual company. A hospital in Bavaria operates under different rules than a manufacturing plant in North Rhine-Westphalia. A retail chain’s distribution center has different requirements than its store locations.

"Each customer installation encodes a unique interpretation of labor law. The code is the only complete specification of how their rules actually work."

Over two decades, each customer installation evolved to implement their specific Tarifvertrag requirements. Night shift premiums calculated one way here, another way there. Break time rules that depend on shift length, but with different thresholds per customer. Overtime that accrues differently based on contract type, employment status, and which collective agreement applies.

The business rules aren’t in a requirements document. They’re scattered across thousands of lines of VBA, written by developers who understood both the code and the labor law — some have moved on, but many remain available as domain experts who can validate what the AI extracts.

When these systems need modernization, organizations face a fundamental problem: even when the original developers remain available, they can’t dedicate months to explaining every module. The documentation, if it ever existed, describes intent rather than implementation. Users know what the system does for them, but not how — and certainly not how all the pieces interact.

Why Traditional Approaches Fall Short

The Documentation Gap

Most VBA customizations were never formally documented. A developer wrote code to solve an immediate problem, it worked, and everyone moved on. Even when documentation exists, it typically describes what someone intended to build, not what was actually built — and certainly not the subtle modifications made over years of maintenance.

The Interview Limitation

Business users can describe what they do with the system. They know their workflows, their edge cases, their workarounds. But they describe behavior, not logic. When they say “the system calculates our commission,” they can’t tell you the seven nested conditions that determine which commission rate applies, or the special handling for discontinued products, or the quarterly adjustment that kicks in for high-volume accounts.

The Manual Code Review Problem

Skilled developers can read VBA code. But reading thousands of lines across dozens of customized installations, identifying which patterns represent business rules versus technical implementation, and synthesizing it all into coherent understanding — this takes months. Even then, the review is colored by what the reviewer expects to find. Unexpected patterns get overlooked.

Enter AI-Assisted Code Archaeology

When I started working with this client as a Developer Advocate, the challenge was clear: extract enough understanding of the existing business rules to rebuild the system as a modern Progressive Web App — deployable both on-premises for customers who require it and as a SaaS offering for those ready for the cloud.

Traditional analysis would take a year or more. The domain experts know the business, but they don’t read VBA. The people who wrote the code are still around, but they’ve taken on other responsibilities — customer support, implementation consulting, training — and can’t dedicate months to walking developers through every module. And with several hundred customer variants, manually reviewing each installation was impractical.

Large language models trained on code bring something new to this analysis. Unlike previous attempts to simplify software development, AI doesn’t promise to eliminate the need for expertise — it amplifies it. These models have seen millions of code patterns across languages. They can recognize what code is trying to accomplish even when the implementation is convoluted. They don’t get tired after reading the hundredth subroutine. And they can be directed to look for specific types of business logic.

What AI Does Well

Pattern Recognition at Scale: AI models can process vast amounts of code and identify recurring patterns. They can spot where similar business logic appears across different customer installations, even when implemented differently.

Translation to Natural Language: Given VBA code, an AI can generate plain-language descriptions of what the code does. Not perfect descriptions — the AI may misunderstand context — but starting points that humans can verify and refine.

Comparison and Contrast: When analyzing multiple installations, AI can highlight where they differ. “Installation A calculates tax this way, but Installation B has this additional condition.” These differences often represent critical business rules specific to each customer.

Question Answering: Rather than just summarizing code, AI can answer specific questions. “How does this system handle returns?” “What triggers the credit limit warning?” “Where does the discount calculation happen?”

What AI Cannot Do

Understand Business Context: AI doesn’t know why a rule exists, only what it does. A human must determine whether a peculiar calculation reflects genuine business requirements or a long-forgotten workaround.

Guarantee Completeness: AI may miss subtle interactions between code modules. It may overlook conditional logic that rarely executes. It provides assistance, not certainty.

Replace Domain Expertise: The AI can identify that a calculation exists and describe its mechanics. Only someone who understands the business can judge whether the calculation is correct, necessary, or obsolete.

A Practical Approach

The approach we’ve developed treats AI as a bridge between code and domain expertise. The AI reads the VBA. The domain experts validate the business rules. The output isn’t just understanding — it’s executable specifications that will drive the new implementation.

The Account Challenge

A large portion of the VBA code deals with accounts — the building blocks for calculating employee payments. There are hundreds of different account types: base salary accounts, overtime accounts, night shift premium accounts, holiday accounts, sick leave accounts, each with their own calculation rules that vary by Tarifvertrag and customer configuration.

Understanding how each account type works — when it accrues, how it calculates, what triggers adjustments — is essential for the new system to produce correct paychecks.

Phase 1: AI-Driven Extraction to GitHub Issues

We direct the AI to analyze specific functional areas of the VBA code. “Examine this module and identify all account types. For each account, describe when it accrues, how amounts are calculated, and what conditions affect the calculation.”

The AI doesn’t just produce a report — it creates a GitHub Issue for each discovered business rule or account type. The issue contains the AI’s analysis: what the code appears to do, the conditions that apply, any variations it noticed, and questions where the logic was unclear.

"Each GitHub Issue becomes a unit of work: one business rule, extracted by AI, validated by humans, implemented in the new system."

Phase 2: Human Review and Scheduling

The subject matter experts who review each issue are the same people who wrote the original VBA code. They’ve since moved into customer-facing roles — implementation, support, training — but they remember the logic. They don’t need to re-read their own VBA; they read the AI’s business-language description and judge whether it matches what they built years ago.

Sometimes the AI got it exactly right. Sometimes it missed a nuance that the original author catches immediately. Sometimes the AI surfaced behavior that even the author had forgotten about — edge case handling they added for a specific customer a decade ago.

Validated issues get scheduled for implementation. Unclear issues get flagged for deeper investigation, often involving a quick conversation to refresh memories about that particular customer’s requirements.

Phase 3: AI-Assisted Implementation

Implementation follows a similar pattern. Given a validated issue describing a business rule, we prompt the AI to write the C# code and associated tests for the new PWA.

The AI produces both the implementation and the test cases. The tests encode the business rules in executable form: “Given an employee with contract type X working shift pattern Y, when calculating the night premium account, then the amount should be Z.”

Phase 4: Targeted Human Validation

The SMEs review the generated tests — but not line by line. They know which accounts are straightforward and which hide complexity. They know which Tarifvertrag rules have subtle edge cases and which are simple calculations.

They focus their attention on the critical and difficult parts. When they see a test for overnight shift premiums, they check whether it handles the midnight boundary correctly. When they see holiday accrual tests, they verify the logic for partial-year employees. Their expertise guides where to look, not whether to look at everything.

This targeted review is far more efficient than exhaustive verification. The SMEs apply judgment about where errors are likely to hide, rather than treating all code as equally risky.

The Augmentation Mindset

The domain experts at this company wrote the original VBA code. They know German labor law intimately, and they know the code because they built it. But their time is scarce — they’re busy with customer implementations, support calls, and training. Having them re-read thousands of lines of their own code to explain it to new developers isn’t a good use of their expertise.

The AI creates a translation layer. It reads the code and produces business-language descriptions. The original authors validate those descriptions — quickly, because they recognize correct explanations of their own work. Together, they surface understanding in hours that would otherwise take weeks of interrupted conversations.

"The domain expert knows the law. The AI reads the code. The tests capture what they discover together."

This collaborative model defines the Developer Advocate approach: hands-on technical work that amplifies existing expertise rather than replacing it. The AI is a tool. The domain experts provide judgment. The Developer Advocate orchestrates the process and ensures the extracted knowledge becomes executable specifications — not just documentation that will drift out of sync.

This matters especially for legacy modernization projects where understanding the existing system is craft work — investigation, hypothesis, verification. AI accelerates the investigation and verification phases while keeping humans firmly in control of the judgment calls.

Practical Considerations

Model Selection

Different AI models have different strengths. For code analysis, models with strong coding capabilities and large context windows work best. Claude Sonnet 4.5 and similar models can handle substantial code files and maintain coherence across long analysis sessions.

Context Management

VBA modules can be large. Providing enough context for the AI to understand what it’s looking at — without overwhelming it with irrelevant code — requires judgment. Sometimes you need to feed related modules together; sometimes you need to focus on specific functions.

Prompt Engineering

How you ask matters enormously. “What does this code do?” produces generic answers. “This VBA code appears to calculate pricing discounts. Identify all the conditions that affect which discount rate is applied, and explain each condition in business terms” produces useful analysis.

Version Control

When you’re analyzing code from multiple customer installations, keeping track of which code came from where is essential. The AI doesn’t care, but the humans interpreting its output certainly do.

Beyond Extraction: Building for the Future

Understanding legacy business rules is only the first step. The larger goal is typically to rebuild this logic in a modern system — documented, tested, maintainable.

The patterns you extract from legacy VBA can become the basis for:

Executable specifications that document exactly what the system should do
Test suites that verify the new implementation matches the old behavior
Domain models that make business rules explicit rather than buried in code

AI assistance doesn’t stop at extraction. The same models can help translate identified business rules into modern code, generate test cases, and document the intended behavior. The entire arc from understanding to rebuilding becomes faster.

The Real Value

The personnel scheduling system represents decades of accumulated knowledge about German labor law — not abstract legal theory, but practical implementation of how hundreds of organizations actually apply these rules. That knowledge has enormous value, but it was locked in VBA code that only a handful of people could read.

Now that knowledge is becoming explicit. The tests we’re creating don’t just validate the new PWA implementation — they document exactly how each Tarifvertrag rule works in practice. When a customer asks “how do you handle rest periods for part-time employees in retail?”, the answer exists in readable, executable form.

This changes the modernization economics fundamentally. A year of manual analysis compresses into weeks. The domain experts — who would have spent that year answering questions from developers trying to understand the code — instead validate extracted rules at the business level. Their expertise is leveraged, not consumed.

"We're not just building a new application. We're capturing institutional knowledge that would otherwise disappear with the legacy system."

For organizations facing legacy systems with extensive customization, this represents a new capability. Work that previously required months of expensive specialist time now happens in weeks. Analysis that was too expensive to justify becomes affordable. Business knowledge that was locked in decades-old code becomes accessible to people who can actually use it.

The code isn’t going anywhere. But now we have better tools to understand what it knows.

The Crunch That Never Ends

2026-02-06T00:00:00+01:00

Monday Morning, 09:47 — Development Floor

"147 tickets. 89 marked 'critical.' 42 flagged 'urgent.'"

The Berlin gaming studio’s development floor hummed with the particular tension of permanent crisis. Not the focused intensity of a real emergency — that would imply an end point. This was different. This was month three of what management kept calling “temporary crunch.”

Flourescent lights buzzed overhead, casting everything in that institutional white-blue that made everyone look slightly dead. The air smelled like cold coffee and the faint sweetness of energy drinks. Keyboards clattered in an uneven rhythm. Someone’s phone alarm went off — the third snooze this morning.

Tomasz Kowalski sat at his desk, staring at the Jira board on his secondary monitor. 147 tickets. 89 marked “critical.” 42 flagged “urgent.” The numbers blurred together. His eyes burned from too many late nights staring at screens. And now, vibrating insistently on his phone: another Slack message from Lukas.

His coffee had gone cold an hour ago. The mug sat forgotten beside his keyboard, a film forming on the surface.

Lukas Weber (CEO) Need to discuss adding multiplayer tournament mode to this week's sprint. Players have been asking for it. Huge revenue opportunity.

Tomasz’s hands hovered over the keyboard. His jaw tightened. A muscle in his temple throbbed. Three months ago, he would have typed a careful explanation about technical debt, velocity, and sustainable pace. Now, his fingers moved almost involuntarily, adrenaline making them shake slightly:

Tomasz Kowalski No.

Lukas Weber ?

Tomasz Kowalski I said no. We're already working 60-hour weeks. The team is exhausted. Mariana found a critical bug on Friday that we still haven't fixed. If you jam one more feature into this sprint, I quit.

He hit send before he could reconsider. His heart hammered against his ribs.

His phone stayed silent for exactly eighteen seconds. Then it rang. Lukas. The vibration felt like a small electric shock in his palm.

Tomasz let it ring four times before answering, watching the screen pulse with each ring. “I meant what I said.”

“Let’s talk in person.” Lukas’s voice had that forced calm that meant he was furious. “Conference room B. Five minutes.”

The line went dead.

Mariana Silva Santos looked up from her monitor two desks away, dark eyes sharp behind wire-frame glasses. “Did you just—”

“Threatened to quit.” Tomasz stood, grabbed his coffee mug even though it was cold. His legs felt unsteady. “Want to place bets on how long before I’m replaced?”

“You’re not getting replaced. You’re the only person who understands the entire codebase.”

“Exactly why I can make the threat.” Tomasz’s smile didn’t reach his eyes. “They need me more than I need this shitshow.”

10:03 — Conference Room B

"You think you're the only one exhausted?"

Lukas was already there when Tomasz arrived, laptop open, Apple Watch glowing blue on his wrist. He looked up, all business casual authority in his untucked white button-down and artfully graying temples. The conference room smelled like the mint tea Lukas always drank. Floor-to-ceiling glass walls overlooked the development floor — deliberately transparent, deliberately exposing.

“Close the door.”

Tomasz did, the magnetic latch clicking shut with a soft finality. But he didn’t sit. Standing gave him height advantage. “I’m not negotiating.”

“Neither am I.” Lukas closed his laptop with deliberate care. “You think you’re the only one exhausted? I’m running a company that’s burning through €1.2 million per month. We have eighteen months of runway if we don’t hit our growth targets. The board is watching every metric. Our last update underperformed, and players are asking for features we promised six months ago.”

“Features we promised because you said yes to everything without asking if we could deliver.”

“I said yes because that’s what product companies do. We listen to customers. We move fast.”

“Fast?” Tomasz laughed, sharp and bitter. “We’ve been ‘moving fast’ for three months straight. You know what moving fast actually means? Linnea crying in the bathroom last week because she’s so tired she can’t think. Anton shipping code with half the unit tests commented out because there’s no time to fix them properly. Hassan, our only DevOps engineer, mentioned as a blocker in every single standup because he’s one fucking person managing infrastructure for 85 people.”

Lukas’s expression didn’t change. “So we hire more.”

“We can’t onboard ten new developers when we’re already drowning. Training takes time. Ramp-up takes time. You keep adding people like throwing gasoline on a fire will put it out.”

“Then what’s your solution? Tell the board we’re slowing down? Watch our competitors ship the features we’re ‘too tired’ to build?”

Tomasz set his coffee mug down on the glass table with more force than intended. The sound cracked through the room. Cold coffee sloshed over the rim. “My solution? Stop saying yes to everything. Stop jamming features into sprints that are already overloaded. Give us time to fix the technical debt that’s strangling us. Let us breathe.”

“We don’t have time.”

“Then you don’t have me.”

The words hung in the air between them. Through the glass walls, Tomasz could see developers at their desks, oblivious. Lukas’s watch buzzed. He glanced at it, then back at Tomasz. When he spoke, his voice was quieter. “I need you here, Tomasz. You know that.”

“Then stop treating development like a magic box where features go in one end and revenue comes out the other.” Tomasz picked up his mug, ignoring the coffee pooled on the table. His hands were steady now. Calmer. “I’ll be at my desk. Let me know if you actually want to change anything, or if this was just another meeting where you pretend to listen before doing exactly what you planned anyway.”

He left before Lukas could respond, the glass door clicking shut behind him.

14:34 — Code Review

"Line 247 made her stomach drop."

Mariana had been staring at the pull request for twenty minutes. Her second monitor glowed with line after line of code, syntax highlighting making it look deceptively clean. The code wasn’t complicated — a simple inventory system update for their RPG hybrid game. But line 247 made her stomach drop.

inventory_items = player_data['items'][:100]

The function assumed player inventory arrays would never exceed 100 items. No validation. No error handling. Just a hard assumption baked into the slice.

She’d seen this pattern before. Six months ago, in the payment processing module. A developer assumed transaction IDs would never exceed six digits. When they hit 999,999, the entire payment system crashed for four hours. Support tickets flooded in. Players demanded refunds. The company lost €47,000 in a single afternoon.

This was worse. Players who hoarded items — and mobile RPG players always hoarded — would hit this limit within weeks of the update. Their inventory would silently corrupt. Progress would vanish. No error message. No warning. Just hundreds of hours of gameplay evaporating.

Her pulse quickened. She grabbed her water bottle, took a long drink, and set it down carefully.

She opened the code review comments:

Mariana Santos CRITICAL: Line 247 assumes max 100 inventory items with no bounds checking. Players regularly exceed this in our analytics data. This will cause silent data corruption when inventories exceed the limit. Recommend adding validation + error handling before merge.

Priority: CRITICAL

Blocking: YES

She hit Submit Review, marked the PR as “Changes Requested,” and immediately opened Slack to message Anton, the PR’s author.

Mariana Santos Hey Anton - flagged an issue in your inventory PR. It's critical. Can we pair on it tomorrow morning?

Anton Mikhailovich Petrov Saw your comment. Makes sense. But Lukas wants this shipped by Wednesday for the update. No time for refactor.

Mariana Santos This isn't a refactor. This is preventing data corruption. If we ship this, players will lose progress.

Anton Mikhailovich Petrov I know. But deadline is deadline. Already got pushback from Katja for being "too slow" last sprint.

Mariana stared at the screen. Her pulse hammered in her temples. Heat crept up her neck — that familiar flush of anger mixed with helplessness. Three months of this. Three months of “ship it now, fix it later.” The “later” never came. It just piled up, invisible and growing, until something catastrophic forced everyone to notice.

She picked up her phone with hands that trembled slightly and called Katja directly.

14:41 — Katja’s Office

"When does talking to Lukas actually change anything?"

Katja Müller was in her fourth meeting of the day when her phone buzzed. Mariana. She glanced at the Zoom gallery on her laptop screen — product roadmap discussion, mostly Lukas talking while everyone else half-listened, cameras on but eyes glazed. Her office window showed gray Berlin sky. Rain streaked the glass.

She muted herself, the red icon appearing beside her name. “Sorry, urgent call. Five minutes.”

Lukas kept talking, not even pausing to acknowledge her.

Katja answered, pressing the phone to her ear. “What’s wrong?”

“Anton’s inventory PR. Critical bug. Silent data corruption if player inventory exceeds 100 items. I flagged it. He says Lukas wants it shipped Wednesday regardless.”

Katja closed her eyes. “How bad?”

“Players lose all inventory progress. We’re talking thousands of hours of gameplay vanishing. Support nightmare. Review bombs. Refunds.”

“I’ll talk to Lukas.”

“Katja.” Mariana’s voice was steady but sharp. “This is the third time this month you’ve said you’ll talk to Lukas. The tournament leaderboard bug shipped. The daily reward duplication shipped. Both caused exactly the support nightmares I warned about. When does talking to Lukas actually change anything?”

The words hit harder than they should have. Because Mariana was right. Katja felt it like a physical blow — chest tightening, breath catching. Mariana was right. Katja had talked to Lukas. Every time. He’d listened, nodded, promised to “balance speed with quality,” and then made the exact same call: ship it anyway.

“I hear you.” Katja’s voice sounded tired even to herself. She pressed two fingers against her temple, where a headache was beginning to build. “But I have to try.”

“Do you?” Mariana asked. “Or are these conversations just theater so we all feel like we pushed back before doing what he wanted anyway?”

Katja had no answer for that. Her throat felt tight.

Mariana sighed. “I’ll document the bug in the ticket. When it blows up in production, at least we’ll have proof we saw it coming.”

She hung up.

Katja sat in the silence of her office, phone still pressed to her ear, listening to dead air. Through the wall, she could hear Lukas’s voice from the conference room, energetic and certain, outlining the update launch plan. His voice was muffled but recognizable — that confident cadence that made everything sound achievable.

She unmuted herself and rejoined the Zoom. Nobody had noticed she was gone.

17:17 — Lukas and Katja

"Ship the inventory fix. Make it happen. Wednesday is non-negotiable."

Lukas found Katja in her office an hour before most people left for the day. She was debugging something, two monitors full of terminal windows and stack traces, green text on black backgrounds scrolling as she typed. Her desk was cluttered — coffee cups, Post-it notes, a half-eaten protein bar still in its wrapper.

“Do you have a minute?”

She looked up, adjusted her glasses. Dark circles under her eyes. “For you or for another crisis?”

“Both.” He closed the door, the click echoing in the small space, and sat in the chair across from her desk without being invited. The leather creaked under his weight. “Tomasz threatened to quit this morning.”

“I know. He told me.”

“Did he tell you why?”

“He’s burned out. The team is burned out. You keep adding features to sprints that are already overloaded, and then you’re surprised when people break.”

Lukas’s jaw tightened. “I’m trying to save this company. The board expects growth. Players expect features. Competitors are moving faster than us. I don’t have the luxury of slowing down.”

“And I don’t have the luxury of pretending we can sustain this pace indefinitely.” Katja closed her laptop with deliberate care, gave him her full attention. The screen’s glow disappeared, leaving them in the dimmer overhead light. “Lukas, I need you to listen. Really listen, not just wait for me to finish so you can explain why you’re right.”

“I’m listening.” But his leg was already bouncing — that tell he had when he was impatient.

“Mariana flagged a critical bug in Anton’s inventory code this afternoon. Silent data corruption. Players will lose progress. She’s blocking the PR.”

“How long to fix?”

“That’s not the point.”

“It is the point. Wednesday is the launch. We promised players this update. If we delay again—”

“We delay and fix it properly, or we ship and watch it blow up in our faces two weeks later.” Katja’s voice was sharp. Her hands were flat on the desk, fingers splayed. “Lukas, this is the third critical bug this month that I’ve brought to you. The tournament leaderboard. The daily rewards. Both shipped despite my warnings. Both caused exactly the disasters I predicted. How many times are we going to do this?”

Lukas stood abruptly, the chair scraping against the floor. He paced to the window. Berlin traffic hummed below, red taillights streaming through the darkening streets, the city preparing for evening. Rain had started again, droplets catching the streetlights. When he turned back, his expression was unreadable.

“What do you want me to do, Katja? Tell the board we’re slowing down? Watch our churn rate climb while we ‘take our time’? I’m making the best decisions I can with the information I have.”

“Then get better information.” The words came out sharper than she intended. “You’re making decisions based on what you want to be true, not what’s actually happening in development. You have no visibility into our real capacity, our real technical debt, our real risks. You just see deadlines and revenue targets and assume we’ll figure out the details.”

“I trust you to figure out the details. That’s why I hired you.”

“You hired me to build a CTO organization. But you keep overruling me every time I tell you we can’t do something. So what’s the point of having me here if you’re going to ignore my judgment anyway?”

The question hung between them. Silence except for the rain against the window. Lukas’s watch buzzed. He glanced at it, then back at her. His jaw was set.

“Ship the inventory fix. Make it happen. Wednesday is non-negotiable.”

He left before she could respond, pulling the door open and walking out without looking back.

Katja sat alone in her office, staring at her closed laptop. Her reflection stared back from the black screen — glasses askew, hair escaping from its clip. Outside, the sky was darkening to that deep blue-gray that meant night was coming. Inside, the glow from the hallway lights painted everything in cold fluorescent white.

She opened Slack.

Katja Müller @Anton @Mariana - What's the absolute fastest we can fix the inventory bug without cutting corners?

Anton Mikhailovich Petrov 6-8 hours if we skip unit tests and manual QA.

Mariana Santos That's cutting corners.

Katja Müller I know. But Lukas won't delay the launch. So it's skip corners or ship corrupted.

Mariana Santos Unbelievable.

Katja Müller Anton, you and Mariana pair on this tomorrow. All day. Get it done. I'll handle Lukas if he complains about other work slipping.

Mariana Santos We'll fix it. But Katja — how long are we going to keep doing this?

She closed Slack before either of them could respond.

The update was launching Wednesday. The bug would be fixed by then. Everything would be fine.

Except Katja knew it wouldn’t be. Because this wasn’t about one bug. It was about a pattern. A system. A way of working that assumed development could absorb infinite pressure without breaking.

And she had no idea how to see the full scope of the damage when all she had were fragments — individual bugs, individual complaints, individual fires that demanded immediate attention but revealed nothing about the larger structure burning around them.

Her phone buzzed. Mariana again.

Mariana Santos We'll fix it. But Katja — how long are we going to keep doing this?

Katja stared at the message. She had no answer.

23:23 — Hassan’s Breaking Point

"He was 'handling it' the way a drowning person handles water."

Hassan Al-Rashid was the only person left on the development floor. The open-plan office was dark except for his monitor’s glow — harsh white against the darkness — and the red blink of the server status LEDs across the room. The building’s heating had shut off at 20:00. The air was cold enough that he could see his breath when he exhaled. His coffee had gone cold hours ago.

His terminal showed the deployment pipeline. Again. For the fourth time that day. Red error text filled the screen.

ERROR: Deployment failed at step 7/12
Database migration timeout (600s exceeded)
Rolling back...

He’d been fighting this deployment system for three months. Manual scripts duct-taped together by five different developers over three years. No CI/CD pipeline. No automated testing. Just a bash script with 2,000 lines and comments like “# TODO: fix this hack” dating back to 2023.

Every deployment took eight hours. Eight hours of Hassan babysitting shell scripts, manually checking logs, praying nothing failed at 3 AM. His eyes burned. He blinked hard, trying to clear the blur. His neck ached from hunching over the keyboard.

And now they wanted to deploy twice per week. His laugh came out as a harsh exhale.

Elif Yılmaz Hassan — any update on deployment fix? Need to push event tomorrow morning for player retention.

Hassan Al-Rashid Still broken. Won't be ready until Wednesday at earliest.

Elif Yılmaz That's too late. Players churn if we don't ship live ops content on schedule.

Hassan Al-Rashid Then hire another DevOps engineer. I'm one person.

Elif Yılmaz You know I can't hire. That's Lukas.

Hassan Al-Rashid Then tell Lukas I can't scale this system alone.

Elif Yılmaz I have. Multiple times. He keeps saying you're 'handling it.'

He was “handling it” the way a drowning person handles water — desperately, ineffectively, and not for much longer.

His screen showed the deployment log, red text scrolling past like accusations. He’d rewritten this migration script twice already. It should work. The code was clean. The logic was sound.

But the system was fundamentally broken. You couldn’t polish a turd. You couldn’t scale a mess. And you definitely couldn’t do it alone while everyone else assumed “Hassan’s handling it” meant everything was fine.

His hands were shaking. Not from cold. From exhaustion so deep it felt like gravity had doubled.

He closed his laptop. Saved nothing. Just shut it. The screen went black.

If it failed again tomorrow, it failed. He’d fix it when he wasn’t seeing double from exhaustion, when his hands stopped trembling, when he could think in straight lines again.

The office was silent except for the server fans humming across the room, a mechanical drone that never stopped. Hassan grabbed his jacket from the back of his chair and left, his footsteps echoing in the empty space.

He didn’t see the Slack message that arrived two minutes later:

Lukas Weber @Hassan - Can you deploy the hotfix tonight? Marketing needs it live before 08:00 CET. Thanks!

Tuesday, 07:34 — Katja Can’t Sleep

"She had no idea what was actually happening across the organization."

Katja hadn’t slept more than four hours. She’d spent the night replaying conversations — Lukas dismissing her warnings, Mariana asking when talking to Lukas would change anything, Tomasz threatening to quit. Every time she’d closed her eyes, the words came back, looping endlessly. At 04:30 she’d given up and gotten out of bed.

She sat at her kitchen table in Kreuzberg, laptop open, coffee going cold beside her. Gray morning light filtered through the window. The apartment was quiet except for the occasional rumble of the U-Bahn beneath the building. Her cats, Turing and Lovelace, watched her from the windowsill with vague disapproval, tails twitching.

She opened her notebook — actual paper, fountain pen, the physical act sometimes helping her think. Tried to write down what was actually wrong. Her handwriting was messier than usual, fatigue making her grip unsteady.

Team is burned out.
Shipping bugs we know about.
Lukas won’t delay launches.
No visibility into real capacity.
Status meetings are theater.

She stared at the list. It was all true. But it didn’t capture the real problem. Her stomach tightened with frustration.

The real problem was that she had no idea what was actually happening across the organization. She knew fragments. Symptoms. Individual fires. But she couldn’t see the pattern. Couldn’t see how deep the dysfunction ran.

Every department lead blamed another department. Every bug seemed isolated. Every delay looked like a personal failure instead of a systemic issue.

But Katja had been a developer long enough to recognize a pattern when she saw one — even if she couldn’t articulate it yet. That familiar itch in the back of her mind when the data didn’t add up, when something was wrong beneath the surface.

This wasn’t about one bad sprint or one wrong decision. This was about an entire organization running blind. Making decisions based on gut feelings, status reports that hid reality, and meetings where everyone performed competence while privately knowing they were drowning.

She closed her notebook and stared at the list again. The words blurred. She rubbed her eyes, felt the grit of exhaustion.

She had no idea how to fix this. The weight of that realization settled in her chest like lead.

Next Episode: "When Players Revolt" The update launches Wednesday. The bug Mariana flagged ships anyway. And the players notice immediately.

Desde Cero

2026-02-05T00:00:00+01:00

Previously: "Cenizas" — After the demo disaster, Camila revealed Project Fénix — a working payment system she built in secret. The investors saw real software, not slides, and offered a bridge round to continue. Don Hernando finally listened to the developers. Alejo disappeared into the night, already planning his next move.

The New Rhythm

FinPulso office. Six weeks later. Monday, 9:15 AM.

The office sounds different now.

Gone is the oppressive silence of fear, the whispered complaints, the frantic clatter of last-minute emergencies. In its place: conversation. Keyboards clicking in rhythm. Occasional laughter from the pair programming stations.

Camila walks the floor with her notebook, checking in with each team. It still feels strange — being the one people look to for answers. But six weeks of daily standups, weekly retrospectives, and relentless focus on working software have built something that slides alone never could.

Confidence.

The office sounded different now. It sounded like work being done.

Diego and Pipe are at one station, an unlikely pair that has become FinPulso’s most productive. Diego’s instinct for clean architecture combined with Pipe’s encyclopedic knowledge of the legacy systems — they’ve migrated three major modules in five weeks, each one deployed without incident.

“The reconciliation module goes live today,” Diego announces as Camila approaches. “Final tests passed at 7 AM.”

“Pipe stayed until midnight fixing that date calculation bug,” Camila notes.

“The bug was mine,” Pipe admits gruffly. “From 2019. Left it in because I was too busy fighting fires to fix it properly.” He shrugs. “Now I’ve fixed it. Better late than never.”

Sebastián appears with coffee for everyone — another change. The co-founder who once hid in his office now spends mornings moving between teams, learning what they’re building, asking questions instead of demanding status reports.

“Stefan’s arriving from Panama this afternoon,” Sebastián says. “He wants to review the bank integration before Thursday’s deadline.”

“We’ll be ready,” Camila says.

But from the corner of the office, someone is watching. Listening. Not joining.

Hernán Mendoza, senior developer, twenty years in the industry, and FinPulso’s most persistent problem.

The Resistance

11:00 AM.

Hernán has been at FinPulso since the beginning — one of the original three developers hired when the company was just an idea and a seed round. He’s survived every crisis, every deadline, every leadership change.

He has no intention of changing now.

“Pair programming is for people who can’t think for themselves,” he announces to no one in particular, though his voice carries across the open floor like a slap.

Camila pauses at his desk. Her jaw tightens. “Something wrong, Hernán?”

“Wrong? No. Just observing the fucking circus.” He gestures at the pair programming stations with barely disguised contempt. “Two developers doing the work of one. Two salaries for half the output. Very efficient.” His lips curl. “Did they teach you that at whatever bootcamp you crawled out of?”

“The research shows—”

“Research.” Hernán’s laugh is bitter. “I’ve been writing production code since you were in primary school. I don’t need research to tell me how to do my job.”

"I've been writing production code since you were in primary school."

Other developers are watching now. This confrontation has been building for weeks — Hernán’s snide comments, his refusal to attend retrospectives, his solo commits that bypass the team review process.

“The bank integration module,” Camila says carefully. “You’re the only one who hasn’t contributed code this sprint.”

“Because I’m working on it properly. Not rushing to check boxes on your little board.”

“The integration is due Thursday. We need to test—”

“It will be ready when it’s ready.” Hernán turns back to his screen. “I’ve delivered more integrations than anyone in this company. I don’t need a junior developer telling me how to manage my time.”

Camila’s hands tighten on her notebook. She could push. Could escalate. Could invoke her new authority.

Instead, she walks away.

Diego catches her eye as she passes. Want me to talk to him? his look asks.

She shakes her head. Not yet.

The Arrival

2:30 PM.

Stefan emerges from the elevator with his worn leather bag and the unhurried manner of someone who has seen enough crises to recognize real problems from manufactured ones.

He finds Camila in the small conference room, staring at a whiteboard covered in integration diagrams.

“You look worried,” he says.

“Hernán Mendoza.” Camila doesn’t turn around. “He’s been here since the beginning. Knows the banking APIs better than anyone. And he’s refusing to work with the team.”

“Refusing how?”

“Solo commits. No code reviews. Won’t pair. Won’t attend standups.” She finally faces him. “The bank integration he’s building — I have no idea if it works. He won’t show anyone.”

Stefan sets down his bag. “What have you tried?”

“Talking to him. Multiple times. He sees me as a junior developer who got lucky. Twenty years of experience versus two years. From his perspective, I’m an insult to everything he’s built.”

“And from yours?”

Camila considers. “From mine… he’s a risk. A single point of failure. We’re supposed to be eliminating those, and instead we’ve built our most critical deadline around someone who won’t collaborate.”

"What have you tried?"

Stefan walks to the window. Outside, Bogotá’s afternoon traffic crawls through the streets of Chapinero. He’s quiet for a long moment.

“In my experience,” he says finally, “there are three kinds of resistance to change. Fear, pride, and principle.”

“Which one is Hernán?”

“That’s what you need to find out. Fear can be addressed with safety. Pride can be addressed with respect. But principle…” He turns back to her. “If someone genuinely believes the old way is better, you have to let them prove it. Or fail trying.”

“And if they fail on Thursday? With the bank integration?”

“Then you’ll have learned something important. About Hernán, about your process, about what this team is really made of.”

Camila doesn’t like the answer. But she’s learning that Stefan’s answers aren’t meant to be comfortable. They’re meant to be true.

The Visit

5:00 PM.

Hernán is still at his desk when the office begins to empty. He’s the last of the old guard — the developers who remember when FinPulso was a dream and a garage, before investors and consultants and junior developers who think they know better.

He doesn’t hear Stefan approach.

“Mind if I sit?”

Hernán looks up, startled. Stefan is already pulling over a chair, settling in with the ease of someone who has nowhere else to be.

“The German,” Hernán says. “Heard you were coming.”

“Stefan Richter. We haven’t been formally introduced.”

“I know who you are. The consultant who’s supposed to fix us.” Hernán’s voice is flat. “How’s that going?”

“I don’t fix companies. I help teams see what they’re capable of.” Stefan gestures at Hernán’s screen, filled with dense Java code. “That’s the bank integration?”

“Part of it.”

“May I?”

Stefan saw what Camila couldn't see. The code was good. The coder was afraid.

Hernán hesitates, then scrolls through the file. Stefan reads in silence, occasionally nodding.

“The transaction batching logic,” Stefan says after a few minutes. “You’re handling the edge case where the bank returns a partial acknowledgment. I’ve seen that problem break systems at scale.”

Hernán blinks. “You… recognize it?”

“I worked on a similar integration in Germany, fifteen years ago. Before the APIs were standardized. We had to handle twelve different response formats from twelve different banks.” Stefan smiles faintly. “I spent three months on that project. It taught me more about defensive programming than any book.”

The silence that follows is different. Less hostile.

“Nobody here understands this code,” Hernán says finally. “They want me to pair program with developers who’ve never seen a bank API. Who think everything can be solved with unit tests and continuous deployment.”

“Can’t it?”

“Some things require experience. Intuition. The kind of knowledge you only get from twenty years of watching systems fail in ways the documentation never mentions.”

Stefan nods slowly. “You’re right.”

Hernán looks at him sharply. He wasn’t expecting agreement.

“The question,” Stefan continues, “is whether that knowledge dies with you. Or whether you find a way to pass it on.”

The Choice

Wednesday. One day before deadline.

The integration is not ready.

Camila discovers this at the morning standup, when Hernán — forced to attend by direct order from Sebastián — admits that he’s hit a problem with the authentication flow.

“The bank changed their certificate requirements last week,” he says. “Didn’t announce it. I’ve been debugging for three days.”

“Why didn’t you ask for help?” Diego asks.

“Because—” Hernán stops. Because he doesn’t trust anyone else. Because asking for help feels like weakness. Because twenty years of being the expert have made it impossible to be the learner.

The room waits.

"Why didn't you ask for help?"

“Because I thought I could solve it alone.” The words come out ragged, torn from somewhere deep. Hernán’s face is flushed, his eyes bright with something that might be shame. “I was wrong.” He swallows hard. “Jesus Christ, I was so fucking wrong.”

The room is silent. No one has ever heard Hernán admit anything.

Camila makes a decision.

“Diego, Pipe — you’re pairing with Hernán today. Full focus on the authentication issue.” She turns to the rest of the team. “Everyone else, continue on the deployment pipeline. We need to be able to push the fix the moment it’s ready.”

“And if we can’t fix it by Thursday?” Sebastián asks.

“Then we tell the bank the truth. We’re delayed, and we explain why.” Camila’s voice is steady. “But we don’t hide. We don’t pretend. We show them what we’re doing to solve the problem.”

Don Hernando has appeared at the edge of the standup circle. He’s been attending these meetings for three weeks now — listening, learning, staying silent.

He catches Camila’s eye and nods. Just once. But it’s enough.

The Night

Wednesday, 11 PM.

The office is dark except for three monitors at the pair programming station. Hernán, Diego, and Pipe — an unlikely alliance — have been working for fourteen hours straight.

Camila brings coffee. Stefan brings sandwiches from the arepa shop downstairs. Neither speaks. The developers are in the zone — that state of flow where the problem is everything and the world falls away.

“The bank’s certificate chain is incomplete,” Diego says. “They’re not sending the intermediate certificate.”

“Which is why our validation fails,” Pipe adds. “But only in production. The test environment uses a different chain.”

“So we need to bundle the intermediate certificate ourselves.” Hernán is already typing. “It’s not pretty, but it’s what we did at Bancolombia in 2008.”

The expert, the prodigy, and the survivor — working as one.

Stefan watches from across the room. He’s seen this before — the moment when individual ego dissolves into collective purpose. When the code becomes more important than credit.

It doesn’t always happen. But when it does, it’s why he keeps doing this work.

At 2:47 AM, Diego pushes a commit. The test suite runs: 847 tests, 847 passing. The deployment pipeline triggers automatically.

At 2:51 AM, the bank integration goes live.

At 2:52 AM, the first transaction processes successfully.

Hernán stares at the screen. He hasn’t shipped code this fast in years. Maybe ever.

“It works,” he says, as if he can’t quite believe it.

“It works,” Diego confirms.

“How did we—” Hernán stops. He knows how. He just didn’t expect it. “Thank you. Both of you.”

Pipe shrugs. “De nada. Now go home and sleep. You look worse than I do.”

The Morning

Thursday, 8 AM.

The bank confirms: twenty-three transactions processed overnight, zero errors. The integration is stable. The deadline is met.

Sebastián calls an impromptu all-hands meeting. Not to celebrate — that will come later — but to acknowledge what happened.

“Last night, three developers solved a problem that had stumped one of them for days,” he says. “They did it by working together. By trusting each other. By admitting what they didn’t know and combining what they did.”

Hernán stands at the edge of the group. His expression is complicated — pride, embarrassment, something that might be the beginning of change.

“I’ve been at this company since the beginning,” Hernán says. The room goes quiet. “I’ve survived because I knew things no one else knew. That was my value. My security.”

He pauses.

“But last night… I realized that knowing things doesn’t matter if you can’t share them. And that the people I dismissed as too inexperienced—” he looks at Camila, then Diego, “—they know things I don’t. Different things. Important things.”

"They know things I don't. Different things. Important things."

He turns to Camila.

“I’ve been unfair to you. You earned your position. I was too proud to see it.” He extends his hand. “I’d like to try again. If you’ll have me.”

Camila takes his hand. “Welcome to the team. Finally.”

The room exhales. Someone claps. Then someone else. And then the whole office is applauding — not for the integration, but for something harder to achieve.

A change of heart.

The Shadow

Somewhere across Bogotá. Thursday, 10 AM.

Alejo’s apartment has a view of the city he used to own. Now he watches from exile, tracking FinPulso’s progress through carefully cultivated sources.

His phone buzzes. A message from a number he knows well.

Unknown The bank integration went live. No issues. The German was there all night.

Alejo And the team?

Unknown Functioning. Better than expected. They're actually starting to trust each other.

Alejo That's a problem.

Unknown What do you want me to do?

Alejo Nothing yet. Keep watching. Report everything.

Unknown The next milestone is the merchant onboarding system. Two weeks.

Alejo I know. That's when we move.

He sets down the phone and pours himself a coffee. The first phase of his plan required FinPulso to succeed — just enough to attract attention, to prove the concept has value.

The first phase required FinPulso to succeed. The second phase would require it to fail.

The second phase requires it to fail. At exactly the right moment. In exactly the right way.

And thanks to his informant, he’ll know precisely when to strike.

The First Deployment Celebration

Friday, 6 PM.

The tradition started three weeks ago: every successful deployment gets a small celebration. Nothing elaborate — just a moment to acknowledge that software shipped, that it worked, that the team made something real.

Today’s celebration is bigger. Not just the bank integration, but the hundredth successful deployment since Project Fénix went live.

Don Hernando has ordered champagne. Real champagne, not the local sparkling wine. He raises his glass.

“One hundred deployments,” he says. “In six weeks. Without a single production incident.” He shakes his head slowly. “When Stefan first arrived, I thought he was selling me a fantasy. Deploying every day? Impossible. Dangerous. Reckless.”

One hundred deployments. Zero incidents. One team, finally together.

He pauses.

“I was wrong. About a lot of things. I’m learning — slowly — that the people closest to the work understand it best. And that my job is not to tell them what to do, but to remove the obstacles that prevent them from doing it well.”

Sebastián catches Isabella’s eye across the room. She smiles — the first real smile he’s seen from her in months. Something unspoken passes between them. A question, perhaps. Or the beginning of an answer.

Camila finds Stefan by the window.

“You’re leaving tomorrow?” she asks.

“For a few weeks. Another engagement.” He sets down his champagne. “But I’ll be back for the next milestone. You don’t need me for the daily work anymore.”

“I don’t need you.” She pauses. “But the team is better when you’re here. I’m better.”

“That’s your confidence speaking. It doesn’t come from me. It comes from proving, every day, that you can do difficult things.”

"You don't need me for the daily work anymore."

Camila wants to say something more. To acknowledge whatever this is between them — respect, affection, something she can’t quite name. But Stefan has always kept a careful distance. And she knows, somewhere beneath the wanting, that the distance is necessary.

“Thank you,” she says instead. “For everything you’ve taught me.”

“You taught yourself. I just asked the right questions.” Stefan finishes his champagne. “Take care of this team. They’re worth it.”

The Discovery

Saturday, 7 AM.

Camila arrives early, as always. The office is empty. She likes these quiet hours before the team arrives — time to think, to plan, to review the metrics that tell the real story of how the company is doing.

She opens her laptop. Checks the deployment dashboard. Scans the error logs.

Then she sees something that makes her freeze.

An access log entry from 3 AM. Someone connected to the production database from an IP address she doesn’t recognize. The session lasted fourteen minutes. No changes were made — but someone was reading. Looking.

At transaction data. Customer records. The bank integration she just shipped.

The access logs don't lie. Someone inside FinPulso was feeding information outside.

Camila traces the IP. It routes through a VPN — untraceable. But the access credentials belong to someone on the team. Someone who has been here from the beginning.

Someone she trusted.

Her phone buzzes. A message from Diego.

Diego You at the office?

Camila Yes.

Diego Don't touch anything. I'm on my way. I found something too.

She stares at the screen. At the name attached to the access log.

Her heart sinks.

The Revelation

Saturday, 8:30 AM.

Diego arrives running. He has his laptop open before he reaches Camila’s desk.

“Look at this.” He pulls up a chain of commits from the past six weeks. “Someone’s been adding logging to the payment modules. Very subtle. Easy to miss in code review.”

“What kind of logging?”

“Transaction summaries. Amounts. Timestamps. Customer identifiers.” Diego’s face is grim. “It’s not storing them in our system. It’s sending them to an external endpoint. The same IP you found.”

Camila’s hand shakes as she scrolls through the code. The commits are small, innocuous-looking. The kind that slip through when everyone is focused on shipping features.

“Who wrote these?”

Diego doesn’t answer. He pulls up the commit history.

The author is clear. The timestamps are clear.

The betrayal is clear.

The commits told the story. Someone had been a spy all along.

“We need to tell Don Hernando,” Diego says.

“And Stefan. Before he leaves.”

“And what about—” Diego can’t say the name. Neither can Camila.

But they both know who it is.

Someone who has been at every standup. Every retrospective. Every celebration. Someone who has seen the recovery from the inside — and reported every detail to the man who wants to destroy it.

The sun rises over Bogotá, bright and indifferent. Inside the FinPulso office, Camila picks up her phone.

Some conversations can’t wait until Monday.

Next Episode: "El Regreso" The spy is unmasked. But before Camila can act, Diego returns with unexpected news: the competition has made an offer. Not a threat — a proposition. Meanwhile, Alejo's endgame becomes clear, and FinPulso must choose between safety and ambition. Some battles require more than good code. They require trust.

Frameworks vs Visualization: Process or Insight?

2026-02-03T00:00:00+01:00

Why Organizations Reach for Process When They Need Sight

03.02.2026, By Stephan Schwab

Organizations often reach for elaborate management frameworks when they cannot see what is actually happening. But the root problem isn't missing process — it's missing visibility. Visualization provides the same diagnostic power without the bureaucratic overhead, revealing delivery reality through simple, observable signals rather than complex role hierarchies and ceremony schedules.

The Visibility Deficit

"When executives cannot see what teams are doing, they buy frameworks to feel in control."

Most organizations that adopt heavy management frameworks do so because they feel blind. Work happens somewhere. Money goes out. Occasionally software appears. The connection between investment and outcome feels opaque, unpredictable, and slightly magical.

This blindness triggers a predictable response: if we can’t see what’s happening, we should mandate a process that tells us what should happen. Framework vendors understand this anxiety intimately. Their sales pitch addresses it directly — adopt our roles, our ceremonies, our artifacts, and clarity will emerge.

But the clarity that emerges is process compliance, not delivery reality. Organizations gain visibility into whether teams held their standups and completed their sprint planning. They learn nothing about whether the work matters, whether customers use what ships, or whether the codebase is healthy enough to sustain continued development. This dynamic — where frameworks diagnose symptoms but cannot repair root causes — explains why so many transformations stall.

What Management Frameworks Actually Make Visible

"Framework artifacts answer questions nobody was asking."

When a management framework promises visibility, examine what becomes visible:

Role occupancy. You know who fills which framework-defined position. You have a Product Owner, three Scrum Masters, and a Release Train Engineer. Whether any of them possess the skills to do their jobs effectively remains invisible.

Ceremony completion. You know that teams held retrospectives last week. What you don’t know is whether anyone acted on insights or whether the retrospective was theater — people going through motions because the calendar demanded it.

Artifact production. You know that user stories exist, that they have acceptance criteria, that someone estimated them in story points. The relationship between these artifacts and actual work done remains tenuous. Teams learn to write stories that satisfy process auditors, not stories that clarify intent.

Velocity metrics. You know that teams claim to complete a certain number of points per sprint. But story points are internally defined, inconsistently sized, and easily gamed. Comparing velocity across teams is meaningless. Comparing a team’s velocity across time requires that nothing else changed — an assumption that never holds.

None of this answers what executives actually need to know: Is work flowing from idea to production? Are we building things users want? Is the codebase sustainable? Where should we invest next?

What Visualization Makes Visible

"A cumulative flow diagram reveals more than a month of status reports."

Simple visualization techniques — requiring no framework adoption, no role changes, no certification expenditure — reveal delivery reality directly:

Cumulative flow diagrams show work accumulating in each stage over time. When the “in development” band grows while “deployed” stays flat, work is starting but not finishing. No ceremony audit reveals this pattern; the shape makes it obvious instantly.

Lead time distributions show how long work items take from commitment to delivery. The shape tells the story — a tight cluster suggests predictable flow; a long tail suggests some work gets stuck. Executives can see this without understanding engineering details.

Deployment frequency tracked over time shows whether the pipeline is flowing or constrained. If deployments decrease while headcount increases, something is consuming energy that isn’t reaching production. As explored in Technical Practices That Drive Business Results, deployment frequency is one of the key metrics that connects engineering practice to business outcomes.

Escaped defect rates show quality problems that reach users. This is more honest than test coverage metrics or story point completion. Either users experience problems or they don’t.

Pipeline dashboards show builds passing or failing in real time. Red builds that persist for days indicate development health problems no standup report captures.

These automated signals reveal much — but not everything. Some delivery friction lives in human context: unclear requirements, coordination issues, blockers that emerge between commits. For these signals, lightweight collaborative logging provides visibility without ceremony overhead. Tools like Caimito Navigator transform brief daily entries into synthesized weekly intelligence — surfacing patterns invisible in status meetings while giving executives strategic visibility without disrupting the team.

These visualizations share a critical property: they derive from systems rather than from ritual. No one can game what the build server records or spin a lead time distribution. Daily entries compound into organizational intelligence that reveals where teams are stuck, what’s accelerating, and where capacity is constrained. The data exists regardless of what anyone claims in a status meeting.

Why Frameworks Proliferate Despite Their Overhead

"Frameworks feel like action. Dashboards feel like watching."

If visualization is simpler and more honest, why do organizations buy frameworks instead?

Frameworks feel like action. Commissioning a transformation, hiring consultants, training everyone — these are visible investments. Building a dashboard feels passive, even though the dashboard produces more actionable insight.

Frameworks assign blame elsewhere. When things go wrong, the framework provides vocabulary for attributing failure — teams lacked maturity, the organization resisted change, we need more training. Visualizations offer no such comfort. They show what happened without explaining it away.

Frameworks create jobs. Process roles don’t ship software, but they do employ people who attend meetings, produce slide decks, and coordinate calendars. This creates a constituency that defends the framework’s existence.

Frameworks feel comprehensive. A diagram with fourteen boxes connected by arrows looks like a complete solution. A simple dashboard looks like it might be missing something. Executives often equate complexity with thoroughness.

Visualization requires engineering capability. Building effective dashboards requires access to data, understanding of what to measure, and technical skill to surface it clearly. Organizations that lack engineering fluency can’t build their own visibility — so they buy packaged frameworks instead.

The Integration Problem

"Buying a framework doesn't automatically produce useful data."

Management frameworks often include reporting tools — burndown charts in Jira, PI objectives in SAFe dashboards, OKR tracking software. These create an illusion of data-driven management while missing the fundamental problem.

Framework dashboards report on framework artifacts. They tell you about story completion rates, sprint commitments, and planning increment progress. They do not tell you about actual software reaching actual users.

The data that matters lives in engineering systems: source control, CI/CD pipelines, production telemetry, incident management. Framework overlays rarely connect to this layer. They create a parallel universe of process data that management watches while the real delivery story goes unobserved.

Organizations that understand this invest in connecting their visualization to their engineering systems. They show deployments, not sprint completion. They track lead time from commit to production, not from story creation to acceptance. They measure user adoption, not feature acceptance by a Product Owner.

Practical Visualization Without Frameworks

"Start with one question. Make the answer visible. Repeat."

Building useful visibility doesn’t require buying anything or reorganizing anyone:

Step one: Identify one real question. Not “are we agile?” but “how often do we deploy to production?” Not “are teams performing?” but “how long does work take from start to finish?”

Step two: Find the source of truth. The deployment timestamp lives in your CI/CD system. The work start and end dates live in your issue tracker. The production error rate lives in your monitoring. These systems already contain the data.

Step three: Make it visible. A shared screen displaying deployment frequency. A weekly email with lead time distributions. A Slack integration that announces each production deployment. Start simple; sophistication can come later.

Step four: Act on what you see. If lead times are long, investigate where work stalls. If deployments are rare, understand what’s blocking flow. The visualization exists to prompt inquiry, not to provide answers.

Step five: Repeat with the next question. Over time, a small collection of visualizations creates comprehensive delivery insight. Each one emerged from a genuine question, so each one stays relevant.

Step six: Capture human context. Automated systems miss blockers, unclear requirements, and coordination friction. Brief daily logbook entries — stating the day’s heading, noting surprises, capturing outcomes — compound into organizational intelligence. Weekly synthesis reveals patterns: where teams are stuck, what’s accelerating, where capacity is constrained. Leaders gain evidence-based insight without scheduling another meeting.

This approach costs nothing. It requires no training, no certification, no consultant engagement. It produces genuine insight rather than process compliance data.

When Frameworks Add Value

Not all framework adoption is misguided. Frameworks provide value when:

Organizations genuinely lack shared vocabulary. If teams describe work completely differently, common terms reduce confusion. Frameworks provide terminology that enables cross-team conversation.

Diagnosis is the goal. Applying a framework briefly to diagnose organizational patterns can reveal dysfunction. The framework provides a lens for analysis, not a permanent operating model.

Coordination at scale requires some structure. Very large organizations benefit from predictable integration points. The question is whether you need the entire framework or just the coordination mechanisms.

Learning is the intent. Teams new to iterative delivery may learn faster with a structured starting point than with pure experimentation.

The key distinction: using a framework as a learning scaffold differs from adopting it as a permanent operating model. Scaffolding comes down when the building stands. Frameworks often persist indefinitely, their ceremonies continuing long after anyone remembers why they started.

The Cost of the Wrong Choice

"Every hour in a process ceremony is an hour not writing software."

Choosing frameworks over visualization carries real costs:

Direct expense. Training, consulting, certification renewals, and tooling subscriptions add up. Visualization built on existing engineering infrastructure costs development time only.

Opportunity cost. Every hour spent in framework ceremonies is an hour not spent writing software, fixing defects, or talking to users. Visualization requires maintenance measured in minutes per week.

Technical capability atrophy. When organizations outsource improvement to methodology, they stop developing internal capability to understand and fix their own systems. Visualization requires — and builds — engineering fluency.

False confidence. Framework metrics can look healthy while delivery stalls. Visualization connected to engineering reality cannot lie in the same way.

Delayed learning. When feedback comes through ceremony-based retrospectives instead of real-time dashboards, organizations learn slowly. Problems that persist for sprints could have been caught in hours.

The Path Forward

"Make reality visible. Let it inform decisions. Skip the bureaucracy."

Organizations seeking delivery visibility face a choice. They can buy a framework — adopting roles, ceremonies, and a belief system along with reporting tools disconnected from engineering reality. Or they can build visualization — connecting simple displays to the systems that actually produce software.

The framework path offers comfort, external validation, and someone else to blame when things go wrong. The visualization path offers accuracy, low overhead, and the discomfort of seeing reality clearly.

Reality, even when uncomfortable, is where improvement begins. You cannot fix what you cannot see. You cannot see clearly through a framework built to obscure as much as it reveals.

Start simple. Pick one question that matters. Make the answer visible. Watch what happens when everyone shares the same view of reality.

The best governance is the lightest governance that still provides clarity. As explored in How to Govern Without Control, effective leadership replaces permission with visibility. For most organizations, that means visualization first, frameworks never — or frameworks only after simpler approaches have been exhausted and found genuinely insufficient.

Management Frameworks and the Proximity to Snake Oil

2026-01-31T00:00:00+01:00

Selling Certainty in an Uncertain World

31.01.2026, By Stephan Schwab

Many management frameworks operate close to the snake oil line — selling beliefs and process models rather than verifiable outcomes. When the business model depends on monetizing belief instead of measurable improvement, the framework has crossed from guidance into ideology. The closer a vendor is to selling certainty in uncertain environments, the closer their offering is to pseudoscience.

Where the Dynamic Comes From

"Frameworks sell beliefs and process models, not something you can directly verify like software or machinery."

The proximity to snake oil isn’t accidental. Several structural factors push management frameworks toward dubious territory — dynamics I’ve explored in Management Frameworks Don’t Fix Software Teams:

Intangible product. Frameworks sell beliefs and process models, not something you can directly verify like software or machinery. When the product is essentially a way of thinking, measuring its effectiveness becomes subjective at best.

Promise of certainty. They target management’s desire for predictable outcomes in inherently uncertain environments. Software development, organizational change, market dynamics — these are complex adaptive systems. Promising predictability is promising something that cannot be delivered.

Rebranding old ideas. Many frameworks are thin repackagings of long-existing principles, marketed as new breakthroughs. The core concepts of iterative development, frequent feedback, and cross-functional collaboration have been known for decades. Adding new terminology and proprietary diagrams doesn’t constitute innovation.

Certification economy. The business model depends on selling training, certifications, and consulting rather than making teams more effective. When revenue comes from credential production, the incentive is to create more credentials — not to make the credentials unnecessary.

Lack of falsifiability. When a framework fails, promoters claim you didn’t implement it correctly. This is structurally identical to pseudoscience. No outcome can disprove the framework’s validity because failure is always attributed to execution rather than the framework itself.

One-size-fits-all claims. They promise universal applicability, which rarely matches reality in complex socio-technical systems. Context matters enormously in organizational effectiveness. What works in a forty-person startup bears little resemblance to what works in a forty-thousand-person enterprise.

Management seduction. They give leaders a sense of control without forcing them to understand engineering, complexity, or systems thinking. The framework becomes a substitute for genuine understanding — a set of templates and rituals that create the appearance of competent governance.

How Close Is Close?

"Snake oil means high promises, low evidence, low accountability."

Close enough that the line depends on intent, transparency, and evidence.

The classic snake oil pattern has three elements: high promises, low evidence, low accountability. Many popular frameworks — Scrum implementations, SAFe deployments, OKR systems, value stream transformation consultancies — fit this pattern at least partially.

The distinction isn’t binary. Frameworks exist on a spectrum. Some provide genuine diagnostic value while their vendors oversell transformation promises. Some started as useful lightweight guidance and calcified into prescriptive ideologies. Some are straightforward revenue extraction vehicles with no pretense of evidence.

Indicators That a Framework Has Crossed the Line

When a framework exhibits these characteristics, it has moved from guidance into snake oil territory:

Outcome claims without hard data. “Productivity doubles.” “Agility increases by 300%.” These claims lack rigorous, reproducible evidence. If challenged, vendors point to case studies that lack controls, confounding variables, or honest assessment of what else changed simultaneously.

Defensive logic. “If it didn’t work, your culture is wrong — not the method.” This reasoning is unfalsifiable. The framework cannot fail; only implementations can fail. This is the hallmark of ideology, not empirical practice.

Cult-like language. “True Scrum.” “Enterprise agility.” “Mindset transformation.” The vocabulary exists to create in-group identity and dismiss criticism as coming from outsiders who don’t understand. Terms become shibboleths rather than communication tools.

Certification treadmill. Constant new badges, master-coach levels, renewals. The certification structure exists to generate recurring revenue, not to validate competence. When someone can become a certified practitioner in two days, the certification measures willingness to pay, not capability.

Heavy reliance on anecdote. Success stories replace systematic evidence. The plural of anecdote is not data. Organizations that improved after adopting a framework may have improved for entirely unrelated reasons — new leadership, market conditions, staff changes, parallel initiatives.

Punishing dissent internally. “That’s resistance to change.” Criticism becomes pathologized as a psychological failing rather than engaged as substantive feedback. Organizations adopting frameworks often adopt this defensive posture, making rational assessment impossible.

Framework bloat. As frameworks age, they accumulate roles, ceremonies, artifacts, and layers. Each addition creates consulting and training opportunities. Rarely does anyone subtract. The framework becomes a bureaucracy that exists to perpetuate itself.

Why Organizations Keep Buying

"Real improvement requires engineering fluency, which many leaders lack."

Understanding why frameworks sell despite their limitations explains why the market persists:

Leaders want predictability. Software development feels chaotic. Frameworks promise order. The promise is more comforting than honest acknowledgment of inherent uncertainty.

Leaders want simple diagnosis. Frameworks provide templates and checklists. “Your problem is lack of alignment” is easier than “your problem is a complex web of technical debt, organizational dysfunction, market misunderstanding, and inadequate engineering capability.”

Leaders want external legitimacy. Certifications look like action. “We hired SAFe consultants and trained everyone” is a visible intervention. Quietly improving engineering practices generates no comparable theater.

Real improvement requires engineering fluency. Understanding why code takes longer than expected, why certain architectures create friction, why some technical decisions compound into debt — this requires knowledge that many business leaders don’t have and don’t want to acquire. Frameworks offer a shortcut. As I argued in Reclaim Your Organization, executives who abdicate this understanding to methodology resellers pay a steep price.

What Is Not Snake Oil

Empirical engineering practices exist independently of belief systems:

Test-driven development produces measurable outcomes: defect rates, design quality, confidence in refactoring. You can observe whether a team practices it and correlate with outcomes.

Trunk-based development and continuous integration have clear operational definitions and measurable effects on integration friction and deployment frequency.

Lean principles rooted in operations research and queuing theory make falsifiable predictions. Little’s Law doesn’t require belief. Work-in-progress limits either improve flow time or they don’t.

Lightweight guidance that avoids universal claims and adapts to context treats recommendations as hypotheses to test, not doctrines to implement.

The distinction: these practices make claims that can be disproven. If TDD produces worse outcomes in a particular context, that’s useful information. The practice doesn’t defend itself with “you weren’t doing true TDD.”

The Core Problem

"Once the vendor must maintain the illusion of effectiveness, the framework becomes ideology."

Management frameworks become snake oil when the business model depends on selling the framework rather than improving the organization.

Once that happens, the vendor must maintain the illusion of effectiveness — even when evidence contradicts it. The vendor cannot acknowledge fundamental limitations because doing so threatens revenue. The vendor cannot recommend simpler alternatives because those alternatives don’t require the vendor.

This creates a predictable pattern: initial adoption produces enthusiasm (the Hawthorne effect plus organizational attention), followed by gradual disillusionment as promised transformations fail to materialize, followed by blame-shifting toward implementation, followed by the next framework.

Organizations cycle through frameworks not because each new framework is better, but because each new framework offers fresh hope and a fresh scapegoat for the previous failure.

What This Means for Leaders

Recognizing the snake oil dynamic doesn’t mean rejecting all guidance. It means asking different questions:

What evidence exists beyond anecdote? If the vendor has only case studies, ask for controlled comparisons. If those don’t exist, recognize you’re buying belief.

What would falsify this framework’s claims? If no possible outcome could demonstrate the framework’s failure, you’re looking at ideology.

Who benefits from continued adoption? If the vendor’s revenue requires your ongoing subscription, their advice is structurally compromised.

What does this framework substitute for understanding? If the framework promises results without requiring you to understand the underlying systems, that promise is probably hollow.

What lightweight alternative might achieve similar outcomes? Often, expensive frameworks overlay basic practices that teams could adopt directly.

The most effective organizations treat frameworks as sources of ideas, not as doctrines to implement. They extract useful concepts, adapt them to context, measure results, and discard what doesn’t work — regardless of what the framework prescribes.

The Line Between Guidance and Grift

"The closer the vendor is to monetizing belief instead of outcomes, the closer the framework is to snake oil."

The framework industry will persist because it addresses real needs: leaders genuinely want to improve their organizations, and genuine expertise in organizational effectiveness exists. The challenge is separating those who can actually help from those who merely profit from the appearance of helping.

The signal is accountability for outcomes. Vendors willing to tie their compensation to measurable improvements — and to define those improvements in advance, with clear measurement criteria — are distinguishing themselves from the snake oil merchants. The grateful boundaries between consultants who diagnose and developers who implement remain essential.

Those who demand full payment for training and certification, with no accountability for whether the training produces results, have revealed their business model. They are selling belief.

The proximity to snake oil isn’t about any particular framework. It’s about the relationship between promises, evidence, and accountability. Close that gap, and you have genuine consulting. Widen it, and you have a well-dressed medicine show.

Cenizas

2026-01-29T00:00:00+01:00

Previously: "El Demo Day" — The investor demo crashed spectacularly, live, in front of everyone. The São Paulo partners left without committing. In the aftermath, Don Hernando and Stefan shared aguardiente and hard truths. Meanwhile, Alejo watched from the shadows, seeing opportunity in the ashes.

The Morning After

FinPulso office. Friday, 8:30 AM.

The office has the feeling of a wake. Developers sit at their desks, but no one is working. The whiteboards from the war room still display their desperate plans — monuments to yesterday’s failure.

Camila is the first to arrive, as always. She makes coffee. She checks the error logs. She does what she always does: the quiet work that keeps systems running while everyone else is distracted by drama.

But today, she also opens a folder on her laptop labeled “Project Fénix.” A folder no one knows about.

She had been building in secret for three months. Today, the secret might matter.

Diego arrives next. He looks like he hasn’t slept — because he hasn’t. He’s been analyzing what went wrong, tracing the cascade of failures that brought down the demo.

“Connection pool exhaustion,” he says, sitting next to Camila. “The reporting module was running a legacy query that never releases connections. We missed it because—”

“Because no one ever tests the reporting module,” Camila finishes. “I know. I’ve been saying that for months.”

Diego looks at her — really looks at her, perhaps for the first time. “You have, haven’t you?”

“I say a lot of things. Nobody listens to the junior developer.”

Something in her tone makes Diego pause. But before he can respond, the elevator doors open, and Don Hernando walks in with Stefan, Laura close behind.

The old man’s face is carved from stone. He’s wearing the same suit he wore to his son’s funeral — the suit of important days. Bad days.

“Conference room,” he says. “Everyone. Now.”

The Reckoning

9:00 AM.

They gather like survivors around a campfire: Don Hernando at the head of the table, Stefan standing by the window, the developers clustered at one end. Sebastián sits apart, staring at a tablet displaying yesterday’s error logs as if they might reveal something new.

Isabella enters last, her eyes red from a sleepless night. She sits next to Sebastián but doesn’t look at him.

“Mariana called this morning,” Don Hernando says without preamble. “She and her partners have discussed the situation. They’re flying back to Bogotá on Monday for a formal board meeting. They will decide whether to continue their investment or demand liquidation.”

The word hangs in the air. Liquidation.

“They want to see a recovery plan,” Don Hernando continues. “Something credible. Something that shows we understand what went wrong and can prevent it from happening again.” He looks at Stefan. “I’ve asked our German friend to prepare such a plan.”

"They will decide whether to continue their investment or demand liquidation."

Pipe snorts. “A plan. As if a plan will fix what happened.”

“A plan won’t fix the past,” Stefan says quietly. “But it might save the future. If there’s still a future to save.”

“Is there?” Sebastián asks. His voice is hollow. “I’ve run the numbers. Even with a bridge round, we have maybe four months of runway. That’s not enough time to rebuild the platform from scratch.”

“No,” Stefan agrees. “It isn’t.”

“Then what are we talking about? Fairy tales?”

Stefan moves to the whiteboard. He picks up a marker, considers it, sets it down again.

“I’ve been observing FinPulso for three weeks now,” he says. “I’ve pair-programmed with every developer. I’ve read the codebase. I’ve studied the deployment logs — what little exists of them. And I’ve identified the core problem.”

“The code is shit,” Pipe says. “We know.”

“The code is debt. Debt accumulated over two years of impossible deadlines and pressure to show progress that didn’t exist. But that’s not the core problem.” Stefan pauses. “The core problem is that this company has been optimizing for appearances instead of reality. For demos instead of deployment. For investor confidence instead of user value.”

Don Hernando’s expression doesn’t change. But his hands tighten on the armrests.

“And your solution?”

“Stop pretending. Start delivering.”

The Plan

9:30 AM.

Stefan draws on the whiteboard as he speaks. Not diagrams — just words, connected by arrows.

Day 1-30: Foundation

Automated deployment pipeline
Basic test coverage for critical paths
Production monitoring and alerts

Day 31-60: Stability

Daily deployments to staging
Weekly deployments to production
Incident response process

Day 61-90: Velocity

Feature flags for safe releases
Metrics-driven development
User feedback loops

“This isn’t a rebuild,” he explains. “It’s a transformation. We stop pretending the old system works and start building the capability to actually deliver software.”

“In three months?” Isabella asks. “You said yourself we can’t rebuild the platform in four.”

“We don’t rebuild the platform. We rebuild the process. And we start delivering value — small value, incremental value — within the first two weeks.”

“Value to whom?” Sebastián asks. “Our users have never even seen the real platform. They’ve only seen the demos.”

“Then maybe it’s time they see something real.”

"We stop pretending the old system works and start building the capability to actually deliver."

The room is silent. Pipe is shaking his head slowly. Diego is staring at the whiteboard with an intensity that suggests he’s actually considering the proposal. Isabella is watching Don Hernando, trying to read his reaction.

“This plan requires something,” Stefan says. “Something this company hasn’t had.”

“What?” Don Hernando asks.

“Honesty. Radical, uncomfortable honesty. About what works. About what doesn’t. About what we can actually deliver versus what we’ve been promising.” Stefan meets the old man’s eyes. “Yesterday, you asked me what happens now. This is what happens now. We tell the truth. Or we die.”

Don Hernando is silent for a long moment. Then:

“Laura. Get Mariana on the phone. Tell her we’ll have a presentation ready for Monday. A real one.”

“Patrón, I—”

“And someone find me coffee. Real coffee. This is going to be a long weekend.”

The Secret

11:00 AM.

The team disperses to begin preparations. Stefan is reviewing deployment infrastructure with Diego. Pipe is grumbling over legacy documentation. Isabella is drafting talking points for the board presentation.

Camila approaches Stefan when no one else is watching.

“May I show you something?”

Stefan looks up from his laptop. He’s learned to recognize that tone — the one developers use when they’re about to reveal something important.

“Of course.”

She leads him to her desk, away from the others. She pulls up the folder she checked this morning.

“I’ve been building this for three months,” she says quietly. “In my spare time. Nights. Weekends. I call it Project Fénix.”

Stefan looks at her screen. At first, he doesn’t understand what he’s seeing. Then he does.

It’s a payment processing module. Clean architecture. Comprehensive test coverage — the kind Diego used to write before he burned out. Integration tests that actually pass. And at the bottom of the screen: a deployment log showing daily automated releases to a staging environment she’s been running on her personal cloud account.

"I've been building this for three months. In my spare time."

“You’ve been doing continuous delivery,” Stefan says slowly. “On your own. While everyone else was building a house of cards.”

“I learned from your book,” Camila says. “The one you wrote five years ago. About sustainable software delivery. I found it online.”

“I remember writing that.” Stefan scrolls through her code. “This is… remarkable. The transaction handling is cleaner than anything in the main codebase. How did you—”

“I rewrote it from the requirements documents. The original ones, before they got corrupted by scope creep. The platform we promised investors — the simple, reliable payment processor — it’s possible. It just got buried under features no one asked for.”

Stefan sits back. He’s looking at Camila differently now. Not as a junior developer. As a colleague.

“Why didn’t you tell anyone?”

“I tried.” Her voice carries a familiar frustration. “I sent Sebastián a proposal four months ago. He said it was ‘interesting’ but we didn’t have bandwidth. I showed Alejo a demo — he said it was too simple, that investors want sophistication. I even mentioned it at a team meeting once. Pipe told me to focus on my assigned tasks.”

“And you kept building anyway.”

“Someone had to.” She closes the laptop halfway. “The question is: does it matter? Is this too little, too late?”

Stefan is quiet for a moment. Then he stands.

“Diego. Pipe. Sebastián. I need you here. Now.”

The Revelation

11:30 AM.

They crowd around Camila’s desk. She’s nervous now — this is more attention than she’s received in her entire time at FinPulso. But Stefan stands beside her, and his presence is steadying.

“Show them,” he says.

She opens Project Fénix again. Walks them through the architecture. Demonstrates the test suite — 847 passing tests, zero failures. Shows the deployment logs: 94 successful releases over 12 weeks, average deployment time 4 minutes.

Diego is the first to speak. “You’ve been running this on AWS? Your personal account?”

“The free tier, mostly. A few dollars a month for database hosting.”

“The transaction module…” Diego leans closer. “This handles the concurrent connections problem. The one that crashed the demo. You solved it.”

“Connection pooling with automatic recovery. It’s not rocket science. It’s just… correct.”

"847 passing tests. Zero failures. 94 successful deployments."

Pipe is shaking his head, but his expression has changed. Not cynicism anymore. Something like wonder.

“You built this alone? No code review? No pair programming?”

“I reviewed it myself. Multiple times. And I watched every talk by Diego on the internal wiki. The ones from before—” She hesitates. “Before things got bad.”

Diego blinks. “You watched my old talks?”

“All of them. The one about test-driven development changed how I think about code.” Camila’s voice is quiet but firm. “You’re good, Diego. Really good. The codebase just… buried it.”

For a moment, Diego can’t speak. He’s being seen — his old self, the one who cared about craft — by someone who paid attention when no one else did.

Sebastián has been silent, studying the code. Now he looks up.

“Can it scale? The payment volume we promised investors—”

“I’ve tested it with simulated load,” Camila says. “Ten thousand transactions per minute. It held. The main platform crashes at two thousand.”

“Why?” Sebastián’s voice is almost pleading. “Why does it work when ours doesn’t?”

“Because I started with tests. Every feature, every edge case — I wrote the test first, then made it pass. There’s no hidden complexity because every piece of complexity is documented in the test suite.”

Stefan speaks. “This is what continuous delivery looks like. Not as a process document. Not as a consultant’s recommendation. As working software, built by someone who refused to accept that failure was inevitable.”

The room is silent.

Then Pipe says something no one expected.

“Mija, why the hell didn’t we listen to you?”

The Conversation

2:00 PM.

Don Hernando has been briefed. He stands at the window of his office, looking out at the Bogotá afternoon, processing what he’s just been told.

Stefan sits across from his desk. Camila hovers near the door, unsure if she should be here.

“This junior developer,” Don Hernando says slowly. “She built a working system. By herself. While my expensive team was failing.”

“She built what the team could have built,” Stefan corrects. “If they’d been allowed to work correctly. She wasn’t fighting deadlines no one could meet. She wasn’t being told to add features that didn’t exist. She was just… building.”

“And you’re saying we should use her system instead of ours?”

“I’m saying her system is ours. It’s what FinPulso promised to be. Simple. Reliable. Real.” Stefan leans forward. “Monday, when Mariana and her partners arrive, you have two options. You can show them another presentation — slides, promises, apologies. Or you can show them Project Fénix. Working software. Something they can touch.”

"She built what the team could have built. If they'd been allowed to work correctly."

Don Hernando turns. His eyes find Camila.

“You,” he says. “Come here.”

Camila approaches, uncertain. The old patriarch studies her the way he studies horses at auction — assessing breeding, temperament, potential.

“Why?” he asks simply.

“Why what, señor?”

“Why build this thing in secret? Why not demand recognition? Why not threaten to leave unless we listened?”

Camila considers the question. “Because leaving wouldn’t fix the problem. And threatening wouldn’t make anyone listen. The only thing that works…” She pauses. “Is work that works.”

Something shifts in Don Hernando’s expression. A flicker of recognition.

“Jorge used to say something similar,” he murmurs. Then, louder: “My son. He said that making demands is for people who have no leverage. The people who change things are the ones who simply do the thing, and let the results speak.”

“He sounds like he was wise.”

“He was. And I was too stubborn to hear him.” Don Hernando walks to his desk. “Camila Torres. Starting today, you report directly to Stefan. You’re the technical lead for Project Fénix. Your budget is whatever you need to make this real by Monday.”

“I—” Camila falters. “I don’t know if I’m ready to lead—”

“Neither did I, when my father handed me the ranch at twenty-two.” Don Hernando’s smile is thin but genuine. “You’ll figure it out. People who build things in secret because they care — those people figure it out.”

The Push

Saturday, 9 AM.

The office has transformed again — but differently this time. Not the frantic energy of the war room. Something calmer. More focused.

Camila stands at the main whiteboard, marker in hand. For the first time, everyone is looking at her.

“The goal is simple,” she says. “By Monday morning, Project Fénix needs to be running on FinPulso’s official infrastructure. Not my personal AWS account. The real thing.”

“What about the existing platform?” Sebastián asks.

“We don’t touch it. Fénix runs in parallel. The investors see both — what we have, and what we’re building. Radical honesty, like Stefan said.”

Diego is already at his laptop. “I’ve pulled the Fénix repository. The architecture is clean, but it’s designed for single-server deployment. We’ll need to containerize it for our Kubernetes cluster.”

“That’s your task,” Camila says. “Stefan suggested you’d know how.”

“I do.” Diego’s fingers are moving faster than they have in months. “Give me three hours.”

Not a war room. A workshop.

Pipe surprises everyone. “I know the production database schema better than anyone.” His voice is rough, almost angry — but the anger is turned inward. “If you need Fénix to read from the same data sources, I can build the adapters.”

“You’d do that?” Camila asks.

“Mija.” Pipe’s jaw works. He looks down at his hands — the hands of a man who’s been writing code for thirty years and somewhere along the way forgot why he started. “I’ve been a bitter old cabrón for too long. Bitching about everything, contributing nothing. I’ve been waiting for someone to build something worth a damn. I just didn’t expect it to be you.” His voice cracks slightly. “No offense.”

“None taken.” Camila’s eyes are wet.

“None taken.”

Stefan moves between stations, watching, occasionally asking questions. But mostly, he stays out of the way. This is their moment, not his.

Isabella arrives with coffee and sandwiches. “I can’t code,” she says, “but I can make sure you don’t starve. And I can document every step for the investor presentation.”

“The presentation should be the software,” Camila says. “But… documentation helps. Thank you.”

By Saturday evening, Fénix is running in a staging environment on FinPulso’s infrastructure. By Sunday morning, it’s processing test transactions without a single error.

At 3 PM Sunday, Camila runs a full load test: ten thousand simulated payments. The system handles them in under eight minutes.

She stares at the success metrics, not quite believing what she’s seeing.

“It works,” she whispers.

“Of course it works.” Diego is beside her, equally exhausted, equally amazed. “You built it to work.”

The Shadow Returns

Sunday, 8 PM.

While the team celebrates their first real success in months, a phone rings in a hotel room across the city.

Alejo answers.

“The board meeting is tomorrow,” says the voice on the other end. Marco, calling from somewhere in Europe. “Is the old man going to sell?”

“He should. They have nothing. The demo was a disaster.”

“My sources say differently.” Marco’s tone is careful. “They say there’s movement. The developers are working. Something new.”

Alejo’s eyes narrow. “What kind of movement?”

“I don’t know yet. My contact went silent after Thursday. But there’s energy in that office. Not the energy of defeat.”

"They have nothing," Alejo said. He was about to be wrong.

Alejo is quiet for a moment. He’s been certain that FinPulso would collapse — that the demo failure was the final blow. He’d already prepared his pitch to Mariana: take his side, force a merger with MiPago, emerge as CEO of the combined company.

But if something has changed…

“I need to be at that meeting,” he says.

“You were removed from the board.”

“I still own ten percent. They can’t prevent a shareholder from attending.” Alejo’s mind is racing. “Book me a flight. First thing tomorrow. I want to see for myself what they’re planning.”

“And if they have something real?”

“Then I find a way to take credit for it.” Alejo’s smile returns, though it doesn’t reach his eyes. “Or destroy it. Whichever is easier.”

The Night Before

Sunday, 11 PM.

The office is quiet now. Most of the team has gone home to sleep — real sleep, not the exhausted collapse of the war room. Only Stefan and Camila remain.

She’s running one final round of tests. He’s writing notes for tomorrow’s presentation.

“You know they might still say no,” Stefan says without looking up. “Mariana’s partners. They might decide the risk is too great, regardless of what we show them.”

“I know.”

“And if they do?”

Camila considers the question. “Then I have a working payment system, a lot of experience, and proof that I can build things that matter. That’s not nothing.”

Stefan sets down his pen. “No. It’s not.”

“Can I ask you something?”

“Of course.”

“Why do you do this? Travel to broken companies, try to fix them. It can’t pay well enough to justify the frustration.”

"Why do you do this?"

Stefan is quiet for a long moment.

“I burned out once,” he says finally. “Badly. I was running a team at a company that demanded the impossible, and I gave it to them, until there was nothing left of me to give. I spent six months on my finca in Panama, doing nothing but walking with my horses and wondering if I’d ever want to work again.”

“What brought you back?”

“A junior developer. At a company I consulted for years earlier. She sent me an email saying that something I’d taught her had changed her career. That she was now leading a team, and they were shipping good software, and she wanted me to know it mattered.”

Camila blinks. “That’s…”

“That’s why I do this. Not for the companies. Not for the investors. For the Camilas. The people who care about craft even when no one is watching. The ones who build in secret because they believe things can be better.” He meets her eyes. “You reminded me of her. Of why I started.”

The moment stretches. Then Camila smiles — the first real smile Stefan has seen from her.

“Tomorrow,” she says. “We show them what real software looks like.”

“Tomorrow,” Stefan agrees. “We tell the truth.”

The Arrival

Monday, 2 PM.

They come in the same convoy of black SUVs: Mariana and her partners from São Paulo. Eduardo, Patricia, Victor. The same people who watched the demo crash three days ago.

But this time, there’s a surprise.

As Don Hernando greets them in the lobby, a fourth figure emerges from a taxi behind the convoy. Impeccable suit. Predator’s smile.

Alejo.

“Don Hernando,” he says smoothly. “I hope you don’t mind. As a shareholder, I felt it important to attend.”

Don Hernando’s expression freezes. Laura takes an involuntary step backward. But Mariana — Mariana’s eyes narrow with interest.

“Alejandro,” she says. “I thought you’d left the company.”

“A misunderstanding. I stepped back temporarily to give the team space. But I remain deeply committed to FinPulso’s success.” He glances at Don Hernando. “Whatever form that success takes.”

The snake had returned to the garden.

The lobby feels suddenly colder.

“Shall we?” Mariana gestures toward the elevators. “I believe you have something to show us.”

Don Hernando leads the way, but his jaw is tight. This was supposed to be a fresh start. Alejo’s presence is a reminder that the old battles aren’t finished.

Stefan catches Camila’s eye as they enter the conference room.

Stay focused, his look says. The work speaks for itself.

She nods. She’s ready.

The Presentation

2:15 PM.

The conference room is arranged differently today. No podium, no formal presentation screen. Instead, there’s a laptop connected to a monitor, showing a terminal window with live metrics.

“Before we begin,” Don Hernando says, “I want to be clear about something. What you’re about to see is not a pitch. It’s not a promise. It’s working software.”

He steps aside and gestures to Camila.

The investors exchange glances. A junior developer leading the presentation? Victor looks skeptical. Eduardo looks curious. Patricia is already taking notes.

Alejo’s smile falters, just slightly.

“My name is Camila Torres,” she begins. “I’m a software developer at FinPulso. And for the last three months, I’ve been building something in secret.”

She walks them through Project Fénix. Not with slides — with code. With tests. With live demonstrations. She processes a payment in front of them. Then another. Then a hundred simultaneously.

"This is not a pitch. It's working software."

“The system you saw Thursday was built to impress,” Camila says. “This system was built to work. There’s a difference.”

Victor speaks. “The test coverage—”

“Ninety-two percent. Every critical path is tested. Every edge case is documented. You can read the tests yourself — they’re in the repository.”

“And the deployment process?”

“Automated. Triggered by code commit. Average deployment time: four minutes.” Camila pulls up a log. “We deployed twelve times this weekend. Zero failures.”

Patricia looks up from her notes. “You built this alone?”

“I started alone. This weekend, the team helped migrate it to production infrastructure.” Camila glances at Diego, at Pipe, at Stefan. “I proved it was possible. They proved it was real.”

Eduardo leans back in his chair. He hasn’t said anything. But his expression has shifted from skepticism to something else.

“And the old platform?” Mariana asks. “The one that crashed?”

“Still exists. Still broken. We’re not hiding from that.” Camila takes a breath. “But we’re not hiding behind it either. Stefan has a 90-day plan to transition fully to the new architecture. We can walk you through the phases.”

Alejo has been silent throughout. Now he speaks.

“Impressive demonstration.” His voice is smooth, congratulatory. “But surely a prototype built by a junior developer isn’t sufficient basis for continued investment? What about scalability? Security audits? Enterprise readiness?”

He’s trying to sow doubt. Camila recognizes the technique.

“Those are valid questions,” she says calmly. “And I have answers for each of them. Would you like to hear them, or would you prefer to keep asking questions that assume I haven’t thought this through?”

The room goes very quiet.

Alejo’s smile freezes.

Victor — the technical partner — actually laughs. “I think I like her.”

The Verdict

4:00 PM.

The investors have retreated to Don Hernando’s office for deliberation. Mariana leads the discussion while Don Hernando, surprisingly, has left them alone.

He finds Stefan in the development area, watching the team work.

“Whatever happens,” Don Hernando says quietly, “I owe you an apology.”

“For what?”

“For yesterday. And the day before. And every day since you arrived.” The old man looks suddenly tired. “I hired you to save my company, then fought you at every turn. I demanded honesty but punished anyone who gave it to me. I—” He stops. “I was doing what I’ve always done. And it wasn’t working.”

“It takes courage to admit that.”

“It takes more courage to keep showing up, even when the old fool won’t listen.” Don Hernando manages a small smile. “If they invest — if we survive — I want you to stay. Not as a consultant. As… I don’t know. Advisor. Partner. Someone who can tell me when I’m being an idiot without fearing for their job.”

"It takes courage to keep showing up when the old fool won't listen."

Stefan considers. “Let’s see what Mariana says first.”

“Fair.” Don Hernando straightens his jacket. “Whatever she says, one thing is certain: the girl — Camila — she’s remarkable. I had her in my company for two years and never saw it.”

“You weren’t looking.”

“No. I wasn’t.” The old man’s voice is heavy with regret. “How many others have I not seen? How many Jorges have I missed because I was too busy managing instead of listening?”

Before Stefan can answer, the office door opens. Mariana emerges, followed by her partners.

Her expression is carefully neutral.

“We’ve reached a decision,” she says.

The Answer

4:15 PM.

Everyone gathers. The developers, Don Hernando, Stefan, even Alejo — though he stands apart, arms crossed, already calculating his next move.

“I’ll be direct,” Mariana says. “What we saw Thursday was unacceptable. A company at FinPulso’s stage should not be presenting demos that crash. Should not be making promises that can’t be kept. Should not be—” she pauses, “—showing investors one thing while the reality is something else entirely.”

Alejo nods, positioning himself with the criticism.

“However.” Mariana’s gaze moves to Camila. “What we saw today was different. Not a desperate attempt to salvage the situation. A genuine foundation for something real.”

She walks toward the development area. Toward the team.

“Victor tells me the codebase is clean. Eduardo says the transaction logic is sound. Patricia believes the deployment process is more mature than companies twice your size.” She stops in front of Camila. “And all of that was built by a junior developer, in her spare time, because she believed things could be better.”

"That's the kind of company we want to invest in."

Mariana turns back to the room.

“That’s the kind of company we want to invest in. Not the one that crashed Thursday. The one that rose this weekend. So here is our offer.”

She names a number. Not the full bridge round they’d hoped for — but enough. Enough to extend the runway. Enough to complete Stefan’s 90-day plan. Enough to give Project Fénix a chance.

“There are conditions,” she continues. “Monthly progress reviews. Technical audits. And—” she glances at Alejo, “—a governance restructuring to ensure alignment between leadership and execution.”

Alejo’s smile finally dies.

“What kind of restructuring?” he asks.

“The kind where people who build things have a voice. And people who only talk about things… don’t.”

The room is silent.

Then Don Hernando extends his hand to Mariana.

“Deal,” he says.

The Aftermath

6:00 PM.

The investors have departed. Alejo has vanished — no goodbyes, no final word. Laura reports seeing him make an angry phone call from the lobby before climbing into a taxi.

The team gathers in the conference room one last time. Not for a crisis meeting. Just to breathe.

“We did it,” Sebastián says, as if he can’t quite believe it.

“We haven’t done anything yet,” Camila corrects. “We bought time. Now we have to deliver.”

“The hardest part,” Stefan agrees. “The work itself.”

But Diego is smiling — actually smiling, for the first time since he returned to FinPulso. “I’d forgotten what this feels like. Shipping something real. Having it work.”

“Don’t get too comfortable,” Pipe grumbles. “Tomorrow we start the migration. There’s a lot of legacy code that needs to die.”

“Some of it is your legacy code,” Diego points out.

“I know. That’s why I have to kill it myself. A matter of honor.”

Not the end. The beginning.

Don Hernando enters last. He looks around the room — at the developers, at Stefan, at the woman who saved his company.

“There’s a phrase,” he says slowly, “that the gauchos use on the plains. Después del fuego, la pradera florece. After the fire, the prairie blooms.”

He walks to Camila.

“I owe you an apology,” he says. “For two years of not listening. For dismissing ideas because of who presented them. For building a culture where someone had to work in secret to do the right thing.”

Camila doesn’t know what to say. So she says nothing.

“Tomorrow,” Don Hernando continues, “we start again. Differently. But tonight—” he produces a bottle of aguardiente from behind his back, “—tonight, we celebrate surviving the fire.”

Stefan catches Camila’s eye across the room.

You did this, his look says.

We did this, hers replies.

And somewhere across the city, Alejo makes another phone call.

“The investment went through,” he says. “They chose to double down.”

“That’s… unexpected,” Marco replies. “What happened?”

“A junior developer. Someone nobody noticed. She built something real while we were playing chess with shadows.”

“What are you going to do?”

Alejo is silent for a long moment.

“Find a new game,” he says finally. “One where I make the rules.”

He hangs up. He looks out at the Bogotá night.

This round is lost. But the war, he knows, has only just begun.

Next Episode: "Desde Cero" Six weeks into the recovery. The team is transforming: pair programming, automated tests, daily deployments. But change breeds resistance, and not everyone at FinPulso is ready to let go of the old ways. When a critical deadline approaches, Camila must prove that the new process isn't just different — it's better. Meanwhile, Alejo's new game begins to take shape, and someone on the team isn't who they appear to be.

Legacy Modernization and the Strangler Fig

2026-01-27T00:00:00+01:00

The Death of Big-Bang Replacement

27.01.2026, By Stephan Schwab

Legacy modernization rarely happens in neat phases anymore. The strangler fig pattern — incrementally replacing pieces of a legacy system while both systems run — means discovery, decision-making, construction, and migration happen concurrently across different slices. Governing this requires tracking multiple work streams simultaneously, each at a different stage of maturity, rather than moving the whole project through sequential gates.

Why Sequential Phases Don’t Reflect Reality

Traditional project thinking imagines modernization as a sequence: first understand the legacy system, then decide what to build, then build it, then migrate. Each phase completes before the next begins. Governance checkpoints mark the transitions.

"The strangler fig doesn't wait to understand the entire tree before it starts growing. Neither should modernization."

This mental model made sense when systems were replaced in big-bang cutovers — one weekend, everything switches. But big-bang replacements are increasingly rare, and for good reason. They concentrate risk into a single moment. They require understanding the entire legacy system before replacing any of it. They demand that the new system be complete before anyone uses it.

The strangler fig pattern works differently. You identify a slice of functionality, understand that slice, build its replacement, migrate its users, and decommission that piece of the legacy system — while the rest continues running. Then you do it again with another slice.

This means at any given moment, different slices are at different stages. You’re still discovering some parts of the legacy system while you’re already migrating users off other parts. Governance that assumes sequential phases can’t see this clearly.

Four Concurrent Work Streams

Rather than phases, think of modernization as four types of work happening concurrently, each applying to different slices of the system at any given time.

Discovery Work

"Discovery never really ends — it just shifts focus as you move through different parts of the legacy system."

Understanding what the legacy system actually does. This is craft work: investigation, hypothesis, verification. Legacy systems accumulate behavior over decades. Documentation describes intent, not reality. The developers who understood the quirks have departed.

Discovery happens throughout the project, not just at the beginning. When you start working on a new slice, you discover things about that slice. When migration reveals unexpected behavior, you’re doing discovery. When users report that the new system handles something differently, discovery explains why.

Governance questions for discovery work:

Which slices are we currently investigating?
What have we learned that surprised us?
Are we talking to the people who actually use each slice?
Is discovered behavior being documented for future slices?
Are we finding things that affect slices we thought we understood?

Decision Work

Choosing what the replacement should do. Not every legacy behavior deserves replication. Some behaviors are essential business logic; others are accidental complexity from old constraints; others are bugs that users have worked around for so long they’ve become expectations.

"The hardest decisions aren't technical. They're about which behaviors the business actually needs versus which it merely tolerates."

Decision work happens for each slice as you prepare to build its replacement. It may also happen when construction reveals that earlier decisions were wrong, or when migration surfaces behaviors no one anticipated.

Governance questions for decision work:

Which slices have pending decisions?
Who is involved in these decisions? Is the business represented?
What tradeoffs are we making, and are they explicit?
Are we distinguishing “how it works” from “how it should work”?
Are decisions being documented so future slices can learn from them?

Construction Work

Building the replacement components. Once you understand a slice and have decided what its replacement should do, construction often follows trade patterns — established approaches, standard frameworks, familiar architectures. The novelty was in discovery and decision; the building is execution.

"Construction is where traditional project metrics start to apply — but only for slices that have completed discovery and decision work."

Multiple slices may be under construction simultaneously. Some may be nearly complete; others just starting. Governance needs to track each without assuming they’re all at the same stage.

Governance questions for construction work:

Which slices are under construction?
For each, can the team estimate remaining work with confidence?
Are slices being built in a way that enables incremental migration?
Are integration tests validating behavior against real legacy data?
Is construction revealing gaps in earlier discovery or decisions?

Migration Work

Moving users and data from the legacy slice to its replacement. This is often the hardest work — not technically, but operationally. Running systems in parallel, synchronizing data, shifting traffic gradually, handling edge cases where old and new behave differently.

"A slice isn't done when it's built. It's done when its piece of the legacy system turns off."

Migration work may surface problems that send you back to discovery, decision, or construction. A slice you thought was complete turns out to handle a case you didn’t know about. Users report behavior they depended on that the replacement doesn’t provide. The integration between the new slice and remaining legacy components doesn’t work as expected.

Governance questions for migration work:

Which slices are in migration?
What percentage of traffic/users has shifted to each new slice?
What problems have emerged, and how are they being addressed?
Are we on track to decommission the legacy piece?
What’s blocking full migration for each slice?

Governing the Portfolio of Slices

Effective modernization governance tracks a portfolio of slices, each at its own stage. This looks less like traditional project oversight and more like portfolio management.

"At any moment, you should be able to see the status of each slice: what type of work is active, what's blocking progress, what's next."

A useful governance view shows:

Slice	Discovery	Decisions	Construction	Migration	Blocking Issues
Billing	Complete	Complete	Complete	60% migrated	Data sync latency
User Auth	Complete	In progress	Not started	—	Awaiting security review
Reporting	In progress	—	—	—	Key user on leave
Inventory	Not started	—	—	—	Depends on Billing

This view reveals several things traditional project tracking misses:

Dependencies between slices. Some slices can’t start until others complete. Some share components. Governance can see these relationships.

Where work is stuck. A slice that’s been “in progress” on decisions for months needs attention. A slice that’s 40% migrated and hasn’t moved in weeks has a problem.

Resource allocation. If too many slices are in construction and nothing is migrating, teams may be avoiding the hard operational work. If everything is in discovery and nothing is being built, investigation may have become an excuse for inaction.

Actual progress. Migrated slices with decommissioned legacy pieces represent real progress. Everything else is work in progress.

When Work Streams Interact

The concurrent nature of strangler fig modernization means discoveries in one stream affect work in others.

Discovery reveals that a decision was wrong. A slice under construction turns out to need capabilities you decided not to include. Do you revise the decision, extend the slice, or accept a gap?

Construction exposes incomplete discovery. Building the replacement surfaces legacy behaviors no one knew about. Do you pause construction, document and decide quickly, or build what you know and handle the rest later?

Migration proves the replacement inadequate. Users in production find problems that testing missed. Do you roll back, fix forward, or run both systems longer?

"Governance must accept that these interactions are normal, not failures. The strangler fig pattern explicitly expects iterative refinement."

Governance that treats any backwards movement as failure creates incentives to hide problems. Governance that accepts iteration while monitoring for genuine stalls enables teams to respond to reality.

Signals Across Work Streams

Rather than tracking percentage complete, effective governance monitors signals that reveal actual health.

Healthy Signals

Slices are moving through stages at a reasonable pace — not stuck indefinitely in any stage.
Discovered surprises lead to explicit decisions, not silent scope creep.
Construction velocity is roughly consistent once slices reach that stage.
Migration percentages increase over time; slices eventually reach 100% and legacy pieces turn off.
Problems surface early and get addressed; they don’t accumulate silently.

Warning Signals

Multiple slices stuck in discovery with no decisions being made.
Decisions being made without business involvement.
Construction happening but no slices reaching migration.
Migration stalled at partial percentages — parallel running becoming permanent.
Teams reporting green status while nothing actually moves to production.
Discovery work expanding to slices not yet scheduled, suggesting avoidance of harder slices.

The Budget Question

“How much will this cost?” is hard to answer for strangler fig modernization because you’re not building a single thing — you’re replacing a system piece by piece.

"Budget modernization per slice, not as a single project. Each slice is more predictable than the whole."

Approaches that work:

Per-slice budgeting. Estimate and fund each slice separately. Early slices inform estimates for later similar slices. Variation averages out across the portfolio.
Burn rate over time. Rather than asking “how much total,” ask “how much per month” and “for how long.” Track whether burn rate is producing proportional migration progress.
Value-based prioritization. Not all slices are equally valuable. Prioritize slices that relieve the most pain, reduce the most risk, or enable the most opportunity. Stop when the remaining legacy pieces aren’t worth replacing.

Approaches that fail:

Demanding total cost upfront. You don’t know how many slices exist until you start. You don’t know how hard each slice is until you work on it. Total estimates made early will be wrong.
Treating all slices as equivalent. Some slices are simple; others are deeply entangled. Governance that assumes uniform effort misunderstands the work.
Waiting until everything is “done.” With strangler fig, you can stop when remaining slices aren’t worth the effort. Governance should ask “is this slice worth it?” not just “is it done?”

Management Frameworks Offer Nothing for the Actual Work

Organizations often reach for familiar management frameworks when governing modernization. This is understandable — executives want structure they recognize. But here’s an uncomfortable truth: management frameworks have nothing to offer for the actual software development work. They don’t help developers understand legacy code, make architectural decisions, write better tests, or migrate users safely.

"Management frameworks govern the governance. They don't touch the actual work of building software."

SAFe, LeSS, PMI, PRINCE2, and similar frameworks concern themselves with organizational coordination, resource allocation, reporting structures, and stakeholder communication. These are legitimate concerns — but they are entirely separate from software development. No management framework teaches you how to refactor a legacy codebase, design a strangler facade, validate behavior equivalence, or handle data migration. No planning ceremony produces better code. No project charter improves your test coverage.

This matters for legacy modernization because the actual difficulty lies entirely in the technical work: understanding what the legacy system really does, deciding what behavior to preserve, building replacements that work correctly, and migrating without disrupting users. Management frameworks are silent on all of this.

What management frameworks address:

How to report progress to stakeholders
How to coordinate multiple teams
How to allocate budgets across initiatives
How to structure governance committees
How to escalate decisions

What management frameworks don’t address — and can’t:

How to investigate undocumented legacy behavior
How to design replacements that can run alongside legacy systems
How to test that new and old produce equivalent results
How to migrate users incrementally without data loss
How to handle the edge cases that only surface in production

Approaches that actually help the work:

Kanban-style visualization works for tracking slices across stages — but this is a visualization technique, not a management framework. Teams benefit from seeing work items move through columns with WIP limits. The board doesn’t tell you how to do the work; it helps you see where work is stuck.

Cynefin (Dave Snowden) helps governance understand why different work streams need different approaches — discovery work lives in the complex domain; construction work is complicated. But again, this is a sensemaking tool for choosing approaches, not a prescription for executing them.

Real Options thinking treats each slice as an option — investing in discovery buys the option to build. This helps with prioritization decisions, not with the actual building.

The pattern is clear: useful approaches help you see, decide, or prioritize. None of them help you actually do the technical work. That requires engineering skill, domain knowledge, and hands-on experience — none of which come from management frameworks.

The danger:

When organizations invest heavily in management framework adoption, they often believe they’ve addressed the modernization challenge. They haven’t. They’ve addressed the coordination and reporting challenge — which is real, but much smaller than the technical challenge. A perfectly governed project with inadequate technical capability will still fail. An ungoverned project with excellent technical execution might succeed despite the chaos.

The Patience for Incremental Progress

Strangler fig modernization produces incremental value — each migrated slice is a piece of legacy system that no longer needs maintenance, a piece of technical debt retired, a group of users on a better system. But it doesn’t produce dramatic milestones.

"Progress in strangler fig looks like gradual shrinking of the legacy system, not sudden replacement."

Executives accustomed to big project launches may find this unsatisfying. There’s no ribbon-cutting moment — just the gradual dimming of the legacy system’s lights. Governance that demands visible milestones may create pressure to batch work artificially, losing the risk reduction that incremental migration provides.

The organizations that modernize successfully are those where governance values sustainable progress over theatrical milestones. They celebrate each decommissioned legacy piece. They trust that the system is getting better even when there’s no single moment to point to. They understand that software development includes significant design work — and that design work applied slice by slice, with learning between slices, produces better results than attempting to design everything upfront.

The legacy system took years to build and decades to evolve. The strangler fig will take time too — but it will produce value along the way, not just at the end.

When Software Development Is Craft and When It Is Trade

2026-01-24T00:00:00+01:00

The Two Faces of Building Software

24.01.2026, By Stephan Schwab

Software development oscillates between two modes: craft, where skilled practitioners make judgment calls in novel situations, and trade, where established patterns solve familiar problems. Understanding which mode applies — and when to shift between them — determines whether organizations invest appropriately, whether modernization projects succeed, and whether developers find satisfaction in their work.

What These Words Actually Mean

Before we proceed, we should clarify our terms. English uses “craft” and “trade” somewhat interchangeably, which obscures an important distinction. German preserves this distinction more clearly, and understanding it illuminates what we’re really discussing.

"In German, 'Handwerk' carries genuine prestige — it's not just a job category but a mark of mastery earned through years of rigorous training."

Handwerk (craft) in German refers to the traditional, regulated, highly skilled manual professions. The path to mastery is long: a formal apprenticeship of about three years, followed by several years working as a Geselle (journeyman) — traditionally traveling between workshops to learn from different masters — before finally qualifying to take the Meisterprüfung (master examination). The Zimmerer (timber-frame carpenter), Elektriker (electrician), Goldschmied (goldsmith), and master baker all practice Handwerk. When Germans say “Handwerk hat goldenen Boden” (craft has a golden foundation), they express genuine admiration. These are professions where judgment, tradition, and deep skill combine — earned over many years.

Gewerbe or Beruf (trade, occupation) describes work that can be learned more quickly — sometimes through a shorter training period, sometimes through on-the-job experience alone. Assembly work, machine operation, many warehouse roles. Valuable work, certainly, but work where the patterns are established and the skill lies primarily in reliable execution rather than judgment.

This distinction matters for software because both modes exist in our field, often within the same project or even the same day. The question isn’t which is better — both are necessary — but which applies to the work at hand.

A Master Carpenter Doesn’t Reinvent the Dovetail Joint

Walk into a furniture workshop and you’ll observe something instructive. The master carpenter cutting dovetail joints for a drawer doesn’t reinvent the joint each time. Centuries of woodworking tradition have established optimal angles, spacing, and techniques. The skill lies in execution — consistent cuts, tight fits, appropriate wood selection — not in reimagining what a dovetail should be.

"The carpenter exercises craft in choosing which joint for which purpose, but executes it as trade — following proven patterns with reliable precision."

Yet when that same carpenter encounters an unusual commission — perhaps furniture that must fold in unconventional ways, or a curved surface that standard techniques don’t address — the work shifts. Now judgment, experimentation, and creative problem-solving take over. The carpenter is no longer executing known solutions but discovering new ones.

Software development works the same way. Much of development isn’t novel. Authentication systems, database queries, form validation, API integrations — these are dovetail joints. We know how they work. The patterns are established. The skill lies in reliable execution: writing clean code, handling edge cases properly, testing thoroughly, deploying safely.

Trade Work Is Not Lesser Work

Calling something “trade work” carries unfortunate connotations in software circles. Developers often want to see themselves as creative problem-solvers, not workers following blueprints. But this view misunderstands both the value of trade work and the reality of what most software development requires.

"The plumber who keeps water flowing through millions of homes performs trade work of enormous value."

A skilled electrician wiring a house follows established codes and patterns. Nobody would dismiss this as uncreative or unimportant. The work demands expertise, attention to detail, and pride in doing things properly. Lives depend on correct execution. The same is true for much of software development.

When a developer implements a standard REST API, writes unit tests for a service layer, or configures a deployment pipeline, they’re doing trade work. They’re applying known patterns reliably. This work keeps businesses running. It serves customers. It requires skill and care. Dismissing it devalues the contributions of countless developers who build and maintain the systems our economy depends on.

When Craft Emerges

Craft work in software emerges from genuine novelty — but developers must be honest about what counts as novel.

"Craft emerges when the problem hasn't been solved before, or when familiar solutions must be adapted to unfamiliar constraints."

Imagined novelty is common: a developer convinces themselves their situation is unique, then builds a custom solution for a problem that established tools already handle well. They create a bespoke authentication system when OAuth exists, write a homegrown ORM when mature frameworks abound, or design a custom message format when JSON would suffice. This often happens because building something new feels more interesting than applying something existing — or because the developer hasn’t fully explored what’s already available.

Real novelty is different. You’ve genuinely evaluated the established approaches and found they don’t fit. Your domain constraints are unusual, the integration boundaries are unique, or the performance requirements exceed what commodity solutions can deliver. In these situations, craft work is necessary — not because it’s more prestigious, but because no ready-made pattern applies.

You’ll find genuine craft work in several places:

Domain complexity that defies standard patterns. When the business domain has genuine intricacy — financial derivatives with unique risk characteristics, manufacturing processes with unusual constraints, logistics problems with novel optimization criteria — standard solutions won’t fit. Developers must understand the domain deeply and invent approaches tailored to its specific challenges.

System integration across unusual boundaries. Connecting systems that weren’t designed to work together, bridging legacy and modern architectures, making disparate data models cohere — these situations demand creative problem-solving. The patterns for connecting System A to System B don’t exist because nobody has connected these particular systems before.

Performance at unusual scales. When a system must handle loads or data volumes beyond common experience, standard approaches may fail. Craft work discovers what works in these specific circumstances.

User experience innovation. Creating genuinely new ways for people to interact with systems requires craft. Not the superficial novelty of different button colors, but fundamental rethinking of how users accomplish goals.

The Danger of Misclassification

Organizations get into trouble when they misclassify work in either direction.

"Treating trade work as craft wastes resources. Treating craft work as trade produces failures."

Treating trade work as craft leads to over-engineering, inflated timelines, and unnecessary complexity. Every feature becomes a research project. Developers build custom solutions for problems that commodity tools solve perfectly well. Simple applications balloon into architectural monuments. Technical debt accumulates not from cutting corners but from over-elaborate solutions that nobody can maintain.

Treating craft work as trade leads to failed projects and missed opportunities. Organizations expect predictable timelines for inherently unpredictable work. They pressure developers to commit to deadlines before exploration has revealed what the work actually requires. Teams implement the first approach that seems workable rather than discovering the approach that actually fits.

Reading the Signals

How do you know which mode applies? Several signals help:

Has this problem been solved many times before? If experienced developers immediately recognize the pattern and can name the standard approach, you’re likely looking at trade work. If they furrow brows, ask clarifying questions, and propose exploratory spikes — craft work.

"The experienced developer's reaction to a problem tells you more about its nature than any methodology can."

Do established libraries and tools address it? Rich ecosystems of libraries suggest trade work — others have encountered this enough that solutions have been packaged. Sparse options suggest craft territory.

Can you estimate with confidence? Trade work supports reasonably accurate estimation because the patterns are known. Craft work resists estimation because the discovery hasn’t happened yet. If teams can’t estimate confidently, that’s a signal about the work’s nature, not the team’s competence.

Does the business domain drive complexity? When complexity comes from the business domain rather than technical requirements, craft work is more likely. Technical complexity has often been solved; domain complexity is specific to this situation.

Modernization: Where Both Modes Meet

A significant portion of software work involves neither building new systems from scratch nor maintaining stable ones. Many developers spend their days modernizing existing systems — improving aging architectures, replacing legacy components, or migrating to new platforms. This work deserves special attention because it blends craft and trade in distinctive ways.

"Modernization requires the judgment to understand what exists, the craft to envision what should replace it, and the trade discipline to execute the transition reliably."

Understanding the existing system is craft work. Legacy systems rarely come with accurate documentation. The developers who built them have often moved on. The code embodies decisions made under forgotten constraints, workarounds for problems no one remembers, and integrations with systems that have themselves evolved. Making sense of this — understanding not just what the code does but why it does it that way — requires investigation, hypothesis, and judgment. No established pattern tells you how to understand a specific legacy system.

Deciding what to preserve and what to change is craft work. Not everything in a legacy system is technical debt. Some apparent complexity reflects genuine business requirements that new developers don’t yet understand. Some seeming inefficiencies exist because faster approaches failed under production load. The craft lies in distinguishing valuable complexity from accidental complexity, in recognizing which behaviors must be preserved exactly and which can be reimagined.

The actual replacement often follows trade patterns. Once you understand what the new system must do, much of building it may be straightforward. Implementing a modern REST API to replace an aging SOAP service uses established patterns. Migrating data from one schema to another follows known approaches. Setting up CI/CD pipelines for the new system is trade work. The novelty was in understanding what to build; the building itself may be routine.

But integration and migration require craft again. Running old and new systems in parallel, gradually shifting traffic, handling the edge cases where they behave differently — this demands judgment and creativity. Every migration has unique characteristics. The established patterns for strangler fig migrations or parallel runs provide starting points, but the specific decisions about what to migrate when, how to handle data synchronization, and when to cut over require craft judgment.

Organizations often underestimate modernization projects because they see “replace legacy system with modern equivalent” and assume trade work. The hidden craft — understanding the legacy system, making judgment calls about what to preserve, navigating the transition — is where projects stumble.

Both Modes Require Expertise

A common mistake is assuming craft work requires expertise while trade work doesn’t. Both modes demand skill — different kinds of skill.

Trade work requires:

Deep knowledge of established patterns and when to apply them
Discipline to execute consistently and thoroughly
Attention to edge cases that pattern descriptions often omit
Testing rigor to verify correct implementation
Communication skills to coordinate with other practitioners

Craft work requires:

Ability to recognize when standard patterns don’t apply
Creativity to envision novel solutions
Humility to explore and revise when approaches don’t work
Judgment to know when discovery has revealed enough to proceed
Communication skills to explain unfamiliar approaches to stakeholders

"The best developers move fluidly between modes, recognizing which situation calls for which approach."

What This Means for Organizations

Understanding these two modes helps organizations make better decisions:

Staff appropriately. Trade work benefits from developers who find satisfaction in reliable execution and take pride in well-implemented standard patterns. Craft work benefits from developers who thrive on ambiguity and novel challenges. Mismatches create frustration on both sides.

Set expectations correctly. Trade work should come with predictable timelines and reliable estimates. Craft work should come with explicit acknowledgment of uncertainty and iterative approaches that reveal scope as work progresses.

Invest proportionally. Trade work should use commodity tools and established libraries. Craft work may justify custom solutions — but only when the genuinely novel aspects require it.

Recognize transitions. Work often begins as craft and becomes trade. The first implementation of a novel system involves significant discovery. Subsequent maintenance and enhancement may be largely trade work — applying established patterns within a now-understood system. Staff and expectations should shift accordingly.

The Honest Conversation

Perhaps most importantly, organizations and developers should have honest conversations about which mode applies to their work. Developers who frame trade work as craft — because craft feels more prestigious — do themselves and their organizations a disservice. Organizations that insist all work is trade — because trade is more predictable — create conditions for failure.

The master carpenter feels no shame in cutting dovetail joints well. The satisfaction comes from quality execution, from contributing to something useful, from the pride of work done properly. The same carpenter feels different satisfaction when solving an unusual problem — the excitement of discovery, the creativity of inventing approaches, the reward of making something genuinely new.

Both forms of work have dignity. Both require expertise. Both contribute value. The wisdom lies in recognizing which mode applies and responding appropriately — as practitioners and as organizations.

Understanding software development as a design discipline helps here: design work naturally oscillates between applying proven patterns and inventing new approaches. And recognizing what intrinsically motivates developers — pride in craft, curiosity, the satisfaction of solving real problems — helps organizations create conditions where both modes of work can thrive.

El Demo Day

2026-01-22T00:00:00+01:00

Previously: "Fantasmas del Sprint" — The emergency board meeting ends with Alejo's removal. Diego returns to FinPulso as a consultant, ready to help rebuild. But in a hotel bar in Zona Rosa, Alejo sits alone, planning his next move.

The Announcement

FinPulso office. Tuesday, 9:15 AM.

The post-Alejo atmosphere is strange — lighter in some ways, heavier in others. The developers work with a cautious optimism, like survivors emerging from a storm who aren’t yet sure the sky has cleared.

Diego has claimed a desk near Camila. They’ve been reviewing her rebuild project since dawn, whiteboards filling with architecture diagrams and migration plans. Pipe watches from his corner, still suspicious but no longer hostile. The email Diego sent him — acknowledging Pipe’s deep knowledge of the legacy systems — had opened a door.

Stefan observes from his usual position, notebook in hand. The team dynamics are shifting. Not healed, but healing.

Then Mariana’s face appears on the conference room screen, and everything changes.

“I have news,” she says without preamble. “Good news, I think. But it comes with conditions.”

"Good news. But it comes with conditions."

Don Hernando leans forward. “We’re listening.”

“After the board meeting, I briefed my partners on the situation. The fraud, the cleanup, the leadership changes.” Mariana pauses. “They were concerned. Understandably. But they were also impressed by how quickly you acted once the evidence was clear.”

“We did what was necessary,” Don Hernando says.

“You did. And that bought you credibility.” Mariana’s eyes are sharp. “My partners want to see FinPulso for themselves. They’re flying in Thursday. They want a demonstration of the platform — not slides, not promises. Working software.”

The silence is absolute.

“Thursday,” Sebastián repeats. “As in… the day after tomorrow?”

“As in 48 hours from now, yes.”

Don Hernando’s face is unreadable. “And if the demonstration goes well?”

“They’re prepared to discuss a bridge round. Additional funding to extend your runway while you execute the recovery plan.” Mariana’s voice softens slightly. “This is a lifeline, Don Hernando. But it’s also a test. They want to see if the team can actually deliver.”

Stefan watches the room absorb this. Sebastián looks terrified. Don Hernando looks calculating. And somewhere in the development area, Diego and Camila are still drawing on whiteboards, unaware that everything just accelerated.

“We’ll be ready,” Don Hernando says.

“I hope so.” Mariana nods once. “I’ll send the details. Thursday, 2 PM Bogotá time. Don’t disappoint me.”

The screen goes dark.

The War Room

Tuesday, 11 AM.

The conference room has transformed. Whiteboards line every wall. Post-it notes cluster in anxious constellations. Pizza boxes from last night’s dinner share space with untouched arepas from this morning’s breakfast.

Everyone is here: Don Hernando in his usual chair, radiating controlled intensity. Sebastián at the whiteboard, marker in hand, trying to map what exists versus what was promised. Isabella with her laptop, pulling up user flows and feature lists. Diego and Camila at a side table, debating technical feasibility in rapid-fire Spanish.

Stefan stands apart, watching. Pipe sits in the corner, arms crossed, waiting to see which way this goes.

“The payment processing module,” Sebastián says, pointing to a box on the whiteboard. “This is what Mariana’s partners will want to see. It’s our core value proposition.”

“And it doesn’t work,” Diego says flatly.

48 hours. 12 features. 4 developers. The math didn't work.

“It works partially,” Isabella corrects. “The happy path functions. If you enter exactly the right data in exactly the right order, you can process a payment.”

“And if you don’t?”

“Error screens. Timeouts. Occasionally a complete freeze that requires a server restart.” Isabella’s voice is tired. “We’ve been demoing the happy path to investors for months. It’s a very narrow path.”

“What about Camila’s rebuild?” Sebastián asks.

Camila looks up from her laptop. “The new payment module is clean. Good test coverage. But it’s not connected to the production database yet. We’d need to build the integration layer, test it, deploy it—”

“How long?”

“To do it right? Two weeks minimum.”

“To do it wrong?”

Camila exchanges a glance with Diego. “We could hack something together. Bridge the new code to the old database with duct tape and prayers. It might work for a demo. It might also corrupt transactions and destroy data.”

“Unacceptable,” Don Hernando says. “We cannot risk corrupting real user data for a demonstration.”

“Then we demo what we have,” Diego says. “The happy path. And we pray no one clicks the wrong button.”

The Code Review That Broke Diego

Flashback: Two months earlier. A rushed code review meeting.

The conference room smells of stale coffee and desperation. It’s 6 PM, and Diego is presenting his latest fix for the payment module — a complex refactoring that should finally stabilize the transaction processing.

Sebastián sits at the head of the table, laptop open, glancing at his watch. Isabella is there, taking notes. Alejo joins via video, his face impassive.

"Skipping testing is how we got the last outage."

“This refactoring addresses the race conditions in the payment queue,” Diego explains, pointing to the code diff on the screen. “It adds proper locking and error handling. But it requires testing the full integration — we can’t just deploy and hope.”

“How long for testing?” Sebastián asks.

“Two days minimum. We need to simulate load, check for regressions—”

“We have the investor meeting next week,” Alejo interrupts. “The board wants to show progress. Can we deploy a simplified version? Just the core fix, skip the full testing?”

Diego’s jaw tightens. “Skipping testing is how we got the last outage. This code touches the payment flow — if it fails, real users lose money.”

“It’s a calculated risk,” Alejo says smoothly. “And we have Diego here to monitor it live.”

Isabella speaks up. “Diego’s right. We need proper validation. The investors will understand if we show stability over features.”

But Sebastián is already nodding. “Deploy the simplified version. We’ll monitor it closely. The board needs to see momentum.”

Diego meets Isabella’s eyes. She shakes her head slightly — not worth fighting. Not now.

The code goes live that night. It works. For the demo.

But Diego knows the debt is growing. Another compromise, another ghost in the sprint.

The Honest Proposal

Tuesday, 2 PM.

Stefan has been silent all morning. Now, during a break while the developers argue about database connections, he approaches Don Hernando.

“May I speak freely?”

The old man’s eyes narrow. “You’ve been speaking freely since you arrived. Why ask permission now?”

“Because what I’m about to suggest will sound like surrender.” Stefan sits across from him, setting his notebook on the table. “You’re planning to demo features that don’t work. To show a product that exists only in pitch decks. To continue the pattern that Alejo exploited.”

“That’s not—”

“It is exactly the same.” Stefan’s voice is quiet but firm. “Different motive, same behavior. Presenting a reality that doesn’t exist, hoping no one looks too closely.”

"What I'm about to suggest will sound like surrender."

Don Hernando’s jaw tightens. “What would you have me do? Tell Mariana’s partners that we have nothing to show them?”

“Show them what you have. The actual working components. The rebuild Camila has been creating. The monitoring systems Diego installed. The real metrics — not inflated, not adjusted. Show them a team that knows its weaknesses and has a plan to address them.”

“They’ll think we’re amateurs.”

“They’ll think you’re honest.” Stefan leans forward. “These are sophisticated investors. They’ve seen a hundred demos. They know when they’re being sold a fantasy. What they haven’t seen — what almost no one ever shows them — is a team that admits reality and presents a credible path forward.”

Don Hernando is silent for a long moment. His hands rest on the table, still.

“And if they don’t invest?”

“Then you find out now, not six months from now when the runway is gone and the lies have compounded.” Stefan’s voice softens. “This is what sustainable delivery looks like. Small, honest steps. No more sprints toward cliffs.”

The door opens. Sebastián appears, looking frazzled. “We found a way to stabilize the payment flow. It requires disabling three features, but the core transaction path should hold for a 30-minute demo.”

Don Hernando looks at Stefan, then at his co-founder.

“Proceed,” he says. “We show them everything. The full vision.”

Stefan closes his notebook. Says nothing. Returns to his corner.

The Countdown

Wednesday, 11 PM.

The office has the feeling of a siege. Empty coffee cups form cairns on every surface. Someone has taped a countdown timer to the wall: 14:32:17 and falling.

Camila hasn’t slept in 36 hours. Neither has Diego. They’ve been working in parallel — Camila stabilizing the frontend, Diego patching the backend, both aware that they’re building a house of cards that needs to stand for exactly 30 minutes.

“The webhook timeout is fixed,” Diego announces, rubbing his eyes. “But we’ve got a new problem. The fraud detection module is throwing false positives on any transaction over 500,000 pesos.”

“So we demo with smaller amounts,” Isabella says.

“What if the investors ask about larger transactions?”

“We tell them it’s a feature, not a bug. Enhanced security for high-value transfers.” Isabella’s smile is exhausted. “I’ve been writing talking points all day. I have an answer for everything except ‘why doesn’t this work?’”

Pipe, surprisingly, is still there. He’s been migrating database configurations since noon, his COBOL-era experience proving invaluable for understanding the legacy systems no one else can navigate.

“The reporting module is stable,” he says gruffly. “First time in months. You’re welcome.”

14 hours. 12 critical bugs. 1 chance.

Stefan walks the floor, observing. He’s seen this before — the adrenaline-fueled heroics, the last-minute miracles, the collective denial that this is any way to build software. Tomorrow, regardless of outcome, there will be a reckoning.

But not tonight. Tonight, the team believes they can do the impossible.

He hopes they’re right. He fears they’re not.

The Morning Of

Thursday, 8 AM.

Don Hernando arrives in a suit he hasn’t worn since his son’s funeral — dark, impeccable, carrying the weight of occasions that matter. He finds the development team exactly where he left them: at their desks, surrounded by the debris of battle.

“Status,” he says.

Sebastián stands, swaying slightly from exhaustion. “The demo environment is stable. We’ve run through the script fourteen times. It worked twelve of those times.”

“Twelve out of fourteen.”

“Eighty-five percent success rate.”

“And the other fifteen percent?”

Sebastián hesitates. “Various failures. A timeout here, a display glitch there. Nothing catastrophic. We’ve built in recovery points — places where we can restart if something goes wrong.”

Don Hernando nods slowly. “And what are the chances that something goes wrong during the actual demo?”

No one answers.

"Eighty-five percent," Sebastián said. Don Hernando heard "fifteen percent."

“Laura,” Don Hernando calls. His assistant appears instantly — she’s been hovering nearby, anticipating needs. “The conference room. Fresh flowers. The good coffee. Water with lime, not lemon — the Brazilians prefer it. And make sure the air conditioning is working. We cannot have sweating executives.”

“Already done, patrón.”

“Of course it is.” He almost smiles. “Everyone else: go home. Shower. Sleep if you can. Be back by noon looking like professionals, not survivors. We have one chance to show these investors who we really are.”

He pauses at the door.

“And who we really are is not a company that looks defeated before the battle begins.”

The Arrival

Thursday, 1:45 PM.

They come in a convoy of black SUVs from the airport — Mariana and three partners from her São Paulo fund. Two men and a woman, all in expensive casual, all carrying the confident energy of people who evaluate companies for a living.

Laura greets them in the lobby with the rehearsed warmth of someone who has managed ranchers and investors with equal skill. She guides them to the conference room, where Don Hernando waits with Sebastián and Isabella.

The developers are hidden in the back — Diego at the main terminal, Camila monitoring systems, Pipe watching the database like a hawk guarding its nest. Stefan stands near the window, present but uninvolved.

“Welcome to FinPulso,” Don Hernando says, shaking hands with each investor. “Thank you for making this journey.”

The stage was set. The actors were in place. All that remained was the performance.

Mariana makes introductions: Eduardo, managing partner, grey-haired and sharp-eyed. Patricia, operations specialist, already scanning the room for signs of dysfunction. And Victor, the technical partner, who will be watching the demo with developer’s eyes.

“Shall we begin?” Eduardo asks.

“Absolutely.” Don Hernando gestures to the main screen. “Sebastián, our CTO and co-founder, will walk you through the platform.”

Sebastián steps to the podium. His hands are steady. His voice is clear. He’s rehearsed this a hundred times.

“FinPulso was founded on a simple belief: that financial services in Colombia are too complex, too expensive, and too inaccessible for ordinary people. Our platform changes that…”

In the back room, Diego’s fingers hover over the keyboard. The demo environment shows green across all monitors. The first API call is loading.

So far, so good.

The First Cracks

2:15 PM.

Twenty minutes into the demo, everything is working. Sebastián has shown the onboarding flow, the account dashboard, the transaction history. The investors nod along, occasionally asking questions that Isabella fields with practiced ease.

Then Victor speaks up.

“Can you show us a live transaction? Not a simulation — an actual payment between two accounts.”

Sebastián’s smile doesn’t waver. “Of course. We have a test environment that mirrors production exactly.”

He navigates to the payment screen. The cursor blinks in the amount field.

In the back room, Diego leans forward. This is the part that failed twice during rehearsals.

Sebastián enters 250,000 pesos — safely under the threshold that triggers the fraud detection bug. He selects a recipient account. He clicks “Process Payment.”

The loading spinner appears.

The spinner had been rotating for five seconds. It should have completed in two.

Three seconds. Normal.

Five seconds. Sebastián keeps talking, filling the silence.

Eight seconds. Victor’s eyes narrow.

“There’s sometimes a brief delay when connecting to our payment partners,” Isabella says smoothly. “Security verification at multiple levels.”

Ten seconds.

In the back room, Diego is already typing. The transaction is stuck in a queue — the same queue they thought they’d fixed at 3 AM.

“Camila,” he whispers. “The webhook isn’t responding.”

“I see it.” Her fingers fly across the keyboard. “Restarting the service.”

On the main screen, the spinner disappears. A green checkmark appears: Transaction Successful.

Sebastián exhales invisibly. “And there we have it. 250,000 pesos transferred instantly, with full encryption and regulatory compliance.”

“Impressive,” Patricia says. She’s writing something in her notebook.

Don Hernando allows himself a microscopic smile. The hard part is over.

Except it isn’t.

The Request

2:32 PM.

Victor has been quiet since the transaction demo, but now he raises his hand like a student with a difficult question.

“The multi-party payment feature,” he says. “The one mentioned in your pitch deck. The ability to split a transaction between multiple recipients in real-time. Can we see that?”

Sebastián’s face goes carefully blank. The multi-party feature was Alejo’s favorite slide — impressive in PowerPoint, nonexistent in code.

“That’s in our Phase 2 development,” Isabella says quickly. “We’ve been focused on perfecting the core transaction engine first.”

“The pitch deck mentioned it as a current capability.”

“The deck was… optimistic in some areas. We’ve refined our timeline based on technical realities.”

Victor nods slowly. He doesn’t look satisfied.

"The deck was optimistic," Isabella said. Victor heard: "The deck was fiction."

Eduardo clears his throat. “Perhaps we could see the fraud detection system. Mariana mentioned it was quite sophisticated.”

This, at least, exists — though “sophisticated” is generous. Sebastián navigates to the monitoring dashboard.

“Our AI-powered fraud detection analyzes transaction patterns in real-time—”

“AI-powered?” Victor interrupts. “What’s the underlying model? Random forest? Neural network? Something proprietary?”

In the back room, Diego and Camila exchange horrified glances. The “AI” is, of course, the Venezuelan contractors and their manual review process.

“It’s a hybrid approach,” Sebastián says carefully. “Machine learning combined with human verification for edge cases.”

“Can we see the model performance metrics? False positive rates, detection accuracy, latency?”

Sebastián looks at Isabella. Isabella looks at Don Hernando. Don Hernando’s jaw is set like stone.

“We can provide those in a follow-up document,” Isabella says. “The real-time dashboard focuses on operational metrics rather than model internals.”

Victor writes something in his notebook. His expression is unreadable.

The Crash

2:47 PM.

They’re almost through. Sebastián has shown the remaining features, deflecting the hardest questions with promises of documentation and follow-up calls. The investors seem… not convinced, exactly, but not walking out either.

Eduardo checks his watch. “One final item. Could we see the reconciliation report? The daily summary of all transactions, as it would appear to a bank partner?”

“Of course.” Sebastián navigates to the reporting module. “This is where Pipe’s work really shines — he’s been in banking for fifteen years and designed this system to match exactly what traditional institutions expect.”

He clicks “Generate Report.”

The screen freezes.

Not the loading spinner — a complete freeze. The cursor doesn’t move. The timestamp in the corner stops updating. The entire interface is locked.

The screen froze. The room froze. Time itself seemed to stop.

“Technical difficulty,” Isabella says, her voice admirably steady. “Sebastián, perhaps try refreshing?”

Sebastián clicks. Nothing happens. He clicks again. The screen remains frozen.

In the back room, Diego is pulling up server logs, his face pale. “The database connection pool is exhausted. Every thread is locked waiting for a response that will never come.”

“Can you restart it?” Camila asks.

“Restarting means losing the demo session. They’d have to start over.”

“Do it.”

“It takes four minutes to reboot.”

Pipe appears behind them. “Move.” He shoulders Diego aside and starts typing commands that look like they belong in a museum. “The connection pool is hung on a legacy query — something in the reporting module that shouldn’t be running during a demo.”

“Can you kill it?”

“I can try.”

In the conference room, the silence has become unbearable. Don Hernando stands slowly.

“My apologies,” he says. “We appear to be experiencing—”

The screen flickers. Goes black. Then displays an error message in stark white text:

FATAL ERROR: Database connection timeout. Please contact system administrator.

“No.” The word rips out of Sebastián’s throat. “No, no, no, no —”

His face has gone the color of ash. His hands are shaking so violently that he knocks over his water glass, sending it shattering across the conference table. Isabella grabs his arm — whether to steady him or herself, she doesn’t know.

Patricia closes her notebook. Eduardo’s face is a mask of barely contained contempt. Victor is already standing.

“I think we’ve seen enough,” Eduardo says, and his voice is like a door slamming shut.

The Aftermath

3:15 PM.

The investors have retreated to a private conversation with Mariana in Don Hernando’s office. The door is closed. Laura stands guard outside, her face revealing nothing.

In the development area, the team sits in shell-shocked silence. Camila stares at her screen, where the error logs scroll endlessly. Diego has his head in his hands. Pipe is muttering a steady stream of profanities — hijo de puta, mierda, cabrón — his voice mixing Spanish curses with what might be COBOL commands.

Sebastián stands at the window, looking out at the Bogotá afternoon. His reflection is that of a man who has lost something important.

They had prepared for everything except the truth.

Stefan approaches him.

“This wasn’t your fault,” Stefan says.

“I’m the CTO. Everything technical is my fault.”

“The system failed because it was built on debt — technical debt, organizational debt, honesty debt. You inherited that debt. You didn’t create it.”

Sebastián turns. His eyes are red but dry. “I could have listened to you. Shown them what actually worked. Been honest about where we really are.”

“Yes.”

“Why didn’t I?”

“Because Don Hernando told you not to. And you still need his approval.” Stefan’s voice is gentle. “That’s not a criticism. It’s an observation. You’re still the co-founder who gave away his company because he didn’t want to fight.”

“And now I’ve lost it anyway.”

The office door opens. Don Hernando emerges, followed by the investors. His face is impossible to read.

Mariana approaches the development team. Her expression is… not angry, exactly. Something closer to resigned.

“The partners are returning to São Paulo tonight,” she says. “They’ll need time to discuss what they saw.”

“And?” Sebastián asks.

“And nothing is decided. But I won’t lie to you — it didn’t go well.” She pauses. “I argued for you. I reminded them of the leadership changes, the cleanup, the potential. But Victor was clear: he saw a platform that doesn’t work and a team that doesn’t know it.”

The words land like blows.

“We know it,” Diego says quietly. “We’ve always known it. We just weren’t allowed to say it.”

Mariana looks at him — really looks at him, seeing the returned developer for the first time.

“Then perhaps,” she says, “it’s time to start saying it.”

The Night After

Thursday, 11 PM.

The office is empty except for Stefan and Don Hernando. They sit in the old man’s office, a bottle of aguardiente between them that neither has touched.

“You were right,” Don Hernando says finally. “I should have listened.”

Stefan says nothing.

“My whole life, I’ve believed that you show strength by projecting success.” Don Hernando’s voice is thick, strange. His hands — those weathered hands that had built empires, broken horses, buried a son — are trembling. “On the ranch, you never let the workers see you doubt. In business, you never let investors see you struggle.”

He stops. A sound escapes him that might be a laugh or might be a sob.

“That philosophy built my fortune. And today…” His voice breaks. The old patriarch’s face crumples, and for a moment he looks every one of his seventy-three years. “Dios mío. Today it may have destroyed my son’s legacy. The only thing of Jorge’s I had left.”

"My philosophy built my fortune. And today it may have destroyed my son's legacy."

“Jorge would have told them the truth,” Stefan says.

Don Hernando looks up sharply. “How do you know that?”

“Because you told me. The son who argued with you. Who pushed back. Who wanted to build technology companies while you insisted on cattle.” Stefan meets the old man’s eyes. “He wouldn’t have demoed features that don’t exist. He would have shown them what he was actually building and made them believe in the vision.”

“And I would have called him naive.”

“And you would have been wrong.”

The silence stretches. Outside, the city hums with a million lives unaware of the small drama in this office.

“What happens now?” Don Hernando asks.

“Tomorrow, you call a team meeting. You take responsibility for the demo failure — not the technical failure, but the decision to show more than what existed. You acknowledge that the old approach isn’t working.” Stefan pauses. “And then you ask them what they would do differently.”

“You want me to take advice from developers?”

“I want you to listen to the people who actually build things. The way you never listened to Jorge.”

The name hangs in the air between them.

Don Hernando reaches for the aguardiente. He pours two glasses. He slides one to Stefan.

“To my son,” he says. “Who was right about everything, and never got to hear me say it.”

They drink in silence.

The Shadow

Somewhere in Bogotá. Midnight.

Alejo watches the video on his phone for the third time. The demo crash. The frozen screen. The investors’ faces as they realized what they were seeing.

His contact inside FinPulso — someone he’s cultivated for months — sent the footage twenty minutes ago. It’s not official. It’s not complete. But it’s enough.

In the ashes of their failure, Alejo saw opportunity.

He types a message to Marco:

Alejo The demo failed spectacularly. Investors are gone. The old man is vulnerable.

Marco And the MiPago timeline?

Alejo Accelerating. They'll be desperate now. A rescue offer will look like salvation.

Marco And you?

Alejo Patience. Let them burn a little longer. Then I'll return with the solution to every problem I helped create.

Marco Elegant.

Alejo It always is.

He puts down the phone and pours himself a whiskey. The first battle was lost. But the war is far from over.

And in the ashes of FinPulso’s public humiliation, Alejandro Vega sees exactly the opportunity he’s been waiting for.

Next Episode: "Cenizas" In the aftermath of the demo disaster, the investors demand answers and the board convenes. Stefan presents his findings: a 90-day recovery plan built on continuous delivery principles. But the real revelation comes from Camila, whose secret project might be the only thing that can save FinPulso. If anyone is willing to listen to the junior developer no one noticed.

Grace Hopper: The Compiler That Changed Everything

2026-01-21T00:00:00+01:00

She Made Machines Understand Words

21.01.2026, By Stephan Schwab

Before Grace Hopper, programming meant thinking in binary. Her invention of the compiler didn't just make programming easier — it made programming possible for everyone who wasn't a mathematician. The abstraction she pioneered remains the foundation of every line of code written today.

The Problem Nobody Wanted to Solve

"They told her computers could only do arithmetic. She proved they could understand language."

In 1952, programming a computer meant writing sequences of numbers. Machine code. Ones and zeros, or if you were lucky, hexadecimal values that represented ones and zeros slightly more compactly. Every instruction, every memory address, every calculation — numbers.

The programmers of that era were mathematicians. They had to be. The cognitive overhead of translating human intent into numeric sequences required a particular kind of mind. Most people looked at programming and saw an impenetrable wall.

Grace Hopper looked at the same wall and asked a different question: Why should humans learn to think like machines when we could teach machines to understand humans?

Her colleagues thought she was crazy. Computers do arithmetic, they said. You can’t make a computer understand words. The machine doesn’t know English.

She built it anyway.

The A-0 System: Proof That Abstractions Work

"The first compiler wasn't elegant. It was proof that the impossible was merely difficult."

In 1952, Hopper created the A-0 System for the UNIVAC I. It wasn’t pretty. It wasn’t fast. What it did was revolutionary: it took mathematical notation that humans could read and translated it into machine code that computers could execute.

A compiler. The first one. The concept that you could write in one language and have a machine automatically translate it to another.

The reaction from the computing establishment was predictable. They didn’t believe her. For three years, she demonstrated her compiler and was told it couldn’t work — while they watched it work. The resistance wasn’t technical. It was psychological. Programmers had invested enormous effort in learning to think in machine code. They had made themselves indispensable through an arcane skill. A compiler threatened that position.

Sound familiar?

From A-0 to FLOW-MATIC to COBOL

"She didn't just want programmers to understand code. She wanted business people to read it."

Hopper wasn’t satisfied with making programming easier for mathematicians. She wanted to make it accessible to business people who needed to solve business problems.

In 1958, she led the team that created FLOW-MATIC, the first programming language to use English-like syntax. Not mathematical notation. Actual words. COMPARE, TRANSFER, MULTIPLY. Instructions that a business manager could read and understand.

The computing priesthood was horrified. Real programmers don’t use English, they insisted. This will make programming too easy. It will let the wrong people in.

Hopper’s response was characteristic: “It is easier to ask forgiveness than it is to get permission.” She built it anyway. FLOW-MATIC directly influenced COBOL, which by 1970 was the most widely used programming language in the world.

Billions of lines of COBOL are still running today. In banks. In insurance companies. In government systems. Code written in a language designed to be readable by non-programmers, still processing transactions sixty years later.

The Abstraction That Keeps Giving

"Every high-level language you use today exists because she proved abstractions don't make you weak — they make you powerful."

The compiler was more than a tool. It was a proof of concept. It demonstrated that abstraction — hiding complexity behind simpler interfaces — was not just possible but essential for the growth of computing.

Every programming language you use today exists because Grace Hopper proved that machines could translate human-readable code into machine instructions. Python, JavaScript, Rust, Go — all of them depend on compilers or interpreters that trace their conceptual lineage back to A-0.

The principle extends beyond languages. Every framework that hides complexity. Every library that provides a simpler interface to a harder problem. Every API that abstracts away implementation details. They all embody the same insight: humans shouldn’t have to think like machines.

When someone tells you that “real programmers” don’t use frameworks, or that you should understand everything happening at the machine level before you’re allowed to use higher-level tools, they’re echoing the same resistance that Hopper faced in 1952. The gatekeeping hasn’t changed. Only the abstraction layer being defended has shifted.

The Organizational Insight

"She taught us that the hardest problems in computing aren't technical — they're about convincing humans to change."

Hopper’s three years of demonstrating a working compiler to people who insisted it couldn’t work tells us something important. The barriers to progress in software are rarely technical. The A-0 compiler worked. The resistance was human.

This pattern repeats constantly. Test-driven development works. Continuous integration works. Trunk-based development works. The evidence is overwhelming. Yet organizations resist, not because the techniques don’t work, but because adopting them requires changing how people think about their work.

Hopper didn’t just build a compiler. She spent years evangelizing the concept, demonstrating it, convincing skeptics one by one. The technical achievement was necessary but not sufficient. The human work — changing minds, overcoming institutional inertia — was equally important.

Permission and Forgiveness

Her famous quote — “It is easier to ask forgiveness than it is to get permission” — wasn’t about being reckless. It was about recognizing that gatekeepers often protect their positions rather than the organization’s interests. Sometimes the only way to prove something works is to build it and show results.

This doesn’t mean ignoring legitimate concerns. It means recognizing when “concerns” are actually fear of change dressed in technical language. Hopper’s compiler didn’t threaten the machines. It threatened the monopoly of a small group of specialists.

Every time someone tells you that your approach won’t work — without trying it — ask yourself whether they’re protecting technical integrity or professional territory. The answer is usually obvious.

The Standard That Emerges

"Standards emerge from working code, not committee meetings."

COBOL became a standard not because a committee decreed it, but because FLOW-MATIC and similar languages demonstrated the value of the approach. The standard followed the practice, not the other way around.

Hopper understood this. She built working systems first. The standardization — COBOL, developed by a committee she participated in — came after the concept had proven itself in production. The standard codified what worked, rather than specifying what might work theoretically.

This remains good advice. Build something that works. Demonstrate value. Let the standard emerge from practice. The alternative — designing standards before implementation — produces specifications that satisfy committee politics but fail in reality.

What She Teaches Us

Grace Hopper’s contribution to software development wasn’t just the compiler. It was the demonstration that:

Abstraction is strength, not weakness. Every layer of abstraction that hides complexity and exposes simpler interfaces makes software more accessible and more powerful.

Working code beats theoretical arguments. Three years of demonstrating a working compiler eventually overcame resistance that no amount of argument could have defeated.

Gatekeeping is about power, not quality. The people who insist that programming should remain difficult are protecting their position, not the craft.

Standards follow practice. Build what works, prove its value, and the standard will emerge.

Human change is harder than technical change. The compiler was the easy part. Convincing the industry to use it was the real work.

The next time you use a high-level programming language — any of them — you’re building on the foundation Grace Hopper laid in 1952. Not just technically, but conceptually. She proved that we don’t have to think like machines. We can teach machines to understand us instead.

That insight changed everything.

Iterative Design: What Software Can Learn from Rockets

2026-01-19T00:00:00+01:00

When Rockets Teach Software Teams Humility

19.01.2026, By Stephan Schwab

SpaceX builds rockets the way great software teams build software — through rapid iteration, learning from failure, and relentless focus on the feedback loop. Their approach to hardware development offers powerful lessons for software organizations stuck in analysis paralysis or waterfall thinking. When you can afford to test your assumptions quickly, you discover reality faster than any planning document ever could.

The Starship Philosophy

"If you're not blowing things up, you're not iterating fast enough."

SpaceX’s Starship program has become legendary for its approach to development. Rather than spending decades perfecting designs on paper before building anything, they build prototypes rapidly, test them to destruction, learn from the failures, and build the next version. The graveyard of exploded Starship prototypes at Boca Chica isn’t a record of failure — it’s a record of learning at unprecedented speed.

Traditional aerospace operates differently. The Space Launch System took over a decade of development before its first flight, with engineers attempting to anticipate every possible problem through analysis and simulation. The result was a rocket that cost billions more and flew years later than planned.

SpaceX’s philosophy inverts this. Build something. Test it. Watch what breaks. Fix it. Repeat.

The Cost of Learning

"The only way to validate assumptions is through reality, not spreadsheets."

What makes SpaceX’s approach possible is a deliberate focus on reducing the cost of each iteration. When building a prototype costs less and takes less time, you can afford more iterations. More iterations mean faster learning. Faster learning means reaching your destination sooner.

This principle transfers directly to software development. Teams that can deploy changes quickly learn faster than teams that bundle weeks of work into massive releases. The team deploying ten times a day gets ten opportunities to observe reality. The team deploying monthly gets one.

But reducing iteration cost requires investment. SpaceX built their own factories, developed their own manufacturing techniques, and vertically integrated their supply chain — all to make each iteration cheaper and faster. Software teams need similar investments: automated testing, continuous integration, feature flags, observability infrastructure. These aren’t optional improvements; they’re the foundation that makes rapid learning possible. The connection between technical practices and business results becomes clear when you see iteration capability as a strategic asset.

Embracing Productive Failure

"Every failure that teaches you something is more valuable than success that teaches you nothing."

The first Starship orbital test flight ended in an explosion. SpaceX called it a success. This wasn’t spin — they meant it. The vehicle cleared the launch tower, demonstrated the unprecedented coordination of 33 engines firing simultaneously, gathered telemetry data no simulation could provide, and revealed exactly where the design needed improvement.

Compare this to organizations where failure is punished. Teams hide problems. Experiments become career risks. Learning grinds to a halt because no one can afford to be wrong. The irony is that these organizations, in their pursuit of perfection, become far less capable than organizations that embrace productive failure.

Software teams need the same relationship with failure. A bug that escapes to production isn’t just a problem to fix — it’s information about where your testing was inadequate, where your assumptions were wrong, where your system behaves differently than you expected. Organizations that treat every production incident as a learning opportunity improve faster than those that treat incidents as occasions for blame.

The Prototype Mindset

"The best way to learn what you need to build is to build something and discover why it's wrong."

SpaceX builds prototypes expecting them to be replaced. Early Starship prototypes were explicitly designated as test articles, not flight vehicles. This mindset — building something to learn, not to keep — enables a kind of freedom that perfectionism never allows.

Software developers often resist this approach. We want our code to be permanent, our architectures to be final, our solutions to be complete. But this desire for permanence creates its own problems: over-engineering, analysis paralysis, and the fear of starting because we might have to throw it away.

The prototype mindset liberates teams. Build the simplest thing that could possibly work. Deploy it. Watch real users interact with it. Discover the requirements you never knew you had. Then build the next version with that knowledge.

This doesn’t mean building garbage. SpaceX prototypes are sophisticated engineering achievements. But they’re built with the understanding that learning is the primary goal, and that learning will reveal what the next version needs to become. This connects to a deeper truth: software development is itself a design discipline, where discovery and iteration are fundamental to the craft.

Testing in the Real Environment

Rockets can be simulated extensively, but there’s no substitute for actual flight. The interactions between thousands of components, the stresses of actual launch conditions, the behavior of propellants in real tanks — these reveal themselves fully only through real testing.

SpaceX takes this principle seriously. They test at their launch site in conditions as close to actual flight as possible. When they can’t test the full system, they test subsystems in realistic conditions. Every piece of real-world data improves their models and reduces uncertainty.

"Your staging environment is a hypothesis. Production is reality."

Software teams often miss this lesson. They test in environments that barely resemble production. They validate features with fictional data that doesn’t reflect real usage patterns. They simulate load conditions that don’t match actual traffic. Then they’re surprised when production reveals problems their testing never caught.

True iterative design requires testing against reality as early and as often as possible. This means production-like test environments, real data (appropriately anonymized), actual user behavior, and production deployments that provide genuine feedback about how your software performs in the world.

The Vertical Integration Decision

SpaceX made an early strategic decision to build most components themselves rather than relying on traditional aerospace suppliers. This wasn’t arrogance — it was recognition that iteration speed depends on controlling the entire feedback loop.

When a design change requires renegotiating contracts with external suppliers, iteration slows to the pace of procurement. When you build it yourself, you can change it tomorrow. SpaceX’s vertical integration enables experimentation that would be impossible with a fragmented supply chain.

Software organizations face similar choices. Heavy reliance on external vendors, rigid enterprise contracts, and outsourced development can make iteration prohibitively slow. Each design change requires approvals, negotiations, and handoffs that consume weeks or months.

This doesn’t mean building everything yourself — that’s often impractical. But it means being intentional about where you need iteration speed and structuring your technology organization to enable it. Core differentiating capabilities often need to be owned internally. Commodity functions can be outsourced without sacrificing agility.

Rapid Feedback and Organizational Learning

SpaceX’s approach works because the organization is structured to learn from each iteration. Engineers who designed a component watch the test, analyze the failure, and design the improvement. The feedback loop is tight, the people are close to the problem, and decisions can be made quickly.

"Distance from the problem is distance from the solution."

Contrast this with organizations where development teams hand off to testing teams who file reports that go to different teams who eventually plan fixes that get prioritized by yet another team. Each handoff introduces delay, loses context, and dilutes learning.

The most effective software organizations keep teams close to their work. The developers who build a feature monitor it in production, respond to incidents, and observe how users actually use it. This proximity creates learning loops that no process document can replicate.

Beyond Move Fast and Break Things

SpaceX’s iterative approach is often misunderstood as recklessness. It’s the opposite. Every test is instrumented. Every failure is analyzed. Every lesson is incorporated into the next design. The speed comes not from carelessness but from systematic investment in making each iteration cheaper and more informative.

“Move fast and break things” became a problematic mantra because it was interpreted as permission to be sloppy. SpaceX moves fast and breaks things — very expensive things — but they do so with engineering discipline that ensures each broken thing teaches maximum lessons.

Software teams seeking faster iteration need the same discipline. Comprehensive observability so you know what happened. Feature flags so you can limit blast radius. Automated rollbacks so recovery is fast. Thorough post-incident analysis so learning is captured. Speed without these safeguards is just chaos.

The Compounding Returns of Iteration

"Every iteration improves not just the product, but your ability to iterate."

SpaceX’s current iteration speed is the result of years of investment in iteration capability. Each rocket they built taught them how to build rockets faster. Each factory they constructed taught them how to construct factories more efficiently. The learning compounds.

Software organizations experience the same compounding — or its absence. Teams that invest in deployment automation, testing infrastructure, and observability get faster with each iteration. Teams that defer these investments find each iteration harder than the last, buried under the accumulated friction of manual processes and technical debt.

The choice of whether to invest in iteration capability is the choice of whether learning will accelerate or stagnate. SpaceX chose acceleration. Successful software organizations make the same choice.

When Analysis Actually Matters

Iterative design doesn’t mean abandoning thought for action. SpaceX performs sophisticated analysis, simulation, and planning. But they use analysis to guide experiments, not to replace them. They simulate to identify risks, then test to verify whether the risks are real.

The failure mode of traditional organizations is using analysis to defer action indefinitely. There’s always another study to conduct, another risk to evaluate, another stakeholder to consult. Action requires certainty, and certainty never arrives.

The failure mode of naive iteration is action without reflection. Building the same wrong thing repeatedly, faster and faster. Speed without direction.

Effective iterative design balances both. Analyze enough to form a hypothesis. Build enough to test the hypothesis. Observe closely enough to learn from the test. Repeat.

Lessons for Software Leaders

SpaceX’s hardware development offers software leaders several actionable insights:

Invest in iteration infrastructure. The ability to iterate quickly is itself a capability that requires investment. Automated testing, continuous deployment, feature flags, and observability aren’t overhead — they’re the foundation of learning.

Embrace productive failure. Create environments where teams can experiment, fail, and learn without career risk. Celebrate the lessons learned from failures, not just the successes.

Keep teams close to their work. Minimize handoffs and organizational distance between those who build software and those who observe its behavior in production.

Reduce the cost of each experiment. When experiments are cheap, you can run more of them. More experiments mean faster learning.

Use analysis to guide experiments, not replace them. Think carefully about what you’re trying to learn, then build something to test your thinking.

The rocket scientists at SpaceX have demonstrated that even the most complex hardware can be developed iteratively. Software, which can be deployed in seconds rather than months, has even more potential for rapid learning. The question is whether organizations will embrace it.

When "Developer Advocate" Meant Something Else

2026-01-16T00:00:00+01:00

The Sticker Distributor

16.01.2026, By Stephan Schwab

The term "Developer Advocate" has drifted from a senior technical authority to a marketing function, much like "Agile Coach" before it. We explore why this shift happened, the gap it left in the boardroom, and why we define the role strictly as a senior engineer who advocates for the internal team against executive fantasy.

When I introduce myself as a “Developer Advocate,” I often get a specific look. It’s a mix of anticipation and calculation. The person across the table—usually a conference organizer or a community manager—is silently wondering: Do you have stickers? Do you have budget for pizza? Can you sponsor our hackathon?

I have to disappoint them. I don’t have stickers. I don’t have a marketing budget. I have a deep concern about the fact that your deployment pipeline takes 45 minutes and fails randomly, and I am here to advocate for the team that has to suffer through it.

Somewhere in the last fifteen years, we lost the definition of this role. It drifted from “Senior Engineer who protects the ecosystem” to “Charismatic person who generates leads.” And just like the term “Agile Coach,” the commoditization of the title has left a vacuum where technical authority used to be.

The Stolen Title

"An Evangelist takes the product to the world. An Advocate takes the world to the product."

There was a brief, golden era—mostly pioneered by companies like Google and Mozilla around 2010—where a Developer Advocate was a terrifyingly technical role.

In those days, the distinction between “Evangelist” and “Advocate” was precise. An Evangelist (a term inherited from Guy Kawasaki’s Apple days) was outbound. They brought the Good News from the specific mountain of the vendor down to the masses.

An Advocate was inbound. They were “Customer Zero.” They were senior engineers who tried to build real applications with the platform, found where it was broken, and had the internal political capital to march into the product manager’s office and say, “This API is garbage. We cannot ship this.”

They advocated for the developer to the company.

Then the “API Economy” exploded. Twilio, Stripe, SendGrid, and a thousand venture-backed SaaS tools needed to acquire users. The “Developer Advocate” role was absorbed into the “Top of the Funnel” machinery. Reporting lines shifted from the CTO to the CMO. The KPI changed from “SDK quality” to “Sign-ups.”

The “Advocate” became a friendly face who generates excitement, not a senior engineer who generates friction.

The Agile Coach Parable

"If you cannot read the code, you cannot coach the team."

We have seen this erosion of technical meaning before. It is the exact tragedy of the “Agile Coach.”

If you go back to the origins of Extreme Programming (XP) in the late 90s, the “Coach” (as defined by Kent Beck) was a master practitioner. They sat next to you. They pair-programmed. They saw you write a test after the code and corrected you. They saw you skip refactoring and stopped you. They were a technical mentor who taught the craft of software delivery.

Then came the certification industrial complex. Scrum replaced XP. “Scrum Masters” replaced Technical Coaches. We decided that you didn’t need to know how to code to “facilitate the process.”

Today, an “Agile Coach” is often a therapist for organizational dysfunction—someone who manages the Jira board, facilitates “Retrospectives” that result in zero action, and talks about “psychological safety” while the team drowns in technical debt.

The title remained. The competence was hollowed out.

The Incentive to Dilute

Why does this semantic drift happen? Why do powerful, technical roles inevitably degrade into soft-skill support roles?

The driving force is the conflict between competence and scale.

First, scaling excellence is impossible. It is incredibly difficult to find a Senior Staff Engineer who is also a brilliant communicator and willing to spend half their time analyzing organizational dysfunction. It is much easier to hire a junior “growth hacker” or a non-technical manager and give them a title that sounds authoritative.

Second, competence creates friction. A true technical advocate who says “This architecture will collapse under load” is an obstacle to a manager who just wants to mark the project as “Green”. A coach who focuses on “team feelings” is far less threatening to the status quo than one who points out that the code is untestable.

The industry systematically removes the “hard” (technical) requirements from these roles to make them easier to fill and easier to manage. In doing so, it removes the very thing that made them valuable: the bite.

The Boardroom Gap

Why does this matter? Because the removal of the Internal Advocate has left a dangerous gap in our organizations.

When the “Developer Advocate” is outside giving talks, and the “Agile Coach” is managing tickets, who is left to tell the truth to the executives?

Who has the mandate to tell the CEO: “Your deadline is fantasy because we have no automated tests”? Who tells the CTO: “We are bleeding talent because our legacy architecture is unworkable”? Who advocates for the internal development team against the pressure of the business?

This is the gap we are reclaiming.

Integrating the Role

When we use the term “Developer Advocate” in our consulting, we are returning to the original, stricter definition.

"We advocate for the engineering reality against executive fantasy."

It means a Senior Developer who:

Is Embedded: Sits with the team, shares the pain, and experiences the friction of the daily work.
Has Authority: Reports to leadership but acts on behalf of the engineers.
Ships Code: Does not just talk about “best practices” but demonstrates them in the repository.

You can call it “Embedded Advocacy” or “Technical Authority” if you prefer. But the function is non-negotiable. You cannot fix a software organization from the outside. You have to be in the code, feeling the heat, to know which fire to put out first.

We don’t have stickers. But we can help you ship on Friday.

Fantasmas del Sprint

2026-01-15T00:00:00+01:00

Previously: "Los Secretos del Código" — Stefan discovers evidence of financial fraud in the production logs. Diego makes contact with a proposition to return. In a midnight conversation, Sebastián finally tells Don Hernando the truth about Alejo's betrayal.

The Gathering Storm

FinPulso boardroom. 8:47 AM.

The boardroom has never felt smaller.

Don Hernando sits at the head of the table, his weathered hands flat on the mahogany surface. To his left, Sebastián clutches a folder of printed evidence — Isabella’s documentation, Stefan’s technical findings, screenshots of Alejo’s encrypted conversations with Marco.

To Don Hernando’s right, the chair is empty. Alejo hasn’t arrived.

On the wall-mounted screen, Mariana Ríos watches from São Paulo. Her video connection is crisp, her expression unreadable. She joined the call at exactly 8:30, asked no preliminary questions, and has been waiting in silence ever since.

The empty chair spoke louder than any words.

Stefan stands by the window, technically not invited but also not dismissed. He’s here as a witness — and possibly as protection.

“He’s late,” Sebastián says, breaking the silence.

“He’s calculating.” Don Hernando’s voice is flat. “Deciding which story to tell.”

The door opens.

Alejo enters wearing his most expensive suit — Italian, navy, perfectly tailored. His smile is bright and warm, completely disconnected from the tension in the room.

“My apologies for the delay. Traffic from Rosales was impossible.” He takes his seat, adjusting his cuffs. “Shall we begin?”

The Counter-Attack

Sebastián presents the evidence methodically, just as Stefan coached him the night before. The falsified metrics. The altered code. The term sheet with MiPago. The intercepted messages between Alejo and Marco.

Alejo listens without interrupting. His expression shifts from polite attention to studied concern to something that might be sorrow.

When Sebastián finishes, the silence stretches.

“May I respond?” Alejo’s voice is gentle, almost wounded.

“That’s why you’re here.” Don Hernando’s eyes are hard.

Alejo stands, straightening his jacket as if preparing for a pitch. “First, let me say that I understand why Sebastián believes what he believes. He’s been under tremendous pressure. We all have. And when people are stressed, they look for villains.”

He walks to the window, forcing Stefan to step aside.

“The metrics adjustment he mentioned? That was my attempt to correct a counting error that underreported our performance. I informed the board at the time that we were revising our methodology. Perhaps the communication wasn’t clear enough.”

“You multiplied transaction counts by 1.5,” Sebastián says. “That’s not a methodology revision.”

“It’s a weighted average that accounts for transaction value, not just volume. Standard practice in fintech reporting.” Alejo’s smile doesn’t waver. “I have the industry benchmarks if you’d like to review them.”

On the screen, Mariana leans forward. “And the term sheet with MiPago?”

“Exploratory. Preliminary. The kind of strategic conversation any responsible CFO should be having.” Alejo spreads his hands. “I never hid that I was exploring partnership opportunities. The board authorized me to assess strategic options.”

“You authorized yourself,” Don Hernando says quietly.

“I informed you I was having conversations. You said, and I quote, ‘Handle it.’” Alejo turns to face the old man. “I was handling it. For you. For the company. For all of us.”

"When people are stressed, they look for villains."

Stefan watches the performance with grim recognition. He’s seen this before — the confident reframing, the strategic partial truths, the way an experienced manipulator can make the accuser look like the aggressor.

“And the messages with Marco Benedetti?” Mariana asks. “Discussing timelines for the MiPago deal?”

Alejo’s smile tightens almost imperceptibly. “Where did you obtain those messages?”

“That’s not relevant—”

“It’s extremely relevant. If someone is intercepting private communications between board members and external consultants, that’s a serious breach.” He looks at Stefan. “Perhaps our German guest can explain his surveillance methods?”

Stefan says nothing.

“I see.” Alejo nods slowly, as if confirming a suspicion. “So this entire proceeding is based on illegally obtained evidence presented by an outside consultant with no authority and no accountability?” He turns to Mariana. “Is this how we conduct governance now?”

The Unsent Letter

Flashback: Four months earlier. Diego’s apartment, 2:37 AM.

Diego stares at the email draft on his screen. The subject line reads: I can’t do this anymore.

His desk is a disaster zone — energy drink cans, cold empanadas wrapped in paper, a stress ball he’s squeezed into misshapen oblivion. Three monitors display the production logs he’s been watching for eighteen hours straight.

The incident started at 8 PM the previous night. A payment processing error that affected 12,000 transactions. The kind of bug that shouldn’t have happened if anyone had listened to him about the technical debt three months ago.

But they didn’t listen. They never listen.

Sebastián (11 PM) Any update? The board is meeting tomorrow and I need to report the status.

Sebastián (11:47 PM) Diego?

Sebastián (12:22 AM) I know you're online. The error logs show you're still working.

Sebastián (1:15 AM) Please respond. Don Hernando is asking.

Diego ignored every message. He was too deep in the code, too focused on the fix that would save everyone’s reputation while destroying his nervous system.

The unsent letter was the truest thing he'd written in months.

Now, at 2:37 AM, the immediate crisis is resolved. The fix is deployed. The transactions are reprocessing. By morning, it will look like nothing ever happened.

And Diego is writing his resignation letter.

I’m writing this at 2 AM, which is apparently when I do my most honest thinking.

This is the fourth production emergency this month. Each one was preventable. I documented the risks in my Technical Risk Assessment (attached again, in case you lost it). I begged for two weeks to add test coverage. I was told there was no time.

There’s never time for quality. There’s always time for emergencies.

I have been on-call for 47 consecutive days. My average weekly hours since September are 73. I have missed my mother’s birthday, my cousin’s wedding, and three appointments with a therapist I started seeing because I can’t sleep anymore.

But the worst part isn’t the hours. It’s the pretending.

Every sprint review, we demo features that don’t actually work. Every investor meeting, we show slides with numbers we know are inflated. Every board meeting, I watch Alejo present a version of reality that has no connection to what’s actually in production.

And everyone knows. Sebastián knows. Isabella knows. Even Don Hernando, in his gut, knows something is wrong. But no one says anything because saying something means admitting we’re in trouble.

I can’t pretend anymore.

I have attached evidence of specific discrepancies. I know this might be career suicide, but I’d rather be unemployed than complicit.

— Diego

He reads it three times. His finger hovers over the send button.

Then his phone buzzes. A message from Luciana.

Luciana Still at office? I'm at Marco's event. It's amazing. You should come.

Luciana Wait, are you still working? At this hour?

Diego Production issue. Fixed now.

Luciana You work too much, mi amor. Marco says your company doesn't appreciate you. He says in Europe developers are treated like artists.

Diego Marco says a lot of things.

Luciana He's actually really smart. You should talk to him sometime. He has ideas about how to fix your agile problems.

Diego I have to go. I'll call you tomorrow.

Luciana ❤️

Diego looks at the resignation letter. At the evidence he’s compiled. At the messages from Sebastián asking for status updates at midnight.

He selects all. He deletes.

Then he opens a new document and starts a fresh Technical Risk Assessment — the third one this quarter. The professional version. The one that says everything in language no one will understand, attached to emails no one will read.

He saves the draft of the resignation letter to a hidden folder. Insurance, he tells himself. For later.

The Debugging Nightmare

"This isn't sustainable. Every 'minor fix' breaks something else."

Flashback: Three months earlier. A late-night debugging session.

Diego stares at the error logs scrolling across his screen. It’s 1:47 AM, and the payment processing module has been throwing intermittent timeouts for three hours. The team deployed a “minor fix” yesterday afternoon — Sebastián called it “non-disruptive” — but now transactions are failing at random intervals.

Pipe is beside him, his face illuminated by the glow of his own monitor. At 44, Pipe has seen this before. Too many times.

“The connection pool is exhausted,” Pipe mutters. “Look at this — the queries aren’t releasing connections properly. We patched the auth module last week, but we didn’t test the integration.”

Diego traces the code path, his fingers flying over the keyboard. “The patch added a new validation step. It should be closing the connection, but…” He runs a test query. “It’s hanging. The database thinks the connection is still active.”

Pipe leans back, rubbing his eyes. “We need to rollback the patch. But Sebastián wants the auth feature live for tomorrow’s demo.”

“Demo or production? We can’t have both.” Diego’s voice is sharp, exhaustion making him blunt. “This isn’t sustainable. Every ‘minor fix’ breaks something else. We need proper testing, not duct-tape deployments.”

Pipe says nothing. He knows Diego is right. But he also knows the cycle — pressure from above, compromises from below, disasters in the middle of the night.

Diego pushes the fix live at 2:15 AM. The timeouts stop. The demo will work. For now.

But as he watches the green status indicators, he knows this is just another ghost in the machine. Another sprint that haunts the codebase.

The Pivoting Patriarch

Present day. The boardroom.

The argument has shifted. Alejo, sensing advantage, is now questioning the entire basis of the investigation.

“Let me understand,” he says, his voice dripping with reasonableness. “Stefan Richter — a contractor with no equity, no board seat, no formal authority — has been conducting surveillance on company executives. He’s been accessing production systems using credentials obtained from… where, exactly?”

Stefan’s face remains impassive.

“And based on this unauthorized surveillance, he and Sebastián have compiled a dossier of accusations against me — the CFO who has kept this company solvent through three near-death experiences.” Alejo shakes his head. “If anyone should be investigated, it’s not me.”

“The evidence speaks for itself,” Sebastián says, but his voice has lost its confidence.

“Evidence obtained illegally. Evidence interpreted by someone with a financial interest in finding problems.” Alejo turns to Don Hernando. “You brought me in because you wanted professional management. Real governance. And now, because I did my job too well — because I found efficiencies and built relationships and positioned us for growth — I’m being treated like a criminal.”

Don Hernando has been silent for five minutes. His face reveals nothing.

“Tell me about Jorge,” he says finally.

The question catches everyone off guard. Alejo’s smile flickers.

“I’m sorry?”

“My son. Jorge. You reminded me of him — that’s why I trusted you.” Don Hernando’s voice is soft, almost gentle. “But Jorge would never have hidden things from me. Jorge would never have positioned himself for personal gain at the family’s expense. Jorge would never have looked me in the eye and lied.”

"Jorge would never have looked me in the eye and lied."

“With respect, Don Hernando, I’m not your son. And this comparison—”

“You’re right. You’re not my son.” The old man stands, slowly, his hands on the table. “My son was honest. Sometimes painfully so. He told me things I didn’t want to hear. He pushed back when I was wrong. He died before I could tell him I was proud of him.”

The room is very quiet.

“You told me what I wanted to hear. You made problems disappear before I knew they existed. You surrounded me with comfort and called it competence.” Don Hernando’s voice drops. “That’s not loyalty, Alejo. That’s manipulation.”

“I was protecting you—”

“You were protecting yourself.” Don Hernando picks up one of the printed screenshots — Alejo’s message to Marco about the MiPago timeline. “This is dated before you had any authorization to negotiate. Before we discussed strategic options. Before you ‘informed’ me of anything.”

Alejo’s composure cracks, just slightly. “That document is—”

“Real. Authentic. Incriminating.” Mariana’s voice cuts through from São Paulo. “I’ve had my team verify the metadata. It’s genuine.”

When They Still Had Each Other

Flashback: Five months earlier. Diego’s apartment, 2 AM.

"You're here now."

Diego unlocked his apartment door as quietly as he could, laptop bag weighing down his shoulder. Another production emergency, another all-nighter. He was exhausted, wired on coffee, ready to collapse.

The lights were off, but he could see Luciana in their bed, her silhouette outlined by the city lights filtering through the window. She’d waited up — he could tell by the book on the nightstand, still open.

“Lo siento,” he whispered, setting down his bag. “Production issue. I texted but—”

“I know.” Her voice was soft, not angry. She sat up, sheet pooling around her waist. She was wearing his old conference t-shirt, the fabric thin and worn. “You’re here now.”

“I need to shower, I smell like—”

“I don’t care.” She reached for him, pulling him down to the bed. Her hands found the buttons of his shirt, working them open with practiced ease. “You work too hard, Diego.”

“The system was down, users were—”

“Shh.” She kissed him, silencing the excuses. Her lips were warm, familiar. Her hands pushed his shirt off his shoulders, traced the tension knotted in his back. “They can wait until morning. Right now, you’re mine.”

He kissed her back, letting the stress drain away. This was what mattered. This woman who knew him, who waited for him, who still wanted him even when he came home smelling of stale coffee and midnight panic.

They made love slowly, quietly, her body warm against his, her breath in his ear whispering his name. Afterward, she curled into him, her head on his chest.

“I miss you,” she murmured.

“I’m right here.”

“No. I miss you. The you who used to take me dancing. Who laughed. Who didn’t check his phone during dinner.” Her fingers traced patterns on his skin. “I’m losing you to that company.”

“It won’t always be like this. After the funding, after we stabilize—”

“There’s always an after.” She kissed his shoulder. “Just… don’t forget there’s a life outside the code. Don’t forget me.”

“Never,” he promised.

But he was already thinking about the deployment schedule. Already mentally reviewing the fix he’d just pushed. Already half-gone.

He didn’t notice when her hand stopped moving. Didn’t see the resignation in her eyes.

The Night Diego Saw

Flashback: Three months earlier. Andrés Carne de Res restaurant.

Diego didn’t want to come. Work dinners exhausted him — the forced camaraderie, the drinking he couldn’t keep up with, the endless small talk about things he didn’t care about.

But it was Sebastián’s birthday, and Luciana insisted.

“You never come out anymore,” she’d said that morning. “People are starting to talk.”

“Let them talk.”

“Diego.” She touched his face. “I love that you’re dedicated. But you need to live too. Just one night. For me.”

So he came. He dressed in his least-faded jeans and a shirt without band logos. He smiled when people made jokes he didn’t find funny. He nursed the same beer for two hours while watching Luciana dance to cumbia with Isabella and Laura.

She was beautiful. She was always beautiful. And lately, she’d seemed distant — distracted by something she wouldn’t name.

He told himself the distance was work stress. He told himself a lot of things.

Around 11 PM, Diego stepped outside for air. The restaurant sprawled across multiple buildings, interconnected by paths lined with folk art and recycled sculptures. He wandered toward a quieter patio, away from the noise.

That’s when he saw them.

Not the tentative brush of new lovers, but the desperate hunger of people who'd done this before.

Luciana and Marco, pressed against the wall of a corner alcove designed for privacy. Marco’s hands were on her waist, pulling her close. Her fingers tangled in his hair. They were kissing — not the tentative brush of new lovers, but the desperate hunger of people who’d done this before.

Marco’s mouth moved to her neck. Luciana’s head tilted back, exposing her throat, a soft sound escaping her lips that Diego couldn’t hear but could imagine. Marco’s hands slid lower, possessive, and she arched into him.

The world went red.

Diego’s glass slipped from his fingers and shattered on the decorated concrete, but he didn’t hear it. Couldn’t hear anything over the roaring in his ears. His chest seized — a physical pain, like someone had reached in and squeezed his heart until it cracked. His stomach twisted, bile rising. He wanted to scream. He wanted to charge at them, rip Marco away, demand answers.

But his body wouldn’t move. He stood frozen, forced to watch his girlfriend — the woman he’d been planning to propose to, the woman he’d neglected while debugging at 3 AM — melt into another man’s arms.

Puta madre. All those late nights. All those “I’m just networking” excuses. All those times she said Marco was “just a colleague.” All those times she came home smelling different — perfume he hadn’t bought, wine he didn’t drink.

He’d been a fucking idiota. A blind, lovesick pendejo working himself to death while she was spreading her legs for a smooth-talking Italian parasite.

Marco noticed him first. He didn’t stop kissing Luciana’s neck, but his eyes met Diego’s over her shoulder. His expression shifted from surprise to something like amusement — the smug satisfaction of a man who’d won. He whispered something against Luciana’s skin, and she turned.

Her lipstick was smeared. Her dress was rumpled. Her hair fell loose from where Marco’s hands had pulled it free.

Their eyes met across twenty meters of decorated concrete.

The world went red.

Diego watched Luciana’s face cycle through emotions — shock, guilt, fear. She stepped away from Marco, smoothing her dress with trembling hands. Her mouth opened, closed. No words came out.

She didn’t run to him. Didn’t try to explain. Just stood there, caught, looking small and guilty and utterly fucking selfish.

Marco smiled and raised his glass in a mock toast. The arrogance. The casual cruelty.

“Hijo de puta,” Diego breathed. His hands were shaking. His vision blurred with tears he refused to let fall. His entire body felt like it was vibrating, rage and heartbreak colliding until he couldn’t tell them apart.

He wanted to destroy something. Someone. But instead, he turned and walked away. Because what was the point? She’d made her choice. She’d been making it for weeks, probably months, while he was too fucking stupid to see.

Diego walked back inside. His legs felt like they belonged to someone else. He found Sebastián, who was too drunk to notice anything wrong. He said he wasn’t feeling well. He took a taxi home.

He didn’t cry. He was too fucking exhausted for tears. Too hollowed out. Instead, he sat in the dark of his apartment, bottle of aguardiente in his lap, thinking about all the late nights he’d spent fixing problems while Luciana was… where? In Marco’s bed? Laughing at him?

“Mierda,” he whispered to the empty room. “Mierda mierda mierda.”

At 3 AM, he opened the hidden folder with his unsent resignation letter. He read it again.

This time, he didn’t delete it. His hands were steady now — the cold steadiness of a man who had nothing left to lose. He added a new paragraph:

P.S. — The company culture that allows code fraud also allows personal betrayal. When you treat people as resources to be optimized rather than humans to be valued, you shouldn’t be surprised when they treat each other the same way.

I’m done being a resource.

He still didn’t send it. But he started building his exit — documenting everything, creating backups, installing the monitoring that would let him watch from outside.

Two weeks later, he stopped coming to the office.

The Verdict

Present day.

The board meeting has lasted three hours. Coffee has been ordered and ignored. Alejo has tried every defense — procedural objections, character attacks, threats of legal action.

None of it worked.

Mariana speaks first. “Based on the evidence presented, I’m calling for an immediate vote to remove Alejandro Vega as CFO and from the board of directors.”

“You don’t have authority to—”

“I represent 40% of this company’s equity, Mr. Vega. I have exactly the authority our shareholders’ agreement gives me.” Her voice is cold. “Don Hernando?”

The old man nods. “I vote in favor.”

“Sebastián?”

“In favor.”

“That’s a majority.” Mariana’s image on the screen doesn’t change, but there’s satisfaction in her voice. “Mr. Vega, your access to company systems will be revoked within the hour. You have 48 hours to collect personal belongings from your office. We’ll discuss severance terms through lawyers.”

Alejo is very still. When he speaks, his voice has lost its charm.

“You’re making a mistake. This company needs me more than you know. The relationships I’ve built, the investors I’ve cultivated—”

“Will be informed of the circumstances of your departure.” Mariana cuts him off. “I suggest you focus on your legal exposure rather than making threats.”

Even in defeat, Alejo's eyes were planning.

Alejo looks at each of them — Don Hernando, Sebastián, Stefan, the screen where Mariana watches.

“This isn’t over,” he says quietly. Then he walks out, his Italian shoes clicking on the floor.

The door closes behind him.

Don Hernando exhales slowly. “Now we rebuild.”

The Return

The next morning. FinPulso office.

The atmosphere is strange — equal parts relief and uncertainty. Word has spread that Alejo is gone, but no one knows the full story. Rumors multiply.

Stefan is at his usual corner desk when the elevator opens.

Diego walks in.

He looks different than the photos — thinner, his beard trimmed, dark circles still visible but somehow less pronounced. He carries a laptop bag over one shoulder and pauses at the entrance, taking in the office he hasn’t seen in three months.

Camila notices first. Her face lights up with something between surprise and joy. She half-rises from her desk, then catches herself, uncertain of the protocol.

Pipe looks up, his expression cycling from shock to suspicion to cautious hope.

The prodigal developer returns.

Sebastián emerges from his office. “Diego.” His voice cracks slightly. “You came.”

“You asked.” Diego walks toward the development area. “And Camila’s been sending me her code for review. Did you know she’s building a complete rebuild of the payment processing module?”

“I… no, I didn’t know that.”

“It’s better than what we have in production. Better architecture. Better tests. Better everything.” Diego sets his bag down at an empty desk. “I’m not back as an employee. Not yet. But Stefan and I talked, and I think I can help.”

Stefan nods once, a small acknowledgment.

“What do you need?” Sebastián asks.

“Coffee. A whiteboard. And an honest answer to one question.”

“Anything.”

Diego’s face is unreadable. “Why didn’t you read my reports? The real reason. Not the excuses you’ve been telling yourself.”

The question hangs in the air. Sebastián is silent for a long moment.

“Because I was scared,” he says finally. “Because if I read them — really read them — I’d have to admit that everything was broken. And I didn’t know how to fix it.” He meets Diego’s eyes. “I still don’t know. But I’m ready to try.”

Diego nods slowly. “That’s the first honest thing you’ve said to me in a year.”

The Ghosts We Carry

That evening. The rooftop terrace.

Stefan finds Diego standing at the railing, watching the Bogotá sunset paint the mountains in shades of orange and pink. The city sprawls below, indifferent to the small dramas of one fintech startup.

“You came back faster than I expected,” Stefan says.

“Camila’s project. I reviewed the code last night.” Diego doesn’t turn around. “It’s good. Really good. Better than anything I built when I was here.”

“She learned from your work.”

“She learned from my mistakes.” Diego finally turns. “The patterns she’s using — they’re the opposite of what I did. Smaller functions. More tests. Less cleverness, more clarity.” He almost smiles. “She figured out what I never could: that simple is harder than complex, but it’s worth it.”

"Simple is harder than complex, but it's worth it."

Stefan leans against the railing. “What happened wasn’t your fault. The conditions you worked in — they would have broken anyone.”

“Maybe.” Diego is quiet for a moment. “But I let it break me instead of breaking the conditions. I complained in emails no one read instead of refusing to deploy code that wasn’t ready. I burned out instead of setting boundaries.”

“You were young. And alone.”

“I was twenty-six. Old enough to know better.” Diego shakes his head. “The unsent resignation letter — I’ve read it a hundred times. Every word is true. But I never sent it because I was afraid of what would happen.”

“And now?”

“Now I’m not afraid anymore. Or maybe I’m afraid of different things.” Diego looks at Stefan. “I’m afraid of watching Camila make the same mistakes. I’m afraid of this company failing because no one tells the truth. I’m afraid of spending the rest of my life building beautiful systems that get destroyed by politics and ego.”

“Those are reasonable fears.”

“They’re not going away.” Diego straightens. “But I can work with them. And maybe this time, I can help build something that lasts.”

Stefan nods. “¿Y eso está en producción?”

Diego laughs — a genuine, unexpected sound. “Not yet. But it will be.”

The Weight of Tomorrow

FinPulso office. Night.

The office is mostly empty. Laura is the last to leave, as usual — she glances at the light still on in Don Hernando’s office but doesn’t disturb him. Some vigils are private.

In the development area, Camila works at her desk, headphones on, lost in code. Her private repository is open on her second monitor, but for the first time, she doesn’t feel the need to hide it. Diego reviewed it. Stefan approved it. Tomorrow, they’ll start planning the migration.

Sebastián is in his office, door open, staring at the wall where a whiteboard holds the beginnings of a recovery plan. His phone buzzes — a message from Isabella.

Isabella Heard Diego came back. Are you okay?

Sebastián I think so. Ask me again in a week.

Isabella I'm proud of you. For finally speaking up.

Sebastián It was too late. Diego warned me months ago.

Isabella It's never too late to start doing the right thing. That's the whole point.

He smiles at the phone, just slightly.

Tomorrow would bring new problems. But tonight, for the first time in months, the future felt possible.

In Suba, Diego sits in his apartment, surrounded by his servers and monitors, drafting an email to Pipe. An olive branch wrapped in technical questions — asking about the legacy systems, acknowledging that Pipe knows things no documentation captured.

And in a hotel bar in Zona Rosa, Alejo sits alone with a whiskey he’s barely touched. His phone shows a half-composed message to Marco, but he hasn’t sent it. He’s thinking. Planning. The first battle is lost, but the war isn’t over.

Tomorrow, the real work begins.

For everyone.

Next Episode: "El Demo Day" A major investor demo is just 48 hours away, and the platform must work. The war room atmosphere intensifies as the team races against time. But when Sebastián proposes radical honesty — showing what actually works and admitting what doesn't — Don Hernando refuses. Then the demo crashes. Live. In front of everyone.

Alan Turing: Defining Computation Before Computers Existed

2026-01-12T00:00:00+01:00

The Mind That Gave Machines Their Limits

12.01.2026, By Stephan Schwab

In 1936, before any programmable computer had been built, Alan Turing described a simple abstract machine that could compute anything computable. His paper "On Computable Numbers" didn't just solve a mathematical problem — it defined what computation itself means. Every program running today, from the simplest script to the most complex AI, operates within the boundaries Turing drew on paper with nothing but thought experiments.

A Question About Numbers

"We may compare a man in the process of computing a real number to a machine." — Alan Turing, 1936

Alan Mathison Turing was born in 1912 in London. By his early twenties, he was already grappling with one of the most profound questions in mathematics: the Entscheidungsproblem, or “decision problem,” posed by David Hilbert. Could there be a mechanical procedure that would determine, for any mathematical statement, whether it was provable or not?

To answer this question, Turing first had to define what “mechanical procedure” meant. His insight was to imagine the simplest possible machine that could still perform any calculation a human could perform. The result was what we now call the Turing machine: an abstract device with an infinite tape of symbols, a read/write head, and a finite set of rules determining what to do next based on the current symbol.

This imaginary machine wasn’t meant to be built. It was a thought experiment. Yet it captured something fundamental about the nature of computation itself.

Alan Turing at age 16

The Universal Machine

Turing’s most remarkable discovery wasn’t the machine itself — it was what he called the “universal machine.” He proved that a single Turing machine could simulate any other Turing machine if given a description of that machine as input. In other words, the same hardware could run any program.

"It is possible to invent a single machine which can be used to compute any computable sequence."

This is so obvious to us today that we struggle to see its revolutionary nature. Of course the same computer can run a word processor, a game, and a database — we just install different software. But before Turing, the assumption was that each type of calculation required its own specialized machine. Charles Babbage’s Analytical Engine was programmable — as Ada Lovelace recognized — but nobody had proven that a single design could handle all possible computations.

Turing proved exactly that. His universal machine is the theoretical ancestor of every general-purpose computer. The laptop, the smartphone, the cloud server — they are all physical implementations of Turing’s paper machine.

The Limits of Computation

Turing answered Hilbert’s question with a negative: no, there cannot be a general mechanical procedure to decide all mathematical statements. His proof introduced the halting problem — the demonstration that no algorithm can determine, for all possible programs and inputs, whether a given program will eventually stop or run forever.

This wasn’t a failure. It was a fundamental truth about the nature of computation. Some things simply cannot be computed, not because our machines are too weak, but because computation itself has inherent limits.

"There are things that cannot be computed. This is not an engineering limitation — it is mathematical certainty."

For software practitioners, this matters more than it might seem. Every time a program attempts to analyze another program’s behavior — whether for optimization, security scanning, or verification — it runs into walls that Turing identified in 1936. The halting problem isn’t academic trivia; it’s why we cannot write a perfect bug-finder, why code coverage doesn’t guarantee correctness, and why formal verification remains challenging.

Bletchley Park: Theory Meets Practice

When World War II began, Turing’s theoretical brilliance found urgent practical application. At Bletchley Park, he led the effort to decrypt messages encoded by the German Enigma machines. The work he did there saved countless lives and shortened the war by an estimated two years.

Turing designed the Bombe, an electromechanical device that could rapidly test possible Enigma settings. He also contributed to breaking the even more complex Lorenz cipher. This wasn’t merely applying theory — it was inventing new techniques under extreme pressure, combining mathematical insight with engineering pragmatism.

The secrecy surrounding Bletchley Park meant that Turing’s wartime contributions remained classified for decades. But the experience shaped his thinking about building actual computing machines.

After the War: Building Real Computers

After 1945, Turing worked on the design of actual stored-program computers. At the National Physical Laboratory, he wrote the first detailed design for a stored-program computer, the ACE (Automatic Computing Engine). Later, at the University of Manchester, he worked on programming the Manchester Mark 1, one of the world’s first true computers.

Turing wrote some of the earliest actual computer programs. He also wrote the first programming manual. The gap between his 1936 paper and these practical machines was remarkably small — his theoretical framework had been so precise that building physical implementations confirmed his predictions.

The Question of Machine Intelligence

In 1950, Turing published “Computing Machinery and Intelligence,” asking whether machines could think. Rather than debating definitions, he proposed a practical test: if a human conversing with a hidden machine couldn’t reliably distinguish it from another human, the machine should be considered intelligent.

"I propose to consider the question, 'Can machines think?'" — Alan Turing, 1950

The “Turing test” remains central to AI discussions today. Turing anticipated objections ranging from religious arguments to claims about consciousness, addressing each methodically. He predicted that by the year 2000, machines would be able to fool average interrogators about 30 percent of the time. Large language models have since surpassed that threshold, proving his intuition about the trajectory of artificial intelligence.

More importantly, Turing framed the question correctly. He didn’t ask whether machines “really” think in some metaphysical sense — he asked whether their behavior would become indistinguishable from human thought. That pragmatic framing continues to guide AI research.

Why Turing Matters to Software Practitioners

"Every program is a Turing machine. Every limit Turing found applies to what you build."

Turing gave software development its theoretical foundation. The Church-Turing thesis — the idea that any reasonable definition of computation is equivalent to what Turing machines can do — means that all programming languages are fundamentally equivalent in power. Python, JavaScript, C++, and assembly language can all compute exactly the same things.

This universality underlies everything we do. When we abstract away implementation details, when we trust that an algorithm will work regardless of hardware, when we believe that a correct program on one machine will be correct on another — we are relying on principles Turing established.

But Turing also gave us our limits. The halting problem tells us that perfect automated testing is impossible. The incompleteness of computation tells us that some problems cannot have algorithmic solutions. Understanding these limits helps us avoid chasing impossible goals and focus on what engineering can actually achieve.

A Life Cut Short

Alan Turing died in 1954 at age 41, after being prosecuted for homosexuality — then a criminal offense in Britain. He was subjected to chemical castration as an alternative to prison. His death was ruled a suicide, though some have questioned this conclusion.

The tragedy of his treatment has been widely acknowledged. In 2009, the British government issued a formal apology. In 2013, Queen Elizabeth II granted Turing a posthumous royal pardon. His face now appears on the British £50 note.

But the truest memorial to Turing is not official recognition — it is the billions of devices running software today. Every computation proves his ideas correct. Every program exists within the framework he defined.

The Foundation We Build On

We remember Alan Turing not for any single machine or program, but for defining computation itself. Before Turing, “computing” meant human calculators working through arithmetic. After Turing, we had a precise, mathematical definition of what any mechanical process could accomplish — and what it could never do.

Every developer writes programs that are Turing machines. Every algorithm operates within limits Turing proved. Every debate about AI capability starts from the questions Turing asked. The field of computer science exists because Turing showed that computation was worth studying as a subject in its own right.

Computation has boundaries. Turing drew them.

Treating Developers With Respect

2026-01-09T00:00:00+01:00

Why Professional Respect Drives Engineering Excellence

09.01.2026, By Stephan Schwab

Respect for software developers is not a perk — it is a prerequisite for building anything worth using. Most developers are introverts who have no interest in office politics; they simply want to solve problems well. Through rigorous practices like test-driven development, they often understand the business more deeply than anyone realizes. You cannot demand their best effort, but when they believe in the mission, they will give it freely. Organizations that treat this expertise with genuine respect get cleaner code, earlier problem detection, and innovation that no specification could capture.

There is a quiet epidemic in software organizations. Developers are hired for their expertise, then systematically excluded from the decisions that shape their work. They are expected to estimate tasks they had no part in defining, implement solutions designed by people who will never touch the code, and meet deadlines set without their input. Then, when things go wrong, they are asked what went wrong — as if they had been steering the ship all along.

This is not respect. This is using people as an extension of a keyboard.

"We hire smart people so they can tell us what to do." — Steve Jobs

The irony is visible in every frustrated executive who wonders why their teams lack initiative. You cannot hire expertise and then ignore it. You cannot recruit problem-solvers and then hand them solutions. The pattern defeats itself.

The cost of this pattern is enormous, but it rarely appears on any dashboard. It shows up in the best developers leaving for companies that value their judgment. It shows up in systems that technically work but are painful to change. It shows up in estimates that everyone knows are fiction but nobody is allowed to say so. And it shows up in the slow, grinding disengagement of people who once cared deeply about their craft.

What Respect Actually Means

Respect for developers does not mean giving them whatever they want. It does not mean avoiding hard conversations about priorities, deadlines, or trade-offs. It means something more fundamental: treating them as professionals whose perspective has value, whose time has limits, and whose expertise was acquired through years of deliberate practice.

Respect is not softness. It is honesty, inclusion, and the recognition that good judgment cannot be outsourced to a process.

In practice, this looks like:

Including developers in problem definition, not just solution delivery. The difference between a developer who understands why something matters and one who is handed a specification is the difference between engaged problem-solving and compliant implementation. Developers who understand the business context make better decisions at every level of the code.

Asking for estimates and listening to the answers. Many organizations have ritualized estimation into a performance where developers say numbers and managers nod, then set the actual deadlines based on other factors. This teaches developers that their judgment does not matter — a lesson they remember when asked to flag technical risks later.

Protecting focused time. Context switching is not a minor inconvenience for software development; it is an architecture-level problem. A developer interrupted four times in a morning does not lose four small blocks of time — they lose the ability to hold complex systems in their head long enough to reason about them. Organizations that respect this fact structure meetings, communication, and expectations accordingly.

Taking technical concerns seriously. When developers raise concerns about architecture, technical debt, or unrealistic timelines, they are not being obstructionist. They are offering information that most organizations desperately need and systematically ignore. The proper response is to understand the concern, weigh it against other factors, and make a decision — not to dismiss it as “not understanding the business.”

Understanding Who You Are Working With

Most software developers are introverts. This is not a stereotype — it is a consistent finding across decades of personality research in technical fields. Introversion is not shyness or social anxiety; it is a preference for depth over breadth, for thinking before speaking, for processing internally before expressing externally.

This has profound implications for how developers communicate, especially in meetings.

When an introvert speaks loudly in a meeting, they are not "finally engaging" — they are signaling that something has gone seriously wrong.

In a typical meeting, developers may appear quiet or disengaged. They are not. They are listening, evaluating, and forming views they may or may not share depending on whether the environment feels safe. When they do speak up forcefully — interrupting, raising their voice, or pushing back hard — it is rarely because they have suddenly become assertive. It is usually because they feel unheard, cornered, or witness to a decision so misguided they cannot stay silent.

Organizations that interpret this quietness as lack of opinion, and then interpret rare outspokenness as attitude problems, have the dynamic exactly backwards. The quiet is normal. The loud is a signal — often the last one before disengagement.

There is another trait worth understanding: most developers have little interest in controlling a narrative or playing office politics. They are not competing to be seen as the person with the best idea in the room. They are not angling for credit or positioning themselves for the next reorg. They simply want to solve the problem well and move on to the next one.

This disinterest in political maneuvering is often misread. Executives accustomed to environments where everyone is managing perception may assume developers are naive, or that their apparent indifference to optics means they do not care about outcomes. The opposite is true. Developers care intensely about outcomes — they just measure success by whether the system works, not by who gets credit for it.

When organizations treat this apolitical orientation as a weakness to exploit rather than a strength to protect, they poison the well. Developers who are forced into political games do not become better politicians; they become disengaged engineers.

This communication pattern and political disinterest are aspects of a deeper issue: many organizations do not invest in understanding the people who build their software.

The Asymmetry of Expertise

One of the strangest dynamics in software organizations is the asymmetry of expected understanding. Developers are frequently told they need to “understand the business” — as if they were somehow disconnected from it. But developers who practice test-driven development, who model business rules in code, who translate domain concepts into working systems — these developers often understand the business more deeply than anyone realizes.

The act of writing tests forces a developer to confront every edge case, every exception, every unstated assumption. What happens when a customer cancels mid-transaction? What if an account has multiple owners with different permissions? What does “expired” mean when the product crosses time zones? These are not technical questions. They are business questions that developers must answer precisely, in code, or the system fails.

Developers who model business rules in code often understand the domain more deeply than anyone realizes. Ask them what they have learned.

Organizations that encourage developers to “learn about the business” have it backwards. Developers who do rigorous work already know the business — often better than the people who handed them requirements. The question is whether anyone asks them what they have learned. The insight sitting in the heads of your development team is an untapped resource. They have seen where the specifications contradict themselves, where the edge cases reveal unstated policies, where the domain model breaks down under real conditions.

Yet this expertise is rarely solicited. Instead, developers are expected to absorb business context quietly and implement what they are told. The asymmetry runs in the wrong direction: developers are treated as consumers of business knowledge rather than contributors to it.

The reverse expectation is curiously absent as well. Executives and product managers are rarely expected to develop even a basic understanding of software development. Technical complexity is treated as someone else’s problem, a black box that should simply produce features on demand.

This double asymmetry creates a power imbalance that undermines respect. Developers must understand the business but are not asked for their insight; meanwhile, the organization’s fundamental assumptions about how software works remain unexamined. The relationship becomes extractive rather than collaborative.

The most effective organizations bridge this gap in both directions. Leaders learn enough about software development to ask good questions, recognize reasonable trade-offs, and understand why some things are harder than they appear. And they treat developers as sources of business insight, not just recipients of requirements. This does not require learning to code. It requires genuine curiosity and the humility to recognize that expertise deserves understanding, not just deployment.

When that curiosity is absent, small frictions accumulate into something more damaging.

The Cost of Disrespect

Disrespect rarely announces itself. It accumulates in small moments: the meeting where a developer’s concern was brushed aside, the deadline set without consultation, the architecture decision made by someone who will not maintain the result, the performance review that valued hours logged over problems solved.

Each incident is survivable. In aggregate, they create an environment where the best developers leave — not always for more money, but for organizations that value what they know. What remains is a workforce that has learned to protect themselves through compliance: do what is asked, no more and no less, and save your real thinking for somewhere it might matter.

This protective withdrawal becomes most visible when the organization needs something it cannot command.

You Cannot Demand What Must Be Given Freely

One of the clearest indicators of respect — or its absence — is how an organization handles crunch time. Every software project has moments of genuine urgency: a critical bug in production, a competitive deadline, an unexpected opportunity that requires fast movement. Developers understand this. They have been through it before.

You cannot demand overtime from developers. But when they believe in the mission, they will give it freely — often more than you would dare to ask.

Here is what organizations often fail to grasp: you cannot demand this kind of effort. You can require people to be present, but you cannot require them to bring their full capability, their creative problem-solving, their willingness to push through walls. That can only be given, and it is given when people believe the mission matters and that their contribution is valued.

Developers who respect their organization and feel respected in return will work weekends to ship something important. They will stay late to fix a critical issue. They will think about hard problems in the shower and arrive Monday with solutions. This is not because they are told to — it is because they care.

But extract that effort through pressure, guilt, or normalized overwork, and you get something that looks similar but is fundamentally different. You get hours logged, not problems solved. You get presence without engagement. And you burn through goodwill that takes years to rebuild.

This is the hidden cost of treating developers as resources rather than professionals: you get exactly what you measure and specify — and nothing beyond. The small improvements, the edge cases caught early, the architectural foresight that prevents next year’s crisis: these come from people who care, and caring requires a reason.

Organizations that struggle with software delivery often look for process solutions: better project management, more detailed specifications, tighter controls. Sometimes these help. But often the problem is simpler and harder to fix. The people who build the software have stopped believing that their judgment matters, and they are acting accordingly.

The good news is that this dynamic can be reversed — not through slogans, but through structure.

Building a Culture of Respect

Changing this pattern requires structural changes that demonstrate, through repeated experience, that developer expertise is valued.

Involve developers early. When a new initiative is being shaped, include developers in the conversation before the solution is determined. Their early input often prevents expensive mistakes and creates ownership that no amount of later explanation can replicate.

Make estimates meaningful. If developers provide estimates, treat those estimates as real information. If deadlines must be set differently, be honest about why — and acknowledge that the gap between estimate and deadline represents risk the organization is choosing to accept.

Protect deep work. Audit how developers actually spend their time. If the best engineers are spending more time in meetings than in focused development, something is structurally wrong. Consider meeting-free days, async-first communication, and expectations that protect rather than fragment attention.

Create real feedback loops. Developers should see what happens when their software reaches users. This is not about blame when things go wrong — it is about connection between effort and outcome. When developers see real usage data and user behavior, their decisions become better informed and more motivated.

Take technical concerns seriously. When developers raise concerns about technical debt, complexity, or timeline risk, treat these as valuable business intelligence. You may still decide to proceed as planned, but the decision should be explicit and informed — not a reflexive dismissal.

The Payoff

Organizations that genuinely respect their developers do not just retain talent better — they get different results. Code is cleaner because developers take pride in their work. Problems are flagged earlier because raising concerns is rewarded, not punished. Innovation happens naturally because people are engaged enough to see opportunities that no specification would capture.

This is not idealism. It is practical recognition that software development is knowledge work performed by humans, and those humans respond to how they are treated. Respect is not a cost center. It is the foundation of every system that works well and keeps working.

The question for any organization is simple: are you treating your developers as professionals whose judgment you value, or as sophisticated keyboards you are trying to operate more efficiently? The answer shows up in the software — eventually, it shows up everywhere.

A Personal Note

I was born in late 1968. When Borland released Turbo Pascal in 1983, I was fourteen years old and already teaching week-long classroom courses to adults — professionals who struggled to grasp basic programming concepts that seemed obvious to me. These were intelligent people, successful in their own fields, sitting in a room being taught by a teenager.

Nobody questioned whether I understood the material. What mattered was whether I could help them understand it.

Software has always been like this. Expertise in this field does not correlate with age, seniority, or organizational rank. A twenty-three-year-old developer may understand a system better than the executive who commissioned it. A junior hire may spot the flaw that senior architects missed. The person closest to the code often knows things that the person furthest from it cannot see.

Organizations that respect developers understand this. They do not assume that hierarchy equals insight. They ask questions of people who have answers, regardless of title or tenure. And they recognize that in a field where a teenager can teach adults, the traditional markers of authority may not apply.

Respect the expertise. It does not always come from where you expect.

Los Secretos del Código

2026-01-08T00:00:00+01:00

Previously: "La Nueva" — Stefan Richter arrives in Bogotá and begins asking questions no one wants to answer. He discovers Camila's secret project, and Don Hernando confronts Alejo about his unauthorized negotiations.

The Email That Shouldn’t Exist

FinPulso office. Day 3. 6:47 AM.

Stefan arrives before dawn, as is his habit. The office is empty except for the security guard, who nods and returns to his phone. The cleaning crew finished an hour ago. The coffee machine hasn’t been started.

He settles at the desk he’s claimed — a corner position with sight lines to both the entrance and the development area — and opens his laptop. The leather notebook sits beside him, already filling with observations.

One new email. Personal account, not corporate. No sender name, just an alphanumeric string that will probably resolve to a disposable service.

Subject: You asked the right questions.

He opens it.

"You asked the right questions."

The credentials you need are below. They’ll work for 72 hours, then rotate automatically. Don’t waste time.

Production SSH: [redacted] Database read-only: [redacted] Logging dashboard: [redacted]

Start with the transaction logs from October 15th. Compare what the board saw to what actually happened.

And Stefan — the Venezuelan team isn’t the real problem. Follow the money.

— D

Stefan reads it twice. Then a third time.

He pulls up the terminal. Hesitates for exactly three seconds — long enough to acknowledge that using anonymous credentials could end his engagement immediately — then enters the SSH command.

The connection establishes. A Linux prompt blinks at him.

He’s in production.

What the Board Never Saw

The FinPulso production environment is not what the architecture diagrams suggested.

Stefan spends the first hour simply mapping what exists versus what was documented. The discrepancies fill two pages of his notebook:

Three services listed as “deprecated” are still handling live traffic
The payment processing module runs on a server that should have been decommissioned in August
Database backups exist, but the restore process has never been tested
The “AI fraud detection” service is actually a Node.js wrapper that forwards requests to an external API — which then forwards them to the Venezuelan contractors

This last discovery is almost elegant in its deception. Anyone auditing the code would see calls to a legitimate-looking AI service. They’d have to trace the network traffic to discover it terminates in Maracaibo.

But Diego’s email said this wasn’t the real problem.

Stefan navigates to the transaction logs from October 15th. This was the date of the board meeting where Don Hernando presented the quarterly metrics — user growth, transaction volume, the numbers that justified the company’s valuation.

The logs tell a different story.

The board presentation claimed 47,000 successful transactions. The logs show 31,000.

The board presentation claimed 47,000 successful transactions in October. The logs show 31,000. The presentation showed a 12% growth rate. The actual rate was 3%.

Stefan checks the git history for the reporting module. Someone modified the calculation logic on October 14th — one day before the board meeting. The commit message says “Bug fix: transaction counting.” The actual change multiplies certain transaction types by 1.5.

The commit author: A. Vega.

Alejo.

Stefan sits back. His coffee has gone cold. The office is still empty, but soon the others will arrive.

He has evidence of fraud. Not the gentle fraud of the fake AI — that’s embarrassing but fixable. This is financial fraud. Misrepresenting metrics to investors. The kind that ends careers and starts lawsuits.

The question is: who else knows?

The Morning After

By 9 AM, the office has filled with its usual cast. Pipe is at his desk, headphones on, pretending the world doesn’t exist. Camila is reviewing code, her private repository open on a separate browser tab she minimizes when anyone walks by. Isabella arrived at 8:30, looking like she didn’t sleep.

Sebastián doesn’t come in until 10.

Stefan watches them all, his notebook closed now, the evidence locked behind mental compartments. He needs to understand the relationships before he acts. Who is complicit? Who is a victim? Who can be trusted?

Laura brings him coffee without being asked. She lingers for a moment.

“You were here early,” she says. It’s not a question.

“I keep farmer’s hours.”

“So did Don Hernando, once.” She sets down the cup. “He’s coming in at noon. He wants a progress report.”

“I’ll have something for him.”

Laura hesitates. She’s deciding something. Stefan waits.

“Be careful,” she says finally. “In this company… not everyone wants the problems found.”

"In this company... not everyone wants the problems found."

She leaves before he can respond.

The Accounting Anomaly

Stefan finds Isabella in the small kitchen, staring at the coffee machine like it holds the secrets of the universe.

"There's no such thing as off the record here. But ask anyway."

“May I ask you something? Off the record.”

She turns. Her eyes are red-rimmed but sharp. “There’s no such thing as off the record here. But ask anyway.”

“The October board presentation. The transaction numbers. Were you involved in preparing them?”

Isabella’s expression flickers. Fear, then anger, then something like relief.

“Why are you asking?”

“Because I found the logs. And I found the commit that changed the calculations.” Stefan keeps his voice low. “And I need to know if this was Alejo alone, or if—”

“It wasn’t me.” The words come fast. “I found the discrepancy two weeks after the board meeting. I brought it to Sebastián. He said he’d handle it.”

“And did he?”

“He talked to Alejo. Alejo said it was a temporary bug, already fixed. Sebastián believed him.” She laughs bitterly. “Sebastián believes everyone. It’s his best and worst quality.”

“Did you believe Alejo?”

Isabella is quiet for a long moment. Then she pulls out her phone and shows Stefan a folder labeled “Insurance.”

“I’ve been documenting his activities for three months.” Her voice drops to barely a whisper, but her hands are shaking. “The inflated metrics. The consulting fees to Marco that don’t match any deliverables. The conversations with MiPago that predate any board authorization.”

She meets Stefan’s eyes, and hers are burning — fierce, exhausted, vindicated all at once.

“Every goddamn thing that made my skin crawl, I wrote down. Every lie that kept me awake at night.” Her jaw tightens. “I was waiting for someone who could actually do something with it. Someone the old man might actually believe instead of dismissing as ‘the girl from Kennedy who doesn’t understand business.’”

“Why not go to Don Hernando directly?”

“Because Don Hernando loves Alejo like a son. And I’m just the product manager — the girl from Kennedy who doesn’t understand how business really works.” The bitterness in her voice is old, calcified. “I needed evidence. And I needed someone the old man would believe.”

Stefan considers this. “Show me what you have.”

The Document

They meet in the Innovation Lab — the same glass-walled room where Camila showed Stefan her secret project. Isabella closes the blinds.

Her documentation is meticulous. Spreadsheets comparing reported metrics to actual data. Screenshots of Slack conversations where Alejo pressures developers to “optimize” the numbers. Bank statements showing payments to Marco’s consulting company that far exceed his billed hours.

And one document that makes Stefan pause.

“What is this?”

“I don’t know. I found it on a shared drive that Alejo thought was private.” Isabella pulls it up. “It’s a term sheet. For a merger with MiPago.”

Don Hernando's equity would be diluted to insignificance. Alejo would receive a $2 million "retention bonus."

The document is dated three months ago. It shows FinPulso being acquired for $8 million — barely half of the Series A valuation. Don Hernando’s equity would be diluted to insignificance. Alejo, however, would receive a $2 million “retention bonus” and the title of CEO of the combined entity.

“He was going to sell the company out from under everyone,” Stefan says.

“He was going to sell Don Hernando’s legacy for a personal payout.” Isabella’s voice is cold. “The old man put eight million dollars of his own money into this. Money that was supposed to be his son’s inheritance.”

Stefan thinks of the conversation in the boardroom, of Don Hernando’s face when he confronted Alejo about the MiPago negotiations. The old man had suspected. But this document shows the scale of the betrayal.

“Does Sebastián know about this?”

“Not the term sheet. I was afraid…” She stops.

“Afraid of what?”

“Afraid he’d try to handle it himself. Confront Alejo directly. And Alejo would destroy him.” Isabella looks at the document on the screen. “Sebastián isn’t a fighter. He’s a dreamer. He thinks everyone is basically good. He can’t comprehend someone doing this deliberately.”

The door to the Innovation Lab opens.

Sebastián stands in the doorway, his face pale.

“I heard my name,” he says quietly. “And I think it’s time someone explained what’s actually happening in my company.”

The Dreamer Awakens

They tell him everything.

Stefan presents the technical evidence — the falsified metrics, the altered code, the hidden commit. Isabella shows her documentation — three months of careful observation, of suspicions confirmed. Together, they paint a picture of systematic betrayal.

Sebastián listens in silence. His hands are shaking, but his voice is steady when he finally speaks.

“I knew Alejo was ambitious. I knew he wanted more control. But I thought…” He stops. Swallows. “I thought we were building something together. I thought when he pushed back on my ideas, it was because he saw risks I didn’t.”

“He saw opportunities,” Isabella says. “Just not for the company.”

“And Diego?” Sebastián looks at Stefan. “Did he know? Is that why he left?”

Stefan thinks of the email, the credentials, the message about following the money. Diego didn’t just know — he tried to warn them.

“I believe Diego documented many of these issues in a report he sent you. Four months ago.”

Sebastián’s face goes gray. “The Technical Risk Assessment. I read it. I thought it was about architecture problems. Technical debt. I didn’t understand…” He puts his head in his hands. “I didn’t want to understand.”

"I didn't want to understand."

Stefan lets the silence settle. Then: “The question is what you do now. Mariana returns in eleven days. You can present this evidence to Don Hernando, to the board. Remove Alejo before he does more damage. Or—”

“Or?” Sebastián looks up.

“Or you can stay silent. Let Alejo continue. Hope he finds another way out that doesn’t involve burning everything down.”

“That’s not really a choice.”

“No. It isn’t.” Stefan closes his notebook. “But it has to be your decision. Don Hernando trusts you. If this comes from me, it’s an outsider attacking a family member. If it comes from you — the co-founder, the CTO, the person who built the first prototype — it’s something else.”

“It’s a son telling his father he was betrayed by someone he loved.”

The words hang in the air. Sebastián stands slowly.

“I need to talk to Diego first. I need to understand why he didn’t come to me with this.”

“He did come to you,” Isabella says gently. “You just weren’t ready to hear it.”

The Contact

Sebastián walks to the rooftop — the real one, not the party terrace. The December rain has stopped, but the concrete is still wet, the sky still gray. He pulls out his phone and sends a message to the unknown number from weeks ago.

"I read your report again. All of it this time. I understand now."

Sebastián I read your report again. All of it this time. I understand now.

Sebastián I'm sorry.

Sebastián Can we talk?

The response comes faster than he expected.

Unknown Same coffee shop where we used to go. Tonight, 8pm. Come alone.

Sebastián How do I know this is really you?

Unknown You still owe me 15,000 pesos from the last time we played pool. You scratched on the eight ball and claimed the table was crooked.

Sebastián It WAS crooked.

Unknown It wasn't. Tonight.

Sebastián almost smiles. It’s the first time in weeks.

Afternoon Maneuvers

Don Hernando arrives at noon as announced. He spends an hour in his office with Laura, reviewing schedules and correspondence. Then he calls for Stefan.

“Close the door.”

Stefan complies.

“My people tell me you were in the office at dawn. Alone.” Don Hernando’s eyes are sharp beneath their weathered lids. “Working on what?”

“Understanding your systems.”

“And what have you understood?”

Stefan considers his options. He could present the evidence now — the falsified metrics, Alejo’s betrayal. But Isabella was right: it needs to come from Sebastián. The family dynamics matter more than the facts.

“I’ve understood that your technology problems are symptoms, not causes. The real disease is organizational.”

Don Hernando grunts. “I didn’t need a German consultant to tell me my people are broken.”

“Your people aren’t broken. Your trust was misplaced.” Stefan meets the old man’s gaze. “You surrounded yourself with people who told you what you wanted to hear. Diego tried to tell you the truth, and he was dismissed. Camila has solutions, but no one asks her opinion. Sebastián has vision, but no authority.”

“And Alejo?”

“Alejo tells you what you want to hear.”

"You surrounded yourself with people who told you what you wanted to hear."

The silence stretches. Don Hernando’s jaw works.

“My wife used to say that about my son,” he says finally. “That I never listened until it was too late.” He turns to the window, looking out at the gray Bogotá afternoon. “Jorge wanted to build technology companies. I told him it was a waste of his education. I told him to learn the cattle business first, then play with his computers.” His voice is rough. “He died before I could admit I was wrong.”

Stefan says nothing. Some confessions require only a witness.

“I invested in FinPulso because of Sebastián,” Don Hernando continues. “He reminded me of Jorge. The passion. The belief that technology could change things. I thought — maybe this time, I could support instead of dismiss.”

“And instead you took control.”

“Because I was afraid.” The old man turns back. “Afraid they would fail. Afraid I would lose another son’s dream.” He laughs bitterly. “So I put Alejo in place to protect my investment. And Alejo…”

“Alejo is protecting something else.”

Don Hernando nods slowly. “I’m beginning to see that.” He sits heavily in his chair. “What would you recommend?”

“A conversation with your co-founder. Tonight, if possible. And then — depending on what he tells you — some difficult decisions.”

The Coffee Shop

8 PM. A small café near the Universidad Nacional, far from Chapinero’s startup scene.

Sebastián arrives early. The place is nearly empty — a few students with laptops, an old man reading El Tiempo, a bored barista. He orders a tinto and takes a table in the back, facing the door.

Diego appears at 8:07. He’s thinner than before, his beard longer, his eyes wary. He scans the room before approaching.

“You came alone.”

“You asked me to.” Sebastián stands, unsure whether to embrace him or shake hands. In the end, they do neither — just stand awkwardly until Diego sits.

“You look like hell,” Diego says.

“You look like you’re living in a bunker.”

“Close. An apartment in Suba. I have servers in the living room. My landlord thinks I’m mining cryptocurrency.”

“Are you?”

“A little. It pays the rent.” Diego signals the barista. “And keeps me connected to FinPulso’s systems.”

Sebastián blinks. “You still have access?”

“I built back doors before I left. Insurance.” Diego’s tinto arrives. He wraps his hands around the cup. “I knew something was wrong. I just didn’t know how wrong until I could watch from the outside.”

“The credentials you sent Stefan — that was you?”

“Who else? The Venezuelan team doesn’t know production exists. Pipe doesn’t have clearance. And Camila…” Diego pauses. “Camila’s too smart to get her hands dirty. She’s building something clean instead.”

“You know about her project?”

“I’ve been reviewing her commits. Anonymously.” For the first time, Diego almost smiles. “She’s good, Sebastián. Really good. Better than me, in some ways. She learned from books and videos what it took me years to figure out. And she didn’t have anyone teaching her bad habits.”

“Why didn’t you tell me about Alejo? Not the technical stuff — the financial fraud. The MiPago deal.”

Diego’s face hardens. “I tried. The risk assessment I sent you — there was a section about ‘financial anomalies.’ Revenue projections that didn’t match transaction logs. Consulting expenses that seemed inflated. I was careful because I didn’t have proof, just patterns.”

“I didn’t read that section.”

“I know. You told me it was ‘too detailed’ and asked me to summarize.”

The words hit Sebastián like a physical blow. He remembers that conversation. He was stressed about a product demo. He was tired. He told Diego to bottom-line it, and Diego said something about “concerning patterns,” and Sebastián said they’d look at it after the demo, and the demo came and went and he never followed up.

“I failed you,” Sebastián says.

“You failed yourself.” Diego’s voice is flat. “You gave away your company because you didn’t want to deal with the hard parts. You made Don Hernando CEO because it was easier than pushing back on his ego. You let Alejo handle the finances because numbers bored you. And when I showed you evidence that something was wrong, you asked me to summarize so you wouldn’t have to think about it.”

“That’s not—” Sebastián stops. It’s exactly fair.

“I didn’t leave because of Luciana,” Diego continues. “That hurt, but I could have survived it. I left because I couldn’t watch anymore. I couldn’t keep building something beautiful and watch it get corrupted by people who saw it as a vehicle for their own ambitions.”

“And now?”

Diego takes a long drink of his coffee. “Now I have evidence. Real evidence, not just patterns. Bank records. Email archives. The term sheet Alejo thought he’d deleted.” He looks at Sebastián. “Enough to destroy him.”

“Or enough to save FinPulso?”

“Enough to destroy him. Or enough to save FinPulso. Maybe both.”

"Enough to destroy him. Or enough to save FinPulso. Maybe both."

The Proposition

“I want to come back,” Diego says. “Not as an employee — not yet. As a consultant, like Stefan. Someone with defined scope and an exit clause.”

“You’d work with Stefan?”

“He’s the real thing. I’ve been watching how he operates. He asks questions instead of giving answers. He respects the people doing the work. And he’s not afraid of Don Hernando, which is more than I can say for anyone else in that office.”

“What would you do?”

“Help Camila finish her rebuild. Migrate the production systems properly — not the cowboy deployments we were doing before. Document everything so that when I leave again, I’m not the only one who knows how things work.” Diego pauses. “And testify, if it comes to that.”

“Testify?”

“If Mariana decides to pursue legal action against Alejo. If there’s a board investigation. Someone needs to explain what happened from a technical perspective. How the metrics were falsified. Where the money went.” Diego’s jaw tightens. “I have logs of every commit, every deployment, every time someone accessed the financial systems. I can prove exactly who did what and when.”

Sebastián stares at his friend. “You planned this.”

“I’ve had nothing but time to plan. Three months of watching, waiting, hoping someone would finally see what I saw.” Diego leans forward. “You’re not a bad person, Sebastián. You’re just conflict-avoidant. You wanted to build something beautiful, and you assumed everyone else wanted the same thing. Now you know they don’t.”

“What happens next?”

“You talk to Don Hernando. You show him Isabella’s evidence and mine. You convince him that Alejo has to go before Mariana comes back — because if the board discovers this first, it’s not just Alejo who’s finished. It’s everyone.”

“Including Don Hernando.”

“Especially Don Hernando. He’s the one who trusted Alejo. He’s the one who signed off on the reports. If this looks like a cover-up instead of a clean break, the liability falls on him.”

Sebastián is silent for a long time. The café has emptied around them. The barista is wiping down tables, pointedly not looking in their direction.

“I have to tell him tonight,” Sebastián says finally.

“Yes.”

“He’s going to be devastated.”

“Better devastated than destroyed.” Diego stands, leaving money on the table. “Call me after you talk to him. And Sebastián—”

“Yes?”

“Thank you for finally listening.”

"Thank you for finally listening."

The Midnight Conversation

Don Hernando’s home is a penthouse in Rosales, purchased when he decided that commuting from the Llanos was no longer practical. The doorman knows Sebastián — the young man has been here many times for strategy dinners and Sunday coffees.

Tonight, there is no dinner. Just two men and a bottle of aguardiente that neither really drinks.

Sebastián presents everything. Isabella’s documentation. Stefan’s technical findings. Diego’s logs. The term sheet that would have stripped Don Hernando of his legacy.

The old man listens without interrupting. His face is stone, but his hands — wrapped around the glass he never lifts — tremble.

When Sebastián finishes, the silence stretches.

“I loved him like a son,” Don Hernando says finally. “I saw Jorge in him — the ambition, the intelligence, the hunger. I thought…” He stops. Breathes. “I thought I was getting a second chance.”

“I’m sorry.”

“Don’t be sorry for telling me the truth. Be sorry that it took so long.” Don Hernando sets down his untouched glass. “What do you recommend?”

Sebastián has thought about this all the way from the café. “Emergency board meeting. Tomorrow, if Mariana can join by video. Present the evidence. Remove Alejo as CFO and from the board. Offer him a quiet exit in exchange for not pursuing charges.”

“You want to let him walk away?”

“I want to save the company. A public legal battle destroys us regardless of outcome. We lose Mariana’s confidence, we lose our remaining runway, we lose whatever trust the team has left.” Sebastián meets Don Hernando’s eyes. “Alejo wins if we let him burn it down. The only victory is building something real in spite of what he did.”

The old man is quiet for a long moment. Then he nods.

“Call the board meeting. I’ll handle Mariana personally.” He stands, suddenly looking every one of his fifty-eight years. “And Sebastián — the German. Stefan. He’s earned his fee.”

"Tomorrow we clean house. And then we build."

“He’s barely started.”

“He showed me the truth no one else would speak. In my world, that’s worth more than all the management consulting in Bogotá.” Don Hernando walks to the window, looking out at the city lights. “Tomorrow we clean house. And then we build.”

The Night Watch

Midnight. Somewhere in Suba.

Diego sits in his apartment, surrounded by humming servers and the blue glow of multiple monitors. One screen shows FinPulso’s production logs. Another shows Alejo’s email — a tap Diego installed months ago and never removed.

A new message appears in Alejo’s inbox. From Marco Benedetti.

Marco Heard rumors of problems at the office. Everything okay?

Alejo Being handled. The German is asking questions but has no authority.

Marco And the old man?

Alejo Still trusts me. These ranchers — loyalty blinds them.

Marco The MiPago timeline?

Alejo Moving forward. Next week I'll push for a "strategic review" with the board. Frame it as fiduciary responsibility. By the time they realize what's happening, the term sheet will be signed.

Marco Excellent. Drinks Friday to celebrate?

Alejo After this is done, drinks in Milan.

Diego screenshots the conversation, adds it to his archive, and opens a new message to Stefan.

Diego New evidence. Alejo thinks he still has time.

Diego He doesn't.

He hits send, leans back in his chair, and watches the screens glow.

The game isn't over. But for the first time in months, the right people are finally playing.

The game isn’t over. But for the first time in months, the right people are finally playing.

Next Episode: "Fantasmas del Sprint" The emergency board meeting explodes. Alejo fights back with accusations of his own. And a series of flashbacks reveals what really happened in the months before Diego disappeared — the burnout, the impossible expectations, and the night everything fell apart.

We Don't Take Advice From Non-Developers

2026-01-06T00:00:00+01:00

The Astrophysics of Software

06.01.2026, By Stephan Schwab

When critical decisions about software development are shaped by those who've never written production code, organizations pay a recurring tax: failed projects, departed talent, and developers who learn the new framework vocabulary while joking about it in the parking lot. The most effective organizations ensure that technical decisions are informed by genuine technical expertise.

The Scene That Says It All

There’s a memorable moment in the 1998 film Armageddon where military officials and NASA scientists debate how to stop an asteroid from destroying Earth. A general insists that the president’s scientific advisors believe a nuclear blast could change the asteroid’s trajectory. Dr. Ronald Quincy, a British NASA scientist introduced as “pretty much the smartest man on the planet,” delivers a devastating response:

“I know the president’s chief scientific advisor. We were at MIT together. And in a situation like this, you really don’t want to take the advice of a man who got a C-minus in astrophysics.”

"The problem isn't that non-experts have opinions. The problem is when organizations treat uninformed opinions as equivalent to informed expertise."

The scene resonates because it captures something we instinctively understand: when facing complex technical challenges, the people who actually understand the domain should drive the approach. A nuclear solution might sound decisive, but without understanding orbital mechanics and physics, it could make things catastrophically worse.

Software organizations face this dynamic constantly. And too often, they choose the equivalent of the nuclear option.

The Conference Room Where Code Goes to Die

Picture a familiar scene: a meeting room where decisions about software architecture are being made. Around the table sit executives, project managers, and perhaps a consultant from a prestigious firm. The developers — the people who will actually build the thing — are either absent, outnumbered, or speaking last.

Someone suggests rewriting the system in a framework they read about in Harvard Business Review. Another proposes blockchain because their golf partner’s company did something with blockchain. A third insists on a vendor solution because the sales presentation was impressive.

The developers exchange glances. They know these approaches will create problems. But they’re outnumbered, outranked, or simply not asked.

Why This Pattern Persists

It would be easy to blame hubris, but the pattern has structural roots.

Hierarchy trumps expertise. Seniority in the org chart confers authority in all domains. The person who excels at finance is assumed to have valid opinions about software architecture. But a brilliant marketing executive doesn’t become a qualified surgeon by moving up the corporate ladder.

Abstraction creates confidence. Software is invisible. You can’t touch it or see its internal structure. This makes it seem simpler than it is. “It’s just code, how hard can it be?” No one looks at a skyscraper and says, “It’s just steel and concrete, how hard can it be?”

Consultants speak the language of power. External consultants succeed by telling executives what they want to hear in strategic-sounding language. The consultant’s confident simplification wins against the developer’s careful qualification.

The Framework That Will Fix Everything

"The surest sign a methodology was chosen without developer input is watching developers learn the new vocabulary while continuing to work exactly as before."

Perhaps no pattern better illustrates the problem than management frameworks imposed on development teams. A new methodology arrives — complete with certifications, consultants, and fresh vocabulary — promising to solve all delivery problems. Developers are sent to training. New rituals are mandated. Dashboards are configured.

And then: nothing changes.

The developers learn the terminology. They attend the required ceremonies. They update work items with expected labels. To executives, everything looks transformed. The organization has “gone Agile” or adopted “SAFe.”

But in the parking lot, a different conversation happens. Developers joke about the theater of it all. They translate their actual work into framework-speak for status meetings, then translate it back to get things done. The framework becomes a productivity tax — overhead to be managed rather than a tool that helps.

This isn’t cynicism. It’s adaptation. When people who understand the work aren’t consulted about organizing the work, the inevitable result is a gap between the official process and the real one. The real process continues in whatever form actually works. The official process becomes performance art.

"When developers joke about your process in the parking lot, you don't have a culture problem. You have an expertise problem."

The tragedy is that many frameworks contain genuinely useful ideas. But imposed from above, without input from those who understand the work, even good ideas become resented mandates.

The Cost of Ignoring Expertise

Organizations that consistently override developer expertise pay a recurring tax:

Projects fail. When technical decisions are made by non-technical people, systems often don’t work as promised. The asteroid isn’t destroyed; it breaks into fragments that cause even more damage.

Good developers leave. Talented practitioners have options. When their expertise is consistently ignored, they find organizations that value what they know.

Technical debt accumulates. The quick solution that seemed reasonable in a conference room becomes a permanent drag on productivity.

Innovation stalls. When developers learn their expertise isn’t valued, they stop offering it. They implement what they’re told, even when they know it won’t work.

What Genuine Expertise Sounds Like

Developers aren’t trying to be difficult when they raise concerns. They’re trying to prevent disasters.

When a developer says “that timeline is unrealistic,” they’re applying years of experience to recognize that certain things take certain amounts of time. When they question a technology choice, they’re considering factors that won’t be visible until months into the project. When they request time for refactoring, they’re identifying necessary work that will be done proactively and cheaply, or reactively and expensively.

"Developers who push back on unrealistic plans aren't being difficult. They're being professional."

The credentials that matter in software aren’t degrees or certifications. They’re having built things that ran in production. Having maintained systems and felt how today’s shortcuts become tomorrow’s emergencies. Having shipped projects that didn’t work out and learned what to avoid.

Creating Space for Technical Judgment

Organizations that build successful software create structures where technical expertise informs technical decisions.

Include developers in decisions. When a choice has technical implications — which means most choices about software — developers should be in the room, not receiving decisions after the fact.

Weight expertise appropriately. When the topic is astrophysics, the astrophysicist’s opinion matters most. When the topic is code architecture, developers’ opinions should carry decisive weight.

Distinguish between what and how. Business leadership appropriately decides what problems to solve. Technical practitioners appropriately decide how to solve them. Confusion between these domains is where dysfunction occurs.

"Trust your developers the way you'd trust your surgeons: respect their expertise in their domain while maintaining oversight of outcomes."

None of this means non-developers have no role. Business expertise, domain knowledge, and strategic vision are essential inputs. But these inputs should inform technical approaches, not dictate them. A CEO might appropriately say, “We need to handle ten times our current traffic.” A CEO should not then say, “Therefore use microservices and Kubernetes” — unless they have the technical background to make that recommendation.

The Question Worth Asking

In Armageddon, the NASA scientists’ approach prevails. The crude nuclear solution gives way to a plan that accounts for actual physics. The mission succeeds because expertise was valued.

Next time you’re in a meeting where software decisions are being made, look around the room. Who’s speaking? Who’s being heard? Are people with relevant expertise shaping the discussion, or being overruled by people whose credentials are in other domains?

If you’re a leader making decisions about software, consider: would you accept a surgery plan designed by your lawyer? A legal strategy devised by your accountant? The technical expertise of software developers deserves the same respect you’d give any other professional domain.

We don’t take advice from the guy who got a C-minus in astrophysics. Perhaps it’s time to extend the same logic to software development.

Ada Lovelace: Imagining Software Before It Existed

2026-01-03T00:00:00+01:00

The First Vision of Software as Creative Medium

03.01.2026, By Stephan Schwab

In 1843, decades before the first computer ran, Ada Lovelace saw what no one else could: a machine for calculation might become a machine for thought. Her notes on Charles Babbage's Analytical Engine contain the first algorithm intended for machine execution and — more importantly — the first articulation that software transcends arithmetic. Lovelace imagined possibilities that would take a century to realize.

Beyond the Calculator

Augusta Ada King, Countess of Lovelace, was born in 1815 as the daughter of poet Lord Byron and mathematician Anne Isabella Milbanke. Her mother, determined to suppress any poetic tendencies, ensured Ada received rigorous training in mathematics and logic. This unusual education for a woman of her time positioned her uniquely to recognize something Charles Babbage himself had missed about his own invention.

"The Analytical Engine weaves algebraic patterns just as the Jacquard loom weaves flowers and leaves." — Ada Lovelace, 1843

Babbage, the brilliant engineer behind the Analytical Engine, saw his machine as a powerful calculator — a device to tabulate mathematical functions without human error. When Italian mathematician Luigi Menabrea published a description of the engine in French, Babbage asked Lovelace to translate it into English.

She did far more than translate. Her notes, labeled A through G, more than doubled the length of the original paper. In them, she laid the conceptual foundation for what we now call software.

Ada Lovelace, 1843

Note G: The First Algorithm

Note G contains what historians recognize as the first computer program: a detailed sequence of operations for calculating Bernoulli numbers. Lovelace didn’t merely describe an idea; she worked out the specific steps the engine would need to execute, including loops and conditional branching.

But the algorithm itself, while historically significant, wasn’t her most important contribution. What distinguished Lovelace was her understanding of what such algorithms meant.

She recognized that the Analytical Engine could manipulate any symbols according to defined rules — not just numbers. Music, she speculated, might be composed by such a machine if the relationships between sounds could be expressed symbolically. The engine could process information, not merely calculate.

"The engine might compose elaborate and scientific pieces of music of any degree of complexity."

This was a conceptual leap that Babbage, focused on numerical precision for astronomical tables, never fully made. He built hardware. Lovelace saw software.

The Imagination Principle

Lovelace articulated something that remains central to software development: the machine does exactly what we tell it, nothing more. She wrote that the engine “has no pretensions to originate anything. It can do whatever we know how to order it to perform.”

This observation has two sides. The machine’s power is limited only by our imagination — and by our ability to express intentions precisely. Every software system ever built confirms her insight. Code doesn’t spring from machines — it springs from minds capable of imagining what might be, then translating that vision into instructions.

Modern developers take for granted that software can do essentially anything: control spacecraft, generate music, translate languages, simulate weather. Lovelace saw this universality in a machine that was never even completed, using technology that wouldn’t exist for another century.

Why This Matters Today

"Software is imagination made executable."

When we debate whether AI systems are “creative” or worry about automation replacing human work, we’re engaging with questions Lovelace raised in 1843. Her insistence that the engine “cannot originate” anything remains relevant to AI ethics debates today.

For software practitioners, her legacy is a reminder that our work is fundamentally about imagination. Requirements documents, user stories, architecture diagrams — these are attempts to capture human imagination in forms precise enough for machines to execute. The technical skills matter, but they serve a deeper purpose: translating possibility into reality.

Lovelace died at 36, the same age as her father. The Analytical Engine was never completed. Yet her notes survived, waiting for the world to catch up. When electronic computers finally emerged in the 1940s, engineers discovered they were building what Lovelace had already described.

The First Software Developer

We remember Ada Lovelace not because she wrote one algorithm, but because she saw what computing could become. She understood that a machine following instructions could transform any domain where relationships could be expressed symbolically — mathematics, music, language, logic.

Today, every developer who writes code participates in a tradition she initiated: imagining something that doesn’t yet exist, then specifying it precisely enough that a machine can make it real. The languages have changed. The hardware would astound her. But the fundamental act remains what she described in 1843: teaching machines to weave patterns of our imagination.

Software is imagination. Lovelace saw it first.

La Nueva

2026-01-01T00:00:00+01:00

Previously: "El Pitch Perfecto" — Six months after FinPulso's triumphant Series A, the dream has become a nightmare. Diego has vanished, the AI is a lie, and Don Hernando finally sees the chaos his money has created.

The Man from Panama

El Dorado International Airport. 6:47 AM.

Stefan Richter walks through customs with nothing but a carry-on bag and a worn leather notebook. He’s slept on worse flights than the red-eye from Panama City, and at forty-six, he’s learned that first impressions matter less than people think.

The driver holding the sign that says “RICHTER — FINPULSO” is young, nervous, checking his phone every few seconds. Stefan files this away. Nervous staff usually means nervous management.

Nervous staff usually means nervous management.

“Señor Richter? I’m Carlos. I work for Don Hernando.”

“Stefan is fine.” He follows Carlos to the parking lot, taking in the Bogotá morning — the mountains rising blue in the distance, the traffic already building, the smell of rain-washed streets and diesel. “How long have you worked for Don Hernando?”

“Twelve years. Since the ranch.”

“You came from Los Llanos?”

Carlos looks surprised. “You know the Llanos?”

“I’ve read about them. The llaneros. The cattle culture.” Stefan smiles slightly. “Don Hernando hired someone who still calls himself a rancher. That tells me something.”

“What does it tell you?”

“That he values loyalty. And that he probably doesn’t understand what he’s gotten himself into with a software company.”

Carlos says nothing, but his grip on the steering wheel tightens.

The drive into Chapinero takes forty minutes through morning traffic. Stefan uses the time to review the brief Don Hernando sent him — sanitized, of course. A Series A success story turned crisis. A missing lead developer. An investor demanding answers.

What the brief doesn’t say is more interesting than what it does.

First Impressions

The FinPulso office occupies the fourth floor of a renovated building that probably looked revolutionary five years ago. Now the exposed brick and Edison bulbs feel like a costume — startup theater for investors who expect certain aesthetics.

Laura Méndez meets him at the elevator. Her handshake is professional, her smile practiced, her eyes assessing.

“Señor Richter. Don Hernando is expecting you.”

“Stefan, please. And Laura — may I call you Laura? — I’d like to meet the development team first.”

She hesitates. “Don Hernando specifically asked—”

“I know. But I’ve found that executives rarely know where the real problems are. They know where they think the problems are, which is different.” He gives her a disarming smile. “Indulge me for an hour. Then I’ll meet with Don Hernando and tell him exactly what he wants to hear.”

Something flickers in Laura’s eyes — amusement? Recognition?

“One hour,” she says. “I’ll tell him you’re getting settled.”

She leads him to the development area: an open floor of desks, monitors, the detritus of late nights — empty coffee cups, energy drink cans, a whiteboard covered in diagrams that look like they haven’t been updated in months.

Three people are present. It’s not yet 8 AM.

“Stefan, this is Felipe Gómez — we call him Pipe. He’s been here longest.”

Pipe is forty-something, tired, with the posture of someone who’s stopped expecting good news. He nods without getting up. “Great. Another fucking consultant. Just what we need.”

“Not exactly,” Stefan says. “I write code. May I?” He gestures at an empty chair near Pipe’s desk.

Pipe’s jaw tightens. “Suit yourself. But don’t expect me to pretend I’m glad you’re here.”

"Another consultant." — "Not exactly. I write code."

“How long have you been with FinPulso?”

“Since the beginning. Before it was called FinPulso. Before the money.”

“You’ve seen a lot.”

“I’ve survived a lot. Different thing.”

Stefan opens his leather notebook, writes something. Pipe cranes his neck to look, then snorts. Stefan has written: Pipe — survivor. Knows where the bodies are buried.

“You write everything down?”

“Memories lie. Paper doesn’t.” Stefan looks around. “Where is everyone else?”

“Camila comes in early — she’s probably getting coffee. Sebastián works nights, sleeps late. The others…” Pipe makes a vague gesture. “There used to be more.”

“How many left after Diego?”

The name lands like a dropped glass. Pipe’s expression closes.

“You’ve done your homework.”

“I read the brief. But briefs are written by people with agendas. I’d rather hear from you.”

Pipe is silent for a long moment. Then: “Four. Four left after Diego. They could see what was coming.”

“And you stayed.”

“I’m too old to start over. And too proud to let the platform I helped build die because some genius decided to take his toys and go home.”

Stefan makes another note. “Tell me about deployments. How does code get to production?”

Pipe laughs — a bitter, hollow sound. “That’s the thing. It doesn’t. Not anymore.”

The Coffee Run

Camila Torres returns with four cups of coffee balanced in a cardboard carrier. She stops at the edge of the development area, surprised to see someone new at Pipe’s desk.

“Camila, this is Stefan.” Pipe takes his coffee without looking up. “He’s the new consultant. Different from the last one, apparently.”

Stefan rises, extends his hand. “I’m not actually a consultant. I’m a Developer Advocate. I work with teams, not on them.”

Camila shakes his hand, uncertain. “What’s the difference?”

“Consultants tell you what to do. I help you see what you’re already doing — and whether it’s what you want.”

She considers this. “And if we’re doing things wrong?”

“Then we figure out what ‘right’ looks like. Together.” He gestures at the remaining coffees. “Who are those for?”

“Sebastián. And… one was for Diego. Force of habit.”

Stefan takes the extra cup. “May I?”

Camila nods. Stefan drinks, then makes a note in his notebook. She catches a glimpse: Camila — brings coffee for ghosts. Still believes.

"One was for Diego. Force of habit."

“Can I see your codebase?” he asks.

Pipe nearly chokes on his coffee. “Just like that?”

“I can read architectural decisions faster than people can explain them. And people lie about their architecture. Code doesn’t.”

Camila glances at Pipe, who shrugs.

“The main repository is…” She trails off, fingers hovering over her keyboard. “Actually, I need to get you credentials. And the CI/CD pipeline is… it’s complicated.”

“Show me.”

She pulls up a diagram on her screen — boxes and arrows, deployment stages, integration points. It looks reasonable until you know what to look for.

Stefan leans in, tracing the flow with his finger. “This box here — ‘Production Deploy’ — what triggers it?”

“Manual approval from Diego.”

“And Diego is gone.”

“Yes.”

“So nothing has been deployed in…”

“Forty-three days.” Camila’s voice is quiet. “We can push to staging. We can run tests. But production requires credentials only Diego had.”

Stefan is very still. “And no one thought to address this earlier?”

“We raised it.” Pipe’s voice is bitter. “We raised it every damn week. Management said it was fine, Diego would be back, we should focus on features. And then Diego didn’t come back, and now we can’t deploy shit, and management wants to know why we’re behind schedule.”

“¿Y esto está en producción?” Stefan murmurs — a question to himself.

“What?”

“Nothing. An old habit.” He makes another note. “Show me the test suite.”

The Test Suite

Camila navigates to the testing infrastructure. Her movements are careful, deliberate — the habits of someone who has learned that one wrong click can bring down staging.

“Here’s our test coverage report.”

Stefan reads in silence. The numbers tell a story: 73% coverage on the payment module, 12% on fraud detection, 8% on user authentication. The core business logic is barely tested. The parts that don’t matter have excellent coverage.

73% coverage on payments. 12% on fraud detection. 8% on authentication.

“Who wrote the payment tests?”

“Diego. Before he left.”

“And the fraud detection tests?”

Camila hesitates. “There… aren’t any. Not real ones. The contractor team in Venezuela validates manually, so we never built automated verification.”

“The contractors who are your ‘AI.’”

“Yes.”

Stefan closes his notebook. For a long moment, he says nothing.

Then: “How long have you known this was unsustainable?”

Camila meets his eyes. She’s young, he thinks, but not naive. There’s steel there.

“Since my second week. I wrote a memo. Sent it to Sebastián.”

“And?”

“He agreed. Said he’d raise it with Don Hernando. Then Alejo found out and…” She stops.

“And?”

“I was told to focus on my assigned tickets. Junior developers should learn before they criticize.”

Stefan writes something in his notebook. This time he angles it so she can see: Camila was right. They silenced her.

“Show me what you’ve been working on,” he says. “The things you’re not supposed to be working on.”

The Private Repository

The FinPulso office has a small meeting room with glass walls that someone has optimistically named “The Innovation Lab.” At 11 AM, it’s empty. Camila pulls the blinds and boots up her personal laptop.

“This stays between us,” she says.

“Of course.”

She navigates to a GitHub repository — personal account, not company. The project is called FinPulso-Core-v2.

“I started this six months ago. After I realized the main codebase was…” She searches for a diplomatic word.

“Unmaintainable?”

“Hostile. It actively resists change. Diego built it to work, but he built it in his head. No one else can follow the logic.”

Stefan scrolls through the repository. Clean directory structure. Comprehensive test suite. Continuous integration configured and passing. Documentation that actually explains things.

“You rebuilt the core platform.”

“The critical parts. Payment processing, user auth, the basics. It’s not complete, but what’s there works. And it’s tested.”

“Does it pass the existing integration tests?”

“There are no existing integration tests. But I built my own.” She pulls up a test run. Green checkmarks cascade down the screen. “Every feature I reimplemented, I wrote tests first. Then I made the tests pass.”

"You taught yourself TDD." — "YouTube. Online courses. Books in English."

Stefan is quiet for a long time.

“You taught yourself TDD,” he says finally.

“YouTube. Online courses. Books in English — my English isn’t perfect, but the code examples make sense.”

“And you never told anyone.”

“I told Pipe. He thinks I’m crazy, but he’s been reviewing my code when he has time. And I almost told Sebastián, but…” She hesitates. “Something happened. A few weeks ago. Someone sent me a message.”

“What kind of message?”

Camila pulls up her phone, shows him a screenshot:

Unknown I know what you've been building. Keep going. Don't let them see it yet.

“No signature. The number is gone now — the messages deleted themselves.”

Stefan studies the screenshot. “Diego.”

“I think so.”

“He’s watching.”

“He never stopped. He just stopped being visible.”

The Brief

Don Hernando Castillo is not a patient man. By 11:30, he’s pacing his corner office.

“Where is he?”

Laura checks her phone. “Still with the development team. He asked for an hour.”

“It’s been nearly three.”

“He’s thorough.”

Before Don Hernando can respond, the door opens. Stefan enters without knocking — a calculated choice that makes Don Hernando’s jaw tighten.

“Forgive me, Don Hernando. I was learning interesting things.”

“Such as?”

Stefan takes a seat without being invited. Another calculation.

"You're direct." — "I'm expensive. You're not paying me to be diplomatic."

“Such as the fact that your platform hasn’t been deployed in forty-three days. Such as the fact that the staging environment uses different infrastructure than production, so nothing tested there can be trusted. Such as the fact that no one currently employed has credentials to deploy to production.”

The silence stretches.

Don Hernando sits slowly. “You’ve been here three hours.”

“I ask good questions.” Stefan opens his notebook. “And people are tired of lying. They want someone to tell the truth to.”

“What else did they tell you?”

“That your lead developer didn’t just leave — he was driven out. That your co-founder has been sidelined into irrelevance. And that the young woman who makes coffee every morning might be the best developer you have left, except no one ever asks her opinion.”

Don Hernando’s face has gone very still. “You’re direct.”

“I’m expensive. You’re not paying me to be diplomatic.”

“I’m paying you to fix this.”

“No.” Stefan shakes his head. “You’re paying me to tell you what’s actually broken. Fixing it — that requires decisions only you can make.”

Don Hernando considers this. “What do you need?”

“Time. Access. And a conversation with your CTO that you’re not present for.”

“Sebastián? He barely functions these days.”

“Perhaps because no one has asked him what he actually thinks. I’ll have a preliminary assessment for you by end of day.”

The Afternoon

Sebastián Duarte arrives at the office at 2 PM, looking like he slept in his clothes. He probably did. Since Diego’s document landed in his inbox, he’s been reading it over and over, trying to understand how they got here.

He finds Stefan at Pipe’s desk, both of them staring at code on a screen.

“You’re the German.”

Stefan turns. “And you’re the CTO who doesn’t have production access.”

Sebastián flinches. “It’s complicated.”

“Most dysfunction is.” Stefan rises, extends a hand. “Walk with me? I’d like to understand the product from your perspective.”

They end up on the building’s rooftop — the real one, not the fancy W Hotel terrace. It’s drizzling, but neither seems to mind.

"I want to build something real. Something I can be proud of."

“You built the original prototype,” Stefan says. “In your parents’ garage.”

“A lifetime ago. Before Don Hernando, before the money, before…” Sebastián trails off. “Before we became a real company.”

“You don’t sound happy about that.”

“I’m happy we survived. I’m happy we have a chance. I just…” He stares at the gray sky. “This isn’t what I imagined.”

“What did you imagine?”

“A product that helps people. Colombian families who don’t have bank accounts, who pay fees to send money to their relatives, who get exploited by predatory lenders. FinPulso was supposed to change that.”

“And now?”

“Now we have PowerPoints about AI and investor meetings about runway and a platform that doesn’t work and a lead developer who…” Sebastián’s voice catches. “I pushed him out. Me. Not Alejo, not Don Hernando. Me.”

Stefan waits.

“He came to me. Months ago. With concerns — about the architecture, about the contractor team, about the promises we were making to investors. And I told him we’d address it after the funding closed. After the launch. After, after, after.” Sebastián laughs bitterly. “There’s always an after. Until there isn’t.”

“What do you want now?”

The question seems to catch Sebastián off guard. “What do you mean?”

“Everyone has told me what went wrong. What they’re afraid of. What they think I want to hear. No one has told me what they actually want.”

Sebastián is silent for a long moment. The drizzle turns to proper rain, drumming on the rooftop.

“I want to build something real.” Sebastián’s voice cracks. He turns away, pressing his fist against his mouth for a moment before continuing. “Something that works. Something I can be proud of, even if it’s smaller than what we promised.”

His eyes are wet. The words come out raw, broken.

“That’s all I ever wanted, you know? When Diego and I started this… God, we were so fucking naive. We thought we could change the world. Financial tools for people who’d never been served by banks. Real technology solving real problems.” He laughs bitterly. “And look at us now. A house of cards built on lies.”

Stefan nods. “That’s a start.”

“Is it enough?”

“It’s not my decision.” Stefan opens his leather notebook to a fresh page. “But I’ll tell you what I’ll tell Don Hernando: you have two paths from here. One leads to an honest reckoning — painful, expensive, but survivable. The other leads to more pretending — easier in the short term, fatal in the long term.”

“And what will Don Hernando choose?”

“That depends on what he learns between now and this evening.” Stefan closes his notebook. “Now. Tell me about Camila Torres.”

The Counter-Offensive

Across Bogotá. A coffee shop in Zona Rosa.

Marco Benedetti sips his cortado, watching Alejo Vega pace in the private room they’ve reserved. The Italian has learned to read Colombian anxiety — it manifests differently than European stress, more theatrical, more performative.

“This German,” Alejo says. “He’s a problem.”

“He’s a developer. Developers talk to developers. It means nothing.”

“He talked to Don Hernando for an hour. Alone. Laura says the old man looked thoughtful afterward.”

Marco sets down his cup. “Thoughtful how?”

“She doesn’t know. But Don Hernando asked her to pull the original investor agreements. The ones from before the Series A.”

“That’s… unusual.”

"The German can fix the technology. But he can't fix the board."

“That’s dangerous.” Alejo stops pacing. “Don Hernando doesn’t research. He decides. He commands. If he’s pulling old documents, it means someone challenged his assumptions.”

Marco considers this. He’s been in Bogotá four months now, billing FinPulso for “Agile transformation” while feeding carefully selected information to competitors. It’s not personal — it’s business. Every struggling startup is an opportunity for someone, and Marco has learned to be that someone.

But the German is a variable he hadn’t anticipated.

“What do we know about him?”

Alejo pulls out his phone, scrolls through notes. “Stefan Richter. German, obviously. Based in Panama. Works with companies in crisis — turnarounds, recoveries. Has a reputation for being effective.”

“Effective how?”

“He fixes things. Actually fixes them. Companies that hire him tend to survive.”

Marco’s expression doesn’t change, but something shifts behind his eyes. “That would be… inconvenient.”

“For our arrangement? Extremely.”

The Italian stands, adjusts his cashmere sweater. “Then we need to accelerate. The MiPago deal — how close are we?”

“They want due diligence on FinPulso’s technology. I’ve been stalling because our tech is a disaster.”

“Stop stalling. Give them what they want.”

“If they see how bad it is—”

“They’ll lower their offer. Which means Don Hernando gets desperate. Which means he needs my help negotiating. And suddenly I’m essential — not just useful.” Marco smiles, and it’s the smile of a predator who sees the trap coming together. “The German can fix the technology. But he can’t fix the board. And the board is where this gets decided.”

Alejo nods slowly. “I’ll reach out to Mariana. Frame it as concern. An independent perspective on the recovery plan.”

“Do that. And Alejo?”

“Yes?”

“Keep Sebastián busy. The last thing we need is the co-founder having opinions.”

The Evening Report

By 6 PM, Don Hernando has read Stefan’s preliminary assessment. Three times.

He gathers them in the main conference room: Alejo, Sebastián, Laura, and Stefan. The assessment sits on the table like an accusation.

“I’ve spent the afternoon reviewing this,” Don Hernando says. His voice is calm, which somehow makes it more dangerous. “And I’ve made some calls.”

Alejo shifts in his seat. “What kind of calls?”

“To Mariana at Vulcano. To our legal counsel. To a few old friends who understand business better than I understand technology.” He looks directly at Alejo. “And to a contact who knows the people at MiPago.”

The room goes very quiet.

“Don Hernando—” Alejo begins.

“You’ve been negotiating with them for two months. Without board authorization. Without my knowledge.”

Stefan watches Alejo’s face carefully. The CFO’s mask slips for just a moment — surprise, then calculation, then a smooth recovery.

“Those conversations were exploratory—”

“They were betrayal.” Don Hernando’s voice doesn’t rise, but something in it makes Alejo stop talking. “In my world, we have a word for people who negotiate behind their patrón’s back. We call them traidores.”

"In my world, we have a word for people who negotiate behind their patrón's back. We call them traidores."

Sebastián stares at Alejo. “You were going to sell us out?”

“I was exploring options—”

“¡Silencio!” Don Hernando slams his palm on the table. The room shakes. “You will speak when I tell you to speak.”

He stands, moves to the window, looks out at the city lights beginning to flicker on.

“I made a mistake,” he says. “I thought this business was like the cattle business. Find good people, give them authority, trust them to deliver. But cattle don’t lie. Code, apparently, does.”

He turns back.

“Stefan will stay for three months. Full access. Full authority to assess. He reports to me directly — not to you, Alejo, not to the board. To me.”

“That’s highly irregular—”

“So is selling my company without asking.” Don Hernando’s eyes are cold. “You will continue as CFO because I need someone who understands the numbers. But if I catch you negotiating again, you will leave this building with nothing. Nada. Not even your reputation.”

Alejo’s face is a mask. “Understood.”

“Sebastián.” Don Hernando’s voice softens slightly. “You are the CTO. It’s time to act like one. Whatever Stefan needs, you provide. Whatever decisions need to be made about the technology, you make them. With his guidance, but you make them.”

Sebastián nods, still processing.

“And we need Diego back.”

“He won’t come back,” Sebastián says. “After everything that happened—”

“Then you find a way.” Don Hernando moves to the door. “We have two weeks until Mariana returns. Two weeks to show her a path forward. Two weeks to save my son’s legacy.”

He pauses at the threshold.

“Don’t disappoint me again.”

The door closes.

Stefan opens his notebook and writes: Day 1 complete. The real work begins tomorrow.

The Watcher

Late night. Somewhere in Bogotá.

Diego Vargas sits in the dark, laptop glowing, watching a feed that he shouldn’t have access to anymore. The FinPulso internal Slack. The email threads. The calendar that shows Stefan’s schedule for tomorrow.

He didn’t expect Don Hernando to hire someone like this. The Italian was predictable — all surface, no substance. But the German…

He never stopped watching. He just stopped being visible.

Diego pulls up Stefan’s background. Twenty-five years in software. Successful turnarounds in Germany, the US, Latin America. A reputation for honesty that borders on brutal.

This could work. This could actually work.

But there’s a problem. The same problem there’s always been.

Alejo is still there. Marco is still whispering. And the document Diego sent — the one Sebastián hasn’t shared with anyone — contains information that Alejo would kill to bury.

Not metaphorically.

Diego’s phone buzzes. A message from an encrypted app:

Unknown Our friend landed today. He found Camila's project. Impressed.

Diego I know. I'm watching.

Unknown Time to make contact?

Diego Not yet. Let him see for himself first.

Unknown And if Alejo moves faster?

Diego Then we accelerate. But Stefan needs to trust the evidence, not just my word.

Unknown Careful. You're running out of time.

Diego I know. But some things can't be rushed.

He closes the laptop. In the dark apartment, surrounded by servers he’s been running on his own dime, Diego Vargas considers his next move.

The German is asking the right questions. Camila is building the right thing. Sebastián is finally waking up.

But Alejo and Marco — they’re cornered now. And cornered people do desperate things.

Diego looks out his window at the Bogotá night. Somewhere out there, Don Hernando is staring at the same stars, wondering about his dead son.

Somewhere out there, Stefan is writing in his leather notebook, documenting everything he’s learned.

Somewhere out there, Alejo is making phone calls he doesn’t want anyone to know about.

The game has changed. But it’s far from over.

Next Episode: "Los Secretos del Código" Stefan finally gets server access — through unconventional means. What he discovers will force everyone to choose sides. And Diego makes contact.

Technical Practices That Drive Business Results

2025-12-31T00:00:00+01:00

The Business Value of Technical Excellence

31.12.2025, By Stephan Schwab

Certain software development practices may sound purely technical, yet each one solves a concrete business problem — reducing risk, accelerating delivery, preserving institutional knowledge. Through these practices, developers become deeply knowledgeable about the business itself, moving far beyond the outdated notion of "coders" transcribing someone else's ideas. Understanding what these practices accomplish helps leaders invest wisely and recognize the expertise their technical teams bring.

Why This Matters for Business Leaders

When developers mention practices like “test-driven development” or “continuous integration,” the terminology can sound like technical jargon disconnected from business concerns. Yet each practice emerged because real organizations hit painful problems — failed releases, departed experts taking critical knowledge with them, systems that grew increasingly expensive to change. Bridging this communication gap between technical and non-technical perspectives remains one of the most important challenges in software organizations.

"Every technical practice exists because someone got burned badly enough to find a better way."

These practices weren’t invented in theory. They were discovered by practitioners building real systems and learning — often painfully — what actually works. Understanding this origin helps leaders see technical practices as investments with measurable returns rather than mysterious rituals developers insist upon.

What follows is a guide to the most important practices, what business problems they solve, and how to recognize whether your teams are using them effectively.

Pair Programming: Continuous Knowledge Transfer

What it is: Two developers work together at one computer, actively collaborating on the same code.

The business problem it solves: Knowledge concentration and bus factor risk.

"Every company has that one developer everyone fears losing. Pair programming means no one person holds the keys to any system."

In most organizations, critical knowledge lives in individual heads. The developer who built the payment system knows secrets no documentation captures. When they leave — and they will eventually leave — their knowledge leaves with them. The remaining team faces code they don’t understand, making changes risky and slow.

Pair programming spreads knowledge continuously. Two people always understand each piece of code. Questions get answered immediately rather than waiting for meetings. Junior developers learn directly from senior ones, accelerating their growth.

The business value: reduced dependency on specific individuals, faster onboarding, fewer knowledge gaps, lower risk from turnover.

What non-technical leaders can observe: Ask how many people understand your most critical systems. If the answer is one or two, you have a risk that pair programming directly addresses.

Test-Driven Development: Design Through Conversation With Code

What it is: Developers write automated tests before writing the code those tests verify, using the tests to guide the design of the software itself.

The business problem it solves: Poor design decisions that accumulate cost over time, and uncertainty about whether software actually works.

Despite its name, test-driven development isn’t primarily about testing. While it does produce tests, that’s almost a side effect. The primary purpose is design. Writing a test first forces developers to think from the perspective of someone using the code before writing it. This outside-in thinking leads to cleaner, more usable designs.

"TDD isn't about testing. It's about having a conversation with the code before you write it — discovering the right design through small, concrete experiments."

An analogy from architecture helps illustrate this. An architect doesn’t simply imagine a building and then draw it. They sketch possibilities, consider how people will move through spaces, test ideas against constraints, and refine their thinking through the act of drawing. The drawings aren’t just documentation of decisions already made — they’re tools for thinking and discovery.

Test-driven development works the same way. Each test asks: “If this code existed, how would I want to use it? What would make it clear and convenient?” The test becomes a concrete experiment that reveals design problems before the code is written. If the test is awkward to write, the design is probably awkward. If the test requires complex setup, the code will probably be complex to use.

The Rhythm of Discovery

TDD follows a simple rhythm: write a small test that fails, write just enough code to make it pass, then improve the design while keeping the tests passing. This cycle typically takes minutes, not hours. Each cycle is a small experiment that confirms understanding and reveals the next question.

This incremental approach has profound implications for design quality. Large upfront designs often miss important details that only become apparent during implementation. By the time problems emerge, significant work is already invested in a flawed direction. TDD surfaces these problems immediately, while they’re still cheap to address.

"Would you accept a building where the contractor says 'I think it won't fall down'? The test suite is how developers prove the system works — evidence you can watch being verified."

A Dialogue With Subject Matter Experts

This rhythm of discovery works best as a collaborative dialogue between developers and subject matter experts. Each test begins with a question: “When this situation occurs, what should happen?” The answer comes from someone who understands the business domain — a product manager, a domain specialist, or an experienced user.

This dialogue transforms developers into something far more valuable than the outdated notion of “coders” suggests. That term belongs to the era of punch cards, when machine operators transcribed specifications created by others. Modern software development bears no resemblance to this. Developers aren’t translating someone else’s ideas into a foreign language. They’re actively designing solutions, exploring constraints, and making countless decisions that require deep understanding of the business problem.

"The 'coder' disappeared with the punch card. Today's developers become subject matter experts themselves — often the most knowledgeable people in the organization about how the business actually works."

Through TDD’s dialogue, developers accumulate remarkable domain expertise. They see edge cases that business experts never considered. They understand the interactions between different parts of the business that specialists in individual areas might miss. They know not just what the system does, but why it does it, and what happens when circumstances change.

This accumulated knowledge makes experienced developers extraordinarily valuable — not despite their technical focus, but because of it. They see the business through a uniquely comprehensive lens: every rule, every exception, every interaction encoded in tests that prove understanding. This intrinsic motivation — the pride, curiosity, and care that drives developers to understand deeply — is one of the most valuable assets any organization has.

Design Feedback in Real Time

Software development is fundamentally a design discipline — iterative, exploratory, and collaborative. Test-driven development supports this nature by providing immediate feedback on design decisions. When code is hard to test, it’s usually a signal that the design has problems: too many responsibilities in one place, too much coupling between components, unclear boundaries.

Developers experienced in TDD learn to read these signals. Difficult tests aren’t just inconvenient — they’re diagnostic information about the design. This feedback loop accelerates learning and leads to cleaner architectures over time.

The Executable Specification

The tests created through TDD serve as living documentation. Unlike written specifications that drift out of sync with reality, tests must accurately reflect how the code behaves or they fail. New team members can read the tests to understand what the system does and why. When questions arise about intended behavior, the tests provide definitive answers.

"If you can't read a test and understand what business rule it verifies, the test is checking the wrong thing."

Well-written tests read like business specifications. Anyone who understands English should be able to look at a test and grasp what it’s verifying: “When a customer places an order over €500, shipping is free.” “When an invoice is overdue by more than 30 days, send a reminder.” “When inventory drops below the reorder threshold, create a purchase request.”

Tests that require programming knowledge to decipher are testing implementation details rather than business behavior. This distinction matters. Implementation details change frequently as developers improve the code; business rules change only when the business changes. Tests anchored to business behavior remain stable and meaningful. Tests anchored to implementation become maintenance burdens that break with every improvement.

This readability has a practical implication: business stakeholders can review tests. They can confirm that the rules encoded match their understanding. They can spot gaps where important scenarios aren’t covered. The test suite becomes a shared language between business and technical teams — precise enough to execute, clear enough to discuss.

This living documentation has significant business value. Organizations routinely struggle with knowledge loss when original developers leave. Systems become mysterious black boxes that no one dares change. A comprehensive test suite is an investment in long-term maintainability — it preserves not just what the code does, but the intentions behind it.

The Safety Net for Change

Beyond design, TDD creates a safety net that enables confident modification. Every change can be verified against hundreds or thousands of automated checks in seconds. Problems surface immediately, while the developer still remembers what they changed and why.

This safety net compounds in value over time. Early in a project, changes are easy regardless of testing. But as systems grow, untested code becomes increasingly dangerous to modify. Teams slow down, become conservative, and avoid touching anything that works. Tested code remains malleable, allowing the system to evolve with changing business needs.

The business value: better designs that cost less to maintain, living documentation that prevents knowledge loss, confidence in changes that enables continuous improvement, and proof that software works as intended.

What non-technical leaders can observe: Ask to see the test suite run. Watch hundreds or thousands of checks pass in seconds. Ask how long it takes to verify that a change hasn’t broken anything. Ask whether developers feel confident modifying unfamiliar parts of the system. The answers reveal whether TDD is enabling sustainable delivery.

Continuous Integration: Finding Problems Early

What it is: All developers integrate their work into a shared codebase multiple times per day, with automated tests verifying each integration.

The business problem it solves: Integration problems discovered too late to fix cheaply.

Continuous integration represents a fundamental shift from the traditional approach: developers work separately for weeks, then attempt to combine their work. This “integration phase” routinely reveals that pieces don’t fit together. What seemed like parallel progress was actually parallel divergence. The later you discover incompatibilities, the more expensive they are to fix.

"Finding a problem on Day 1 costs minutes. Finding it on Day 90 costs weeks. Continuous integration ensures you always find it on Day 1."

Continuous integration forces these discoveries to happen immediately. When work integrates multiple times daily, problems surface within hours of being created. They’re fixed while the context is fresh, while the change is small, while the cost is minimal.

The business value: predictable integration, earlier problem detection, smoother releases, reduced emergency fixes.

What non-technical leaders can observe: Ask how often code integrates. If the answer involves branches living for weeks, you’re accumulating integration risk that will arrive as a surprise.

Refactoring: Maintaining the Ability to Change

What it is: Continuously improving code structure without changing its behavior.

The business problem it solves: Systems that become progressively harder and slower to modify.

Every business changes. Markets shift, requirements evolve, opportunities emerge. Software must change to support these shifts. But software that’s never maintained becomes rigid, fragile, and slow to modify. Each change takes longer than the last. Eventually, changes that should take days take months.

"Refactoring isn't rewriting for fun. It's the difference between a building you can renovate and one you can only demolish."

Refactoring is preventive maintenance. It keeps code clean, well-organized, and adaptable. Just as a well-maintained building can be renovated rather than demolished, well-maintained code can be changed rather than replaced.

The business value: sustained velocity over time, faster response to market changes, deferred rewrites, lower long-term cost.

What non-technical leaders can observe: Ask how long a “simple change” takes now versus two years ago. If the answer is “much longer,” you’re paying the cost that refactoring prevents.

Small Releases: Reducing Risk Through Frequency

What it is: Releasing software in small increments, often multiple times per day.

The business problem it solves: The risk that accumulates in large, infrequent releases.

Large releases are dangerous. When you change many things at once, determining which change caused a problem is difficult. Rolling back means losing everything. The stakes are high, so releases become stressful events requiring extensive coordination and recovery plans.

"Release once a quarter, and each release is a crisis. Release ten times a day, and each release is a non-event."

Small releases invert this dynamic. When you release one small change, you know exactly what changed. If something breaks, you know what caused it. Rolling back is trivial because you’re only removing one small piece. The stakes are low, so releases become routine.

The business value: faster time to market, lower release risk, easier troubleshooting, ability to experiment and learn quickly.

What non-technical leaders can observe: Ask about the last release. Was it a calm routine event or a stressful coordination challenge? The answer reveals whether you’re releasing often enough.

Collective Code Ownership: Eliminating Bottlenecks

What it is: Any developer can modify any part of the codebase.

The business problem it solves: Bottlenecks created by territorial code ownership.

In many organizations, each code area has an “owner” who must approve or make all changes. This creates queues. Work waits because the owner is busy, on vacation, or focused elsewhere. Priorities can’t shift because the person who owns that code isn’t available.

"When only one person can work on the payment system, every payment-related priority is hostage to their calendar."

Collective ownership removes these bottlenecks. Any qualified developer can work on any part of the system. Work flows to available people rather than queueing for specific ones. The team becomes flexible rather than constrained by individual schedules.

The business value: faster delivery, reduced queuing delays, flexible resource allocation, lower person-dependency.

What non-technical leaders can observe: Ask what happens when the database expert is on vacation. If work stops, you have an ownership bottleneck that collective ownership addresses.

On-Site Customer: Getting Feedback Before It’s Too Late

What it is: A business representative available to the development team for immediate questions and decisions.

The business problem it solves: Building the wrong thing because questions go unanswered.

Developers constantly face small decisions that affect business outcomes. Should this edge case be handled this way or that way? What matters more: speed or accuracy in this calculation? When users do this unexpected thing, what should happen?

"Every question a developer can't get answered is a decision they'll make alone — possibly wrong."

Without immediate access to business knowledge, developers either wait (blocking progress) or guess (risking wrong outcomes). Neither is good. Having a customer available means questions get answered immediately, with business priorities informing every decision.

The business value: faster progress, better alignment with business needs, fewer costly misunderstandings, reduced rework.

What non-technical leaders can observe: Ask developers how they get questions answered. If the answer involves formal requests, scheduled meetings, or “we just guess,” you’re paying the cost that customer availability prevents.

Simple Design: Building Only What You Need

What it is: Implementing the simplest solution that could work, avoiding speculative complexity.

The business problem it solves: Wasted investment in features and structures that never prove necessary.

"Every feature you build 'just in case' costs money now and might never return value. Simple design means investing only in what you know you need."

Developers often build for imagined future needs. “We might need to handle millions of users.” “We might need to support multiple currencies.” “We might need to integrate with systems that don’t exist yet.” Each “might” adds cost now for uncertain future benefit.

Simple design inverts this. Build what you know you need. Keep the design flexible so you can add what proves necessary. Don’t invest in speculation.

The business value: lower development costs, faster initial delivery, reduced maintenance burden, flexibility to respond to actual needs rather than imagined ones.

What non-technical leaders can observe: Ask about features built for “future needs” that haven’t materialized. Each represents investment that simple design would have avoided.

How These Practices Reinforce Each Other

None of these practices exists in isolation. Test-driven development makes refactoring safe by catching unintended changes. Continuous integration makes small releases possible by ensuring the codebase stays healthy. Pair programming enables collective ownership by spreading knowledge. Simple design reduces the testing burden by keeping systems understandable.

"Technical excellence isn't a luxury. It's the foundation that determines whether your organization can deliver reliably."

Organizations that invest in these practices see compounding benefits: faster delivery, fewer surprises, lower turnover, sustained velocity over time. Organizations that skip them pay compounding costs: slower delivery, more emergencies, frustrated developers, mounting technical debt. These practices form the engine of predictable software delivery — transforming development from a high-stakes gamble into a reliable source of business value.

What This Means for Leaders

If you’re a non-technical leader responsible for software delivery:

Understand the business case. Every practice above has direct business value. When developers request time for testing, refactoring, or pair programming, they’re proposing investments with measurable returns.

Ask good questions. You don’t need to understand how to do pair programming — you need to understand what business problem it solves and how to tell if your teams are doing it effectively.

Fund technical excellence. Teams that skip these practices aren’t saving money — they’re borrowing against future velocity at punishing interest rates. Governing without control means designing systems that tell the truth through automated tests, pipelines, and monitoring — not through status reports.

"These practices aren't developer perks. They're operational necessities that determine whether your organization can actually deliver."

Involve developers in decisions. The practices that work emerge from people who do the work. Technical expertise deserves the same respect you’d give any other professional domain.

The Questions Worth Asking

The next time you’re reviewing software delivery, these questions can reveal whether your organization has the technical foundation for reliable results:

How many people understand our most critical systems?
How do we know the software works before we ship it?
How often does code integrate, and how often do we release?
How long does a “simple change” take compared to two years ago?
What happens when a key developer is unavailable?
How do developers get business questions answered?

The answers reveal whether your organization has the technical foundation for reliable delivery.

These practices aren’t mysterious. They’re proven approaches to problems every software organization faces. The developers building your software have accumulated hard-won expertise — not just in technology, but in your business itself. Understanding these practices helps you invest wisely, ask the right questions, and recognize the value your technical teams bring.

Following the Plan Into the Mountain

2025-12-28T00:00:00+01:00

When Following the Plan Means Dying Together

28.12.2025, By Stephan Schwab

On December 20, 1995, a highly trained crew flew a perfectly functioning aircraft into a Colombian mountainside. They followed their plan with precision. They trusted their instruments. They died anyway. In software development, we call this "staying on track" — and it kills projects just as surely as it killed Flight 965.

It was five days before Christmas. One hundred fifty-nine people were flying home to their families. Some had gifts in the overhead bins. Some were already thinking about the meals they would share, the faces they would see, the embraces waiting at the arrival gate in Cali.

They never arrived.

The Night the Mountain Won

"They were doing everything right. And they were flying directly into a mountain."

American Airlines Flight 965 was a routine trip from Miami to Cali, Colombia. The Boeing 757 was in perfect mechanical condition. The captain had over thirteen thousand hours of flight time. The first officer was experienced and competent. The weather was clear at altitude.

Nothing was wrong — except everything was about to go catastrophically wrong.

During the approach, air traffic control offered a shortcut. The crew accepted. A simple change to the plan. They began reprogramming the flight management computer, entering a new waypoint: “R” for Rozo, the navigation beacon near Cali.

But the letter R pulled up a different beacon first. One near Bogotá. One hundred thirty kilometers away. In the wrong direction.

The crew selected it. The aircraft, obedient as always, banked left and began flying away from Cali, directly toward the Andes.

They didn’t notice. The instruments showed them on course — the course the computer was following, not the course they intended. The pilots trusted the plan. They had entered it themselves. Why would they doubt it?

Outside the windows, invisible in the darkness, the mountains rose.

The Final Seconds

At 9:41 PM, the Ground Proximity Warning System screamed to life: “TERRAIN, TERRAIN. PULL UP. PULL UP.”

The captain reacted instantly. He slammed the throttles forward. He pulled the nose up hard. The aircraft responded — it was doing everything it could to climb, to escape, to live.

But someone had left the speedbrakes extended from the descent. Those panels on the wings, designed to slow the aircraft, were stealing the lift they desperately needed. The crew didn’t notice. They were focused on the climb. They were following the recovery procedure.

Six seconds later, Flight 965 struck the side of El Diluvio — “The Flood” — a ridge rising to nearly nine thousand feet.

Four passengers survived, thrown clear in the wreckage. One hundred fifty-nine people — parents, children, colleagues, friends — did not.

This Is Not Ancient History

I tell you this story not to dwell on tragedy but because I watch organizations fly into mountains every day.

Not literal mountains. Worse, in a way — invisible ones. Technical debt that experienced developers have warned about for years. Architectural decisions imposed by consultants who left before the consequences arrived. Roadmaps dictated by people who have never shipped software, forcing teams to build what cannot be built in the time that does not exist.

"The plan said we would be successful by now. The plan must be correct. Keep descending."

The crew of Flight 965 were not stupid. They were not careless. They were highly trained professionals operating expensive equipment according to documented procedures. They followed the plan.

And the plan flew them into a mountain.

The Seduction of the Plan

Plans are seductive. They offer certainty in an uncertain world. They let us tell stakeholders when we’ll be done. They create the illusion that we understand what we’re building, how long it will take, and what the future holds.

But plans are not reality. They are our best guess about reality at a moment in time — usually the moment when we knew the least about what we were attempting.

The crew of Flight 965 had a plan. It was filed with air traffic control. It was programmed into the computer. It accounted for fuel, time, waypoints, and altitude restrictions. It was a good plan.

It just didn’t account for a single wrong keystroke.

The Mountain Doesn’t Care About Your Plan

Here is the uncomfortable truth that every executive, every program manager, every Gantt chart enthusiast needs to understand:

Reality doesn’t negotiate.

The mountain didn’t care that the crew had a plan. The mountain didn’t care that the computer showed them on course. The mountain didn’t care about the captain’s thirteen thousand hours of experience or the airline’s safety record or the passengers’ Christmas plans.

The mountain was simply there. And when the aircraft’s path intersected with the mountain’s location, the mountain won. It always does.

Technical complexity is a mountain. Architectural constraints are a mountain. The laws of physics that govern how software systems behave under load — those are mountains. Every time management overrides developer judgment with a directive from consultants or a mandate from the boardroom, they are programming a new course. Sometimes that course leads into terrain nobody can see from the executive suite.

The Warning Systems We Ignore

"TERRAIN, TERRAIN. PULL UP."

Flight 965’s GPWS gave the crew a warning. It was loud. It was unmistakable. It was terrifying by design.

They had six seconds. It wasn’t enough — partly because the speedbrakes stole their climb rate, but also partly because the warning came too late. The old GPWS technology couldn’t see ahead; it could only detect the ground rushing up from below.

Your organization has warning systems too. Senior developers saying “this architecture won’t scale.” The team lead warning that the timeline is fantasy. Engineers explaining — again — why the approach mandated by the expensive consulting firm cannot work. Experienced voices, dismissed as “resistant to change” or “not team players,” because they refuse to pretend the mountain isn’t there.

These are your terrain warnings. They are screaming at you right now.

Are you listening? Or are you following the plan that someone outside your cockpit programmed for you?

After the Crash

The investigation into Flight 965 changed aviation. The industry developed Enhanced Ground Proximity Warning Systems — EGPWS — that use GPS and terrain databases to see mountains ahead, not just below. Airlines revised their procedures for programming flight computers. Training emphasized situational awareness over blind trust in automation.

One hundred fifty-nine people died, and an industry learned.

But not every organization learns from disaster. Some respond by buying solutions from the same people who sold them the problem.

The Framework That Forbids Learning

There is another way organizations fly themselves into mountains: they buy management frameworks that promise to “fix” developers. Make them predictable. Make them flow smoothly through a process like widgets on an assembly line. The sales pitch always includes the word “learning” — continuous improvement, feedback loops, adaptation.

But then comes the implementation.

The framework gets installed by people who have never written production code. The trainers leave. And what remains is a system that punishes learning. Going back is failure. Refactoring is waste. Changing direction after discovering new information is deviation from the plan. The entire apparatus is designed around the illusion that work flows forward and never returns — that you can know everything at the start and simply execute.

This contradicts everything we know about building software. Test-Driven Development works precisely because you go back. You write a failing test, you make it pass, you refactor. Red, green, refactor. The cycle is the learning. Every iteration teaches you something about the problem you couldn’t have known before you started.

But the framework was sold on the promise that management would finally have visibility and control. That developers would become predictable resources. That estimates would become commitments and commitments would become delivery dates. Going back wasn’t part of the sales pitch.

So when developers try to refactor — try to learn, try to improve — they are told to stop. The milestone is fixed. The timeline is approved. The resources are allocated. There is no time for learning. There is only time for execution. This is how organizations destroy their developers’ intrinsic motivation — by treating thinking as a bug rather than a feature.

And the aircraft descends, confident and controlled, toward a mountain that the framework’s dashboards don’t show.

When the Method Becomes the Master

"We can see the runway. We are not allowed to land on it."

There is a subtler danger than flying into a mountain. Sometimes organizations create policies so rigid that even when pilots can see the runway clearly, they are forbidden to land.

On October 16, 2023, Lufthansa flight LH458 — an Airbus A350 from Munich — approached San Francisco International Airport. The weather was clear. The runway was visible. The aircraft was functioning perfectly. The crew was experienced and alert.

But SFO was operating visual approaches only that night. And Lufthansa’s corporate policy, instituted after the terrifying 2017 Air Canada near-disaster where a fatigued crew almost landed on a taxiway full of aircraft, prohibited its pilots from accepting visual approaches at night. The policy required an instrument approach — ILS or satellite-guided — regardless of conditions.

The ILS was off. The crew could see the runway. They were not allowed to land on it.

So they declared a fuel emergency and diverted to Oakland. The passengers were bussed back to San Francisco. Nobody died. But a planeload of people spent hours on a bus because company policy had become more important than pilot judgment.

This is what happens when organizations respond to failure by removing discretion. After Air Canada 759 nearly killed over a thousand people by confusing a taxiway for a runway during a visual approach, Lufthansa’s response was rational: ban night visual approaches entirely. Remove the possibility of human error by removing human judgment.

But policies cannot anticipate every situation. The crew of LH458 was not fatigued. They were not confused. They could see exactly where they needed to go. The policy, designed to prevent one kind of failure, created a different kind of absurdity.

In software organizations, this happens constantly. A project fails because developers made autonomous decisions that management didn’t understand. The response? Remove developer autonomy. Institute approval processes. Require sign-offs. Mandate that all technical decisions flow through non-technical managers who have been trained by framework salespeople to distrust the very people who build the software.

The developers can see the runway. They know how to land. But they are not allowed to. The method has become the master. The policy exists to protect against a failure that isn’t happening, while creating new failures that nobody anticipated.

And sometimes the company doesn’t divert to Oakland. Sometimes it runs out of fuel. Reclaiming your organization means trusting the people who actually fly the aircraft.

The Choice That Matters

Every day, leaders face a choice: follow the plan or follow reality.

Following the plan is comfortable. It means the quarterly report looks predictable. It means nobody has to explain why the roadmap changed. It means the expensive management framework you bought is working as advertised.

Following reality is hard. It means admitting uncertainty. It means telling stakeholders the truth. It means trusting the people closest to the work to tell you what’s actually happening — and believing them when it contradicts your carefully constructed plan.

The crew of Flight 965 followed their plan. They trusted their computer. They descended confidently through the darkness, believing they knew where they were.

They were wrong. And because they were wrong, one hundred fifty-nine people never saw Christmas.

How many projects must die before your organization learns? How many millions must be written off? How many talented developers must burn out and leave, their warnings vindicated too late? How many companies must die — actually die, doors closed, everyone gone — before leadership understands that the people in the cockpit might know more about flying than the people in the boardroom?

Your Mountain Is Waiting

Somewhere in your organization right now, an experienced developer is raising a concern. They are saying the timeline is impossible. They are explaining why the architecture mandated from above cannot support the planned features. They are pointing out that the approach imposed by outside consultants contradicts everything they know about building software that actually works.

They are your terrain warning. They are screaming at you.

What will you do?

Will you follow the plan that was handed down from above? Will you stay on course, forcing your experienced crew to execute a flight path they know is wrong, dismissing their warnings as negativity or resistance to change?

Or will you trust the people who actually fly the aircraft — and let them see the mountain before it kills everyone aboard?

One hundred fifty-nine people died five days before Christmas because trained professionals trusted their plan more than they trusted reality.

The mountain is still there. It is always there.

The only question is whether you will see it in time.

El Pitch Perfecto

2025-12-25T00:00:00+01:00

The Night Everything Seemed Possible

Bogotá. Six months ago.

The rooftop terrace of the W Hotel gleams against the night sky. Below, the city sprawls in a river of lights stretching toward the mountains. Up here, above it all, champagne flows.

Don Hernando Castillo stands at the center of the celebration, his leather boots incongruous against the polished concrete floor. Around him, the young people he’s bet his legacy on are drunk on something stronger than the Moët — they’re drunk on possibility.

“Quince millones de dólares,” he says, raising his glass. His voice carries the authority of a man who has commanded cattle drives across the Llanos, who has stared down guerrillas and survived the dark years. “Fifteen million dollars. They believed in us.”

Sebastián Duarte, the co-founder who built the first prototype in his parents’ garage, can barely contain himself. His hoodie is out of place among the cocktail dresses and blazers, but tonight he doesn’t care. He catches Isabella Moreno’s eye across the crowd and smiles — the unguarded smile of someone who believes the hard part is over.

Isabella smiles back, but there’s something reserved in it. She’s learned not to celebrate too early. Daughters of taxi drivers know that money promised is not money in hand.

“Eight months,” Don Hernando continues. “That’s what we told them. Eight months and we deliver a platform that will change how Colombia pays, saves, invests. That will bring the unbanked into the economy.” He pauses, eyes scanning the crowd. “We have given our word. Mi palabra es mi firma.”

At the edge of the terrace, Alejandro Vega — Alejo to those who think they know him — raises his own glass with a smile that never quite reaches his eyes. He’s already calculating. Eight months. Fifteen million in runway. And three competitors who would kill to know what FinPulso is building.

“Por FinPulso,” Alejo says smoothly, stepping forward. “And for Don Hernando, who had the vision to see what we could become.”

The crowd echoes the toast. Don Hernando nods, pleased. This one, Alejo — he’s sharp. Reminds him of his son, before… He pushes the thought away. Tonight is for the future.

Diego Vargas stands alone near the railing, nursing a beer instead of champagne. His girlfriend Luciana is somewhere in the crowd, probably taking photos for her Instagram. He should be happy. The Series A means job security, real salaries, maybe even that apartment in Chapinero they’ve been looking at.

But something gnaws at him. The demo they showed the investors — the one with the “AI-powered fraud detection” — he knows what’s really behind that curtain. And eight months…

Camila Torres, the newest member of the team, approaches him quietly. At 25, she’s still learning to navigate these events.

“You don’t look like someone who just got funded,” she says.

Diego almost smiles. “Have you looked at the codebase?”

“Some of it.”

“Then you know.”

Camila doesn’t answer. She looks out at the city lights instead. Diego is the best developer she’s ever met, and if he’s worried…

On the far side of the terrace, a sleek Italian in a cashmere sweater is making his entrance. Marco Benedetti, “Agile Transformation Consultant,” has been in Bogotá for two weeks. He came for a conference. He stayed for the opportunities.

His eyes find Luciana immediately — the blonde with the phone, the one who’s been posting stories all night. He’s done his research. Marketing Director. Boyfriend is some developer. And she’s clearly bored of this party.

He smiles. In Europe, they know how to have a real celebration.

"Quince millones de dólares. They believed in us."

Six Months Later

The same rooftop. Same city. Different world.

Rain hammers the terrace. The W Hotel’s party space is empty tonight except for one figure standing where Don Hernando stood six months ago. Sebastián stares at his phone, at the message that just arrived:

Emergency board meeting. Tomorrow, 8am. Non-negotiable. — Mariana Ríos, Vulcano Capital

He scrolls up. More messages. The group chat is on fire.

Alejo Diego hasn't responded in two weeks.

Isabella The staging environment is down again.

Pipe Nobody else has the production credentials.

Alejo This is unacceptable.

Isabella Has anyone actually SEEN Diego?

Luciana He moved out last month. I don't know where he is.

Alejo @Sebastian, you're technically CTO. Fix this.

Sebastián’s hands shake. CTO. The title they gave him when Don Hernando took over as CEO. A title without power, without authority, without even access to the servers that run their own product.

His phone rings. The screen shows: DON HERNANDO.

He doesn’t answer. He already knows what the old man will say. En mi finca, los que no rinden se van. On my ranch, those who don’t perform leave.

But this isn’t a ranch. Cattle don’t debug authentication errors at 3am. Bulls don’t write unit tests. Horses don’t carry the entire institutional knowledge of a payment platform in their heads and then disappear without a trace.

He looks out at the rain-soaked city. Somewhere out there, Diego Vargas is alive, theoretically. Somewhere out there are the credentials to production. Somewhere out there is the truth about what their “AI-powered” demo actually does.

Eight months, they said.

Six have passed.

And tomorrow, Sebastián will have to explain to a boardroom full of people who have never touched code why their fifteen-million-dollar investment is burning.

The Morning After

The FinPulso office occupies the fourth floor of a renovated building in Chapinero. Exposed brick, Edison bulbs, a foosball table that no one uses anymore — the standard startup aesthetic that once seemed revolutionary and now feels like a costume.

Laura Méndez is the first to arrive, as always. She’s been Don Hernando’s assistant since the ranch days, and she knows how to read the weather. Today, the old man will be dangerous.

She prepares the conference room: coffee strong enough to wake the dead, water for those who can’t stomach it, and the emergency bottle of aguardiente hidden in the credenza for when things really go south.

By 7:30, they begin to filter in.

Pipe — Felipe Gómez — looking like he hasn’t slept. At 44, he’s the oldest developer on the team, the one who survived every technology transition from COBOL to cloud. He’s seen consultants come and go. He’s seen startups rise and fall. He knows, with the bone-deep certainty of experience, that this meeting will not end well.

Isabella arrives next, her colorful earrings bright against the gray morning. She makes eye contact with Sebastián through the glass walls of the conference room, and something passes between them — worry, solidarity, something neither will name.

Alejo is already seated, reviewing documents on his tablet, perfectly composed in his Italian suit. Of course he is. In a crisis, Alejo is always composed. It’s one of the things Don Hernando admires about him.

Luciana slips in last, sunglasses still on despite being indoors. She’s been crying — Laura can tell. She’s seen enough crying women in her decades with Don Hernando. Something about that Italian consultant, probably. Laura doesn’t approve of him. Too smooth. Like a snake in cashmere.

Speaking of which — where is Marco?

“He’s not invited,” Alejo says, reading her thoughts. “This is internal.”

Laura nods but doesn’t like it. Internal means Don Hernando will shout. Internal means someone will be blamed.

At 7:55, Don Hernando Castillo walks in.

He’s wearing the same boots he wears to check on cattle at dawn. The same gold watch his father wore. The same expression he uses when a ranch hand has disappointed him.

“Dónde está Diego?” he asks. His voice is quiet. This is worse than shouting.

Silence.

“I asked a question.” Still quiet.

Sebastián clears his throat. “We… don’t know, Don Hernando. He stopped coming to the office three weeks ago. He’s not answering calls or messages. Luciana says—”

“I don’t care what Luciana says.” Don Hernando doesn’t look at her. “I care about my eight million dollars. I care about what I will say to Mariana Ríos when she arrives in —” he checks his father’s watch “— three minutes.”

He walks to the head of the table and remains standing. “So. Someone explain to me. In simple words a cattle rancher can understand. Why does one developer, one employee, have the keys to my entire company?”

Pipe mutters something.

“Speak up.”

Pipe looks at Sebastián, then at Alejo, then decides he’s too old to care about politics. “Because we let it happen. Because it was easier. Because Diego was the only one who understood the whole system, and instead of documenting and sharing, we just… kept asking him to do more.”

Don Hernando’s eyes narrow. “And where were the managers while this was happening?”

Everyone looks at Sebastián.

Sebastián feels the blood drain from his face. “I… we were moving fast. There was so much pressure after the funding—”

“Pressure I created?”

“No, Don Hernando, I didn’t mean—”

The door opens. Mariana Ríos enters, escorted by a nervous-looking receptionist. She’s Brazilian, elegant, efficient. She manages the Colombia portfolio for Vulcano Capital, and she’s flown in from São Paulo specifically for this meeting.

“Good morning,” she says. Her Spanish is accented but precise. “I trust we can skip the pleasantries.”

She takes a seat, opens her laptop, and looks at Don Hernando with the calm expectation of someone who has seen dozens of companies fail and has learned not to feel anything about it.

“The board received concerning information last week. I’m here to understand three things.” She holds up fingers. “One: why the platform that was demonstrated during due diligence does not appear to function in production. Two: why your lead developer has disappeared. Three: what you intend to do about it.”

Don Hernando’s jaw tightens. He looks at Alejo.

Alejo clears his throat, unfazed. “Mariana, these are excellent questions. And I want to assure you that we have identified the issues and are already implementing corrective measures—”

“I wasn’t asking you, Alejandro.” Her gaze hasn’t left Don Hernando. “I was asking the CEO.”

The room freezes.

Don Hernando has not been spoken to this way since… since ever. He is the patriarch. He is the investor. He is the one who asks questions, not the one who answers them.

But he is also the one who has put eight million dollars of his own money into this company. The money he was saving for his son. The money that was supposed to build a legacy.

He sits down. For the first time in this room, he sits.

“I don’t know,” he says. The words seem to cost him. “I don’t understand this technology. I trusted the people who do.”

“And where are those people now?”

Sebastián raises his hand like a schoolboy. “I’m here. I’m the CTO. Or at least, that’s my title.”

Mariana’s eyes assess him. “Tell me, CTO. What is the actual state of the platform?”

"I don't understand this technology. I trusted the people who do."

Sebastián looks around the table. Alejo gives him a tiny shake of the head — don’t say too much. Don Hernando’s face is stone. Isabella nods slightly — tell the truth.

He takes a breath.

“The staging environment is unstable. We don’t have access to production because the credentials died with Diego’s departure. The ‘AI-powered fraud detection’ that we showed you…” He pauses, swallows. “It’s not AI.”

“What is it?”

“A team of contractors in Venezuela. Manual review. We were going to build the real thing, but there was never time, and Diego was the only one who—”

“Manual review?” Mariana’s voice is ice. “We invested fifteen million dollars in a company whose core differentiating feature is a lie?”

“It was a temporary measure—”

“Is it in production? Are real users being served by manual contractors pretending to be artificial intelligence?”

Silence.

“I’ll take that as a yes.”

Don Hernando’s face has gone gray. He looks at Alejo. “Did you know about this?”

Alejo spreads his hands. “I’m CFO, Don Hernando. I review financial statements. The technical team assured me—”

“I’m asking if you knew.”

Something flickers in Alejo’s eyes. “I suspected. I chose to trust the experts.”

Mariana closes her laptop. “I’ve heard enough. The board will need to discuss next steps. I recommend you find your missing developer and regain control of your own systems before we meet again.” She stands. “You have two weeks.”

She leaves.

The conference room is silent except for the rain against the windows.

Don Hernando rises slowly. He looks at each face around the table, lingering on Sebastián, on Alejo, on the empty chair where Diego should be sitting.

“Two weeks,” he says. “Find Diego. Fix this. Or I will find people who can.”

He walks out.

Laura quietly retrieves the bottle of aguardiente from the credenza.

They’re going to need it.

Aftermath

Sebastián finds Isabella on the building’s rooftop terrace — the actual roof, not the fancy one with the Edison bulbs. It’s still raining. She doesn’t seem to care.

“Well,” she says without turning. “That could have gone better.”

He stands beside her, letting the rain soak his hoodie. “Do you think she’ll pull the funding?”

“Mariana? No. Not yet. VCs don’t like to admit failures any more than we do. She’ll push for changes first. Probably a new CEO. Probably an ‘advisor’ with significant influence.”

“Don Hernando won’t give up control.”

Isabella laughs, but there’s no humor in it. “Don Hernando’s only alternative is admitting he bet his son’s legacy on a company that was lying to him from day one. Which would mean admitting he was wrong. When has that ever happened?”

She turns to face him. The rain has plastered her curly hair to her face, and her eyes are tired but fierce.

“We need to find Diego.”

“I know.”

“And we need to tell the truth about what we’ve built. All of it.”

“I know.”

“Alejo won’t let that happen. He’s already spinning narratives. By tomorrow, this will all be Diego’s fault — the rogue developer who sabotaged the company. It’s a clean story. The board will believe it.”

Sebastián watches the water pool on the concrete. “What if I don’t let him?”

“You?” Isabella’s voice is gentle but honest. “You gave up the CEO title, Sebastián. You don’t have the power to stop him.”

“I have the truth.”

“The truth doesn’t matter if no one believes you.” She puts a hand on his arm. “I’m not saying give up. I’m saying be smart. Document everything. Find allies. And for God’s sake, find Diego before Alejo does.”

“Why would Alejo want to find Diego?”

Isabella’s expression darkens. “To make sure he never comes back.”

She heads for the door, then pauses. “Oh, and Sebastián? That Italian consultant — Marco Benedetti? He and Luciana are together now. That’s why Diego left.”

The door closes behind her.

Sebastián stands alone in the rain, processing. Diego’s disappearance. Luciana’s betrayal. Marco’s convenient timing. Alejo’s always-composed face.

His phone buzzes. A WhatsApp message from a number he doesn’t recognize:

Unknown They're going to blame me for everything, aren't they?

He stares at the screen. Types quickly:

Sebastián Diego? Is that you?

Unknown Don't use my name. They're probably reading this.

Sebastián Where are you? We need to talk.

Unknown Check your email. Personal account. Not corporate.

Unknown And Sebastián? Don't trust anyone.

Unknown Especially not the people smiling at you.

The messages disappear — auto-delete. The number goes inactive.

Sebastián’s hands are shaking as he pulls out his laptop, finds a dry corner of the terrace, and logs into his personal email.

One new message. Sent three weeks ago. Subject line: Read this before it’s too late.

Attached: a 47-page document titled Technical Risk Assessment: FinPulso Platform — Confidential.

Author: Diego Vargas.

Date: Four months ago.

“Hijo de puta,” he whispers. Four months. Diego tried to warn them four fucking months ago.

Sebastián starts reading. His stomach drops with every page.

By page five, his face is the color of ash. His hands tremble so badly he can barely scroll.

By page twenty, bile rises in his throat. He has to stop, press his palm over his mouth, force himself to breathe.

By page forty-seven, tears are streaming down his face and he knows — with the cold certainty of a man watching his house burn — that what happened in that boardroom today was only the beginning.

The One Who Stayed

Night. The FinPulso office is dark except for one desk lamp.

In the dark, a junior developer writes clean code.

Camila Torres sits alone at her workstation, headphones on, code scrolling across her screen. The others left hours ago. She doesn’t mind. She works better alone.

Her screen shows a different repository than the main FinPulso codebase — a personal project, something she’s been building in her spare time. Same functionality as the main platform, but clean. Tested. Deployable.

She’s been building it for months, using every technique she learned from YouTube tutorials and online courses. TDD. Clean architecture. Automated deployment. Everything Diego tried to implement before they made it impossible.

She doesn’t know if anyone will ever see it. Probably not. She’s just a junior developer, and in this company, juniors don’t speak in meetings.

Her phone buzzes. A message from an unknown number:

Unknown I know what you've been building.

Unknown Keep going. Don't let them see it yet.

Unknown When the time comes, you'll know.

She looks at the screen, then at the empty office around her, then back at her code.

“Okay, Diego,” she murmurs. “Okay.”

She puts her headphones back on and keeps working.

Outside, the rain finally stops. Tomorrow, the sun will rise on a company in crisis, on secrets about to unravel, on alliances about to form and break.

But tonight, in the dark, a junior developer writes clean code.

And somewhere in the city, a man with no credentials reads a document he wrote months ago — a warning that nobody heard.

And on a finca in the Llanos, Don Hernando Castillo stands on the porch of his hacienda, looking at the stars, wondering where he went wrong.

He thinks of his son. The arguments. The dismissal. The funeral.

He thinks of the fifteen million dollars. The legacy he’s trying to build.

He thinks of the young people in that Bogotá office, with their hoodies and their code and their secrets.

And for the first time in a very long time, Don Hernando Castillo is afraid.

Next Episode: "La Nueva" Stefan Richter arrives in Bogotá. The German Developer Advocate isn't what anyone expected — and he's asking questions no one wants to answer.

Software Development Is Design

2025-12-22T00:00:00+01:00

The Creative Heart of Building Software

22.12.2025, By Stephan Schwab

Software development shares more with architecture, industrial design, and creative problem-solving than with manufacturing or construction. Understanding development as a design discipline — iterative, exploratory, and collaborative — reveals why great software emerges from skilled teams solving real problems, and how organizations can create conditions for remarkable digital products.

What Design Really Means

When we hear “design,” we might think of beautiful interfaces, elegant furniture, or striking buildings. But design, at its core, is something more fundamental: the thoughtful arrangement of elements to solve problems and create value for people.

"Design is not just what it looks like and feels like. Design is how it works." — Steve Jobs

An industrial designer creating a new chair considers ergonomics, materials, manufacturing constraints, aesthetics, durability, and cost — all while keeping the person who will sit in it at the center. An architect balances structural integrity, natural light, traffic flow, building codes, budget, and the daily experiences of inhabitants.

Software developers do exactly this kind of work. They consider user needs, system constraints, performance requirements, security implications, maintainability, and business objectives — all while crafting something that serves real people in real situations.

The Journey of Discovery

Every design project begins with incomplete information. Architects don’t know exactly how occupants will use a building until people move in. Product designers prototype extensively because sketches can’t reveal how something feels in your hand. Fashion designers create samples because fabric behaves differently on a body than on paper.

"The best software emerges from continuous dialogue between what's possible, what's needed, and what we learn along the way."

Software development follows this same pattern of discovery. The most effective teams embrace this reality: they build small pieces, put them in front of users, observe what happens, and refine their understanding. Each iteration teaches something that couldn’t be known in advance.

This isn’t a weakness or sign of poor planning. It’s the nature of design work. The medium reveals its possibilities through engagement.

Craftsmanship in the Digital Realm

Watch a skilled woodworker select boards for a project. They consider grain direction, moisture content, how the wood will move over years, and which pieces will create visual harmony. Their expertise guides countless micro-decisions that add up to something beautiful and lasting.

Software developers exercise similar craftsmanship. When building a feature, experienced developers consider how data flows through the system, how the code will behave under stress, how future developers will understand and modify it, and how it will evolve as business needs change.

"Great software, like great furniture or great architecture, reflects deep expertise applied thoughtfully to real problems."

This craftsmanship isn’t visible in the final product the way woodgrain is visible in furniture. But its presence or absence becomes apparent over time. Well-crafted software adapts gracefully to new requirements. It performs reliably under pressure. It welcomes modifications without cascading problems.

Collaboration Creates Excellence

The most celebrated buildings emerge from close collaboration between architects, structural engineers, interior designers, and clients. No single person holds all the expertise. The magic happens in the space between disciplines.

"Software development is a team sport where diverse perspectives create better solutions than any individual could imagine."

Software development works the same way. Business experts understand customer needs and market dynamics. Designers understand human behavior and interface conventions. Developers understand technical possibilities and constraints. Operations specialists understand deployment and reliability.

When these perspectives come together in genuine collaboration — not just handoffs between silos — the results are remarkable. Each discipline enriches the others. Technical constraints inspire creative solutions. User insights reveal opportunities that pure analysis would miss.

The Medium Shapes the Work

Every design discipline has its medium, and the medium shapes what’s possible. Sculptors working in marble create differently than those working in clay. Architects designing with glass and steel think differently than those working with timber and stone.

Software’s medium is unique. Unlike physical materials, code remains malleable after creation — a finished feature can be reshaped, extended, or fundamentally rethought without starting over. Unlike buildings or products, software can be updated after delivery, can respond to individual users, and can connect with other systems in ways that create emergent capabilities.

"Software's malleability is both its greatest strength and its most demanding characteristic."

This malleability means software can evolve with changing needs in ways that physical products cannot. But it also means the design process never truly ends. The best software organizations embrace this continuous nature, treating every release as the current best answer rather than the final answer.

Creating Conditions for Great Work

"The organizations that build remarkable software are those that treat development as a creative endeavor worthy of investment and respect."

What enables excellent design work? The same conditions appear across disciplines:

Time for exploration. Designers need space to try approaches that might not work. Premature commitment to the first idea rarely produces the best outcome. The most elegant solutions often emerge after exploring several possibilities.

Direct engagement with users. Designing for abstract personas produces abstract results. Designers who regularly observe real people using their work develop intuition that no specification can provide.

Cross-functional dialogue. When perspectives stay in silos, solutions become compromised by handoffs. When disciplines work together continuously, solutions become enriched by diverse expertise.

Pride in craft. People who care about quality create quality work. Organizations that celebrate craftsmanship attract and retain talented practitioners who take pride in their creations.

What This Means for Organizations

Understanding software development as design work suggests practical approaches:

Invest in talent. Just as you’d want the best architect for a significant building, you want skilled developers for significant software. The difference between adequate and excellent practitioners is profound — not just in speed, but in the quality and longevity of what they create.

Enable iteration. Create mechanisms for frequent feedback. Let teams release small increments and learn from actual usage. The cost of early course corrections is far less than the cost of late discoveries.

Foster collaboration. Break down barriers between business, design, and technical teams. Encourage regular, informal interaction rather than formal handoffs. Great solutions emerge from ongoing dialogue.

Value the invisible. Much of what makes software excellent isn’t visible to non-practitioners: thoughtful architecture, comprehensive testing, clear documentation, security consciousness. Trust your technical teams when they invest in these foundations.

Think long-term. Like a well-designed building, well-designed software serves for years. Decisions made under short-term pressure often create long-term costs. Balance immediate needs with sustainable practices.

The Joy of Creation

There’s something deeply satisfying about design work done well. The architect who sees a building come to life, the industrial designer whose product appears in stores, the craftsperson who delivers something beautiful and useful — they experience a particular joy in creation.

"Software developers are among the few people who get to create something from nothing every day — and see people use it immediately."

Software developers experience this joy too. They envision solutions, shape them into existence, and see people using their creations — often within days or weeks rather than the years typical in physical design. This rapid feedback loop, when organizations support it, creates an energizing cycle of creation and learning.

The most effective software organizations tap into this creative energy. They recognize that engaged developers who take pride in their work produce better results than disengaged developers following specifications. They create environments where skilled practitioners can exercise their expertise fully.

Looking Forward

As software becomes more central to how organizations operate and compete, understanding its nature becomes more valuable. The organizations that thrive will be those that appreciate software development for what it is: a creative, collaborative, design-driven endeavor.

This perspective opens new possibilities. Instead of asking “Why can’t we predict exactly when this will be done?” leaders can ask “How can we learn faster about what will actually serve our customers?” Instead of measuring success by adherence to original plans, they can measure success by value delivered and capabilities gained.

The future belongs to organizations that embrace the design nature of software development — that invest in skilled practitioners, enable iterative discovery, foster genuine collaboration, and take pride in the digital products they create.

Software development is design. And like all design disciplines, it rewards those who engage with it thoughtfully, patiently, and with genuine respect for both the craft and the people who practice it.

It's Just a Simple Rewrite

2025-12-19T00:00:00+01:00

When “We Just Need to Translate It” Meets Reality

19.12.2025, By Stephan Schwab

The leadership team was confident: twenty years of working Delphi code, clear requirements, and a modern Java stack. What followed was two and a half years of blown estimates, a fired contractor, a key developer who quit in disgust leaving a crippling knowledge gap, tears in meetings, and a €90,000 detour into management consulting that made everything worse. This fictional account of a German Systemhaus shows how a "simple" rewrite nearly destroyed the company — and how they eventually found their way through.

The Company That Time Built

Hartmann & Söhne started in 1998 as a classic German Systemhaus — a software house serving a specific industry vertical. Their niche: configuration and order management for specialized industrial machinery. When a manufacturer needed to quote a complex custom machine with hundreds of configurable options, pricing rules, and engineering constraints, Hartmann’s software handled it.

"Twenty years of domain knowledge encoded in 800,000 lines of Delphi. Every edge case a customer ever encountered became a feature."

The application, called MaschinenKonfigurator, became the standard in its market. Built in Borland Delphi with a local SQL Server database, it ran on customer premises. The software accumulated two decades of domain expertise: complex pricing algorithms, regulatory compliance rules for different export markets, integration with CAD systems, and the peculiar logic of industrial machinery configuration.

Klaus Hartmann, the founder’s son and now managing director, faced an uncomfortable reality in 2024. The Delphi ecosystem had contracted. Finding developers who understood Object Pascal was increasingly difficult. Their best developer, who had been with the company since 2003, was approaching retirement. Customers were asking about cloud access, multi-location deployment, and integration with modern ERP systems.

The decision seemed obvious: rebuild as a modern SaaS application. What followed proved far more complex than anyone imagined.

The Initial Enthusiasm

The leadership team gathered for what Klaus called a “transformation kickoff.” They had already made key technology decisions: Java with Spring Boot for the backend, a modern JavaScript framework for the frontend, PostgreSQL for the database, Kubernetes on AWS for hosting.

“We know exactly what the software needs to do,” Klaus said. “We have twenty years of working code. We just need to translate it to modern technology.”

Thomas, the head of development, nodded cautiously. “The business logic is all there. We documented most of it over the years.”

Maria, the product manager who had joined from a larger software company three months earlier, raised her hand. “How long did it take to build the original system?”

Thomas calculated. “The first version shipped after eighteen months. But we’ve been adding features continuously for twenty years.”

“So we’re not really rebuilding eighteen months of work,” Maria observed. “We’re rebuilding twenty years of accumulated capability.”

The room went quiet. Klaus looked at Thomas, who avoided his eyes. In the corner, Heike — the senior Delphi developer who had been with the company since 2003 — crossed her arms and said nothing. She had seen rewrites proposed before. None had happened. This time felt different — and not in a good way.

The Estimation Trap

The first planning sessions revealed a familiar pattern. The development team, now augmented with contractors experienced in Java and Spring Boot, began estimating the rewrite.

“User authentication and authorization — two weeks.”

“Basic configuration engine — three months.”

“Pricing rules — six weeks.”

“CAD integration — four weeks.”

The estimates accumulated into a comfortable eighteen-month timeline. Klaus approved the budget. The team began work with confidence.

"We estimated translating code. We should have estimated rediscovering decisions."

Three months later, the authentication system was complete. The basic configuration engine existed but couldn’t handle the edge cases that made MaschinenKonfigurator valuable. The pricing rules, supposedly a six-week effort, had consumed two months and covered perhaps thirty percent of the actual complexity.

Thomas called an emergency meeting. “We’re not translating code. We’re rediscovering why the code was written that way in the first place.”

Martin, one of the Java contractors, pushed back. “Maybe if the original developers had documented their work properly, we wouldn’t be guessing.”

The room temperature dropped. Heike, who had been quietly reviewing a printout, looked up. “We documented everything that seemed important at the time. Twenty years of everything is a lot of documentation. Would you like me to show you where it is, or would you prefer to keep complaining?”

Klaus intervened before the situation escalated further. But the damage was visible. The new developers saw the legacy team as obstacles. The legacy team saw the new developers as arrogant newcomers who didn’t understand what they were dismantling.

The Knowledge Problem

The Delphi codebase contained twenty years of decisions. Some were documented. Most lived only in the code itself — or in the memories of developers who had moved on.

Heike became the project’s most valuable resource — though it took weeks for the new team to recognize it. She could look at a block of Object Pascal and explain: “This handles the case when a customer configures a machine for the Japanese market but wants German safety certifications for re-export. We added it in 2011 after losing a major order.”

"Every line of legacy code is a decision someone made. Rewriting means re-making those decisions — often without knowing why they were made originally."

The new Java developers would implement a feature, demonstrate it to Heike, and watch her shake her head. “That works for standard configurations. But what about combination constraints? What about legacy pricing agreements? What about the machines configured before we changed the component numbering scheme in 2015?”

Each “simple” feature had tentacles reaching into edge cases that only became visible when someone tried to use the system the way real customers did.

The Pivot: Running in Parallel

Six months into the project, Klaus faced a difficult decision. The new system had consumed half the budget but delivered perhaps twenty percent of the required functionality. Continuing the same approach meant either dramatically increasing the budget or delivering a system that couldn’t replace the original.

Maria proposed a different strategy. “What if we don’t try to replace MaschinenKonfigurator all at once? What if we run both systems in parallel and migrate capability by capability?”

The approach had trade-offs. Running two systems increased operational complexity. Customers would need to work with both during the transition. But it offered something the original plan lacked: the ability to learn and adjust without betting everything on a single outcome.

The team restructured the project around three principles:

Capability migration, not code translation. Instead of translating Delphi modules to Java, they identified discrete capabilities customers actually used. Each capability became a self-contained piece of the new system.

Production validation at every step. Each capability went to production as soon as it was ready, running alongside the legacy system. Customers could choose which system to use for that function.

Continuous learning loops. Every capability deployment included telemetry. Usage patterns, errors, and performance metrics guided prioritization.

The First Real Victory

The team chose pricing calculations as their first target. Pricing was complex but relatively self-contained — it consumed configuration data and produced quotes without deep integration into other parts of the system.

Building the pricing engine took three months, not six weeks. But this time, the team had Heike reviewing every algorithm, comparing outputs against the Delphi system, and identifying edge cases before customers encountered them.

"The new pricing engine handled in milliseconds what the old system needed minutes to calculate. Customers noticed immediately."

The new pricing engine launched as an optional feature. Customers could generate quotes using either system. Telemetry tracked accuracy — did the new engine produce the same results as the old one?

The first week revealed three edge cases the team had missed. By the second week, those were fixed. By the fourth week, most customers had switched to the new engine permanently. It was faster, accessible from any browser, and produced identical results.

More importantly, the team had learned something: the new system didn’t need to replicate every feature of the old one. It needed to replicate the capabilities customers actually used.

The Configuration Engine Challenge

Pricing was the warmup. The configuration engine — the heart of MaschinenKonfigurator — presented a different magnitude of challenge.

The Delphi configuration engine encoded rules that had evolved over twenty years. Which components were compatible with which bases. What regulatory requirements applied in different markets. How customer-specific pricing agreements modified standard rules. The dependencies formed a web that no single person fully understood.

Thomas proposed an unconventional approach: “We’re not going to rebuild the configuration engine. We’re going to build a new one that learns from the old one.”

"Instead of translating rules, we treated the legacy system as the source of truth and built a system that could validate against it continuously."

The team built the new configuration engine with explicit rule definitions — clear, testable, documented. But every configuration the new engine produced was also run through the legacy Delphi system. Discrepancies triggered investigations.

This “shadow mode” approach served multiple purposes. It validated correctness. It exposed undocumented rules when the systems disagreed. And it built confidence among the team that the new system actually worked.

The configuration engine took eight months instead of the originally estimated three. But when it launched, it launched with confidence.

The Human Dimension

Technical challenges weren’t the only obstacles. The transformation strained the organization in ways Klaus hadn’t anticipated — and nearly broke it.

The first major crisis came three months after the pivot to parallel running. Jürgen, a Delphi developer who had been with the company for twelve years, requested a private meeting with Klaus.

“I can’t do this anymore,” Jürgen said. His voice was steady, but Klaus noticed his hands were shaking. “Every day I come in and watch contractors tear apart code I spent years building. They don’t ask why things work the way they do. They just rewrite it and then blame us when it breaks.”

“We need you, Jürgen. You know the pricing module better than anyone.”

“That’s the problem.” Jürgen’s composure cracked slightly. “I’m not a resource to be mined. I’m a person. And I’m tired of being treated like a museum exhibit everyone needs to visit before they can do their real work.”

Klaus promised changes. Jürgen agreed to stay — for now.

Two weeks later, Martin, one of the Java contractors, pushed too far. In a team meeting, he openly mocked a section of Delphi code displayed on screen. “Who wrote this spaghetti? This is why legacy systems need to die.”

Jürgen had written that code. He stood up slowly, face pale. “I wrote it. In 2014. When we had three days to fix a critical bug for our largest customer. It’s not elegant, but it’s worked for ten years without a single failure.” His voice broke on the last words. He left the room.

The silence that followed was devastating. Lisa, a junior developer who had been taking notes, started crying. She wasn’t sure why — the accumulated tension had simply become too much.

"Legacy code isn't ugly code. It's code that survived. Mocking it means mocking the people who kept the company alive."

Klaus found Jürgen in the parking lot, sitting in his car. He wasn’t coming back inside.

“I’m done,” Jürgen said. “I’ll work out my notice period, but I’m not attending any more meetings with those people.”

No amount of persuasion changed his mind. Jürgen left four weeks later, taking with him irreplaceable knowledge of the pricing engine’s most complex algorithms. The team spent the next two months reverse-engineering code he could have explained in an afternoon.

As for Martin — Klaus fired him the next day.

“You can’t fire me for having an opinion,” Martin protested.

“I’m firing you for creating a hostile environment that cost us a twelve-year employee,” Klaus replied. “Your opinion destroyed more value in five seconds than you created in five months. Clear your desk.”

Martin threatened legal action. Nothing came of it. But word spread quickly among the remaining contractors: the old rules had changed.

Meanwhile, Heike had stopped coming to the integration meetings. When Klaus asked why, she was blunt: “Every time I explain something, someone rolls their eyes. I’ve been protecting this system for twenty years. If they don’t want my help, I’ll wait until they ask.”

Klaus saw a people problem. And like many executives facing people problems, he reached for a familiar solution: outside help.

The Consultants

The management consulting firm came highly recommended. They specialized in “organizational transformation” and “change management.” Their lead consultant, Dr. Berger, arrived with a team of three junior analysts and a methodology called “Adaptive Transition Framework.”

“Technical projects fail because of people, not technology,” Dr. Berger explained in his initial presentation. “We’ll align your stakeholders, establish clear communication protocols, and create accountability structures that drive results.”

Thomas was skeptical. “Have any of your team actually built software?”

Dr. Berger smiled patiently. “We don’t need to understand the technical details. Human dynamics are universal. Resistance to change follows predictable patterns regardless of industry.”

"We'll align your stakeholders and establish accountability structures." The consultants had never shipped a line of code, but they had frameworks.

For six weeks, the consulting team conducted interviews, facilitated workshops, and produced a 47-page report. They identified “communication gaps,” “unclear role definitions,” and “insufficient change readiness.” Their recommendations included a new governance structure, weekly alignment meetings, and a “transformation champion” role.

The weekly alignment meetings added three hours to everyone’s schedule. The governance structure created approval bottlenecks that slowed decisions. The transformation champion — a junior manager from sales — had no idea what the developers were talking about and quietly stopped attending after two weeks.

Heike attended one of Dr. Berger’s “legacy stakeholder integration sessions.” She walked out after twenty minutes. When Klaus asked what happened, she said: “He asked me to describe my ‘emotional relationship’ with the codebase. I told him my relationship with the codebase is that I know how it works and they don’t. He said I was exhibiting ‘defensive posturing typical of change-resistant personas.’”

That evening, Heike sent Klaus an email with her resignation letter attached. “I’ve given this company twenty years,” she wrote. “I won’t spend my final working years being psychoanalyzed by people who couldn’t compile Hello World.”

Klaus called her immediately. It took forty-five minutes to convince her to delay submitting the resignation. “Give me one week,” he said. “If nothing changes, I’ll accept it without argument.”

Thomas was more direct in the next leadership meeting. “Klaus, these consultants are burning €15,000 a week and making everything worse. The developers who were starting to work together are now sitting in meetings drawing stakeholder maps. Meanwhile, no code is getting written. And we nearly lost Heike last night — the one person who can actually finish this project.”

Dr. Berger defended his approach. “Transformation is uncomfortable. Resistance indicates we’re addressing the real issues.”

“Resistance indicates that people who build software don’t enjoy being psychoanalyzed by people who’ve never built software,” Thomas replied.

The breaking point came when the consultants recommended “temporary role rotation” to build empathy — suggesting that Heike spend two weeks working with the Java team while a Java developer “shadowed” her Delphi work.

Heike’s response was icy. “You want someone who doesn’t know Object Pascal to shadow twenty years of work they can’t read? And you want me to write Java, which I’ve never used, while the project burns? This isn’t a team-building exercise. This is a company that’s about to lose its only product.”

Klaus finally saw what Thomas and Heike had been telling him for weeks. The consultants understood generic organizational dynamics, but they had no grasp of what software development actually required. Their frameworks treated all resistance as emotional — never considering that some resistance might be rational disagreement from people who understood the problem better than the consultants did.

He ended the engagement. €90,000 spent, six weeks lost, and the team more fractured than before.

"The people who built your legacy system are not the problem. Treating them like obstacles — or case studies for change management frameworks — guarantees failure."

Klaus realized he had been looking for an external solution to an internal problem. The friction wasn’t about “change readiness” or “stakeholder alignment.” It was about respect — and respect couldn’t be workshopped into existence.

He called a meeting — not about code, but about culture. No consultants. No frameworks. Just honesty. “Heike isn’t here to hand off knowledge and leave. She’s here to help us build something better than what we had. When the new system is done, she’ll have shaped it. Anyone who can’t work with that should tell me now.”

The room was silent.

“And Heike — I need you in every integration meeting. Not as someone being interrogated, but as the technical authority on what this system actually does. If someone rolls their eyes, I want to know about it.”

Heike nodded slowly. It was the first time Klaus had publicly acknowledged her role as essential rather than transitional.

The team restructured. Heike became a technical advisor who reviewed designs before implementation. Legacy developers paired with new developers, each teaching the other. Two more contractors left — they wanted greenfield work, not archaeological expeditions. But the ones who stayed began to understand: the goal wasn’t “replace the old system.” It was “build the next generation of what we started.”

The Multi-Tenant Challenge

Running on customer premises meant MaschinenKonfigurator never needed true multi-tenancy. Each installation was isolated. Customer data couldn’t leak between installations because there was nothing to leak into.

SaaS changed everything. Multiple customers would share infrastructure. Their configurations, pricing, and business rules needed complete isolation while running on shared systems.

“This isn’t a feature,” Maria observed. “This is a fundamental architectural decision that affects everything.”

The team had already built several capabilities assuming single-tenant operation. Retrofitting multi-tenancy would require significant rework.

Thomas made the call: “We stop feature development for six weeks. We rebuild the foundation for multi-tenancy before going further.”

Klaus pushed back hard. “Six weeks of no visible progress? The board is already asking questions. I’ve told them we’re on track.”

“Then tell them we’re not on track,” Thomas replied. “Because if we keep building on this foundation, we’ll be explaining in twelve months why we need to start over. Again.”

The argument continued for an hour. Maria finally broke the deadlock: “Klaus, which conversation do you want to have with the board — ‘we paused for eight weeks to fix architecture’ or ‘we spent eighteen months building something we have to throw away’?”

Klaus authorized the pause. It was the hardest decision he’d made since starting the project.

The multi-tenancy retrofit took eight weeks, not six. It touched every capability already built.

The rework nearly broke what remained of team morale. Andreas, a senior Java developer who had joined full-time after the contractor exodus, confronted Thomas in the hallway. “You’re telling me the last four months of my work is being thrown away?”

“Refactored, not thrown away.”

“That’s corporate speak for thrown away.” Andreas was visibly shaking. “I moved my family here for this job. I left a stable position in Munich. And now you’re saying my work doesn’t count?”

Thomas spent an hour talking Andreas down. Two other developers had similar reactions — one threatened to quit on the spot, the other stopped speaking to Thomas entirely for a week. The tension was so severe that Maria started holding private one-on-one meetings just to let people vent without fear of being overheard.

Thomas spent hours in those weeks explaining that the original design wasn’t wrong, just incomplete for requirements that had become clear later. Some developers accepted this. Others never fully trusted management again.

When the retrofit was done, the system could scale to hundreds of tenants without architectural changes. More importantly, the team had survived a genuine crisis together. But the scars remained. Trust, once broken, rebuilds slowly if at all.

Finding the Right Deployment Rhythm

Early in the project, deployments were major events. The team would accumulate changes for weeks, then deploy in a carefully orchestrated release. Each deployment was stressful — so much had changed that failures were unpredictable.

"We feared deployment because we did it rarely. We did it rarely because we feared it. Breaking the cycle required making deployment boring."

The infrastructure team, led by a DevOps engineer named Felix, invested heavily in deployment automation. Kubernetes orchestration. Automated testing pipelines. Feature toggles that allowed code to be deployed without being activated.

Gradually, deployment frequency increased. Weekly became daily. Daily became multiple times per day. Each deployment was smaller, lower risk, easier to troubleshoot if something went wrong.

The psychological shift was profound. Developers stopped thinking in terms of releases and started thinking in terms of continuous improvement. A bug fix could reach production in hours. A new capability could launch incrementally, enabled for a few customers before rolling out broadly.

The Sunset Conversation

Eighteen months after the project began — the original timeline for complete replacement — about sixty percent of MaschinenKonfigurator’s capability existed in the new SaaS platform. But that sixty percent covered perhaps ninety percent of daily customer usage.

Klaus faced a choice: continue running both systems indefinitely, or begin sunsetting the legacy application.

“Some customers will resist,” warned the sales director, Stefan. “Müller Maschinenbau has been with us for fifteen years. They’ve already complained about the new interface three times.”

“Some capabilities we’ve never rebuilt will disappear,” warned Thomas. “There are features in the Delphi system that two customers use. Are we keeping the whole legacy system running for two customers?”

Heike spoke up — something she did more often now. “Those two customers pay us €180,000 a year combined. One of them is the reference customer we use in every sales presentation. If we tell them their workflow is being retired, we might lose them.”

The room divided. Sales wanted to keep every customer happy. Development wanted to stop maintaining two systems. Finance pointed out that running parallel infrastructure was costing €8,000 per month.

The team analyzed usage telemetry extensively. They identified capabilities that genuinely mattered versus those that existed only because no one had removed them. They talked to every customer about their actual needs versus their theoretical preferences.

"The hardest part of sunsetting legacy systems is distinguishing between 'customers use this' and 'customers once used this and might theoretically use it again.'"

Klaus made the call. “We rebuild the workflow for Müller Maschinenbau. It’s three weeks of work, and it keeps our best reference customer. The other legacy features get documented alternatives and twelve months notice.”

Stefan from sales wasn’t satisfied. “What do I tell customers who complain?”

“Tell them the truth,” Klaus said. “We’re building something better. Some things won’t make the transition. We’ll help them adapt.”

The sunset plan gave customers twelve months of parallel operation. Three customers chose not to migrate and eventually left. Two of them had been paying minimal fees and consuming disproportionate support resources. The third, a mid-sized manufacturer, moved to a competitor — a loss that stung but validated that the company couldn’t be everything to everyone.

The Final State

Two and a half years after the transformation began, Hartmann & Söhne had completed their journey. The new platform — renamed MachineConfigure to signal the transition — served all existing customers plus new ones who would never have considered the legacy desktop application.

The results exceeded expectations in some areas and fell short in others:

Performance: The new system handled complex configurations in seconds instead of minutes. Customers repeatedly cited this as the most visible improvement.

Accessibility: Multi-location teams could now collaborate on configurations. Mobile access enabled sales representatives to create quotes on-site with customers.

Integration: Modern APIs enabled connections to ERP systems, CAD platforms, and e-commerce channels that were impossible with the legacy architecture.

Feature parity: About eighty-five percent of legacy features made the transition. The remaining fifteen percent were either rebuilt with different approaches or retired entirely.

Timeline: Two and a half years instead of eighteen months. The project took longer than the optimistic original estimate but significantly less time than a full parallel development approach would have required.

Cost: Roughly double the original budget — including €90,000 on management consultants who made things worse, months of lost productivity from the knowledge gap when Jürgen left, and the cost of firing Martin before Klaus accepted that respect can’t be workshopped and toxicity can’t be tolerated. Expensive, but the alternative — continuing to maintain an increasingly unsupportable legacy system — would have cost more over time.

Lessons From the Journey

Klaus, reflecting on the transformation a year after completion, identified principles that might help other organizations facing similar challenges:

The knowledge is in the people, not the code. Retaining and respecting the developers who built the legacy system proved more valuable than any documentation. Heike caught problems that no automated testing could find — but only after the team learned to listen to her. Jürgen’s departure over a contractor’s thoughtless mockery cost months of reverse-engineering time. The contractors who dismissed the legacy team’s knowledge were the first to leave — or be shown the door. The ones who stayed learned humility.

Generic management consulting rarely helps technical transformations. The consultants who recommended “stakeholder alignment workshops” and “change readiness assessments” had never shipped software. They treated rational technical disagreement as emotional resistance. The €90,000 spent on frameworks and governance structures was €90,000 not spent on solving actual problems. When your experts tell you something won’t work, consider that they might be right.

Parallel running reduces risk dramatically. Running both systems simultaneously allowed learning and adjustment. The ability to compare outputs built confidence that the new system actually worked correctly.

Small, frequent deployments change everything. Moving from big-bang releases to continuous deployment transformed the team’s relationship with risk. Small changes were easier to validate and easier to roll back.

Multi-tenancy isn’t a feature — it’s a foundation. Trying to retrofit multi-tenancy after building single-tenant capabilities wasted months. Architectural decisions need to be made early, even when features seem more urgent.

Not every feature deserves survival. Legacy systems accumulate capabilities that outlive their usefulness. Transformation is an opportunity to prune, not just port.

The original timeline is always wrong. Not because the team can’t estimate, but because the team can’t know what they don’t know. Building in substantial contingency isn’t pessimism — it’s realism.

The Story Continues

Hartmann & Söhne’s transformation wasn’t an ending. It was a transition to a new way of operating. The SaaS model brought new challenges: monitoring uptime across multiple customers, managing subscription billing, handling data residency requirements for international clients.

But the organization had also built new capabilities. They could deploy improvements daily instead of annually. They could observe how customers actually used the system, not just how customers described their usage. They could experiment with features before committing to them fully.

The specialized machinery market still needed sophisticated configuration tools. Hartmann & Söhne still provided them. The technology had changed completely. The value proposition remained the same.

Heike retired six months after the new platform launched — on her own terms, having shaped the system that would carry her work forward. At her farewell party, she told Klaus: “I was ready to quit when Martin called my documentation useless. I’m glad I stayed.”

“So am I,” Klaus replied. “We couldn’t have done it without you.”

“No,” she agreed. “You couldn’t have. Remember that next time someone tells you a rewrite is simple.”

This is a work of fiction. Any resemblance to actual companies, events, or persons is entirely coincidental. However, if you recognized your own organization in this story, that’s probably not a coincidence — it’s a pattern.

Kubernetes for the Rest of Us: Starting Small with k3s

2025-12-16T00:00:00+01:00

Container Orchestration Without the Enterprise Overhead

16.12.2025, By Stephan Schwab

Kubernetes has earned a reputation as complex infrastructure reserved for large-scale operations. Yet modern lightweight distributions like k3s, combined with AI-assisted learning and simple Helm charts, make container orchestration accessible to modest applications with growth potential. The same workflow — Docker Compose for local development and CI, Helm charts for staging and production — works whether you deploy to a single node or scale to dozens.

Many development teams dismiss Kubernetes before evaluating it. The mental model persists: Kubernetes equals Google-scale complexity, dedicated platform engineers, and weeks of configuration. A small team building a straightforward web application sees no reason to venture into that territory.

This perception made sense five years ago. Running a production Kubernetes cluster meant wrestling with kubeadm, managing etcd backups, debugging networking plugins, and keeping up with rapid API changes. The operational burden overwhelmed smaller organizations.

The landscape has shifted. Lightweight Kubernetes distributions, maturing tooling, and AI assistants have lowered the barrier dramatically. A modest application that might grow — and most successful applications do grow — can start with Kubernetes from day one without the traditional overhead.

k3s: Kubernetes Without the Weight

Rancher Labs created k3s as a certified Kubernetes distribution optimized for resource-constrained environments. The name plays on the original: if Kubernetes (k8s) has 10 letters, k3s aims to be half the size while remaining fully compatible.

A single binary of roughly 50MB contains everything needed to run a complete Kubernetes cluster. No separate etcd installation. No complex prerequisites. Installation on a fresh Linux server takes under a minute:

curl -sfL https://get.k3s.io | sh -

After that command completes, you have a functioning Kubernetes cluster. One node, but a real cluster nonetheless. The same kubectl commands, the same manifests, the same Helm charts that work on managed Kubernetes services like EKS or GKE work here.

This simplicity matters for teams exploring container orchestration. Instead of spending days setting up infrastructure before writing a single deployment manifest, they can experiment immediately. Mistakes are cheap. Learning happens through iteration rather than documentation archaeology.

The Practical Environment Spectrum

With container orchestration accessible, teams can implement a deployment pattern that scales with their needs:

Local development: Docker Compose remains the natural choice. Developers define services, mount volumes for hot reloading, and spin up the complete application stack with a single command. No Kubernetes knowledge required for daily work.

CI/CD pipeline: The same Docker Compose configuration drives integration testing. Build the containers, compose them together, run the test suite against the composed services. This keeps the feedback loop tight and the CI configuration simple.

Staging environment: Here Kubernetes enters the picture. A Helm chart deploys the same containers to a k3s cluster that mirrors production topology. Stakeholders preview features, product owners validate behavior, and the team confirms everything works as expected before users see it.

Production environment: The identical Helm chart deploys to production, possibly with different values for replicas, resource limits, or feature toggles. The promotion path becomes trivial: the staging configuration already proved itself.

This progression respects team capacity. Developers who never touch Kubernetes directly still benefit from its capabilities in staging and production. The infrastructure complexity concentrates where it belongs — in deployment tooling — rather than spreading across everyone’s daily workflow.

Helm Charts Demystified

Helm charts intimidate newcomers with their templating syntax and directory conventions. Yet at their core, they solve a simple problem: how do you deploy the same application to different environments with different configurations?

A minimal chart for a web application might contain:

my-app/
  Chart.yaml       # Metadata (name, version)
  values.yaml      # Default configuration
  templates/
    deployment.yaml
    service.yaml
    ingress.yaml

The deployment template references values rather than hardcoding them:

replicas: {{ .Values.replicas | default 1 }}
image: {{ .Values.image.repository }}:{{ .Values.image.tag }}

Deploying to staging with specific settings becomes straightforward:

helm upgrade --install my-app ./my-app \
  --set replicas=1 \
  --set image.tag=staging-abc123

Production uses the same chart with different values:

helm upgrade --install my-app ./my-app \
  --set replicas=3 \
  --set image.tag=v1.2.3 \
  --values production-values.yaml

The chart itself rarely needs modification. Environment differences live in values files or command-line overrides. This separation keeps the deployment logic stable while allowing flexibility where it matters.

Feature Toggles Across Environments

Feature toggles let you deploy code to production while controlling who sees new functionality — a safety net that makes frequent deployment less risky.

Deploying the same container to staging and production raises a question: how do you test features in staging without exposing unfinished work to production users?

Feature toggles provide the answer. The application reads configuration — environment variables, a configuration service, or a feature flag platform — to determine which functionality to enable. The same binary runs everywhere; only the configuration differs.

A Helm chart integrates naturally with this pattern:

env:
  - name: FEATURE_NEW_CHECKOUT
    value: {{ .Values.features.newCheckout | quote }}
  - name: FEATURE_EXPERIMENTAL_API
    value: {{ .Values.features.experimentalApi | quote }}

Staging enables both features for testing. Production enables only the stable checkout flow. When the experimental API proves ready, a values change promotes it — no code deployment required.

This approach decouples deployment frequency from release risk. Teams can deploy to production multiple times daily, confident that unreleased features remain hidden behind toggles. The psychological barrier to deployment drops when deployment no longer means immediate user exposure.

AI as a Learning Accelerator

Kubernetes documentation is extensive, detailed, and occasionally overwhelming. The learning curve traditionally required reading through concepts, experimenting, debugging, and gradually building mental models over months.

AI assistants have compressed this timeline dramatically. When a deployment fails with a cryptic error, asking an AI to explain the message and suggest fixes often yields useful answers within seconds. When writing a Helm template for the first time, an AI can generate a working starting point from a plain-language description.

This matters particularly for teams where Kubernetes expertise is thin. Rather than hiring a dedicated platform engineer or sending someone to a week-long training course, teams can learn incrementally. Start with a simple deployment. Ask the AI when something breaks. Gradually absorb concepts through practical application.

The AI does not replace understanding — teams still need to grasp what they are deploying and why. But it accelerates the journey from novice to competent, making infrastructure knowledge acquisition a byproduct of regular work rather than a blocked-out learning project.

Starting the Journey

For a team considering this path, the entry point is straightforward:

Provision a small server — a modest cloud VM or an old office machine running Linux suffices for exploration.
Install k3s — the single-command installation creates a working cluster in under a minute.
Deploy something familiar — take an existing Docker Compose application and create a basic Helm chart for it. Start with a single service, not the entire stack.
Iterate — add services, configure ingress, experiment with scaling. Let the infrastructure grow alongside understanding.
Connect to CI/CD — once comfortable, extend the pipeline to deploy to the k3s cluster after tests pass.

The investment is minimal. The learning compounds. And when the application grows beyond what a single server can handle, the transition to a larger cluster — or a managed Kubernetes service — requires changing where you deploy, not how.

Kubernetes is no longer exclusively for organizations that need it at scale. Lightweight distributions like k3s bring its benefits — consistent deployments, environment parity, scaling readiness — to teams building applications that might never need more than a few nodes. The question has shifted from “is Kubernetes worth the complexity?” to “why not start with the infrastructure that grows with you?”

Cypress Beyond Testing: Executable Demos for Your Pipeline

2025-12-13T00:00:00+01:00

Turn Your Product Demos Into Quality Gates

13.12.2025, By Stephan Schwab

What if every product demo you gave also served as a quality gate in your CI/CD pipeline? Cypress, traditionally positioned as an end-to-end testing tool, can be repurposed to create executable demonstrations that both showcase application features to stakeholders and validate critical user journeys. This approach delivers double value from a single investment while keeping your testing pyramid properly balanced.

Most teams encounter Cypress as “yet another UI testing framework.” Install it, write some selectors, click some buttons, assert some outcomes. The documentation emphasizes testing, the tutorials focus on testing, and so teams dutifully add Cypress tests to their suites — often duplicating coverage they already have at lower levels.

There is a more powerful way to think about Cypress: as a tool for creating executable demonstrations that happen to also function as tests.

The Testing Pyramid and Where E2E Fits

Before diving into the approach, let’s revisit the testing pyramid — a concept that remains as relevant today as when Mike Cohn introduced it. The pyramid suggests that the bulk of your automated tests should be fast, isolated unit tests at the base. Above that, a smaller layer of integration tests validates that components work together. At the very top, a thin layer of end-to-end (E2E) tests confirms that critical user journeys work through the complete system.

        /\
       /  \       E2E Tests (few, slow, expensive)
      /----\
     /      \     Integration Tests (moderate)
    /--------\
   /          \   Unit Tests (many, fast, cheap)
  --------------

The pyramid shape is intentional. E2E tests are slow, flaky, and expensive to maintain. They require the full application stack to be running. A single selector change can break dozens of tests. Teams that invert this pyramid — writing more E2E tests than unit tests — often find themselves drowning in test maintenance while still shipping bugs.

So why use Cypress at all? Because those few E2E tests at the top of the pyramid serve a purpose that unit and integration tests cannot: they validate that the application works as a user would experience it, through a real browser, with all the JavaScript, CSS, and network interactions intact.

The key is to be strategic about what you test at this level.

Demos as Executable Specifications

Consider the typical rhythm of a development team. Features get built, and then someone needs to demo them — to product owners, stakeholders, or during sprint reviews. These demos follow a script: “First, I’ll log in as an admin user. Then I’ll navigate to the settings page. Watch as I update the notification preferences. See how the confirmation message appears?”

What if that demo script were executable code?

describe('Notification Preferences Feature Demo', () => {
  it('allows an admin to update notification settings', () => {
    // Authenticate as an admin user
    cy.login('admin@example.com', 'securepassword')
    
    // Navigate to the settings area
    cy.get('[data-cy="settings-menu"]').click()
    cy.get('[data-cy="notifications-tab"]').click()
    
    // Update email notification preferences
    cy.get('[data-cy="email-notifications-toggle"]')
      .should('be.visible')
      .click()
    
    // Adjust notification frequency
    cy.get('[data-cy="frequency-dropdown"]').select('Weekly')
    
    // Save changes
    cy.get('[data-cy="save-preferences"]').click()
    
    // Verify the confirmation appears
    cy.get('[data-cy="success-message"]')
      .should('be.visible')
      .and('contain', 'Preferences saved successfully')
  })
})

This code does three things simultaneously:

Documents the feature in a way that any developer can read and understand
Provides a demo script that can be run visually for stakeholders
Acts as a quality gate in your CI/CD pipeline

For stakeholder presentations, run the tests in headless mode with cypress run — Cypress automatically records videos that you can pause and narrate at your own pace. Alternatively, add cy.pause() commands at key moments in your code; when running in interactive mode with cypress open, execution stops at each pause point, letting you explain what’s happening before clicking “Resume” to continue. Either way, the same code that serves your demo also runs in your pipeline to ensure this critical user journey hasn’t regressed.

Writing Demos, Not Tests

The mental shift is subtle but important. When you set out to “write a test,” you focus on coverage, edge cases, and assertions. When you set out to “write a demo,” you focus on the user journey, the narrative, and the visible outcomes.

This changes how you structure the code:

describe('Order Fulfillment Workflow', () => {
  beforeEach(() => {
    // Set up the scenario: a customer has placed an order
    cy.task('seedOrder', { status: 'pending', items: 3 })
    cy.login('warehouse@example.com')
  })

  it('demonstrates the complete fulfillment process', () => {
    // Warehouse staff sees pending orders on their dashboard
    cy.visit('/fulfillment/dashboard')
    cy.get('[data-cy="pending-orders"]')
      .should('contain', '1 order awaiting fulfillment')

    // They open the order details
    cy.get('[data-cy="order-row"]').first().click()
    cy.get('[data-cy="order-items"]')
      .find('li')
      .should('have.length', 3)

    // Each item gets scanned and marked as picked
    cy.get('[data-cy="scan-item-input"]').type('SKU-001{enter}')
    cy.get('[data-cy="picked-count"]').should('contain', '1 of 3')
    
    cy.get('[data-cy="scan-item-input"]').type('SKU-002{enter}')
    cy.get('[data-cy="scan-item-input"]').type('SKU-003{enter}')
    cy.get('[data-cy="picked-count"]').should('contain', '3 of 3')

    // Order is marked ready for shipping
    cy.get('[data-cy="complete-fulfillment"]').click()
    cy.get('[data-cy="order-status"]')
      .should('contain', 'Ready for Shipping')
  })
})

Notice the comments. They read like a demo script, not test documentation. When you present this to stakeholders, you can literally read the comments aloud while Cypress executes the steps.

Practical Considerations

Use Data Attributes for Selectors

Resist the temptation to select elements by CSS classes or complex DOM paths. Data attributes like data-cy are explicit, stable, and communicate intent:

// Fragile - breaks when styling changes
cy.get('.btn.btn-primary.submit-form')

// Robust - survives refactoring
cy.get('[data-cy="submit-order"]')

Create Custom Commands for Common Actions

Your demos will share common patterns. Encapsulate them:

// cypress/support/commands.js
Cypress.Commands.add('login', (email, password) => {
  cy.visit('/login')
  cy.get('[data-cy="email-input"]').type(email)
  cy.get('[data-cy="password-input"]').type(password)
  cy.get('[data-cy="login-button"]').click()
  cy.url().should('not.include', '/login')
})

Cypress.Commands.add('addToCart', (productId) => {
  cy.visit(`/products/${productId}`)
  cy.get('[data-cy="add-to-cart"]').click()
  cy.get('[data-cy="cart-notification"]').should('be.visible')
})

Now your demos read even more cleanly:

it('demonstrates a complete purchase flow', () => {
  cy.login('customer@example.com', 'password')
  cy.addToCart('product-123')
  cy.addToCart('product-456')
  cy.visit('/checkout')
  // ...continue the journey
})

Keep the Count Low

Remember the pyramid. You’re not trying to test every permutation at the E2E level. Aim for a handful of demos that cover the critical user journeys — the paths that, if broken, would make the application unusable or cost the business significant money.

A typical application might have:

2-3 demos covering the core purchase or conversion flow
1-2 demos for administrative workflows
1 demo for the user onboarding experience

That’s perhaps 5-10 Cypress demos total, not 500 E2E tests.

Running Demos in Your Pipeline

In your CI/CD configuration, these demos become a quality gate:

# Example GitHub Actions workflow
cypress-demos:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - uses: cypress-io/github-action@v6
      with:
        start: npm run start:ci
        wait-on: 'http://localhost:3000'
        spec: cypress/e2e/demos/**/*.cy.js

When a demo fails in the pipeline, it means a critical user journey is broken. This is a much stronger signal than “a test failed.” It forces a conversation: “The order fulfillment demo is failing — we cannot ship this release until warehouse staff can complete orders.”

The Double Return on Investment

The traditional approach treats demos and tests as separate activities. Someone writes Cypress tests for the pipeline. Someone else prepares PowerPoint slides and manually clicks through the application for stakeholders. These activities happen independently, consuming time and often falling out of sync.

The executable demo approach collapses these into one artifact. The demo you show stakeholders is the same code that guards your production releases. When the application changes, updating the demo updates the test. When stakeholders ask “can you show me that feature again?”, you run the demo — and you’ve just verified it still works.

This isn’t about abandoning proper testing. Your unit tests still cover the edge cases. Your integration tests still verify component interactions. The Cypress demos sit at the apex of your pyramid, ensuring the critical paths work end-to-end while serving double duty as stakeholder communication tools.

The next time you reach for Cypress, ask yourself: am I writing a test, or am I scripting a demo? The answer might change how you approach the entire exercise.

Software Complexity: What Leaders Need to Know

2025-12-10T00:00:00+01:00

Why Complexity Demands Different Leadership

10.12.2025, By Stephan Schwab

Software development is fundamentally complex, not merely complicated, yet most organizations manage it using approaches designed for predictable systems. Understanding this distinction — and adopting flow-based delivery over prediction-based planning — transforms how leaders fund projects, measure progress, and enable teams to navigate uncertainty while delivering value continuously.

The Foundation: Complex vs. Complicated

The words “complex” and “complicated” are often used interchangeably in everyday conversation, but in systems thinking they describe fundamentally different phenomena. This distinction matters profoundly for software development.

"In complicated systems, expertise predicts outcomes. In complex systems, experience reveals patterns only after the fact."

A complicated system has many parts that interact predictably. A jet engine is complicated — thousands of components, but given the same inputs, it produces the same outputs. We can blueprint it, replicate it, and predict its behavior.

A complex system contains agents that interact in ways that produce emergent, unpredictable behaviors. The stock market, living ecosystems, city traffic — and crucially, software development — are all complex.

Why Software is Complex, Not Just Complicated

Software might appear complicated, but what makes it complex is the human dimension and emergent properties that arise from interaction.

The Porting Fallacy

"We already built it once. Just translate the code to the new platform."

Non-technical stakeholders often believe porting software to a new platform is purely complicated work — everything is known, just rewrite it in the new language. This treats software like translating a bridge blueprint from imperial to metric: tedious but mechanical. Reality proves otherwise.

When porting, you encounter: implicit knowledge buried in undocumented micro-decisions; different paradigms where old solutions become impossible or dangerous; evolved understanding that reinterprets requirements; changed context as stakeholders add “small changes”; and emergent interactions with new systems that can’t be predicted.

Six months of translation work becomes eighteen months of discovery. Not incompetence — complexity. This pattern appears throughout software development, not just porting.

Building New Features

Building features reveals similar complexity: developers interpret requirements differently, teams communicate with varying clarity, existing code constrains choices unpredictably, user needs evolve through interaction, technical decisions cascade unexpectedly, and external systems change behavior in production.

None of this can be specified upfront. User behavior reveals needs that no analysis captures. This is emergence — the whole behaves differently than its parts suggest.

The Illusion of Predictability

"If we can build a bridge in 18 months, why can't you tell me exactly when this feature will be done?"

Why do organizations apply management approaches designed for complicated systems to complex ones?

Traditional project management emerged from domains where proven designs enable accurate estimation: bridges, automobiles, skyscrapers. Once designed, replication time is predictable.

Software doesn’t work this way. When a manager asks “How long will this take?” they expect a bridge answer. But software is more like negotiating a peace treaty or finding product-market fit. The honest answer: “We’ll discover that as we work, and show you progress along the way.”

Why Traditional Management Approaches Fail

In complicated systems, detailed upfront analysis reduces risk. In complex systems, it creates waste because reality diverges from predictions. What helps:

Short feedback loops: Deliver frequently, gather real usage data, adjust based on learning.

Empirical process control: Decide based on observation, not prediction. Track actual delivery flow.

Adaptive direction: Maintain outcome clarity while staying flexible on path. Quarterly objectives with weekly adjustments beat six-month roadmaps.

Range-based confidence: Accept “30-60 days with unknowns” instead of demanding “47 days exactly.”

Forecasts in complex systems are confidence ranges, not commitments. The further out, the wider the range.

Better than arguing about forecasts: control scope instead of predicting duration.

"Stop asking when. Start asking what's next and how often we ship."

Focus on flow: Decompose work into smallest shippable increments. Ship minimal but valuable versions in days, gather data, decide next. This shifts conversation from “When done?” to “What ships this week?”

Shipping every 3-5 days means ~15-20 increments per quarter — that’s your velocity. This requires technical practices making small changes routine: automated verification, conflict-free integration, ceremony-free deployment.

The benefit: discover you built the wrong thing in weeks, not months. Risk decreases with each release instead of accumulating toward big-bang deployment.

How to Navigate Complexity: Ship Small, Learn Fast

"Ship the smallest valuable piece today. Learn from real users. Decide tomorrow's priority based on evidence, not speculation."

The most effective response: work in small increments delivered to actual users. This transforms complexity into manageable, complicated problems.

Identify the smallest valuable piece, build to production quality, ship, measure user interaction, learn, decide next. User needs and technical constraints reveal themselves through interaction, not speculation. Essential features go unused; overlooked details drive adoption.

Breaking Down Complexity

Proven techniques decompose complex ideas into manageable increments:

Vertical slicing: Build one complete capability end-to-end, not layers. “User logs in with email” — not “authentication database schema.”

User story mapping: Identify minimal viable path through user journey. Everything else becomes optional.

Walking skeleton: Thinnest implementation connecting all layers, then add incrementally. Surfaces integration risks early.

Feature toggles: Deploy code inactive, enable for user subsets to gather evidence before full rollout.

Hypothesis-driven: Frame increments as testable beliefs. Build minimum to test, measure, decide.

These transform “What should we build?” (complex) into “How do we implement this?” (complicated). Complicated problems yield to skill. Complex problems need experimentation.

The Role of Technical Excellence

"You can't have business agility without technical excellence. They're inseparable."

These techniques only work if teams can safely ship small changes frequently. This demands practices that become second nature:

Test-Driven Development (TDD): Verifies each increment during building. Not bureaucracy — confidence when integrating dozens of daily changes. Skipping TDD accumulates debt that prevents iteration.

Continuous Integration (CI): Multiple daily merges with automated verification surface problems in hours, not weeks. Essential because complexity lies in how pieces interact.

Continuous Deployment (CD): Automated pipelines deploy multiple times daily, eliminating ceremony and risk. Manual coordination forces large, risky batches.

Evolutionary architecture: Systems that change incrementally, not through rewrites. Extension and composition, not rigid hierarchies.

Without these, you’re forced into large batches — not because it’s better, but because your practices can’t support anything else. Wanting business agility without technical excellence is like wanting air travel while refusing to maintain engines.

The Hidden Cost of Ignoring Complexity

"Treating software as merely complicated creates dysfunction: false precision, premature decisions, accumulated risk, and organizational friction."

Treating software as complicated creates predictable dysfunctions:

False precision: Six-month forecasts treated as commitments. When reality diverges, blame replaces learning.

Premature optimization: Locked-in decisions before understanding the problem. Expensive rework or systems serving theoretical needs.

Micromanagement: Controlling every detail removes teams’ ability to adapt to learning.

Risk accumulation: Avoiding frequent deployment defers complexity’s reveal. When it arrives — often before deadlines — accumulated risk explodes.

What Non-Technical Leaders Can Do

"Shift from 'Did you follow the plan?' to 'What did you learn?' Learning velocity trumps plan adherence."

Understanding complexity doesn’t abandon accountability. It adapts leadership:

Ask “What did you learn?” not “Did you follow the plan?” Learning velocity matters more than prediction adherence.

Value visible progress: Working software deployed to production tells more than Gantt charts and task percentages.

Invest in fast feedback: Support automated testing, continuous integration, and telemetry.

Fund incrementally: Smaller increments tied to validated outcomes create pivot points based on evidence.

Trust technical judgment on how: Maintain clarity on what and why. Teams need autonomy to navigate complexity.

The Bridge Between Worlds

Leadership changes require technical teams to meet halfway. The understanding gap creates friction: developers feel dismissed when leaders demand impossible certainty; leaders feel frustrated by unpredictability.

The bridge requires mutual adaptation:

Technical teams communicate risk, value, and options — not minutiae
Business leaders accept that direction matters more than detailed roadmaps
Both agree on reality-based measurements: delivery frequency, production stability, validated outcomes

Complexity isn’t an excuse for lack of discipline. It demands different disciplines — empirical over predictive, adaptive over prescriptive.

Building Organizational Intelligence

Systems that surface empirical evidence naturally bridge the gap. Tools like Caimito Navigator help teams maintain daily logbooks — capturing blockers, progress, learning — then synthesize weekly intelligence summaries for leadership.

This creates shared visibility without status meetings. Both parties work from the same factual foundation. When friction appears, leadership responds: removing impediments, adjusting scope, or embedding expertise. Complexity becomes visible and navigable.

Moving Forward

When projects feel unpredictable or teams push back on long-term commitments, ask:

Are we deciding based on production data or months-old predictions?
Do we have fast feedback loops revealing what works?
Are we treating forecasts as ranges or guarantees?
Have we created space for emergence or are we controlling every variable?

Complexity isn’t a problem to solve — it’s a reality to navigate. Organizations that accept this build better products faster with less friction. Those treating software as merely complicated will repeat the same frustrations.

The difference between complex and complicated isn’t semantic. It’s working with reality versus fighting it.

Why We've Tried to Replace Developers Every Decade

2025-12-07T00:00:00+01:00

The Pattern That Frustrates Everyone

07.12.2025, By Stephan Schwab

Every decade brings new promises: this time, we'll finally make software development simple enough that we won't need so many developers. From COBOL to AI, the pattern repeats. Business leaders grow frustrated with slow delivery and high costs. Developers feel misunderstood and undervalued. Understanding why this cycle persists for fifty years reveals what both sides need to know about the nature of software work.

The Dream Was Born During Humanity’s Greatest Achievement

When Neil Armstrong stepped onto the lunar surface in 1969, the world witnessed what organized human ingenuity could accomplish. Behind that achievement stood Margaret Hamilton and her team, writing Apollo’s guidance software by hand, catching critical errors through careful review, and proving that software could be mission-critical.

The Apollo program demonstrated that software development was essential to achieving the impossible. Yet it also revealed something that would frustrate business leaders for decades to come: writing software required specialized knowledge, intense focus, and significant time investment. The dream of making it easier—of needing fewer of these expensive specialists—began almost immediately.

COBOL: Business People Will Write Their Own Programs

The late 1960s and 1970s saw COBOL emerge with an explicit goal stated in its name: Common Business-Oriented Language. The vision was clear: make the language read like English sentences, and business analysts would write their own programs. No need for specialized programmers.

"If we make the syntax readable enough, anyone who understands the business can write the code."

This vision had genuine appeal. Software was becoming essential to business operations, yet programmers remained a scarce, expensive resource. COBOL promised to democratize software creation.

What happened instead? COBOL became another programming language requiring specialized training. Business analysts who tried to write COBOL quickly discovered that readable syntax didn’t eliminate the complexity of logic, data structures, or system design. A new class of COBOL programmers emerged, and the dream of eliminating specialized developers remained unfulfilled.

Yet the dream didn’t die. It simply waited for the next technological wave.

The 1980s: CASE Tools Will Generate Everything

Computer-Aided Software Engineering tools arrived in the 1980s with tremendous promise. Draw flowcharts and entity-relationship diagrams, and the tool would generate working code. The marketing message resonated: visual design was more intuitive than typing cryptic commands. Business experts could model their processes, and software would materialize.

Organizations invested heavily. Vendors promised productivity increases of 10x or more. Yet most CASE tool initiatives struggled or failed outright.

The generated code often required substantial manual intervention. Performance problems emerged. Maintenance became a nightmare when generated code diverged from the visual models. Most critically, drawing accurate diagrams required understanding the same logical complexity that programming demanded. The tool changed the interface but not the fundamental challenge.

Once again, the problem proved more stubborn than the solution.

Visual Basic and Delphi: Drag, Drop, Done

The 1990s brought a different approach. Microsoft’s Visual Basic and Borland’s Delphi made building user interfaces dramatically easier. Drag components onto a form, set properties, write event handlers. Suddenly, creating a Windows application felt achievable for developers with modest experience.

This wave succeeded differently than COBOL or CASE tools. These environments acknowledged that programming knowledge was still necessary, but they reduced the barrier to entry. A broader range of people could create useful applications.

Yet the dream of eliminating developers persisted. “Power users” and “citizen developers” would build departmental applications. IT departments could focus on infrastructure while business units solved their own software needs.

Reality proved more nuanced. Simple applications were indeed accessible to more people. But as requirements grew in complexity—integration with existing systems, security considerations, performance under load, long-term maintenance—the need for experienced developers became evident. The tools expanded who could write software, but they didn’t eliminate the expertise required for substantial systems.

And so the cycle continued into the new millennium.

The 2000s and Beyond: Web Frameworks, Low-Code, and No-Code

Each subsequent decade introduced new variations. Ruby on Rails promised convention over configuration. Low-code platforms offered visual development with minimal coding. No-code platforms claimed to eliminate programming entirely for common business applications.

Each wave delivered real value. Development genuinely became faster in specific contexts. More people could participate in creating software solutions. Yet professional software developers remained essential, and demand for their skills continued growing rather than shrinking.

Which brings us to the question: why does this pattern repeat?

Why the Dream Persists

The recurring pattern reveals something important about how we think about complexity. Software development looks like it should be simple because we can describe what we want in plain language. “When a customer places an order, check inventory, calculate shipping, process payment, and send a confirmation email.” That description sounds straightforward.

The complexity emerges in the details. What happens when inventory is temporarily reserved by another order? How do you handle partial payments? What if the email service is temporarily unavailable? Should you retry? How many times? What if the customer’s session expires during checkout? How do you prevent duplicate orders?

Each answer leads to more questions. The accumulated decisions, edge cases, and interactions create genuine complexity that no tool or language can eliminate. Someone must think through these scenarios. That thinking is software development, regardless of whether it’s expressed in COBOL, a CASE tool diagram, Visual Basic, or an AI prompt.

Which brings us to today’s excitement.

AI: The Latest Chapter in a Long Story

Today’s AI coding assistants represent the most capable attempt yet to assist with software creation. They can generate substantial amounts of working code from natural language descriptions. They can explain existing code, suggest improvements, and help debug problems.

This represents genuine progress. The assistance is real and valuable. Experienced developers use these tools to work more efficiently. People learning to code find the interactive guidance helpful.

Yet we’re already seeing the familiar pattern emerge. Initial excitement about AI replacing developers is giving way to a more nuanced understanding: AI changes how developers work rather than eliminating the need for their judgment. The complexity remains. Someone must understand the business problem, evaluate whether the generated code solves it correctly, consider security implications, ensure it integrates properly with existing systems, and maintain it as requirements evolve.

AI amplifies developer capability. It doesn’t replace the need for people who understand both the problem domain and the technical landscape.

So Much Opportunity, Still Struggling

Here’s the paradox that makes this pattern particularly poignant. We’ve made extraordinary progress in software capabilities. The Apollo guidance computer had 4KB of RAM. Your smartphone has millions of times more computing power. We’ve built tools and frameworks that genuinely make many aspects of development easier.

Yet demand for software far exceeds our ability to create it. Every organization needs more software than it can build. The backlog of desired features and new initiatives grows faster than development teams can address it.

This tension—powerful tools yet insufficient capacity—keeps the dream alive. Business leaders look at the backlog and think, “There must be a way to go faster, to enable more people to contribute.” That’s a reasonable thought. It leads naturally to enthusiasm for any tool or approach that promises to democratize software creation.

The challenge is that software development isn’t primarily constrained by typing speed or syntax knowledge. It’s constrained by the thinking required to handle complexity well. Faster typing doesn’t help when you’re thinking through how to handle concurrent database updates. Simpler syntax doesn’t help when you’re reasoning about security implications.

So what should leaders do with this understanding?

What This Means for Leaders

Understanding this pattern changes how you evaluate new tools and approaches. When someone promises that their platform will let business users build applications without developers, you can appreciate the aspiration while maintaining realistic expectations.

The right question isn’t “Will this eliminate our need for developers?” The right questions are:

Will this help our developers work more effectively on complex problems?
Will this enable us to build certain types of solutions faster?
Does this reduce time spent on repetitive tasks so developers can focus on unique challenges?
Will our team need to learn new skills to use this effectively?

These questions acknowledge that development involves irreducible complexity while remaining open to tools that provide genuine leverage.

And they point to something deeper about the nature of software work.

The Pattern Reveals the Problem’s Nature

This fifty-year pattern teaches us something fundamental about software development itself. If the problem were primarily mechanical—too much typing, too complex syntax, too many steps—we would have solved it by now. COBOL made syntax readable. CASE tools eliminated typing. Visual tools eliminated syntax. AI can now generate entire functions from descriptions.

Each advancement addressed a real friction point. Yet the fundamental challenge persists because it’s not mechanical. It’s intellectual. Software development is thinking made tangible. The artifacts we create—whether COBOL programs, Delphi forms, or Python scripts—are the visible outcome of invisible reasoning about complexity.

You can’t shortcut that reasoning any more than you can shortcut the reasoning required to design a building or diagnose a medical condition. Better tools help. Experience helps. But someone must still think it through.

So how should we move forward, knowing all this?

Moving Forward with Clear Eyes

The next wave of development tools will arrive. Some will provide genuine value. Some will repeat familiar promises with new technology. Having perspective on this recurring pattern helps you engage with new tools productively.

Use AI assistants. Evaluate low-code platforms. Experiment with new frameworks. But invest primarily in your people’s ability to think clearly about complexity. That capability remains the constraining factor, just as it was during the Apollo program.

The moon landing happened because brilliant people thought carefully about every detail of an extraordinarily complex challenge. They wrote software by hand because that was the available tool. If they’d had better tools, they would have used them gladly. But the tools wouldn’t have eliminated their need to think through the complexity.

We’re still in that same fundamental situation. We have better tools—vastly better tools—but the thinking remains essential.

The Dream Serves a Purpose

Perhaps the recurring dream of replacing developers isn’t a mistake. Perhaps it’s a necessary optimism that drives tool creation. Each attempt to make development more accessible produces tools that genuinely help. The dream doesn’t come true as imagined, but pursuing it creates value.

COBOL didn’t let business analysts write programs, but it did enable a generation of developers to build business systems effectively. CASE tools didn’t generate complete applications, but they advanced our thinking about visual modeling. Visual Basic didn’t eliminate professional developers, but it brought application development to more people. AI won’t replace developers, but it will change how we work in meaningful ways.

The pattern continues because the dream reflects a legitimate need. We genuinely require faster, more efficient ways to create software. We just keep discovering that the constraint isn’t the tool—it’s the complexity of the problems we’re trying to solve.

Understanding this doesn’t mean rejecting new tools. It means using them with clear expectations about what they can provide and what will always require human judgment.

Intrinsic Motivation and Software Developers

2025-12-04T00:00:00+01:00

Pride, Curiosity, and Purpose: The Real Currency of Great Software

04.12.2025, By Stephan Schwab

Intrinsic motivation is the quiet force behind the best software you've ever seen: the tools that feel thoughtfully crafted, the systems that behave predictably under pressure, and the products that keep getting better long after the initial launch. When organizations learn to stop fighting this motivation and instead design around it, they get more reliable delivery, healthier teams, and software that users actually value.

Most developers entered this profession because they enjoy solving problems, making things work, and understanding how complex systems behave. That intrinsic motivation — pride, curiosity, and a need for things to make sense — is one of the most valuable assets any organization has. And one of the most frequently destroyed.

Organizations have spent decades trying to manufacture motivation from the outside: bonuses, hackathon days, swag, performance games, methodology rollouts, and high-pressure “all hands on deck” moments. For a short time, it looks like it works. People stay late. Features ship. But underneath, trust erodes, the best people start looking for the exit, and what remains is compliance, not commitment.

The pattern is old and well-documented. Lockheed’s Skunk Works in the 1940s and 1950s succeeded because motivated engineers were protected from bureaucracy and could see the impact of their decisions quickly. SpaceX has done the same since 2002, hiring young engineers to solve problems that once belonged in science fiction — not by offering better perks, but by creating conditions where purpose and autonomy drive the work. Meanwhile, the 1968 software crisis warned that forcing complex, creative work into rigid structures destroys both motivation and results. More than fifty years later, most organizations still manage software as if that warning never happened.

The cost is visible everywhere: high turnover, ballooning budgets, systems that collapse under their own complexity, and teams where the spark is gone. Developers show up, complete tasks, attend meetings — but the code does what it must, and nothing more. The intrinsic motivation is still there; it has just learned to stay quiet, route around official decisions, or leave entirely.

SpaceX and Skunk Works did not need motivational games. They created conditions where intrinsically motivated, often very young engineers could see that their work mattered and could feel the impact of their decisions quickly.

There is a better path. When you stop fighting intrinsic motivation and design your organization around it instead, something fundamental shifts. Developers stop feeling like they must fight the organization to do good work. Leaders stop feeling like they must push teams into motion. Delivery becomes predictable not through control, but through alignment. The key is understanding what intrinsic motivation needs to thrive — autonomy, mastery, and purpose — and building mechanisms that make it visible, usable, and respected rather than hidden, ignored, or crushed.

What Intrinsic Motivation Looks Like in Real Life

Intrinsic motivation shows up as pride, curiosity, and a need for things to make sense. It is the developer improving code without being asked — not obedience, but care.

If you ask developers directly whether they are “intrinsically motivated”, most will shrug. It is not a phrase they use about themselves. Instead, you see it in behavior:

Someone keeps refactoring a tricky module in their spare time because they want the system to be understandable.
A colleague spends their lunch hour helping a teammate debug a flaky test, not because it is on their performance plan, but because they cannot stand unreliable builds.
After a long day, a developer opens the editor “just for ten minutes” to try a small improvement they have been thinking about — and two hours later, a hard problem is solved.

This is not obedience. It is not compliance with a process. It is pride, curiosity, and a need for things to make sense. When you see someone going beyond the minimum requirement without being asked, you are watching intrinsic motivation in action.

From the outside, this can look inefficient: Why are they “wasting time” polishing the logging? Why are they so insistent on writing tests for “simple” code? But over time, those acts of care are exactly what make systems robust, maintainable, and cheaper to change.

The problem is not that organizations lack motivated developers. The problem is that structures often turn this motivation into frustration.

We have seen this story before in engineering history. Skunk Works in the 1940s and 1950s did not succeed because someone wrote the perfect process document; it succeeded because a small group of highly motivated engineers were protected from bureaucracy long enough to make unconventional decisions and learn quickly from reality. The 1968 software crisis — more than half a century ago now — was, in a different way, a warning that when complex work is forced into rigid structures designed for simpler times, motivation and results both suffer. Today, organizations sit somewhere between those two examples: they want Skunk Works outcomes, but often manage software like a slow, compliance-driven project from the software-crisis era.

The warning from 1968 is still current: if you force complex, creative work into rigid structures designed for simpler problems, you do not only lose predictability — you slowly destroy the intrinsic motivation that makes real progress possible.

Beyond structural problems, there is a quieter dynamic at play. In many organizations there is an age and experience gap between executives and developers. Senior leaders have lived through several crises, made painful trade-offs, and survived internal politics; it becomes easy to interpret the energy of a motivated 25-year-old as naïve, or their insistence on quality as an inability to see “the bigger picture”. Younger developers, on the other hand, often arrive assuming that everyone acts professionally and in good faith. The first time they run into politics or see decisions driven by optics instead of evidence, it feels like a violation, not just another day at the office.

Layered on top of that, in some executive circles it is fashionable to joke about “the nerds” or to treat highly skilled developers as a kind of clever but replaceable commodity, motivated primarily by salary and perks. That attitude can be hidden behind polite language and performance dashboards, but it always leaks through in small decisions: who is involved early, whose concerns are waved away, whose time is treated as endlessly elastic. People notice. Intrinsically motivated developers are nobody’s useful idiots; they will lend their talent to an effort they respect — and they will withdraw it, first psychologically and then physically, when they no longer do.

How Organizations Accidentally Crush Intrinsic Motivation

Organizations do not lose developers' motivation suddenly. They wear it down through repeated conflicts between the developer's care for quality and the organization's structures.

Developers rarely lose their motivation overnight. It is worn down by repeated experiences where their care for the work conflicts with the way the organization operates. Whether through structural problems, generational gaps, or simple misunderstanding, the result is the same: intrinsic motivation meets resistance instead of support.

Here are some of the most common patterns.

1. Treating Developers Like Work-Item Machines

When work is structured as an endless stream of work items with little context, developers are reduced to implementers of other people’s ideas. The message is clear: “We tell you what to do; your job is to type it in.”

In this environment:

There is little space for deeper thinking about the problem.
Quality becomes “good enough to close the work item”.
Local optimizations win over long-term coherence.

Intrinsic motivation does not disappear, but it has nowhere to go. People either disengage or move their energy to side projects outside the company.

2. Punishing Honest Risk Signals

Motivated developers care deeply about preventing avoidable pain — outages, data loss, security incidents, and late-night emergencies. When they raise risks early and are ignored, or worse, blamed for “being negative” or “blocking delivery”, something breaks.

After a few cycles of this, the lesson is clear: it is safer to stay quiet and let problems surface later. The organization loses exactly the behavior it needs most: early, honest signals from the people closest to the work.

3. Celebrating Heroics Instead of Systems

Every time an organization celebrates the person who “saved the release” by working through the weekend, it unintentionally sends a message: we value crisis heroics more than quiet, systematic work that prevents crises.

Developers with strong intrinsic motivation do not enjoy chaos. They prefer flow: a stable pace of meaningful work, with enough time to do it properly. When chaos is rewarded and calm is ignored, the signal is again clear: their natural way of working is not valued.

4. Micromanaging the How, Ignoring the Why

Intrinsic motivation thrives when people understand the purpose of their work and have autonomy in how to achieve it. Many teams get the opposite: detailed solution descriptions, fixed implementation plans, and shifting priorities with no explanation.

Developers in these environments spend more time justifying their choices than making good ones. Over time, they learn that initiative is dangerous and that it is safer to follow instructions, even when those instructions are obviously flawed.

When executives treat technical skill as subordinate to organizational power rather than as complementary expertise, intrinsic motivation does not disappear — it goes silent, or it leaves.

Leaders are not outside this system. Most executives could not personally implement the features they ask for, just as most developers could not negotiate an enterprise contract or calm an anxious board. That is normal. The danger begins when power is used as if skill were evenly distributed: “you work for me” instead of “we are in this together”. Skilled, intelligent people will follow for a while out of loyalty and professionalism, but if the environment keeps hurting them, they eventually stop giving their best or quietly leave. Intrinsic motivation cannot be commanded; it has to be met with respect.

The Psychology Behind Intrinsic Motivation

Understanding how intrinsic motivation gets crushed is only half the picture. To design environments where it can thrive, we need to understand what supports it in the first place.

Intrinsic motivation needs three things: autonomy to decide how, mastery to keep improving, and purpose to know why the work matters.

None of this is unique to software. Research in motivation and organizational psychology has consistently shown that intrinsic motivation is supported by three core conditions:

Autonomy – having meaningful control over how you do your work
Mastery – being able to improve your skills and take on challenging problems
Purpose – understanding why the work matters beyond the immediate task

You do not need to quote research papers in a team meeting to see this. Just think of the best work you have ever done in your career. Chances are, you had:

Enough freedom to make real decisions
Problems that were demanding but not impossible
A clear sense that what you were building mattered to someone

When any of these three are consistently missing, people withdraw. They might still show up, still complete tasks, still attend meetings — but the spark is gone. The code does what it must, and nothing more.

These principles are universal, but for developers, autonomy, mastery, and purpose have specific, concrete shapes.

What Developers Actually Need to Stay Intrinsically Motivated

You cannot give people intrinsic motivation — they already have it. Your job is to stop damaging it and shape the environment around it.

If you want to keep intrinsic motivation alive, you cannot “give” it to people — they already have it. Your job is to stop damaging it and to shape the environment around it.

Here are practical levers that matter more than slogans or posters.

1. Real Autonomy Over Technical Decisions

Autonomy for developers does not mean they choose any technology they like. It means they are trusted to decide how to solve a problem within clear constraints.

Many organizations confuse autonomy with standardization debates. The discussion becomes “we use Java” or “which framework should we mandate” — but that misses the point. Real autonomy is about how to architect a system to solve a business problem: how to structure modules so they stay understandable, how to handle failure modes, which parts can change independently, where to draw boundaries. These decisions shape whether the system will be maintainable and evolvable, or a slow-moving liability.

That includes:

Being involved early in shaping solutions, not just estimating them
Having the mandate to improve code structure when they see a better way
Saying “no” to shortcuts that create unacceptable risk, and being taken seriously

If every technical decision must be argued repeatedly with non-technical stakeholders, intrinsic motivation turns into permanent defense.

2. Time and Space for Mastery

Developers become deeply motivated when they can see themselves getting better: understanding a complex domain, improving the architecture, making the system easier for others to work with.

You support this when you:

Protect focus time instead of fragmenting days with meetings
Make it normal to invest in test coverage, refactoring, and internal tools
Encourage sharing knowledge through pairing, reviews, and internal talks

“Learning” is not a separate activity from delivery. In modern software work, it is the only way to keep delivering at all.

There is a particular responsibility toward older developers who chose to stay close to the code instead of moving into management. Many of them carry decades of experience — including scars from projects that went badly for reasons that had nothing to do with their technical judgment. When that experience is systematically ignored or overruled by people who neither see the code nor the consequences, some of them quietly turn cynical. They keep the system running, but they also learn to play their own game: accommodating official decisions on the surface while informally routing around what they see as harmful choices. From the outside everything looks stable, yet a growing part of the real decision-making has moved underground.

3. Clear Purpose Connected to Real Users

Nothing drains motivation faster than building features that no one uses or understands.

Developers stay engaged when they:

See how users interact with the product, including usage data and real stories
Understand the business problem a feature is supposed to solve
Hear directly when a change improved someone’s life or workflow

In many organizations, this connection is completely missing. Developers are shielded from customers, receiving only work item descriptions and second-hand opinions. This is a mistake. When you treat developers as partners in solving user problems, they respond with creativity and energy.

At this point, a common objection arises: won’t giving developers all this autonomy and purpose make delivery unpredictable?

Intrinsic Motivation and Predictable Delivery Are Not Opposites

Intrinsically motivated developers are your best allies for predictable delivery. They simplify designs, catch issues early, and warn when timelines make failure likely.

There is a persistent fear in some leadership circles: if you give developers too much autonomy, you will lose predictability. The assumption is that intrinsic motivation leads to “gold-plating”, endless refactoring, and resistance to business needs.

In reality, the opposite is true when you structure things correctly.

Predictability does not come from forcing people to ignore reality and hit arbitrary dates. It comes from:

Working in small, coherent slices that can be delivered independently
Having honest conversations about risk and uncertainty early
Using evidence from the actual system — deployment frequency, defect patterns, lead time — to adjust plans

Intrinsically motivated developers are your best allies here. They are the ones who will:

Simplify overcomplicated designs
Push for automated tests that catch issues before production
Warn you when timelines and scope make failure likely

The key is to turn these instincts into part of the delivery system instead of treating them as obstacles. That requires specific mechanisms.

Designing Your Organization Around Intrinsic Motivation

Make intrinsic motivation visible and usable through daily logbooks that reveal where it is working and where it is blocked, plus embedded advocacy that translates insight into decisions.

If you want to harness intrinsic motivation rather than fight it, you need mechanisms that make good intent visible and usable.

Two practices are particularly powerful.

1. Daily Logbooks: Seeing the Work as Developers Experience It

Short, structured daily log entries from developers — what they worked on, what blocked them, what they learned — create a living record of how the system really behaves.

Over time, these logbooks reveal:

Where intrinsic motivation is already at work (people improving things unasked)
Where it is being frustrated (repeated blockers, ignored risks, chronic interruptions)
Which parts of the system or organization cause the most friction

Tools like Caimito Navigator automate this pattern: developers capture a few minutes of reflection each day; leadership receives weekly intelligence that highlights patterns, risks, and opportunities. The key is that the signal comes directly from the work, not from polished status reports.

2. Embedded Technical Advocacy: Translating Motivation into Outcomes

Even with visibility, someone has to connect what motivated developers are seeing to decisions at the leadership level. This is where an embedded Senior Developer Advocate becomes crucial.

Because they:

Work directly in the codebase, they recognize where intrinsic motivation is trying to improve things — and where it is being blocked.
Understand executive concerns, they can translate developers’ warnings into clear, actionable options instead of abstract complaints.
Operate across teams, they can spot repeating patterns and propose systemic changes instead of one-off fixes.

In this role, intrinsic motivation is no longer a private, fragile resource. It becomes a strategic asset: a constant flow of grounded insight about where to invest, what to simplify, and how to reduce future pain.

Before moving to implementation, it helps to assess where your organization stands today.

Questions Worth Asking

If you are in a leadership role, here is a straightforward way to assess how well your organization supports intrinsic motivation today.

Ask yourself:

Can I point to concrete examples from the last month where developers changed our plans because they saw a better way — and we listened?
Do I see regular, structured evidence of what is blocking teams, beyond anecdotes in meetings?
When someone raises an uncomfortable risk, is the typical response curiosity or defensiveness?
Are the people who quietly prevent crises by improving the system recognized as clearly as those who “save” releases at the last minute?
Would a thoughtful developer, listening to our leadership jokes and hallway conversations, conclude that we genuinely respect their judgment — or that we merely find them useful as long as they help us hit our own targets?
Do our language and decisions reveal an unspoken story in which younger developers are “idealistic but naïve” and older, hands-on developers are “stuck” or “difficult” — instead of recognizing both as essential partners with different kinds of experience?

If the honest answer to most of these is “no” or “not really”, you have your roadmap. The goal is not to “motivate developers” — they are already motivated. The goal is to stop wasting that motivation.

Bringing It All Together

When you stop fighting intrinsic motivation and design around it instead, developers stop fighting the organization, leaders stop pushing teams, and software delivery becomes something you can trust.

Intrinsic motivation in software development is not a nice-to-have personality trait. It is the engine that makes sustainable, high-quality delivery possible. You cannot buy it, and you cannot force it with slogans. But you can absolutely design your organization so that it survives contact with reality.

That means:

Treating developers as partners in solving real problems, not ticket processors
Creating structures that reward prevention and clarity, not just heroics
Making work and learning visible through daily logbooks and organizational intelligence
Embedding technical advocacy so that motivated insights turn into better decisions

When you do this, something important shifts. Developers stop feeling like they have to fight the organization to do good work. Leaders stop feeling like they must push teams into motion. Instead, intrinsic motivation and organizational purpose align — and the result is software that works, teams that stay, and a delivery system you can actually trust.

If that sounds like a distant ideal in your organization today, remember: you do not need a grand transformation program to begin. You can start tomorrow by asking a simple, sincere question: “What is getting in the way of you doing the work you are proud of?” Then listen — and be prepared to change the system, not the people.

Ready to turn intrinsic motivation into a strategic advantage?

Explore Caimito Navigator to see how daily logbooks and organizational intelligence can surface the signals already present in your teams — or learn more about Senior Developer Advocate services if you want embedded, hands-on support turning that motivation into predictable, reliable delivery.

Bridging the Great Divide

2025-12-01T00:00:00+01:00

A 57-Year Struggle No One Chose — and How to End It

01.12.2025, By Stephan Schwab

By bringing organizational intelligence and embedded technical advocacy into daily operations, organizations can replace assumptions with evidence and transform antagonism into productive collaboration. Since the 1968 software crisis, a recurring pattern persists: non-technical managers and technical teams often misunderstand each other. This divide isn't inevitable — it stems from invisible work, missing shared language, and decisions made without facts.

A familiar pattern plays out in software organizations: managers struggle to understand why timelines slip and technical requests seem endless, while developers feel their expertise and warnings go unheard. Both groups work hard, care about success, yet find themselves in recurring conflict.

You might recognize this moment: You’re a manager preparing for a board meeting, knowing you promised delivery by quarter-end. The team just told you they need “another sprint for refactoring.” Your stomach tightens. How do you explain this to the board?

Or perhaps you recognize this: You’re a developer who’s been warning for months about the authentication system’s fragility. Leadership just added three new features to the roadmap. You know what’s coming — nights, weekends, and eventually, the crisis you predicted. No one will remember you warned them.

Both conversations are real. Both happen in organizations every day. And this pattern — mutual distrust, frustration, and fundamental misunderstanding between technical and non-technical people — has persisted since the 1968 NATO Software Engineering Conference coined the term “software crisis.”

That was 57 years ago. Why hasn’t this improved?

A brief clarification: When we say “non-technical,” we mean specifically those who haven’t built large-scale software systems. Many accomplished engineers and technical leaders from other domains — mechanical engineering, electrical engineering, manufacturing — find themselves managing software teams. Just as a distinguished engine engineer with “gasoline in their blood” would struggle to predict how code will behave under production load, software complexity follows different rules than physical systems. This isn’t about intelligence or technical capability; it’s about domain-specific expertise that only comes from building, breaking, and maintaining complex software over years.

Here’s what’s really happening beneath the surface: Each role carries distinct pressures and perspectives. Managers carry the weight of commitments to customers, boards, and market expectations — they need certainty in an uncertain domain. Developers carry the weight of technical reality and long-term consequences — they see risks others can’t. Everyone is trying to protect the organization, but from different vantage points. Neither perspective is wrong; each is incomplete without the other.

To understand why this pattern persists, we need to look at how it began — and why five decades of methodologies haven’t solved it.

The Software Crisis Never Ended

In 1968, experts recognized that software projects were routinely late, over budget, and of poor quality. The proposed solution was to apply engineering discipline to software development. What they didn’t fully appreciate was that software is fundamentally different from physical engineering — it’s invisible, malleable, and its complexity compounds in ways that defy traditional project management.

The crisis didn’t end. It evolved. Organizations adopted methodologies — Waterfall, Agile, DevOps, Lean — each promising to bridge the gap. Yet the fundamental tension remains: non-technical decision-makers need predictability and control, while technical teams need flexibility and time to manage invisible complexity.

The result is a decades-long pattern of mutual frustration. But here’s the crucial insight: these aren’t personality conflicts or communication failures — they’re psychological responses to genuinely incompatible information environments. Each group is reacting rationally to what they can see, which is fundamentally different from what others in different roles can see.

Let’s examine how this plays out in daily reality:

What managers often experience:

Difficulty getting clear estimates and timelines
Technical explanations that are hard to evaluate
Requests for refactoring that delay visible features
Pushback on business requirements without clear alternatives
Complexity that makes simple changes feel costly

What developers often experience:

Timelines set without technical input or feasibility assessment
Risk warnings that don’t influence decisions until problems emerge
Pressure for immediate delivery without time to address technical debt
Expectations that don’t account for software’s inherent uncertainty
Technical expertise underweighted in strategic decisions

Neither perspective is entirely wrong. And that’s precisely the problem.

The psychological reality: When managers ask for commitments, they’re trying to create stability and predictability for the organization — it’s an act of leadership and responsibility. When developers push back on timelines, they’re trying to prevent future pain and protect quality — it’s an act of professional integrity and care. Both motivations are noble. Both are necessary. The conflict arises not from bad intentions, but from operating in different information spaces with different accountability structures.

So if everyone has good intentions, why does the divide persist? The answer lies not in the people, but in the structural conditions that make collaboration nearly impossible.

Why This Divide Persists

The gap between technical and non-technical perspectives isn’t caused by bad people. It’s caused by structural problems that make mutual understanding nearly impossible. Four factors, in particular, create and perpetuate this divide:

Invisible Work

Software development is largely invisible. A manager can see a construction project’s progress by walking the site. They can count assembled units in a factory. But software? It exists in abstract form — lines of code, architecture diagrams, test suites, deployment pipelines. Progress isn’t visible until something runs, and even then, quality is hard to assess.

“But I can see the software,” you might think. “I use it every day. I see the interface, the buttons, the screens.” This is where the illusion begins. The user interface is like the dashboard of a car — you can see the speedometer, the fuel gauge, the warning lights. But the dashboard tells you nothing about whether the engine was built correctly, whether the transmission will fail under stress, or whether the frame will hold up in a crash. When you look at software’s UI, you’re seeing perhaps 5% of what exists. The other 95% — the architecture, the algorithms, the data structures, the integrations, the error handling, the security layers, the performance optimizations — remains completely invisible. This is why two applications that look identical in the UI can differ wildly in quality, maintainability, and long-term cost.

This invisibility creates an information vacuum that everyone struggles to navigate. Without shared visibility into the actual work, decisions are made with incomplete context, leading to misalignment and frustration.

What this feels like psychologically: For managers, it’s like being responsible for a ship’s navigation but the compass only works for the crew — you can see the destination, feel the pressure from passengers asking “are we there yet?” but you’re navigating by asking questions in a language where every answer feels incomplete. For developers, it’s like being the ship’s engineer — you can hear the hull creaking, you know the engine needs maintenance, but the captain keeps ordering full speed ahead because “the passengers expect to arrive on time.” Both are trying to get everyone safely to shore.

Missing Shared Language

This invisibility problem compounds when we add a second structural issue: even when people try to communicate across these roles, they’re speaking fundamentally different languages.

Technical and non-technical people use different vocabularies. When a developer says “We need to refactor the authentication service before adding SSO,” a non-technical manager hears: “We want to rewrite working code instead of delivering what you asked for.” The manager feels frustration: Why won’t they just do their job?

When a manager says “Can we ship this by month-end?” a developer hears: “I don’t care about quality, architecture, or whether this creates maintenance nightmares. Just make it happen.” The developer feels disrespected: They think I’m making excuses.

Neither translation is accurate. Both people leave the conversation feeling misunderstood and resentful. This happens dozens of times per week in most organizations.

Decisions Made Without Facts

Invisible work and missing shared language create a third problem: when you can’t see the work clearly and can’t communicate about it effectively, decisions inevitably get made without sufficient facts.

You’ve been in these meetings. Someone asks: “How long will this take?” The developer, knowing the answer depends on factors that won’t be clear until they start, offers a range: “Probably two to four weeks, depending on what we discover as we build.” The meeting notes record: “Estimate: 2 weeks.” The developer winces but doesn’t object — what’s the point?

Here’s the reality: Building software is design work, not assembly work. You can’t know how long design takes until you attempt it and learn what the problem actually requires. This is why experienced developers speak in ranges and hedge with “depending on what we find” — they’re being honest about the discovery inherent in creation.

Most software decisions are made with insufficient data:

Estimates are guesses dressed up as commitments
Risk assessments rely on gut feeling rather than evidence
Progress reports emphasize what sounds good over what’s true
Quality is assumed until production breaks
Team performance is measured by output, not outcomes

When decisions are made without facts, they’re influenced by organizational dynamics rather than technical reality. This often results in commitments that don’t reflect actual capacity, leading to overwork, missed expectations, and mutual frustration.

Organizational Incentives Misaligned

Even if we could solve the visibility, language, and information problems, there’s a fourth structural challenge: the incentive systems that drive behavior are fundamentally misaligned.

Consider the incentives:

Sales and product teams are rewarded for promises and features
Executives are measured on revenue growth and shareholder value
Developers are evaluated on code quality and technical execution
Operations teams prioritize stability and uptime

These incentives naturally conflict. Sales wants aggressive timelines. Executives want predictable roadmaps. Developers want sustainable pace. Operations wants no changes that might cause outages.

Without a mechanism to align these incentives around shared outcomes, each group optimizes locally — and the organization suffers globally.

These four structural problems — invisible work, missing language, fact-free decisions, and misaligned incentives — create the conditions for conflict. But the real damage shows up not in org charts or process diagrams. It shows up in people’s lives.

The Human Cost

This divide extracts a toll that rarely appears in quarterly reports:

Developers experience:

Chronic stress from impossible expectations
Burnout from repeated death marches
Disengagement when their expertise is ignored
Career damage when projects fail despite their warnings
Moral injury from being forced to ship work they know is defective

Managers and leaders experience:

Anxiety about commitments made with uncertain information
Difficulty assessing technical tradeoffs without specialized knowledge
Professional risk when delivery doesn’t match expectations
Strained relationships with stakeholders and customers
Exhaustion from managing crises that seem preventable in hindsight

Organizations experience:

High turnover in technical roles
Ballooning budgets as projects drag on
Market opportunities missed due to slow delivery
Technical debt that compounds until systems collapse
Cultural toxicity that repels talent

Nobody wins. Everyone suffers. And the pattern repeats project after project, year after year.

Behind these bullet points are real people:

A manager lying awake at 3 AM, rehearsing how to explain to the board why the promised feature isn’t ready. Again. Wondering if this is the one that costs them their credibility. Feeling trapped between impossible promises and incomprehensible explanations.

A developer sitting in their car in the parking lot before going in, taking deep breaths, trying to find the energy for another day of being told their concerns don’t matter. They’ve updated their resume three times this month but haven’t sent it anywhere. Not yet. Maybe after this release.

An executive watching yet another talented person give notice. “Better opportunity,” they say. But you know it’s the environment. The stress. The constant firefighting. You don’t know how to fix it, and that helplessness is exhausting.

These aren’t just organizational problems — they’re human struggles. Everyone wants to do good work, be respected, and go home feeling they’ve contributed something valuable. The system is failing them.

But here’s the crucial point: this suffering isn’t inevitable. It’s not the natural cost of doing software development. It’s the predictable result of those four structural problems we identified. Which means if we address the structure, we can end the suffering.

Breaking the Cycle

The solution isn’t another methodology. It’s not renaming roles or reorganizing teams. It’s not workshops about empathy or collaboration.

The solution is organizational intelligence — creating visibility into what’s actually happening, establishing shared language grounded in observable facts, and enabling decisions based on evidence rather than assumptions.

Why this matters psychologically: When people have shared access to the same information, the nature of conflict changes. Instead of “you versus me” it becomes “us versus the problem.” Managers can stop feeling like they’re negotiating with an opaque black box. Developers can stop feeling like their warnings fall into a void. Both can focus their considerable talents on solving actual problems rather than defending their positions.

This requires two things:

1. Making the Invisible Visible

Software work must become observable in ways that both technical and non-technical people can understand. Traditional status reports, written after the fact, often lack the detail needed for informed decisions. What’s needed is real-time, structured visibility into:

What people are actually working on day-to-day
What’s blocking progress and how long blockers persist
What’s being learned and how that affects plans
What risks are emerging before they become crises
What patterns repeat across weeks and months

This visibility must be:

Asynchronous, so it doesn’t fracture developer focus with meetings
Structured, so patterns emerge rather than anecdotes
Honest, capturing reality rather than desired narratives
Accessible, giving executives and teams shared context

Caimito Navigator was built precisely for this purpose. Through daily logbook entries — brief, focused observations about work, blockers, and learnings — it creates organizational intelligence. These entries aggregate into weekly reports that synthesize patterns, surface risks, and provide recommendations grounded in what actually happened.

Why logbooks? This practice is borrowed from professions where invisible complexity requires systematic documentation. Ship captains maintain bridge logs recording course changes, weather conditions, equipment issues, and navigational decisions — not for bureaucracy, but because lives depend on understanding what happened and why. Surgeons document procedures, complications, and learnings to improve outcomes and share knowledge. Research scientists keep laboratory notebooks detailing experiments, unexpected results, and evolving hypotheses — because discovery emerges from documented observation. In each case, professionals who work with high complexity and high stakes write things down daily, knowing that memory is unreliable and patterns only become visible when you can look back across time. Software development shares these characteristics: high complexity, high stakes, constant learning, and the need to surface problems before they become crises.

Observers (executives, board members, stakeholders) gain strategic visibility while respecting team autonomy. They see recommendations and conclusions in their full context, enabling informed decisions. They understand where teams are stuck, what’s accelerating, and where capacity is constrained — based on evidence, not opinion.

This transforms decision-making. Instead of “Can we ship by month-end?” the question becomes: “Given what we’re observing about integration complexity and the emerging API dependencies, what’s the earliest realistic date — and what would we need to change to accelerate it?”

Facts replace guesses. Shared understanding replaces conflict.

2. Embedding Technical Advocacy

Visibility creates the foundation for better decisions, but there’s still a gap: someone needs to help people in different roles interpret what they’re seeing and translate it into action. This is where human expertise becomes essential.

This is the Senior Developer Advocate role: a hands-on senior engineer who writes code while clearing delivery obstacles. Not a theorist. Not a process consultant. Someone who improves delivery by improving the code, the pipeline, and the feedback loop simultaneously.

The Developer Advocate:

Works directly in the codebase 60-70% of the time (shipping features, fixing flow, strengthening tests)
Identifies friction in real-time (flaky tests, unclear requirements, blocked dependencies)
Translates technical constraints into business context for executives
Coaches teams through improvements during actual delivery work
Reports directly to senior leadership, maintaining neutral perspective outside internal politics

This role bridges the gap because it eliminates the “us versus them” dynamic. The Advocate isn’t on the technical side or the business side — they’re on the delivery side, focused on getting valuable software into production safely and predictably.

When management asks “Why is this taking so long?” the Advocate can answer with specifics grounded in actual work: “The authentication service has accumulated six months of technical debt. We have three options: ship with known security gaps and plan immediate fixes; invest two weeks refactoring before adding SSO; or implement SSO around the existing structure, accepting slower future changes. Here’s the evidence for each.”

When developers say “This deadline is impossible,” the Advocate can clarify: “Impossible as currently scoped, yes. But if we descope these three features and parallelize testing, we can deliver core value in three weeks instead of six. Here’s what that looks like.”

No one is dismissed. Everyone is heard. Decisions are made with full context.

These two elements — organizational intelligence through Navigator and technical advocacy through embedded expertise — work together to transform how organizations operate. But what does this actually look like day-to-day?

What This Looks Like in Practice

Imagine an organization where:

Daily logbook entries create a transparent record of work, blockers, and learning — visible to everyone from developers to the CEO. When someone asks “What’s the team working on?” there’s an actual answer, not a guess.
Weekly intelligence reports synthesize patterns: where teams are stuck, what’s accelerating, what risks are emerging — automatically generated from the daily log. Monday’s leadership meeting discusses real data, not optimistic status reports.
A Senior Developer Advocate operates inside the team, shipping code while clearing obstacles — trusted by engineers because they write real code, credible to executives because they speak business. When tension arises, there’s someone who can translate without taking sides.
Decisions are made from evidence: deployment frequency, escaped defects, lead time, observed collaboration patterns — not from wishful thinking or political pressure. When someone says “We need two more weeks,” there’s data showing why, not just assertion and counter-assertion.
Problems surface early: a blocked dependency on Tuesday appears in the daily log, gets addressed Wednesday, doesn’t explode into a Friday crisis where everyone’s weekend is suddenly gone.
Trust replaces suspicion: technical people feel heard and respected; non-technical people have visibility and confidence. Meetings become collaborative problem-solving instead of defensive posturing.

This isn’t utopian fantasy. This is how high-performing software organizations operate. They’ve replaced information asymmetry with organizational intelligence. They’ve replaced mutual distrust with shared understanding grounded in facts.

The path forward is clear. The question is whether we’re ready to take it.

Moving Forward

The 1968 software crisis identified a fundamental problem: software is hard to manage using traditional approaches. Fifty-seven years later, many organizations still struggle with the same issues — not because software got harder, but because they’re still trying to manage invisible work with invisible tools and misaligned incentives.

The path forward doesn’t require elaborate frameworks or organizational overhauls. It requires four foundational shifts:

Make work visible through daily structured logging and weekly intelligence
Embed technical advocacy to bridge language gaps and translate between worlds
Base decisions on evidence rather than assumptions, politics, or hope
Align incentives around shared outcomes: valuable software delivered safely

Both technical and non-technical people want the same thing: predictable delivery of high-quality software that serves the business. They’re not enemies. They’re teammates trapped in a system that makes collaboration unnecessarily difficult.

If you recognized yourself in these scenarios — the 3 AM anxiety, the frustration of being misunderstood, the exhaustion of constant conflict — know that you’re not the problem. The system is the problem. And systems can be changed.

We can fix the system. We can bridge the divide. We can replace decades of frustration with productive partnership — but only if we commit to visibility, advocacy, and evidence-based decision-making.

The divide isn’t inevitable. It’s a choice. Let’s choose differently.

Ready to bridge the gap in your organization?

Explore Caimito Navigator to bring organizational intelligence to your software delivery — or learn more about Senior Developer Advocate services to embed hands-on technical expertise that bridges technical and business perspectives.

The Engine of Predictable Software Delivery

2025-11-28T00:00:00+01:00

Why Some Software Teams Are Predictable and Others Aren’t

28.11.2025, By Stephan Schwab

Predictable software delivery is not about magic; it's about discipline, amplified by AI. Core engineering practices — like test-first development, collaboration, and continuous integration — are being supercharged by artificial intelligence. This powerful combination turns software development from a high-stakes gamble into a reliable engine for business value, enabling teams to build the right thing, build it right, and adapt at speed.

Every business leader wants predictability from their software teams. They want to know that when they invest in a new feature, it will be delivered on time, on budget, and to a high standard of quality. Yet, many organizations find themselves trapped in a cycle of missed deadlines, buggy releases, and a constant sense of uncertainty. The problem is often not a lack of talent or effort, but the absence of a few fundamental engineering disciplines — practices that are now supercharged by AI.

These practices form an engine of predictability. They are not a methodology to be bought or adopted; they are a set of disciplined habits that create fast feedback loops, reduce risk, and ensure that the team is always moving forward on a solid foundation. When these practices are at the heart of a project — whether it’s a brand-new application or a decades-old legacy system — the result is a calm, consistent, and predictable flow of value.

With that context, let’s explore what these core practices are and why they are so effective.

The Enduring Quest for a Silver Bullet

The struggle for predictable software delivery is not new. In fact, it dates back to at least 1968, when a NATO conference coined the term “software crisis” to describe the widespread problems of projects running over budget, behind schedule, and delivering unreliable results. In the decades since, a multi-billion dollar industry has emerged, selling management frameworks and methodologies that promise to solve this crisis.

These frameworks are appealing, especially to non-technical leaders, because they offer a sense of order and control. They provide roles, ceremonies, and metrics, all designed to rein in the seemingly chaotic process of software development. Yet, they consistently fail to deliver on their promise because they fundamentally miss the point. They try to impose discipline from the outside, like building a scaffold around a house with a crumbling foundation. They focus on managing the people in the hope that the work will fix itself.

The truth is that predictability doesn’t come from a management framework. It comes from the inherent quality and stability of the engineering process itself. The practices described here are the foundation. Without them, no amount of project management can save a project from delays and defects. With them, the need for rigid, top-down control diminishes, replaced by a natural, predictable flow of high-quality work.

Software Development is More Discovery Than Construction

A common and misleading analogy compares software development to building a bridge. It suggests a world of known quantities, fixed blueprints, and predictable assembly. If only it were that simple. In reality, building software, especially new products, is less like construction and more like a journey of discovery.

When you build a bridge, the laws of physics are known and unchanging. The problem is well-defined. In software, the “problem” is often a moving target. You start with a hypothesis about what users need, and the very act of building and releasing the first version is an experiment to test that hypothesis. The feedback from real users is the most critical ingredient, and it inevitably changes your understanding of what you should be building.

This holds true even in heavily regulated domains where laws and rules seem to dictate the requirements. While the rules themselves might be fixed, the best way to implement them in software is not. There are countless design choices and trade-offs to be made, and the initial interpretation of a rule can often be refined. The process of writing the software reveals edge cases and ambiguities that require clarification. Therefore, an iterative approach is far superior to a rigid, upfront plan. An iterative approach is not childish experimentation; it is a disciplined cycle of building a small, complete piece of functionality, measuring its correctness and effectiveness, and then using that feedback to inform the next small step. It’s how you navigate the journey of discovery without getting lost, replacing large, risky bets with a series of small, safe, and informed decisions.

This is why the “best practices” in software are not about rigidly following a pre-defined plan. Instead, they are about creating a system that can adapt to new information quickly and safely. They are practices for navigating uncertainty and turning discovery into a competitive advantage, not just executing a set of instructions.

Start with the Goal: AI-Assisted Test-First Development

Imagine building furniture with a master craftsperson at your side, instantly providing the blueprint for each cut. This is what modern, AI-assisted software development looks like. The core principle remains the same: writing a small, automated test before writing the actual code for a feature. But now, AI supercharges this process.

A developer can ask an AI assistant, “Write a test for a capability that calculates the total price, including tax.” The AI generates the test code in seconds. This test initially fails because the capability doesn’t exist. The developer then asks the AI to write the simplest possible code to make the test pass. This “test-first” cycle, now happening at the speed of conversation, has profound implications:

Accelerated Clarity: AI helps translate requirements into executable tests instantly. It can even suggest edge cases and scenarios (e.g., “what about negative quantities? what about different tax rates?”) that a human might overlook, forcing a deeper understanding of the problem from the outset.
An Even Stronger Safety Net: Building a comprehensive test suite is faster than ever. This makes the safety net more robust, empowering teams to make changes with even greater confidence. AI can instantly write tests for existing, untested code, making it safer to modernize legacy systems.
Truly Executable Documentation: The tests, often co-created with AI, become a form of living documentation. A new team member can not only read them but also ask the AI to explain them, providing an interactive onboarding experience.

Crucially, these tests should describe what the system should do, not how it does it. The developer’s role shifts to guiding the AI to produce high-level, business-focused tests. When done right, the collection of tests reads like a specification for the system, written in plain English, and validated by the machine.

For a business, this means higher quality, faster development cycles, and a system that is better understood and easier to change.

Two Heads Are Better Than One: Human-AI Collaboration

In many industries, it’s standard practice for critical work to be reviewed. In software, the most effective way to do this has been to have two developers work together. Today, this concept is expanding to include a new kind of partner: the AI assistant.

This isn’t just about two humans anymore. It’s often a human developer paired with an AI. The AI acts as a tireless, knowledgeable partner with instant access to vast libraries of technical information.

Augmented Expertise: The human developer sets the strategy and direction, while the AI handles the tactical implementation. A developer can say, “Refactor this code to be more efficient,” and the AI will perform the complex task, explaining its reasoning. This frees up the human to focus on the bigger picture: the business problem and the overall system design.
Instant Knowledge Sharing: The AI serves as a universal knowledge base for the team. Instead of interrupting a colleague, a developer can ask the AI, “How does our authentication system work?” or “What’s the best way to connect to this database?” This democratizes knowledge and reduces dependencies on key individuals.
Continuous Code Review: The AI acts as a real-time reviewer. It can spot potential bugs, suggest improvements, and ensure the code adheres to the team’s standards, long before it’s submitted for human review.

This doesn’t replace human collaboration, which remains vital for complex problem-solving and mentoring. It augments it, creating a powerful human-AI team that produces higher-quality code, faster.

Integrate Early and Often: The AI-Powered Pipeline

Many teams fall into the trap of working in long, isolated branches. When the time comes to merge all this work back together, the result is chaos — a painful, time-consuming, and error-prone process often called “merge hell.”

The alternative is to integrate work continuously. This means that every time a small piece of a feature is complete (and its tests are passing), it is merged into the main codebase — often multiple times a day. AI makes this practice even more powerful:

No “Big Bang” Integration: Integration becomes a non-event. Small, frequent merges are easy to understand. If a problem occurs, AI can help diagnose it by analyzing logs and suggesting the likely cause.
Constant State of Readiness: The main codebase is always in a working, releasable state. The automated pipeline, often built with AI assistance, ensures every change is automatically tested.
Ultra-Fast Feedback: If a change introduces a problem, the team knows about it within minutes. The AI can pinpoint the exact change that caused the failure, eliminating guesswork.

This practice of Continuous Integration, powered by AI, is the backbone of predictable delivery. It makes the delivery process boring and reliable, which is exactly what you want.

Keep It Simple: AI-Driven Refactoring

In the face of complex problems, it’s tempting to build complex solutions. A core tenet of effective teams is a relentless focus on simplicity. The goal is always to find the simplest thing that could possibly work.

This is coupled with the practice of refactoring — the discipline of continuously improving the design of existing code without changing its external behavior. AI is a game-changer for refactoring.

Identifying Complexity: AI tools can scan the entire codebase and identify areas that are overly complex, hard to understand, or deviate from best practices.
Suggesting Simplifications: A developer can highlight a block of code and ask an AI, “How can I make this simpler?” The AI can propose alternative implementations that are cleaner and more efficient.
Automating Improvements: With the safety net of automated tests, a developer can confidently ask the AI to perform the refactoring, knowing that any unintended side effects will be caught instantly.

This creates a virtuous cycle: the team uses AI to build tests, then uses that safety net to empower the AI to simplify the code, making the whole system easier to manage and change.

The Predictability Engine, Amplified by AI

These practices — testing first, working collaboratively, integrating continuously, and keeping the design simple — are not independent. They reinforce each other, creating a virtuous cycle. And now, AI acts as a catalyst for this entire system.

AI-assisted testing makes it feasible to build the safety net needed for continuous integration and safe refactoring.
Human-AI collaboration produces better, simpler, and more thoroughly tested code from the start.
An AI-powered CI pipeline provides the fast feedback needed to keep the engine running smoothly.

When an organization embraces these fundamental practices and augments them with modern AI tools, they are building a supercharged engine for predictable software delivery. They move from a world of faith-based planning to one driven by evidence, discipline, and intelligent automation. The result is not just better software, but a faster, more reliable, and more sustainable way of working that turns technology into a true competitive advantage.

Leaders Must Work ON the System, Not Delegate

2025-11-25T00:00:00+01:00

Lasting Improvement Comes from Learning, Not from Following a Framework Roadmap

25.11.2025, By Stephan Schwab

Methodologies cannot be installed like software. Big-bang rewrites fail — Netscape and Borland learned this the expensive way. Arbitrary deadlines create panic, not progress. Real improvement requires a journey: developers learning better techniques in context, non-technical colleagues expressing requirements as testable specifications, and executives learning to read delivery signals directly rather than through filtered status reports. We embed with your teams, transfer skills, and step back when you're stronger — creating capability, not dependency. What follows explains why lasting delivery improvement comes from people learning to work better, not from following a branded framework's roadmap.

Three insights executives must accept:

Process cannot be installed with a deadline. Your codebase reflects years of decisions and embeds vast domain knowledge. Improving it requires discipline and time, not heroics or rewrites.
Improvement is a journey, not a destination. Like a car navigation system, you need current position, direction, and the next turn — not a rigid twelve-month roadmap.
Skill uplift beats ceremony compliance. Developers learning TDD, teams mastering CI/CD, and leadership reading real metrics create lasting change. Methodology rituals create theater — or worse, friction that prevents learning by separating thinking from doing, rooted in the misconception that software development is construction rather than design and discovery.

When executives contact us, they sometimes expect a familiar pitch:

Here’s the framework. Here’s the roadmap. Here are the ceremonies.

They've heard it before. They know the script. And maybe this vendor does it better.

But that’s not what we offer.

We don't arrive with a branded methodology. We don't install processes and leave. We don't create certified coaches to enforce compliance.

We embed.
We work with code and people.
We uplift skills.
Our metric is software in the hands of happy users.

But make no mistake: we work on the system, not in it.

Though a Senior Developer Advocate spends significant time in the code and pairing with developers, this role is not another team member subject to organizational rules or process ceremonies.

We operate with the independence needed to identify and address systemic constraints — not get absorbed into the problems we’re there to solve. Don’t fire us for non-compliance - being non-compliant is likely what you are paying us to do.

And then we leave you stronger than we found you — not dependent on us.

The Problem with Methodology Installation

Most consultancies sell transformation as a package:

A maturity model to assess your current state
A roadmap to guide you through stages
Ceremonies to structure your days
Coaches to ensure compliance
Return visits to “measure progress”

It looks comprehensive. It feels safe. It’s expensive.

And it rarely works.

Here’s why:

Software delivery is not a manufacturing process that can be standardized. It’s a creative discipline requiring judgment, adaptation, and deep technical skill.

AI amplifies this creativity — when developers know what they’re doing.

We help teams use AI tools to increase creativity, speed of execution, and iterate faster. But make no mistake: AI will not replace competent developers. We’re here to make everyone a competent developer who can leverage AI effectively.

AI assistance is powerful in the hands of someone who can:

Judge whether the generated code is correct
Spot subtle bugs and security issues
Understand architectural implications
Write tests that validate the solution
Refactor effectively to maintain clarity

Without this foundation, AI becomes a faster way to create legacy code.

The same logic applies to methodology installation.

Installing a method might create the appearance of progress — more meetings, more artifacts, more vocabulary — but it doesn’t address the actual constraints:

Developers who’ve never written a test - first
Teams afraid to integrate their code frequently
Leadership making decisions based on status slides instead of runtime evidence
Architecture decisions that made sense three years ago but now strangle velocity

You can’t ceremony your way out of technical debt. You can’t standupify your way to continuous delivery.

Real improvement requires people learning to work better. And that happens through doing, not through following a script.

What We Do Instead

We engage with the people who do the work and those who lead them.

For Development Teams:

We don’t run training sessions in a conference room. We pair with developers on real production code.

We introduce techniques — TDD, ATDD, trunk-based development, CI/CD — in context, on their codebase, under their constraints.

We show them how to write tests that give confidence. How to integrate safely multiple times per day. How to deploy small changes that reduce risk.

For Non-Technical Domain Experts:

We help developers interact effectively with colleagues who bring market knowledge, customer insight, and subject-matter expertise.

We facilitate ATDD sessions where business analysts, product managers, and domain experts collaborate with developers to define executable specifications.

We show teams how to translate domain language into automated tests, so everyone — technical and non-technical — can see whether the software does what was intended.

This isn’t about teaching non-technical people to code. It’s about creating a shared language for describing what success looks like, and ensuring developers build what’s actually needed — not what they think was requested.

For Leadership:

If you run a software company, you need to understand how software gets made. You wouldn’t run a restaurant without understanding the kitchen. Software is no different.

We help leaders — engineering managers, architects, executives — see what’s actually constraining delivery:

Where integration friction is hiding
What deployment frequency reveals about confidence
How lead time variation signals process dysfunction
Why escaped defects point to test strategy gaps
Are we deploying more frequently with fewer incidents?
Is our lead time trending down or stuck?
Are features being used, or just shipped?

These questions don’t require a computer science degree. They require curiosity about how the work actually happens.

This is what governance without control looks like in practice — designing systems that tell the truth, not managing people through status reports.

Leaders often feel trapped between:

Developers who speak in technical jargon
Project managers who filter bad news into optimism
Consultants who sell complexity as sophistication

We translate — not to shield you from the details, but to make them accessible.

We don’t replace your judgment. We give you better instruments to exercise it.

The goal isn’t to make you a developer. It’s to make you a leader who can have honest, fact-based conversations about delivery with your teams.

Don’t hide from us.

Seek dialog. Ask questions. Challenge our observations.

The worst thing you can do is stay distant and rely on filtered reports. We’re here to give you direct insight into what’s happening — not comfortable narratives, but reality you can act on.

Why This Approach Works

1. It addresses real constraints, not symptoms.

You don’t have a “people problem” or a “process problem.” You have specific technical and organizational constraints.

Maybe your test suite takes three hours to run, so no one runs it. Maybe your branching strategy creates integration debt that explodes during "merge week." Maybe your deployment process requires manual approval from five people, turning every release into a project.

These are fixable. But not by installing a ceremony.

2. It builds internal capability.

When we pair with developers, they don’t just watch us work — they learn to do it themselves.

When we coach leadership, they don’t become dependent on our translations — they learn to ask better questions and read evidence directly.

If after six months you need us the same way you needed us on day one, we’ve failed.

3. It respects your context.

We don’t arrive with a one-size-fits-all playbook.

We assess:

What’s already working (and protect it)
Where the highest-leverage improvements lie
What skills need uplift most urgently

Some teams need better test discipline. Others need deployment automation. Still others need clearer ownership and decision rights.

The solution is always specific. The method is always adapted.

4. It creates lasting change.

Dependency is the enemy of transformation.

If your improvement strategy requires permanent external coaching, it’s not improvement — it’s outsourcing.

We uplift skills so teams can continue improving after we leave.

We instrument delivery so leadership can see problems before they metastasize.

We establish feedback loops so learning becomes continuous, not event-driven.

What This Looks Like in Practice

We embed with teams on an at-will basis:

Observe how work actually flows. Identify the highest-leverage improvements. Pair with developers on real code. Uplift skills systematically. Instrument delivery so progress becomes visible. Step back when teams operate independently.

If we’ve done our job well, you don’t miss us when we leave. You’re just stronger.

Why This Isn’t a “Big Bang” — And Why That’s Good

Executives sometimes worry:

“This doesn’t sound like a complete transformation. Where’s the roadmap? Where’s the certainty?”

Here’s the truth:

Big-bang transformations fail precisely because they promise certainty.

Software delivery is uncertain. You’re building something that’s never been built before, for users whose needs evolve, in a market that doesn’t wait.

Pretending you can plan that into certainty is theater.

What you can do:

Reduce lead time so you learn faster
Increase deployment frequency so you adapt faster
Improve test coverage so you move with confidence
Clarify ownership so decisions don’t stall

These improvements compound. Faster learning enables better decisions. Better decisions compound into competitive advantage.

But they don’t follow a maturity model. They follow reality.

The Test: What Happens When We Leave?

Here’s how to know if an engagement was successful:

Ask these questions six months after we’re gone:

Are features being adopted by users, or just shipped and ignored?
Is revenue per developer trending up?
Are customer satisfaction scores improving?
Can you respond to market changes faster than before?
Are you spending less on operations while handling more volume?

If the answer to most of these is yes, the capability transferred.

If the answer is “we need to hire more coaches,” something failed.

Why We’re Not Competing with Methodology Consultants

Some executives assume we’re just another flavor of consultant.

We’re not.

Management consultants focus on organizational structure, governance, and strategy. That’s valuable work.

We focus on software delivery:

How developers work
How code flows to production
How leadership sees what’s happening

These are complementary.

When a methodology is already in place, we work with it.

We don't arrive to fight turf wars over narrative or frameworks. We're advocates for our client — from the technical side. Our job is to enable success through delivery.

If management consultants are present with their methodology, we collaborate. We make their frameworks executable by connecting them to real delivery signals.

If a method exists but consultants have left, we help you make it work better — or simplify what’s gotten bloated.

When new methodologies are being considered, we assess and advise.

If executives are evaluating a new framework or transformation approach, we will provide technical due diligence.

This isn’t optional — it’s part of our responsibility to you.

We will advise against approaches that:

Create artificial separation between thinking and doing
Treat software development as a manufacturing process
Add ceremony that obscures rather than reveals constraints
Prioritize compliance over learning

Our obligation is to our client’s success, not to any methodology’s brand.

If approaches become incompatible with effective delivery, we step back.

We won’t fight organizational battles over methodology.

If management insists on approaches fundamentally incompatible with our statement of work — approaches that will predictably harm delivery or create the conditions that drive developers to leave — we’ll conclude our engagement professionally.

This isn’t about winning an argument. It’s about integrity and protecting the people we’re there to serve.

Staying in a situation where our technical guidance is systematically overridden creates worse outcomes:

It confuses teams about what actually matters
It creates conflict that erodes trust and psychological safety
It often leads to the best developers leaving rather than fighting

We’d rather step back cleanly than contribute to that dynamic.

The Uncomfortable Truth

Beyond methodology debates, improving software delivery requires four things many organizations resist:

1. Senior leaders must own the transformation.

You cannot delegate this work to consultants. As explored in Reclaim Your Organization, the decision to improve must come from within.

You are the leaders. You set the pace. You protect the vision. You make the decisions. We provide help and guidance — technical expertise, delivery instrumentation, skill transfer.

We help you create and refine that vision by showing you what's actually constraining delivery. We give you better instruments to see reality. We coach you to ask better questions.

But the transformation is yours to lead, not ours to install.

If you’re looking to hand responsibility to an external vendor with a roadmap, we’re not the right fit.

2. Senior leaders must learn to see the work.

You cannot delegate understanding.

If you don’t know why your teams struggle to deploy, or why lead times vary wildly, or why “done” never seems to mean “shipped,” no consultant can fix that for you.

You have to look.

3. Developers must be allowed to improve their craft.

You cannot ceremony your way to technical excellence.

Developers need time to learn test-driven development. To refactor legacy code. To automate what’s manual. To experiment with better architectures.

If your process doesn’t protect space for this, your process is the problem.

4. Improvement is a journey, not an installation with a deadline.

Executives often create artificial urgency: “We need this fixed by October.” “The board expects transformation by Q2.” “If we don’t modernize now, we’re dead.”

This pressure is understandable. But it’s also dangerous.

Your codebase didn’t arrive at its current state overnight. Years of decisions, constraints, and trade-offs created what exists today. More importantly, your codebase embodies vast domain knowledge—business rules, edge cases, regulatory requirements, customer behavior patterns — accumulated through years of learning what actually works.

This knowledge isn’t just in documentation (which is often outdated or missing). It’s encoded in the code itself: how data flows, what validations exist, which assumptions are baked into algorithms.

Improving the codebase requires time and discipline — it cannot be installed or rewritten by heroics. And any rewrite must preserve and distribute this domain knowledge across the organization, or you’ll rebuild yesterday’s problems tomorrow.

The history of software is littered with expensive failures from executive impatience:

Netscape decided to rewrite their browser from scratch. The rewrite took three years. By the time they shipped, the market had moved on. The company never recovered.
Borland attempted to rewrite Quattro Pro. The project collapsed. Competitors shipped incremental improvements while Borland burned resources on a replacement that never materialized.
Countless companies have formed “expert rewrite teams” only to discover that replicating years of domain knowledge and edge-case handling is harder than anticipated. Meanwhile, the existing system continues accumulating technical debt because no one is maintaining it.

The pattern is consistent: Big-bang rewrites fail. Arbitrary deadlines create panic, not progress.

What works is steady, visible improvement:

Fix one integration bottleneck and measure the lead time change
Improve test coverage incrementally so confidence grows
Automate one manual deployment step at a time
Refactor sections of code as you work on them, not in isolation

The destination matters less than the trajectory.

If you’re improving every month, you’ll get where you need to be. If you’re setting deadlines and panicking when they slip, you’ll burn out your best people chasing an arbitrary date.

Patience isn’t passivity. It’s the discipline to value lasting progress over theatrical urgency.

What We’re Really Offering

We’re not selling a method. We’re not selling a transformation.

We’re offering partnership in building capability.

We bring:

Decades of hands-on software delivery experience
Proven techniques that reduce friction and increase throughput
The ability to translate between technical reality and executive decision-making
A focus on making ourselves unnecessary

You bring:

The context we cannot have
The authority to remove organizational obstacles
The willingness to learn alongside your teams

Together, we create lasting improvement.

Not because we installed a process, but because people learned to work better.

The Choice

You can install a methodology:

Buy the framework
Train the method champions
Follow the ceremonies
Hope it works

Or you can build capability:

Engage experienced practitioners
Uplift your teams’ skills
Instrument your delivery
Learn to see what’s happening

The first path creates dependency. The second creates capacity.

Choose accordingly.

Reclaim Your Organization

2025-11-22T00:00:00+01:00

Why Senior Leaders Must Stop Outsourcing Judgment to Framework Vendors

22.11.2025, By Stephan Schwab

Too many organizations lose their best developers not to better offers, but because of methods that treat humans like manufacturing inventory. Predictability is promised; compliance is delivered instead. Meanwhile, executives abdicate strategic judgment to consultants selling packaged frameworks, forgetting that no method can replace the hard work of understanding your own system. This article is a call to senior leaders: reclaim ownership of your organization's fate. Stop farming out decisions to methodology resellers who profit from dependency. Your developers aren't the problem — the theatrical rituals burying them are. The same people who appear unmotivated under rigid frameworks thrive elsewhere, not because those organizations lack structure, but because they treat thinking as a feature, not a bug.

To management consultants and coaches: Your work is valuable when you stay in the management domain. You understand organizational structures, decision pathways, and leadership. We complement each other — you at the management level, we in software development. Leave the coaching and consulting about software development to developers with decades of experience. We’re not competitors; we’re partners with different areas of expertise. Together we can strengthen organizations when each stays in their lane.

Every now and then, another methodology arrives with bold promises:

Predictability. Alignment. Scale.

It comes with certifications, consultants, and a vocabulary that feels modern. And for executives drowning in chaos, it looks like salvation.

But here’s what actually happens:

Your best developers leave. Not because they got better offers — but because they’re tired of being treated like factory inventory in a system that claims to value people.

The ones who stay? They go quiet. They comply. They stop caring.

And somewhere in a boardroom, a consultant presents charts showing “adoption success” while your capacity to deliver software silently rots.

The Seduction of Fake Predictability

Executives are sold a fantasy: that complexity can be tamed through the right process, that humans can be managed like resources, that software delivery can be industrialized.

Methods promise control. They deliver theater.

Daily meetings become status reports. Planning becomes negotiation. Review sessions become complaint sessions that change nothing.

As explored in an earlier article, frameworks can reveal problems but cannot fix the underlying development practices.

Meanwhile, the real work — understanding the problem, designing the solution, testing the assumptions — gets buried under rituals designed to make someone else feel informed.

The Consultant’s Business Model

Let’s be clear: methodology consultants are not evil. They’re running a business.

But here’s the problem: most have never done the work they’re advising on.

They’ve studied management theory. They’ve facilitated workshops. They’ve earned certifications.

But they haven’t shipped production software under pressure. They haven’t debugged a broken deployment at 2 AM. They haven’t felt the pain of technical debt compounding for years.

You wouldn’t hire a carpenter who’s never touched wood. Yet organizations regularly hire process consultants who’ve never written code, managed a pipeline, or wrestled with architectural decisions that haunt you for years.

Their product is dependency. They train your people in a branded language. They certify coaches who enforce compliance. They return in intervals to “assess maturity” and sell the next level.

And because executives have outsourced judgment to the framework, no one dares question whether any of this actually improves delivery.

To challenge the method is to challenge progress itself — even when progress has visibly stopped.

What You Lose When You Delegate Leadership

When you hand strategic decisions to a consultant peddling a packaged framework, you lose:

Your ability to see reality. The method becomes a lens that filters everything. Problems are renamed. Symptoms are ritualized. Truth becomes whatever fits the model.

Your developers’ trust. They watch leadership adopt slogans without understanding the work. They endure process overhead that slows them down while being told it’s for their benefit. Eventually, they stop trying to explain and start looking for the exit.

Your competitive edge. While you’re perfecting your process rituals, competitors are shipping features, learning from users, and iterating fast. Predictability is worthless if you’re predictably slow.

The Developers You’re Losing

Here’s the pattern every technical leader recognizes:

A sharp, curious developer joins your organization. Within months, they’re frustrated. Not by the technical challenges — those energize them. By the process tax:

Meetings that could be async updates.
Estimation rituals that ignore uncertainty.
Work sliced to fit a timebox instead of a learning goal.
Escalation paths that punish honesty.

They don’t quit because they lack discipline. They quit because the system suffocates the very thinking you hired them to do.

And then they go somewhere else — often a smaller, younger company — and suddenly they’re thriving: shipping daily, solving hard problems, engaged and growing.

Same person. Different system.

What Actually Creates Predictability

Real predictability doesn’t come from frameworks. It comes from:

Short feedback loops. Automated tests that run in seconds. Deployments that happen in minutes. Monitoring that surfaces problems before customers do.

Technical hygiene. Clean architecture. Continuous integration. Relentless reduction of coupling and complexity.

Sustainable flow. Small changes. Frequent merges. Low work-in-progress.

Psychological safety. People who can say “I don’t know” without fear. Teams that debate trade-offs openly. Leaders who treat experiments as learning, not failure.

None of this requires a branded method. All of it requires leadership willing to understand the work, not just manage the workers.

Your Job Is Not Delegable

You cannot outsource the understanding of your own organization.

A consultant can show you where the waste is — but only you can decide what to change.

A framework can structure conversations — but only you can foster the culture that makes those conversations honest.

A coach can teach practices — but only you can protect the people who practice them from being buried under performative compliance.

Leadership is judgment. And judgment requires context that no external method can capture.

When you abdicate that judgment to a methodology vendor, you’re not leading — you’re performing leadership while someone else runs your organization by proxy.

How to Take Back Control

1. Stop buying transformation programs. No one can transform your organization but you. Hire expertise for specific problems, not wholesale cultural rewrites.

2. Trust your engineers — then verify the system. Replace status theater with instrumentation: build times, deployment frequency, defect rates, lead time. Let the pipeline do the reporting.

3. Measure outcomes, not adoption. “We completed training” means nothing. “We ship twice as often with half the incidents” means everything.

4. Protect thinking time. If collaboration matters, create space for it. Pairing. Mobbing. Spikes. Experiments. Stop punishing exploration as inefficiency.

5. Fire the method if it’s not working. Seriously. If six months in, delivery hasn’t improved and morale is down, stop doubling down. Admit the experiment failed and move on.

You’re in a leadership position. You can do this.

The Developers Are Watching

Your best engineers know what’s broken. They’ve known for months.

What they’re watching for is whether you know — and whether you have the courage to act.

If you choose the method over the people, they’ll leave quietly. Not with drama. Not with ultimatums. They’ll just stop showing up one day, and your management will explain it as “personal reasons.”

But if you choose reality over ritual, if you protect the space for real work and real learning, they’ll stay. They’ll fight for you. Because finally, someone in leadership sees what they see.

The Test

Ask yourself:

Can my developers deploy safely to production multiple times a day?

If yes: you’re governing, not controlling. Keep it up.

If no: every ritual, meeting, and framework in the world won’t fix that. You need technical capability, not process reformation.

And the consultants selling you the next methodology? They won’t build that capability for you. They’ll just rename your meetings and call it progress.

TL;DR

Methodology consultants sell dependency, not solutions.
Your best developers leave when compliance replaces thinking.
Real predictability comes from technical excellence, not process frameworks.
Leadership is judgment — and judgment cannot be outsourced.
Reclaim your organization before the rituals bury the work completely.

You hired smart people. Let them build. Lead them. Don’t bury them.

The CTO: Between Faith and Physics

2025-11-19T00:00:00+01:00

The Tension Between Process Control and Software Reality

19.11.2025, By Stephan Schwab

Organizations crave predictability—frameworks, timeboxes, and budgets that promise control over software delivery. But software obeys its own laws: complexity compounds, integration resists shortcuts, and discovery cannot be compressed. This article explores the CTO's challenge of balancing organizational faith in process with the hard physics of code, showing how timeboxes meant to contain risk often silence the very communication they claim to value. When control wins over curiosity, metrics may look clean while reality quietly breaks. True progress emerges only when boundaries serve learning rather than enforcement—turning faith into feedback before it's too late.

When Belief Collides with the Laws of Software

Every company wants software that moves like lightning and lands like clockwork. Fast, stable, innovative, and on budget — all at once.

To achieve it, someone introduces a framework. It promises order, cadence, and predictability. It replaces uncertainty with timeboxes and vocabulary.

And suddenly, the CTO stands between faith and physics.

Faith: The Comfort of Control

Faith feels good. It gives complexity a shape and schedule. It offers the reassurance that everything is planned, visible, and under management.

Timeboxes and budgets become symbols of discipline — boundaries that promise progress through regularity.

And to a degree, that works. Boundaries do matter. But their purpose is often misunderstood.

Investment, Not Assembly

In genuine research, time and money are limits on investment, not promises of output. They exist to contain risk while giving exploration room to breathe. At the end, what matters is what was learned — not what was produced.

The same logic should apply to software: use timeboxes to learn just enough to make the next decision, not to guarantee a result.

Once a boundary turns into a countdown for deliverables, discovery stops. Curiosity feels like disobedience. People start optimizing for compliance instead of understanding.

The Silence Behind “Talk to Each Other”

Every organization preaches open communication. “Talk to each other” appears in slide decks, onboarding guides, and leadership speeches.

Yet when the clock rules everything, talking becomes dangerous. Pairing looks inefficient. Asking for help looks unprepared. Exploration looks like delay.

No one wants to risk being seen as the reason something didn’t finish on time. So the team keeps working — quietly, individually, anxiously. The form of collaboration remains, but its spirit withers.

From the outside, it still looks organized. Inside, it’s fear wearing discipline’s clothes.

Physics: The Hard Laws of Code

Meanwhile, the code keeps obeying its own laws. Complexity compounds. Integration resists shortcuts. Reality does not care about the schedule.

You can’t compress discovery without bending truth. You can’t legislate insight. Software moves at the speed of feedback, not at the pace of planning.

The CTO’s Tightrope

The CTO walks between belief and evidence. To leadership, they translate uncertainty into strategy. To engineers, they protect the conditions for real learning.

Their quiet mission: turn faith into feedback, and feedback into visibility — so the system itself tells the truth before it’s too late.

When Faith Wins

When control outweighs curiosity, people stop experimenting. The metrics look clean. The charts glow green. And the organization sleeps soundly — until production wakes it up.

When Physics Wins

When discovery regains space, energy returns. Boundaries become instruments of learning, not punishment. People share, pair, and fix together because it’s safe to do so. Progress becomes quiet, steady, and real.

The Moral

Timeboxes and budgets are tools of investment, not enforcement. They exist to surface insight, not to silence it. If a process truly values communication, it must create time for conversation — not just permission.

Because you can limit the effort, but never the discovery. And no one can think freely under threat.

TL;DR

Control creates silence. Fear looks like discipline. Software only improves when curiosity is safe — and physics always tells the truth.

How to Govern Without Control

2025-11-16T00:00:00+01:00

Leadership Lessons from the Edge of Engineering Chaos

16.11.2025, By Stephan Schwab

Leaders want both stability and innovation, but these forces pull in opposite directions. Many organizations reach for control—the illusion of safety through process, meetings, and metrics—yet in software, control rarely brings stability. It usually just slows feedback until systems fail silently. This article explores how governance differs from control: governance ensures the right things become visible at the right time through automated systems that tell the truth, not status reports. By replacing permission with visibility, technical leaders can manage feedback rather than people, creating sensor networks that surface misalignment early. Real stability looks noisy—with tests, builds, and human debate—but that noise is actually the sound of engineering excellence protecting the business from silent failure.

Every leader wants two things at once:

🔹 Stability

🔹 Innovation

The problem? These two pull in opposite directions.

To get both, many organizations reach for control — the illusion of safety through process, meetings, and metrics.

But in software, control rarely brings stability.

It usually just slows the feedback loop until the system fails silently.

Control Is Not Governance

Governance isn’t about knowing everything.

It’s about ensuring that the right things become visible at the right time.

Control means telling people what to do.

Governance means designing a system that tells the truth on its own.

In good engineering organizations, that truth comes from data, not status reports:

Tests pass or fail.
Pipelines run or stop.
Monitoring shows reality in real time.

That’s governance — not management.

Replace Permission with Visibility

A healthy software system doesn’t need pre-approval for every change.

It needs a pipeline that catches bad changes automatically.

Old Control Mindset	Modern Governance Practice
“Let’s review everything manually”	“Automated tests and gates protect production”
“We must know every detail”	“Dashboards show flow, errors, and uptime”
“We approve releases”	“We approve the process that ensures safe releases”
“We need meetings to align”	“We need systems that surface misalignment early”

Governance isn’t a bottleneck. It’s a sensor network.

The CTO’s Real Job

The CTO who governs without control doesn’t manage people directly.

They manage feedback.

Their job is to ensure that:

Every change has a fast, automated signal.
Quality metrics are visible to everyone.
Technical debt is tracked like financial debt.
Teams own their outcomes end-to-end.

If those systems exist, governance happens naturally — without command structures.

The CEO’s Dilemma

CEOs often mistake quiet for stability.

They see a lack of noise as a sign of control.

But in software, silence means blindness.

Real stability looks noisy — but not the way most executives think.

Yes, tests run. Builds fire. Logs roll. Alerts blink.

But those are just signals.

The real noise is human:

Engineers questioning each other’s assumptions while pairing or mobbing.
Teams proposing spikes — “let’s try this for two days and see what we learn.”
Designers challenging technical constraints.
Developers debating trade-offs openly.
Someone saying “I don’t understand this” and three people stopping to explain.

(And no, not “code reviews” — those often devolve into toxic gatekeeping, another control fallacy disguised as quality.)

This is what a healthy engineering culture sounds like.

It’s not chaotic — it’s collaborative turbulence.

The technical artifacts don’t create the noise.

People talking, questioning, and experimenting do.

When leadership mistakes that energy for disorder and tries to quiet it down, they kill the feedback loop.

The job isn’t to silence the conversation — it’s to make sure that energy converts into learning, decisions, and better software.

And yes, that means: writing code that gets thrown away. Tests that only serve understanding. Experiments that lead nowhere.

That’s not waste — that’s thinking.

The conversations are only the visible, audible part. The real thinking happens in the code itself.

Anyone demanding “fast features” while saying “talk to each other” hasn’t understood that creating and discarding software is the thinking process, not a delay before the “real” programming.

Trust, but Instrument

“Trust” sounds soft, but it’s measurable.

A team that can deploy ten times a day with zero rollbacks is governed.

A team that needs five approvals and three committees for every release is controlled — and still unsafe.

The difference isn’t trust alone — it’s instrumentation.

Automate the feedback loops (tests, monitoring, deployment gates), not the people.

Free engineers from performing safety theater so they can focus on the work that actually matters: thinking, designing, experimenting, collaborating.

Governance scales through architecture, automation, and accountability, not hierarchy.

The Paradox of Modern Leadership

The more you try to control engineers, the less you understand what’s really happening.

The more you trust and instrument the system, the clearer everything becomes.

So stop asking for reports.

Ask for evidence — in the form of logs, metrics, and automated feedback.

And don’t introduce a management framework that encroaches on developers’ freedom to create and innovate.

Yes, many method coaches and framework authors will disagree. Their business model depends on believing software development is plannable like manufacturing.

But here’s the critical point for leaders:

Which approach delivers value faster?

Frameworks can certainly reveal waste and produce signals. That’s their value.

But they’re not a lasting fix for bad software development practices.

Once the framework has done its job and exposed the problems, you need good development practices — not more ceremonies.

Frameworks that dictate how to work — mandatory standups, story point estimates, velocity tracking, sprint ceremonies — cost time and money.

They shift focus from shipping software to performing process.

More importantly: They increase your risk, not reduce it.

Why? Because they treat software development like manufacturing — with a clean separation between preparing the work (planning, estimation, design) and doing the work (coding, testing, deploying).

But software isn’t an assembly line.

Discovery and delivery are inseparable.

You don’t know what you’re building until you start building it:

Requirements clarify through code.
Architecture emerges through experimentation.
The “work” is the learning.

When you force developers to “finish thinking” before they start coding, you’re not reducing risk — you’re delaying feedback until it’s expensive to act on.

And that costs you market opportunities while your competitors ship.

The teams that ship value fastest aren’t the ones with the most ceremony. They’re the ones who can ship early and often — because their leadership invested in feedback systems, not process overhead.

And here’s the economic reality: With good practices and AI, you need smaller teams.

Just as developers moved up from assembly to C, to Java/C# — each step letting them work at a higher level of abstraction — AI lifts them even higher today.

That means:

Less coordination overhead across large teams.
More direct collaboration between developers and subject matter experts.
Faster decisions because fewer intermediaries are involved.

You don’t need 50 developers coordinated through a framework.

You need 3-5 very good developers with AI tools, strong feedback, and direct access to business and domain experts.

That’s not just faster — it’s cheaper by an order of magnitude.

Frameworks promise to organize large teams.

Good practices with AI make large teams unnecessary.

This kind of thinking — strategic, architectural, product-aware thinking — becomes the most valuable part of software work.

The best teams don’t split prepare-vs-do.

They evolve their own rhythms based on real feedback from their system and their users.

Give them clear outcomes, strong instrumentation, and the autonomy to figure out the path.

That’s governance. Everything else is just overhead.

Governance is not knowing.

It’s seeing.

TL;DR

Control is human supervision.
Governance is system feedback.

If you want stability and speed, don’t tighten control — strengthen feedback.

That’s how you govern without control.

Agile, Meet AI: Your Stand-Up Just Got Automated

2025-11-13T00:00:00+01:00

When AI Rewrites the Rules of Software Delivery

13.11.2025, By Stephan Schwab

For two decades, Agile transformed software development — moving teams from Gantt charts to working code, from waterfall to continuous delivery. But AI is now removing the friction that Agile was designed to manage. When a single developer with a good prompt can ship what once took a sprint, the bottleneck shifts from code to coordination, from engineering to decision-making. This article explores how AI doesn't kill Agile — it kills Agile theatre: the endless ceremonies and process rituals that exist to fill boards rather than deliver value. The future belongs to small, skilled teams working in continuous conversation with AI tools, guided by principles rather than process religion.

For two decades, “Agile” was the best thing that happened to software. It got us out of Gantt charts and into working code. I’ve lived that journey — from test automation to CI/CD, from Lean Startup to trunk-based delivery. All of it made us faster by removing friction.

But here’s the punchline: AI removes almost all of it.

The uncomfortable truth

AI doesn’t join your stand-up. It doesn’t care about story points or Jira rituals. It writes code, tests it, refactors, and deploys — sometimes faster than a team can describe the ticket.

That’s not a process problem. It’s a paradigm shift.

When a single developer with a good prompt can ship what once took a sprint, the bottleneck moves — from code to coordination, from engineering to decision-making. The old roles and ceremonies that kept Agile balanced suddenly feel like latency.

Managers, breathe. Developers, adapt.

Agile can survive this new era — but only if we stop treating it as a religion and return it to what it was always meant to be: a mindset of continuous learning and delivery.

AI doesn’t kill Agile.

But it absolutely kills Agile theatre — the endless stand-ups, backlog grooming sessions, and “process ownership” titles that exist because someone had to fill a Jira board.

In the new world, the people who matter are the ones who can:

Translate intent into working systems,
Verify behavior with automated tests,
And keep feedback flowing through CI/CD.

That’s engineering. Everything else is commentary.

What replaces “the team”

A small crew — one domain expert, two developers — working in continuous conversation with AI tools.

Code reviewed and deployed every 15 minutes.

Design patterns emerging from the system, not a meeting.

Compliance, security, and documentation baked into the pipeline, not outsourced to committees.

This is not chaos. It’s real agility — powered by machines, guided by humans who know what they’re doing.

The new job of leadership

Leaders will have to stop managing velocity and start curating intent.

They’ll define direction, not tasks.

They’ll remove blockers that AI can’t yet reason about — legal, ethical, organizational.

And they’ll need to trust that small, skilled teams can do in days what used to take quarters.

The end of “process as religion”

The Agile Manifesto was written in a world where humans typed every line. AI changes that equation.

If you cling to rituals, you’ll slow down.

If you cling to principles — feedback, transparency, technical excellence — you’ll accelerate.

That’s the real test of who understood Agile in the first place.

Grateful Boundaries: Consultants and Software Developers

2025-11-09T00:00:00+01:00

Respecting the Line Between Diagnosis and Implementation

09.11.2025, By Stephan Schwab

Every successful transformation requires two distinct superpowers: consultants who can see and articulate systemic problems that insiders no longer notice, and software developers who understand that inside the codebase, physics takes over. This article explores the boundary where diagnosis meets implementation—where frameworks reveal waste but only software development can remove it. The friction begins when one role tries to become the other. Great consultants know when to stop prescribing ceremonies and start empowering action. When consultants help leaders see the system and developers fix it, transformation accelerates. It's not management versus development—it's strategy and execution shaking hands.

Grateful Boundaries

Every transformation needs both:

👔 Consultants who see the system,

🧰 Software developers who make it real.

The friction starts when one tries to become the other.

The Consultant’s Gift

Let’s give credit where it’s due. Consultants bring language, structure, and courage to organizations that have drifted into chaos. They can articulate what insiders can no longer see. They make invisible waste visible. That’s powerful.

Without them, many companies would never pause long enough to notice what’s actually broken.

The Software Developer’s Domain

But once the problem is visible, the terrain changes. Inside the codebase, physics takes over. The laws of compilation, test coverage, latency, and coupling do not yield to motivational posters. Here, feedback is immediate and absolute. A system either runs or it doesn’t.

This is where software development hygiene — not management theory — decides success. Frameworks may reveal waste; software development removes it.

The Boundary That Builds Trust

Great consultants know when to stop diagnosing and start empowering. They create space for developers to act without prescribing how. They ask, “What would make this faster, safer, more reversible?” instead of saying, “You need a new ceremony.” They understand that culture follows architecture — not the other way around.

Respecting that boundary doesn’t diminish their value. It multiplies it.

The Partnership That Works

When consultants help leaders see the system and developers fix it, transformation accelerates. No ego, no turf war — just aligned expertise. It’s not “management vs. development.” It’s strategy and execution shaking hands.

TL;DR

Consultants make the invisible visible.
Software developers make the visible work.
Stay grateful, stay in your lane, and everyone wins.

Management Frameworks Don't Fix Software Teams

2025-11-07T00:00:00+01:00

When Visibility Meets the Need for Repair

07.11.2025, By Stephan Schwab

Management frameworks arrive with canvases, ceremonies, and dashboards—tools that help organizations see their bottlenecks, overload, and rework. This visibility is valuable, even necessary, because most organizations are blind until someone helps them see. We owe consultants real gratitude for bringing language and structure to chaos. But visibility is not the same as repair. While frameworks diagnose symptoms—labeling issues as "scope creep" or "lack of focus"—only software development can trace problems to their root causes: missing test automation, weak CI/CD pipelines, or architectural coupling. This article explores the boundary where diagnosis meets implementation, arguing that consultants reveal the waste while developers remove it—not as opponents, but as specialists standing on different sides of the same truth.

Every few years, a new management framework arrives with the promise of order. It comes with canvases, ceremonies, roles, and dashboards. It helps organizations see where things go wrong — the bottlenecks, the overload, the rework. And that’s valuable. Because most organizations are blind until someone helps them see.

For that, we owe consultants and method coaches real gratitude. They bring language, structure, and reflection into places that used to rely on chaos and charisma. They make dysfunction visible.

But visibility is not the same as repair.

Frameworks See Symptoms — Software Developers Fix Causes

Frameworks are diagnostic tools. They reveal what hurts, but they can’t perform surgery. Only software development can.

When a sprint keeps slipping, a framework might label it “lack of focus” or “scope creep.” A software developer will trace it to missing test automation, circular dependencies, or a weak build pipeline.

Problem	Framework’s View	Software Development Root Cause
Frequent regressions	“We need clearer roles”	Missing test coverage
Unpredictable releases	“Improve coordination”	Weak CI/CD pipeline
Slow feature flow	“Too much WIP”	Monolith coupling, long build times
Low morale	“Culture issue”	Tooling pain, manual toil, unclear ownership

Both perspectives are true — but only one can actually fix the system.

The Consultant’s Dilemma

Many management consultants genuinely want to help. They come from strategy, operations, or organizational design — domains where process is the lever that moves performance. When they look at software teams, they reach for the same lever.

But software is not a production line. It’s a living system that changes shape every day. Trying to “fix developers” through new ceremonies or motivational campaigns is like trying to tune a database by holding more meetings about the query plan. It feels active but doesn’t touch the cause.

Still, their effort to understand is worth appreciating. They bridge a gap that most executives can’t even articulate — they care enough to try.

The Real Fix: Software Development Hygiene

Once the diagnosis is clear, progress depends on software development principles — not management reform. That’s the moment where the consultant’s insight meets the developer’s craft.

Automate what humans shouldn’t repeat. Keep changes small and reversible. Test before you trust. Make feedback immediate and visible. Measure flow in code, not in meetings.

The consultant helps you see the waste. The software developer helps you remove it.

They are not opponents — just specialists standing on different sides of the same truth.

Let Software Developers Shape Their Work

Consultants can guide how teams interact; software developers must own how the work flows. Crossing that line unintentionally creates friction — not because developers resist change, but because they operate in a world ruled by feedback that’s faster and harsher than any retrospective: the build fails, the system crashes, the user leaves.

To honor that reality is not to reject management. It’s to respect the physics of software.

Grateful Boundaries

We should thank the consultants who challenge complacency and reveal what’s broken. Their frameworks are useful mirrors. But after the mirror comes the wrench. And that’s when software developers must lead — not to replace the consultants, but to finish what they started.

Good management knows when to step back. Great management creates space for the builders to fix what’s visible.

TL;DR

Be grateful to those who reveal the waste.
Then let the software developers repair the system.
Methods start the conversation — software development ends it.

Why the 'Raw Dogging' Team Beats the Factory Method

2025-11-05T00:00:00+01:00

Breaking Free from the Manufacturing Fantasy

05.11.2025, By Stephan Schwab

Management often treats software development as an assembly line—imposing process frameworks like Scrum, SAFe, or OKRs in pursuit of predictability and repeatable output. But software is fundamentally different: it's discovery, translation, and continuous learning wrapped in code. This article challenges the manufacturing fantasy, arguing that true excellence emerges from "raw dogging" teams—small, skilled groups who rely on trust, automation, and direct feedback rather than ritualized ceremonies. When organizations confuse rhythm with results, innovation dies quietly in the name of consistency. The future belongs to teams who ship, learn, and evolve without waiting for permission from a framework.

There’s a certain mythology in management circles: that software development can be tamed by process, that predictability will emerge if we just impose the right structure — Scrum, SAFe, OKR, Lean, whatever acronym happens to be fashionable this decade.

It’s the manufacturing fantasy: that software is an assembly line, and developers are workers piecing together widgets from a predefined blueprint. The goal is “repeatable output.” The metric is “velocity.” The outcome? Mediocrity — at best.

The Myth of Method

Every method that comes from manufacturing assumes a world where the work is known. You can measure it, plan it, and repeat it.

Software is the opposite. It’s discovery, translation, and continuous learning wrapped in code. The work is unknown — and pretending otherwise just makes the unknown invisible.

When managers confuse software creation with assembly, they optimize for the wrong thing. They start policing the rhythm instead of the result. The team stops thinking and starts complying.

That’s when innovation dies — quietly, in the name of “consistency.”

The “Raw Dogging” Team

A raw dogging team doesn’t need the permission of a framework to think. They don’t hide behind process diagrams. They take responsibility — fully. They look at the real problem, talk to the real users, and ship something that works — today, not in a 3-month release window.

They don’t rely on rituals; they rely on trust, skill, and feedback.

They don’t need a “method consultant” timing their moves with a stopwatch. They use tools, automation, and code as extensions of their intelligence — not as bureaucratic theater.

They pair, test, break things, fix them, and learn faster than any team chained to a method ever could.

The Power of Flow Over Framework

When skilled people are allowed to work raw, flow emerges naturally:

Small, meaningful commits land in CI/CD every day.
Test coverage grows organically.
The feedback loop between idea, code, and user stays tight.
Problems are seen immediately — and solved in hours, not in retros.

You don’t need a “daily standup” to talk to your teammates. You just talk. You don’t need a “retro” to learn. You learn all the time. You don’t need a “definition of done.” You just know when it’s done because it runs, passes tests, and users smile.

That’s not chaos. That’s mastery.

The Real Enemy: Fear

What keeps organizations clinging to factory-style frameworks isn’t ignorance — it’s fear. Fear of losing control. Fear of accountability. Fear of admitting that real software work cannot be predicted, only navigated.

So instead of trusting the people who actually build things, companies install layers of process to make themselves feel safe. Ironically, those layers slow everything down — and make the risk they fear even greater.

Trust the Builders

If you’ve ever watched a true expert debug a production issue at 3 a.m., you know what real flow looks like. There’s no process guide for that moment. No index card or Jira issue helps. Just raw focus, creativity, and teamwork.

That’s the essence of software development — the fusion of logic and intuition in the service of solving something real.

And that’s why a “raw dogging” team — small, sharp, self-organizing — will always outperform a methodized, consultant-driven factory. Because where others follow rules, they follow truth.

TL;DR

Software is not assembly.
Process is no substitute for trust.
The future belongs to those who ship, learn, and evolve — raw.

What Is Continuous Integration

2024-09-17T00:00:00+02:00

Software Development Without Delays

17.09.2024, By Stephan Schwab

Continuous Integration (CI) is a practice where team members frequently integrate their work into the main codebase, ensuring that the software product evolves smoothly and efficiently. This article explores the essence of CI, emphasizing the importance of small, frequent contributions, avoiding branching, and leveraging local and automated testing. It also addresses common misconceptions, such as the necessity of a central CI server, and highlights the power of modern developer workstations in facilitating CI practices.

Continuous Integration Is a Practice

Continuous Integration is something that a team does. It means that all contributions in code or other artifacts from all team members are constantly being integrated into the software product as it gains more and more functionality. It does not matter how the team does this. It does not matter if there is a Continuous Integration server or another tool with “CI” in its name.

Once one team member is done with a small contribution, this contribution gets integrated. Small means something that took an hour or two to make. Small is not something that takes longer than a day or even more.

No Branching

As software is made by writing code and code is text, we need a version control system that allows us to merge text from different authors easily. To practice Continuous Integration, we do not need branches and much less a system that is good and fast at branching. In fact, we don’t want branches at all.

Branches mean that the software system exists multiple times and each version is different. We don’t want that. We only want the one and only current version of the system.

That being said, there is nothing wrong with a local branch for some experiment here and there. But note that the moment you create a branch, you have effectively stopped practicing Continuous Integration. You can also do your own work locally in a branch if that makes you feel safer or you are unsure about using the code from that branch. At the moment you want to share the results of your work, you integrate your new code into the one and only main line of the codebase.

Local and Automated Testing

When practicing Continuous Integration, we want to make sure that we won’t break the system with our new code. So we leverage local and automated testing to ensure that everything still works before we share our new code.

We get the latest version of the system from version control, then integrate our work, and finally put the whole thing to a test.

As it is impossible to perform manual testing of the whole system, we need to have meaningful automated tests that also run reasonably fast. Ideally, we want the whole system to be tested in a minute or two but definitely in less than 10 minutes. This process should be enough to get fresh water or coffee but not enough to start new work or be distracted by another activity.

Is One Big Central CI Server Required?

In 2024, developer workstations or laptops are so powerful that they frequently outperform machines used as servers. While in the past Continuous Integration was associated with having a central CI server running some special software to perform integration builds — for example, Jenkins or GitHub Actions — the reality is that CI is fundamentally about the practice, not the tooling.

A central build server can be useful for running the full test suite after code has been pushed, for building release artifacts, or for enforcing quality gates before code reaches production. But the core practice of Continuous Integration happens at the developer’s workstation: pulling the latest code, integrating your changes, running the tests locally, and pushing only when everything passes.

The key insight is that Continuous Integration is about reducing the time between when code is written and when integration problems are discovered. Whether that happens on a developer’s laptop or a server farm is secondary. What matters is that integration happens frequently — multiple times per day — and that feedback comes quickly.

The Business Value of Continuous Integration

When teams practice Continuous Integration effectively, several important benefits emerge:

Problems surface immediately. When you integrate your work with the work of others multiple times per day, incompatibilities appear within hours of being created. They’re fixed while the context is fresh and the change is small.

No integration phase. Traditional approaches involve weeks of parallel development followed by a painful “integration phase” where everything comes together. With CI, there is no integration phase because integration is continuous.

Always releasable. Because the codebase is always in an integrated state and all tests pass, you can release at any time. This flexibility is invaluable when business needs change.

Reduced risk. Small, frequent integrations mean small, manageable risks. If something breaks, you know exactly what changed and can fix it quickly.

Common Misconceptions

“We do CI because we use GitHub Actions.” Using a CI tool doesn’t mean you’re practicing Continuous Integration. If developers work in long-lived branches and only merge after days or weeks, you’re not doing CI regardless of what tools you use.

“CI means running tests automatically.” Automated testing is essential to CI, but it’s not the same thing. CI is about the integration pattern — the rhythm of small, frequent contributions from the whole team.

“We can’t do CI because our tests are too slow.” Slow tests are a problem to solve, not a reason to abandon CI. Invest in faster tests, parallelize your test suite, or identify which tests can run locally versus on a server.

The essence of Continuous Integration is simple: everyone integrates their work frequently, at least daily. This simple discipline, consistently applied, transforms software development from a high-risk gamble into a predictable, sustainable process.

Why Your Team Needs a Senior Developer Advocate

2024-09-15T00:00:00+02:00

Making Software Development More Cost-Effective

15.09.2024, By Stephan Schwab

In-house software development is complex and expensive. Even if you can utilize employees with relatively low salaries, the overall costs are still very high. For example, in Europe a small team of just 5 people with relatively modest salary expectations can cost around $400,000 per year. In North America that number would be significantly higher. Depending on location it might be something like $1.5 million annually.

When demand increases and you need to expand the team, you’ll likely look for agencies or freelance IT specialists. At the lower end, they may charge a rate of around $90 per hour. With the agency’s commission, this rate often rises to about $110 per hour. If used over an entire year, this can add $200,000 or more to your costs, depending on the extent of the engagement.

So, we have $400,000 in fixed costs for the in-house team, and an external specialist increases this by $200,000. If the need for additional staff continues to grow, costs can quickly spiral out of control, becoming a serious issue.

Moreover, typical IT freelancers usually expect to complete a clearly defined task and will not work beyond that. If you request a specialist for “Backend Development, Java, Oracle, Hibernate” from an agency, you’ll get someone who has worked with that exact combination for many years but likely has no knowledge or interest beyond that.

Making Software Development More Efficient

Software development can be very cost-effective. Small teams of talented and capable individuals can manage an entire product independently, and the contribution per employee can be impressively high.

At an insurance company I know, a small team (around 30 people) is responsible for all aspects of a car insurance product. The core team is advised by specialists from the insurance industry, and the product is sold exclusively online. The team handles all aspects of the operation independently.

This level of efficiency is achieved through a combination of:

Training and investment in existing employees
Introducing new methods and tools
A high degree of automation

US business consultant and former submarine captain David Marquet explains in his book Turn the Ship Around! how he transformed a poorly performing crew into one of the best in the US Navy through a combination of the above measures.

But where and how do you start?

Senior Developer Advocate

The role of a Senior Developer Advocate describes an experienced software development specialist with broad expertise and a willingness to share knowledge with others. This type of profile is often overlooked by agencies, as they fail to recognize the value of broad experience and prefer someone who has been doing the same thing for 10 years.

In my case, this also includes knowledge and experience in building and leading companies, even internationally. Understanding business aspects is crucial because many software solutions are not developed as products for the free market but to efficiently support economic activities, such as in the case of the car insurance mentioned earlier.

Structure of a Typical Engagement as a Senior Developer Advocate

Although an essential part of such an engagement is improving the skills of existing employees, it’s also about delivering tangible, short-term benefits to the company. The ability to deploy valuable software solutions earlier and with fewer defects or rework is a clear economic advantage. That’s the primary goal.

Assessment and Interviews: Before we can start, we need to determine where we stand. What is working well, and where are the challenges, issues, or deficiencies?; Depending on the size of the team and the scope of the existing software, various interviews will be conducted over the course of about a week, and existing technical processes will be closely examined.
Coaching Plan to Identify Actions and Expected Results: Based on the findings from the assessment, we jointly develop a coaching plan that, similar to a Story Map, outlines possible actions as well as their timing and context. This coaching plan becomes our shared roadmap and is also used for success tracking.
Practical Work: 60% to 70% of the practical work of a Senior Developer Advocate involves actively contributing to the development of the software solution the team is working on. Therefore, this role is clearly that of a team member and developer, not just a trainer. Most of the knowledge transfer and training is done by pairing. That means the Senior Developer Advocate supports always another team member directly.; The focus on practical work as a developer helps gain the acceptance of the person and the proposed measures by the other team members.; The previously mentioned coaching plan is constantly visible to all team members, and the Senior Developer Advocate actively looks for the right times and opportunities to implement training objectives and actions. This happens situationally and through personal interaction.
Weaning Phase: After some time, the engagement will come to an end, and the weaning phase begins. For sustainability, this phase should start after 12 months at the latest. The involvement of the Senior Developer Advocate is gradually reduced, and the focus shifts more towards observing and supporting the team.; The goal is to fully end the engagement after a few weeks of reduced presence. If necessary, the engagement can be resumed.

Stoos Stampede 2012

2012-07-09T00:00:00+02:00

July 2012, Amsterdam, The Netherlands

09 Jul 2012, By Stephan Schwab

The Stoos movement is bound to change or even replace management from the Industrial Age with a better way.

What started in January 2012 as a meeting of a diverse group of twenty one people, including senior executives, business strategists, managers, academics, and lean/agile development practitioners from four continents, has grown to a conference with 130 people in attendance.

In Intrinsic motivation based on 4 Drive Theory I had a conversation with an engaged group about human nature and why we are they way we are. According to 4 Drive Theory humans possess a drive to acquire, to bond, to learn, and to defend. Interactions between those drives define our behavior. Once a person is unable to satisfy all four drives in a balanced way the person is unhappy and will perform poorly. Thus organizations should provide an environment that allows its members to fulfill this basic need.

Stefan Haas led the workshop Management and corporate culture hacking to find cracks in organizations in order to develop hacks to change things. People developed ideas for changing management and took those with them to try them within their organizations. In the workshop Sociocracy: new governance structure for organizations I learned that Sociocracy has been recognized by the government of the Netherlands as an alternative organizational structure that allows companies not to establish a works council, which otherwise is required by law.

Frequently the organizational environment is shaped by tools. In Organizational culture and the influence by tools on it I introduced the audience to Activity Theory and we explored the influence of time tracking tools onto organizational and personal behavior. Depending on the implementation of the tool it can be used to provide more freedom to people or force them to loose sight of the overall goal by just focusing on simple tasks in a robotic fashion.

Niels Pfläging declared Management dead. According to him Management died in the 1970s but is kept alive like a zombie. In a session filled with passion we learned that management as proposed by Frederick Taylor for the Industrial Age separated thinking from doing and thus created organizational structures shaped like a pyramid. The thinking happens at the top and all the doing, with ever increasing specialization, at the bottom. Niels proposes an organizational structure in the form of a peach that has a peripherie and a center. Instead of making all decisions in the center small groups in the peripherie decide as they have the closest contact with the market and the customers.

Participants of the Stoos Stampede have started to organize satellite events in their regions and agreed upon the need to participate in management conferences in order to take the message to those who are unlikely to attend an "agile event". For many the Stoos Stampede provided confirmation that they are not alone lest crazy in their thinking that tayloristic management is actually preventing people from working. Now there is a movement bound to change that on a global scale. Participants believe that a new way of running organizations will help to get out of the repeating economic crisis we've seen over the last few years.

Agile Roots 2012

2012-07-05T00:00:00+02:00

June 2012, Salt Lake City, USA

05 Jul 2012, By Stephan Schwab

The main hall was offered to me to give my talk Smarter Software with Activity-Centered Design to a slightly larger audience. Activity-Centered Design is an extensive topic and within only 45 minutes it was only possible to introduce the audience a bit to Activity Theory and outline how it can be used to develop smarter software. I invited the audience to download my book in progress to learn more and several people took me up on the offer. After the talk some came up to me and thanked me for the introduction of ideas from a field outside traditional software development. The talk was videotaped. The video is currently in post-production and as soon as I know where it's published, I will post a link to it here.

Corey Haines and Linda Rising gave two keynotes about the agile mindset. They both explained that it's about being agile instead of doing Agile. Working in an agile way is not following a process but instead is rooted in humanistic values. It is an entirely different belief system.

Ghennipher Weeks talked about Bringing Agile to Marketing and showed how marketers are taking advantage of feedback loops and other agile techniques. However, my impression was that there is still a lot of mechanistic thinking in the sense of applying a process to the work. The good news is that it's an example of a field where people are interested in employing agile techniques outside of software development. That's a very good start.

Fun is part of this type of conference. Gil Nahmias dressed like a wizard, completely with the pointy hat and a robe with stars on it, to tell the audience in Black Magic for Scrum Masters how to mix the magic potion that allows the Scrum Master to be more effective: ways to get them to like you, to trust you, negotiation tips, handling resistance, establishing leadership, motivating teams and even some unethical tactics. At the end, after all the ingredients were in the pot, he threw it at the audience. Thankfully he swapped out the pot with another one that only held candy instead of all the liquids he had used to mix the magic potion. People ducked and were scared for a second.

In Influence Strategies Linda Rising demonstrated that, based on many scientific studies, humans are incapable of rational decisions. We are completely controlled by our emotions and only later on justify our decisions with rationality. Psychological tools can be used to take advantage of hardwired traits of human nature in order to influence others. The hardwired traits are: liking, reciprocity, social proof, consistency, authority, and scarcity. The workshop left people a bit scared of themselves, which is a good thing.

As an extension of Linda's workshop Arlo Belshee provided a lecture about how the brain learns. It was a primer in neuroscience in which everyone learned about how the brain grows neurons and pathways between them based on external input. One particular detail I found interesting is that confusion leads to better memorization of a new fact. The advice Arlo gave was to present first a wrong assumption to a learner and then correct it. That leads to confusion and after a while, when neu pathways have been established, the new information enters long-term memory, which means the person has learned something.

SF Agile 2012

2012-07-04T00:00:00+02:00

June 2012, San Francisco, USA

04 Jul 2012, By Stephan Schwab

In the heart of San Francisco about two hundred software developers, managers and founders of new companies from the United States, Europe and even as far as New Zealand gathered for three days to share and learn about new ways of working and running businesses. The content of the conference was crowd-sourced and determined based on votes by the attendees.

My own session Deeper Understanding of User Stories Through Activity Theory was well received. Participants learned how to discover what users want to do through software. Equipped with a new tool developers can now better determine what the right problem to solve is.

In Enabling Emergent Betterness Through Lean Procrastination I learned from Olaf Lewitz and Matt Barcomb how to postpone decision making by decomposing the batch size of decisions and decoupling, which allows us to have real options open for as long as possible.

The second day started with an impressive keynote by Jim McCarthy who was only using his voice with no slides or other visuals. He preached to the audience about the need to do a lot of good. Lots of good will then become greatness. By having lots of greatness we finally will achieve magnifience. His speech resonated well with the audience and set the tone for the day.

In The Why of Scrum Tobias Meyer explained that the purpose of a restrospective is to figure out how to stop doing Scrum and helped us to understand that Scrum is basically a kind of training wheels. I was happy to find confirmation for my own point of view by someone who has been working with the Scrum Alliance in a leadership position. The Cynefin Lego Game with Olaf Lewitz and Brad Swanson allowed me to experience and observe simple, complicated, complex, and chaotic situation by means of a game. We were asked not to communicate verbally, observe a number of rules and build several structures with Lego pieces. When eventually a project manager showed up and replaced team members our productivity came to a halt and our teams slipped into chaos.

Lisa Crispin and Matt Barcomb demonstrated in Growing The Concept Of a Whole Team how a team acquires skills over time with the help of the Dreyfus model for skill acquisition. It was a guided conversation with the audience that resulted in a huge "cave drawing". We all understood how important it is to keep teams together so that they can go from the stage of novice all the way up to the expert level. If we disbandon teams after a 6 months project, we will always have novices or advanced beginners working on important solutions. No wonder they won't get it right.

Probably due to the fact that the sessions for this conference were selected by the audience in advance the event itself provided for a very family-like experience. There were a lot of hugging and deep conversations at dinner and in bars every day after the official program.