When embedded engineering is the wrong call — and I'll tell you

A founder called recently wanting four engineers, starting Monday, to hit a launch. I told him not to hire us.

Not because we couldn't staff it. Because what he needed wasn't four pairs of hands. It was a smaller scope and one senior person to make the hard calls. Four people on an unscoped build would have moved fast in four directions and handed him a bigger mess in six weeks.

Embedded engineering is the right call when you have a clear roadmap and you're capacity-constrained: you know what to build, you just can't hire senior people fast enough to build it. It's the wrong call when the real problem is that nobody senior has decided what to build yet. Throwing bodies at an undecided plan makes it worse, and more expensive.

A few other times it isn't us. If you need to stand up a 15-person team overnight, we're the wrong shop — we work small and senior on purpose. If you want to manage engineers by the hour and sign off on every ticket, you'll be frustrated and so will they. And if what you need is a fractional CTO to set direction before anyone writes a line of code, I'll say so on the call. Sometimes that's a short consulting engagement, not an embedded team.

I'd rather lose the engagement than take work we can't be great on. The case studies on this site exist because we only said yes to builds we could land. That record is worth more to me than one more contract.

So when we get on a call, expect me to ask what you're trying to do — and to tell you honestly whether we're the team for it.