Craig and his team have proved to be an exceptional resource for us. The ability to see the big picture and engage at a high level is highly valued. EES excels at modern microprocessor and wireless communication platforms and has provided valuable advice on best practices and security standards. EES’s ability to develop quickly and iterate has been crucial to our project’s success.
Embedded Systems Consulting
Embedded Systems Consulting
Sometimes you don’t need a project taken off your hands. You need more hands on the project you already have.
That’s what we mean by embedded systems consulting: senior engineers working inside your team, under your direction, on your timeline. Not an advisory report. Not a stack of recommendations someone else has to implement. Direct technical work, done by people who’ve built this before.
Three ways teams bring us in
- Extra bandwidth. Some teams don’t need different expertise; they need more of what they already have. You’re pushing to hit a milestone in the next six months and don’t want to hire two engineers just to let them go when the rush is over. We fill that gap on a defined timeline, working the tasks your project manager assigns, like anyone else on the team.
- Knowledge transfer. This is a common tactic in startups. Junior engineers are cheaper to hire, so you bring in a senior consultant to oversee the work and mentor the team as it moves forward. A year or two later, your junior engineers are more capable because of that mentoring, and the capability stays after we leave.
- A specialized, one-off skill. Antenna tuning. RF design. High-speed or high-power layout. You’ll need these skills once, or maybe two or three times over a product’s life. Hiring someone full-time for that rarely makes sense unless it’s your core business. We keep that skill on staff, and we’re one and done.
Engagements under any of these range from a couple dozen hours to several years. What never changes is the one behind the wheel. You manage the project and allocate the tasks; we do the work.
How the work actually runs
Staff augmentation engagements run inside your existing process, not ours. Jira, Azure DevOps, or whatever other system your team already uses. Your project manager assigns tasks; some go to your team, some go to ours. For an organization that already has the tools and structure in place, this is close to invisible from a process standpoint.
The hardest part isn’t the day-to-day work. Winding down cleanly when the engagement ends can be the hardest part. More on that below.
What an outside set of eyes catches
Every engineer, including ours, comes to a problem with biases shaped by what they’ve built before, what’s broken in past projects, and what worked for them the first time. Bringing in an outside consultant broadens your team’s perspective without increasing your headcount. You get a different history and a different set of assumptions looking at the same system, without the permanence of a new hire.
Usually, this outside perspective surfaces issues the internal team can’t see. The tunnel vision a team develops by building something from the ground up can make it miss an alternative path that is obvious to an outsider with a fresh perspective.
Getting up to speed on a system we didn't build
Every consulting engagement starts with the same problem: almost no domain knowledge going in. Documentation is often stale by the time we’re brought in. It’s not unusual for a client to hand us a schematic that doesn’t match the board in front of us- close, but not exact- because it documents an earlier revision. We track down the current version and work from there.
Most of these engagements aren’t about a broken system. They’re systems built two, three, or ten years ago, and the engineers who built them have moved on. We don’t try to understand the whole thing on day one. We understand the pieces relevant to what needs to be done now and build from there as the work requires.
When there’s a specific issue and a previous consultant involved, we stay technical. We don’t pass judgment on someone else’s earlier work; we don’t know what the constraints were. We assess the system as it is and lay out what it takes to get it where it needs to be.
How we scope an engagement
Staff augmentation is usually straightforward: a defined number of hours over a defined number of months, allocated to whatever tasks come up.
Specialized or diagnostic work is different, because we can’t promise a fix before we understand the problem. So, we scope it in checkpoints. We start with a bounded analysis phase, enough to understand what’s actually going on, then use that to define the next phase, and the one after that if there is one.
This checkpoint system gives you a chance to walk away at every stage. On one recent engagement, a client came to us with a firmware throughput problem. Sixteen hours of analysis ruled out everything we initially suspected. Fully solving it would have taken another 40-plus hours. The client decided the problem was livable, and they stopped our work there. That was the checkpoint model working as intended: you’re never locked into an open-ended engagement to find out what something costs.
Consultant or full-time hire?
The honest answer depends on how long you’ll need the capability that person brings to your team.
If the need is ongoing, hire someone with that expertise. Paying an outside consultant to do your core development work for years costs more than hiring the right person. The same goes for anything that needs someone on call nights and weekends, managing live customer issues directly: that’s an employee’s job, not a consultant’s responsibility.
If the need is specialized and short-lived, bringing in a consultant almost always makes more sense. Antenna tuning, RF design, high-power or high-speed layout: these come up rarely enough that a full-time hire sits idle most of the year. Understanding your timeframe, not just the skill gap, is what actually answers this question.
Winding down without losing what we knew
The hardest part of a long-running engagement usually isn’t the work itself. It’s the farewell. Once a team has worked together for months or years, there’s real risk that something critical walks out the door when we do.
We treat a project wind-down as part of the engagement, not an afterthought. Before we move on, we make sure whatever needs to transfer to your team, such as documentation, context, and the reasoning behind decisions, actually transfers, so your team stays productive after we’re gone.
Where to start
If you already know what kind of help you need, tell us the scope, and we’ll tell you honestly whether it’s a proper fit.
If you’re not sure yet whether the gap is bandwidth, a specific skill, or a system nobody on your team currently understands, start with a free Engineering Reality Check: one hour with a senior engineer, no cost, no pitch.
Talk to a senior engineer
Already have a defined firmware or hardware problem, not an ongoing gap? See the Firmware Flaw Finder audit or EES Design Review. Looking for a full build instead of augmentation? See Embedded Systems Design.
HT Snowday | Head of R&D | midmark