Nobody sets up an engineering firm’s technology twice.
It gets set up once, usually early, usually by whoever was most capable at the time, and then it grows by accumulation. A workstation here. A larger drive there. A backup arrangement someone configured during a quiet week in 2019 and nobody has revisited since.
This works remarkably well for longer than it should. Then, somewhere between the tenth and twentieth employee, it stops working — not dramatically, but persistently, in ways that are hard to attribute to any single cause.
What follows is a stage-by-stage look at how engineering firms actually outgrow their technology, what breaks at each point, and what to do about it. If you recognise your firm somewhere in here, that’s the useful part.
Stage one: Under ten people
At this size, informality is an advantage. Everyone knows where files are because everyone put them there. Decisions happen in conversation. When something breaks, one person fixes it or calls someone who can.
What’s usually adequate: A single file server or a well-organised cloud arrangement. Individual workstations bought as needed. A backup running somewhere.
What’s usually missing: Almost always three things — Multi-Factor Authentication, a tested backup, and any form of monitoring.
These absences don’t cause problems at this stage, which is exactly why they persist into the next one. A five-person firm with no MFA operates identically to a five-person firm with MFA, right up until someone’s password ends up in the wrong hands.
Worth doing now, while it’s easy:
Enforce MFA on every account — with eight people this is genuinely an afternoon’s work
Perform one actual restore test and find out whether your backup works
Move a backup copy somewhere your office network cannot reach
That’s the whole list. It costs very little and it removes the majority of the risk a firm this size carries.
Stage two: Ten to fifteen people
This is where the first genuine strain appears, and it usually shows up as file confusion rather than performance.
The organisational structure that two or three people maintained by convention becomes unclear when eight people are contributing to it. Nobody’s quite sure whether the drawing in the project folder is the current one. Someone starts keeping a working copy on their desktop. Then someone else does.
Meanwhile, concurrent access starts to matter. Several people opening large files simultaneously puts a kind of load on storage that a smaller team never generated.
Symptoms at this stage:
What people say
What’s usually happening
“I can never find the latest version”
File structure has outgrown informal convention
“It’s slow in the afternoon”
Concurrent access hitting storage limits
“I just keep a copy locally”
Workaround forming that will cause problems later
“We had to redo that drawing”
Version conflict already cost real hours
What to address: Storage performance is the technical piece, and it’s frequently misdiagnosed. Firms add capacity when the constraint is speed under concurrent access — a drive that’s half empty but slow helps nobody.
The organisational piece matters more, though. A clear structure, agreed and actually followed, prevents the local-copy habit from taking hold. Once it does, it’s much harder to unwind.
Stage three: Fifteen to twenty-five people
Here the informal arrangement genuinely stops working, and firms usually notice because something goes wrong rather than because they planned for it.
Central model synchronisation, if you’re working that way, creates sustained load that ordinary file storage was never designed for. Several people syncing before lunch means everyone waits together. Consultant coordination intensifies on larger projects, and files start moving constantly between your firm and three or four others.
This is also the stage where remote work stops being occasional. Someone relocates. Site work becomes regular. And the remote access configured years ago for one person checking email gets asked to deliver 400MB models over a domestic connection.
The diagnostic that saves money here: Time a large file opening in the office early in the morning, then time the same operation at 11:45 when several people are working. If the two are broadly similar, individual workstations may be the constraint. If the second is dramatically slower, the bottleneck is shared — and replacing workstations will change almost nothing.
Firms routinely spend heavily on new machines at this stage and see modest improvement, because the new hardware waits on the same slow storage the old hardware waited on.
What’s typically needed:
Storage tuned specifically for concurrent access, not simply expanded
A remote access approach matched to file sizes — often remote desktop sessions where the file never travels
Controlled consultant file transfer, replacing the Dropbox-and-USB improvisation
Continuous monitoring, so degradation gets caught rather than tolerated
Support that responds in minutes rather than days
Our managed IT services address the monitoring and support pieces, and the infrastructure work follows from measurement rather than assumption.
Stage four: Beyond twenty-five
At this size the questions change character. Performance still matters, but it’s joined by governance concerns that smaller firms don’t face.
Access control becomes genuinely important — not everyone should reach everything, and permissions accumulate as people change roles. Documented processes matter, because informal knowledge no longer reaches everyone. And client due diligence arrives: larger clients and public-sector work bring security questionnaires that expect specific answers.
Firms at this stage frequently discover they’ve been running a twenty-five person practice on infrastructure and habits designed for eight. Catching up takes longer than staying current would have.
The three things that break regardless of size
Some problems don’t wait for a particular headcount. These appear at every stage, and they’re worth checking whatever size your firm is.
Backups that were never tested. A completed backup job confirms the job ran. It says nothing about whether the data inside is usable. We’ve tested backups running cleanly for four years that failed on restore, because corrupted data backs up perfectly well. If nobody can give you the date of an actual restore test, you don’t have backups — you have an assumption.
Backups reachable from the network. Ransomware specifically hunts connected backup storage, because attackers know a firm that can restore doesn’t pay. A backup drive in your server room, accessible from any workstation, will be encrypted alongside everything else. Where the copy lives matters as much as whether it exists. Our backup and disaster recovery approach is built around exactly this.
Missing or partial MFA. Stolen credentials remain the most common way anyone gets into a firm, and MFA stops the large majority of those attempts. The failure mode is almost never total absence — it’s partial coverage, with principals exempted because they found it inconvenient. Those are the accounts with the broadest access, and attackers specifically look for the exceptions.
Protecting what the firm actually owns
Engineering firms tend to think about security abstractly, which is understandable when the alternative is thinking about it concretely.
Concretely: your project files are the business. Calculations, designs, survey data, drawing sets, and years of accumulated technical work. Ransomware reaching that storage doesn’t delay one project — it stops all of them on the same morning, with every deadline, every consultant coordination, and every deliverable affected simultaneously.
There’s also a dimension specific to this profession. Engineering work carries professional liability, and a breach raising questions about whether project data was altered rather than merely accessed opens a genuinely difficult line of enquiry. Being able to demonstrate recovery from a verified clean backup is a materially different position from being unable to say what happened.
Layered cybersecurity — endpoint detection and response, MFA everywhere, email threat filtering, DNS security, automated patching — addresses the routes attacks actually take. Continuous monitoring catches the intrusion during the weeks an attacker typically spends inside a network before triggering anything, which is the only window in which it can be stopped cleanly.
The El Dorado County consideration
There’s a practical reality for firms in Placerville and the surrounding foothill communities worth naming directly.
Specialist support has historically been thinner here than in Sacramento. Firms rely on a general vendor, or on the staff member who’s good with computers, and response times measured in days become normal because nothing else was available.
The consequences extend beyond convenience. Maintenance gets deferred. Workarounds become permanent. Controls needing ongoing attention drift, and nobody notices because nobody is watching.
Remote-first managed support has changed this considerably. Most issues now get resolved remotely within minutes regardless of distance, and monitoring requires nobody to be nearby. For a firm outside the metro areas, that’s a meaningful shift from how things worked even five years ago.
Common mistakes worth avoiding
Having watched firms navigate these transitions, a few errors come up often enough to be worth flagging.
Buying hardware before measuring. The single most expensive mistake at stage three. Establish where the delay originates before spending anything.
Treating storage capacity and storage speed as the same problem. They aren’t, and adding space to a slow array achieves nothing.
Letting the local-copy habit establish itself. Once people work from desktop copies, version conflicts follow, and reversing the habit is much harder than preventing it.
Exempting anyone from MFA. Partial coverage isn’t partial protection. It’s a marked map.
Assuming the backup works. Test it. The result is either reassuring or extremely useful.
Waiting for a quiet period to address any of this. Growing firms don’t have quiet periods. That’s what growth means.
Where your firm probably sits
Read back through the stages and find the one that describes your current reality most closely. Then look at the stage after it, because that’s where you’ll be within eighteen months if things go well.
Most of what’s described here is cheaper to do slightly early than slightly late. Storage planned before it becomes a bottleneck costs the same as storage bought during a crisis, but without the disruption. MFA enforced across twelve people is easier than across thirty. A backup tested on an ordinary Tuesday is considerably better than one tested during an incident.
The firms that navigate growth smoothly aren’t the ones with bigger budgets. They’re the ones who saw the next stage coming.
Send us a message describing where your firm sits and what’s currently frustrating people, and we’ll tell you what’s likely causing it and what stage you’re actually at. No obligation attached — get in touch here or call 209-920-4077 to talk it through with someone who’s seen this progression a few dozen times.
