Why strategy is where pragmatism matters most
Every downstream decision — design, purchasing, integration, operations — inherits the assumptions set at the strategy stage. A strategy built on speculation („we might be 10x this size in three years“) cascades into over-built systems, inflated budgets, and idle capacity. A strategy with no horizon at all cascades into short-termism, technical debt, and constant firefighting. Pragmatic strategy sits deliberately between these two failure modes, and it’s cheaper to fix here than anywhere downstream — a wrong assumption on a whiteboard costs an afternoon to correct; the same wrong assumption baked into a live platform costs months and real money.
1. Start from business reality, not from technology ambition
The pragmatic starting question is never „what’s the best architecture?“ It’s:
- What does the business need to be able to do in the next 12–24 months that it can’t do today?
- What’s actually broken, slow, or risky right now?
- What budget and headcount genuinely exist — not what could theoretically be requested?
A strategy document that opens with „we will adopt a cloud-native, event-driven, microservices architecture“ has already failed the pragmatic test — it states a technology preference before stating a business problem. A pragmatic strategy opens with something like „order processing takes 3 days and loses us 8% of customers; support tickets take 48 hours to route“ — problems, not patterns.
2. Plan in stages, tied to triggers — not fixed years
Large enterprises can plan on 3–5 year architecture roadmaps because their growth and market conditions are relatively stable. Companies in the 10–5000 range rarely have that luxury — they pivot, get acquired, double headcount, or lose a major client with little warning. Pragmatic planning replaces calendar-based milestones with trigger-based ones:
- „When we cross 500 transactions/day, revisit the current batch-processing setup“
- „When we hire a second country’s team, revisit the single-region identity setup“
- „When support headcount exceeds 15, revisit the shared-inbox model“
This does two things: it avoids building capacity you don’t need yet, and it removes the anxiety of „did we forecast correctly for 2029?“ — you’re not forecasting, you’re setting tripwires.
3. Inventory before you invent
Before any new system enters the roadmap, pragmatic strategy insists on answering: what do we already have that does this, partially or fully? Mid-size companies accumulate tool sprawl fast — three project management tools because three teams each picked their own, two CRMs from two acquisitions, a reporting tool nobody remembers approving. A strategy phase that skips inventory ends up purchasing solutions to problems that already have half-solutions sitting unused.
A simple, low-effort version of this: a one-page list of every system in active use, who owns it, what it costs annually, and whether anyone would notice if it disappeared tomorrow. This alone often eliminates 10–20% of planned spend before a single new tool is evaluated.
4. Involve the people who will live with the decision
Strategy built only by leadership or only by IT tends to fail in opposite ways — leadership-only strategy underestimates operational cost and complexity; IT-only strategy underestimates business urgency and optimizes for engineering comfort. Pragmatic strategy pulls in:
- The people who will operate the system day to day (not just approve its budget)
- The people who will pay for it and need to justify the spend
- A sample of the people who will actually use it
This isn’t about consensus-by-committee (which is its own anti-pattern) — it’s about surfacing constraints early that would otherwise appear six months into a project as an unpleasant surprise.
5. Accept a shorter planning horizon as legitimate
One of the harder pragmatic disciplines: resisting the pull to plan further ahead than the business itself can reliably see. At this size, „good enough for the next 12–24 months, with a known revisit point“ is not a compromise — it’s the correct level of confidence given how fast the underlying business changes. Over-planning here isn’t rigor; it’s a way of avoiding the discomfort of deciding under uncertainty.
6. Make trade-offs explicit, in writing, before building starts
The single highest-leverage habit in pragmatic strategy: writing down, briefly, what you are deliberately not doing and why. Not a 40-page architecture document — a half-page:
„We are choosing a single shared database over per-team databases because our current team size (6 engineers) doesn’t justify the operational overhead of managing multiple data stores. We will revisit this if the engineering team exceeds ~25 people or if a compliance requirement forces data separation.“
This one paragraph does more to prevent both over-engineering and future regret than almost any other strategic artifact — it turns an implicit assumption into something that can be checked, challenged, and revisited on purpose rather than discovered by accident.
A useful test for any strategy decision at this stage: if a smart new hire looked at this plan in eight months, would they understand not just what we chose, but why we chose it over the alternatives, given what we knew and what we had? If the plan can’t pass that test, it isn’t a pragmatic plan — it’s either a wish list or a guess.
