The word pragmatic traces back to the Greek pragma — „a thing done“ — and that is precisely the standard IT systems should be judged by in companies of 10 to 5000 employees: not how elegant an architecture looks on a whiteboard, but how well it gets things done with the budget, team, and time you actually have.
What does „pragmatic“ mean here?
In IT systems design, pragmatic means optimizing for outcomes achievable with the resources you actually have, not for architectural elegance, technology fashion, or what a Fortune 500 company would do. It means:
- Solving the problem in front of you, not the problem you might have in five years
- Choosing „good enough and shippable“ over „perfect and perpetually in progress“
- Matching complexity of the solution to complexity of the actual need
- Being willing to use boring, proven technology instead of the newest thing
- Accepting technical debt consciously, as a trade-off, rather than either ignoring it or refusing to ever incur it
It’s the opposite of both over-engineering (building for imagined future scale) and cargo-culting (copying practices from big tech companies without the context that made those practices necessary there).
Why is this necessary? What does it differ from?
Companies of 10–5000 employees sit in an awkward middle zone:
- Too big to run everything on ad hoc tools and spreadsheets
- Too small to have Google’s or a bank’s budget, headcount, or risk tolerance for elaborate platforms
What pragmatism differs from — three failure modes it corrects:
- Enterprise-pattern-itis — copying practices designed for organizations with 50 platform engineers (microservices for a 20-person company, Kubernetes for three servers‘ worth of load, elaborate governance boards for a team that ships weekly). This burns budget and slows everything down for problems you don’t have.
- Startup-hack-forever mode — the opposite failure: never revisiting early shortcuts, so by 200 employees the „temporary“ spreadsheet-as-database or single admin’s personal laptop running production is still there, and nobody can safely change anything.
- Vendor/consultant-driven decisions — buying whatever a salesperson pitched, or whatever a consultant’s standard template says, rather than what your actual constraints call for.
Why it matters specifically at this size band:
- Budgets are real constraints, not rounding errors
- IT teams are small (often 1–20 people covering everything), so operational complexity has a direct, painful cost
- The business changes faster than in a large enterprise (growth, pivots, M&A), so rigid big-design-upfront architectures become liabilities
- There’s rarely a dedicated enterprise architecture function to absorb the cost of bad decisions — mistakes hit revenue and morale directly
- Vendor lock-in and skill availability matter more, because you can’t just hire a specialist team for every obscure technology choice
How to be pragmatic — by phase
Strategy & planning
- Start from business goals and constraints (budget, headcount, timeline), not from a technology wishlist
- Build a roadmap in stages tied to actual triggers („when we hit X customers/transactions, revisit Y“), not speculative five-year architecture diagrams
- Inventory what you already have before buying anything new — reuse and consolidate before adding tools
- Involve the people who’ll operate and pay for the system, not just those excited to build it
- Accept „good enough for the next 12–24 months“ as a legitimate planning horizon in a fast-moving company
Design
- Default to the simplest architecture that meets known requirements; add complexity only when a concrete, current requirement demands it (not a hypothetical one)
- Prefer standard, well-documented patterns over clever, novel ones — the on-call engineer at 2am will thank you
- Design for the team’s actual skill set, not the skill set you wish you had
- Make integration points and data models simple and explicit; avoid speculative abstraction layers „in case we need to swap X later“
- Document decisions and trade-offs briefly (a short ADR-style note), not exhaustive architecture books nobody reads
Purchase & development
- Buy vs. build: default to buying/configuring for anything not core to your competitive advantage (HR, accounting, ticketing, basic CRM); build only where you need differentiation or where nothing fits
- Prefer mature, widely-used, well-supported products over niche or bleeding-edge ones — support availability and hiring pool matter
- Total cost of ownership over sticker price: implementation time, integration cost, training, ongoing licensing, and exit cost
- Negotiate contracts with an exit path in mind (data export, reasonable notice periods) to avoid lock-in traps
- Avoid „best of breed for every function“ sprawl — fewer, well-integrated platforms usually beat many best-in-class point solutions at this size
Integration
- Prefer a small number of well-understood integration patterns (a handful of APIs, a lightweight iPaaS/middleware, scheduled syncs) over building a bespoke integration platform
- Avoid point-to-point spaghetti — even a simple hub-and-spoke or a single integration tool pays off quickly once you have more than 3–4 systems talking to each other
- Use vendor-native integrations and standard connectors before custom code
- Keep integration logic visible and documented — this is where organizational knowledge silently disappears when one person leaves
Operation
- Automate the boring, repetitive, error-prone tasks first (backups, patching, user provisioning) — that’s where pragmatic automation pays off fastest, not exotic self-healing systems
- Right-size monitoring and alerting: alert on what actually needs human action, not everything technically measurable
- Build runbooks for common failures instead of tribal knowledge in one person’s head
- Match your operational model to team size: a 5-person IT team should not be running a bespoke 24/7 NOC-grade setup designed for a 200-person SRE org
- Revisit and retire tools/processes regularly — pragmatism is also about removing complexity you no longer need, not just avoiding adding it
Overall strategy for being pragmatic and successful
- Tie every technology decision to a business outcome you can state in one sentence. If you can’t, question the decision.
- Right-size, don’t minimize or maximize — the goal isn’t „as simple as possible“ or „as robust as possible,“ it’s „matched to actual current and near-term need.“
- Prefer reversible decisions when uncertain, and treat irreversible ones (core platform choices, data architecture) with proportionally more rigor.
- Timebox analysis — decisions that would take a Fortune 500 company six months of committee work should often take you two weeks. Perfect information is a luxury you don’t have and often don’t need.
- Revisit deliberately, not accidentally — set explicit checkpoints to reassess (growth milestones, yearly review), so „temporary“ pragmatic choices don’t silently become permanent liabilities without anyone noticing.
- Optimize for the team you have and will realistically be able to hire, not an idealized team.