Back to Blog

Silos, Speed, and Shipping: Notes from Enterprise Projects

By Jan Schäferjohann
•3 min read

Shipping software inside a large enterprise is a highly interdisciplinary sport. The more “platforms,” abstractions, and guardrails we add, the more specialists we need—and the harder it becomes to move end‑to‑end without tripping over silos.

I see this in implementation projects every day. This isn’t about any one stack or about CCM (Customer Communications Management) specifically. It’s about how we structure IT in 2025 and what that does to throughput.

The paradox

We created APIs to decouple systems and reduce integration risk. Then we wrapped them in gateways, orchestrators, and policy layers—and re‑introduced the original complexity at the seams.

The result: deploying software takes about 8 hours of actual work spread across 6 months of calendar time.

Why? Standing up something simple still requires coordination across SSO, API gateways, DB specialists, internal IT, networking, and access to a patchwork of DevOps tools—often owned by different teams. In many enterprises, the same “focus on the core business” logic also outsources half of those functions. Now the seven specialists sit across five separate companies with different policies, and scheduling basics become a tax. There’s no single owner of the path to production.

If speed matters, design for it

When a task requires intense collaboration, I’ve learned to pick one of two modes and commit:

1) Prepare deeply before you start.
Do the prework so the sprint is frictionless: list dependencies, request access early, write env/setup docs, and pre‑book time with external teams. Treat this prep as part of the work, not overhead.

2) Or, insist on fast communication.
If you can’t prepare everything, optimize for velocity: async first, short SLAs, decision makers present, and a “ship‑the‑draft” bias. Skip large recurring meetings; push concise updates with clear blockers.

Tactics that consistently help

  • Create bilateral connections, not big circles. Bring together only the people needed to unblock the next step. Broad threads slow you down.
  • PMs as facilitators, not traffic cops. Great PMs work outside the team—getting credentials, approvals, and meetings that remove blockers. Status reports don’t move code.
  • Engineers own outcomes. Your job isn’t just to write code with perfect inputs. When something’s missing, chase it. If you need a meeting, call it. If a decision is stuck, propose one.
  • Map the critical path early. Write down the exact dependencies to production (security review, SSO, gateway, data access, monitoring). Put owners and SLAs next to each.
  • Default to async docs. A one‑page decision note beats three meetings. Record decisions and owners in a living doc.
  • Pre‑flight environments. Create a sandbox account or “golden project” with the common integrations wired before you need them.

Closing: the ownership gap

If speed is strategic, design for it up front:

  • Put process ownership on the critical path, not in the margins.
  • Assemble the cross‑functional pieces inside the project at kickoff.
  • Decide whether you’ll prepare deeply or communicate fast, and enforce it.
  • Use tools like GPT‑5 in Cursor to compress the inner loop—and spend the saved time unblocking the outer loop.

That’s where the weeks are really lost.