A few things tend to show up together when the timing is right. Every hard decision still routes through the founder. The roadmap shifts mid-sprint more often than it holds. Support is catching problems that should have been caught upstream. Sales is making commitments the team finds out about too late. Engineering is working hard but the work is not consistently moving revenue or reducing drag. If more than two of those sound familiar, the company is probably ready. If all of them sound familiar, we should talk.

It depends on where the company is and what's on fire, which is the honest answer. In the first thirty days, the job is mostly diagnostic: sitting in the meetings, reading the Slack threads, figuring out where decisions are actually getting made versus where everyone thinks they're getting made. After that, it shifts to building. Decision frameworks, operating cadences, prioritization systems, cross-functional feedback loops. On any given week, I might be running a planning session with the product team in the morning, working through a support escalation that's actually a product gap in the afternoon, and writing the accountability structure that keeps both from happening again by end of day. The through line is always the same: find the operational drag, figure out what's causing it, and build something that fixes it at the root.

It’s not! I act as a fractional COO or fractional chief of staff, depending on the engagement.

Threadsmith engagements are execution-first. I am in the work with you, attending the standups, pulling the data, building the systems alongside the people who will run them after I leave. If you need someone to help you think, I will help you think. But thinking is not the deliverable. The operating infrastructure is the deliverable.

Consultants observe and recommend. I embed and build. A consulting engagement typically ends with a report, a deck, or a set of recommendations that your team then has to figure out how to implement. A Threadsmith engagement ends with functioning systems, documented processes, and a team that knows how to use them. I am in your standups. I am in your planning sessions. I am in the cross-functional conversations where things actually break down.

The work product is not a recommendation. It is the thing itself.

Generally, no. Threadsmith engagements are designed for companies that have found product-market fit and are feeling the operational strain of growth, typically between $1M and $10M ARR.

Before product-market fit, the problem is usually product and customer discovery, and that requires a different kind of support. If you are pre-revenue and drowning in operational chaos, I am happy to have a conversation, but I will tell you honestly if this is the right fit.

We work through this on the clarity call because the scope varies by company stage, team size, and what needs to get built. What I can tell you is that engagements are structured as a monthly retainer for the duration of the embed (typically three to six months), and the rate reflects senior operator expertise, not junior consulting hours. If you want to gut-check whether the investment makes sense before we talk, think about what it costs you every month to have the founder as the operational bottleneck. That number is usually the answer.

Both. The operational problems that show up between $1M and $10M ARR are not specific to how the company is funded. Founder as bottleneck, execution drift, cross-functional misalignment, those happen in bootstrapped companies and venture-backed ones at roughly equal rates and for roughly the same reasons. What matters is whether the founder is ready to change how decisions get made across the organization, and that has nothing to do with the cap table.

Yes. Most of the companies I work with are remote or hybrid. I’ve been remote for 7 years. The operational problems that need solving (decision bottlenecks, execution drift, cross-functional gaps) are actually more visible in remote environments because the informal hallway conversations that paper over them in an office do not exist. Remote-first teams usually need clearer decision frameworks and more intentional operating cadences than co-located ones, which makes this kind of engagement a natural fit.