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.

We could have staffed it easily. But hands weren't what the project was missing. It was missing a decision: a clear scope, and one senior person to own the hard calls. Put four engineers on an unscoped build and they'll move fast in four directions and hand you 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.