Fractional Operations and Technology Leadership for Growing Companies
Sales closes a deal that operations hears about afterward. Four systems hold four versions of the same number. AI experiments nobody owns. You are the only person who can see the whole picture — which is exactly the problem.
I work with founders and leadership teams when the way they built the company stops working.
No handoff team. No hundred-page report. You work with me.
01 / The situation
A strong company can still run out of room.
“Sales closes it. Implementation finds out afterward.”
Onboarding that used to take two weeks now takes six, and no two people run it the same way.
“Whose number is right?”
The CRM, the tracker, the wiki, the spreadsheets, and three dashboards that quietly disagree.
“If two people left, we would be in real trouble.”
The process lives in somebody’s head. It has never lived in a document.
“Everything still depends on me.”
You have become the integration layer between every team. You do not scale.
None of these is the problem. They are what the problem looks like from inside the building.
02 / Who you get
When you hire Pinecone, you work with me.
I’m Brian Bousquet-Smith — an engineer, an operator, and a problem solver. I have spent my career stepping into complicated businesses and making them work better.
I have led teams across engineering, product development, manufacturing, logistics, customer success, IT, quality, and sales. Startups, government, public companies. And I have had the unusual experience of holding several of those seats inside the same organization — engineering, then operations, then sales.
Business problems rarely belong to one department. They live in the handoffs: between what engineering builds and what operations can support, between what sales promises and what the business can deliver, and between the numbers leadership sees and what is actually happening on the ground.
Those gaps are invisible from inside. Everyone is doing their job. Nobody owns the space between the jobs.
That is where I am useful. I know how the different rooms talk. More importantly, I know how to hear what is getting lost between them.
03 / What I do
Four ways in, depending on what is actually wrong.
Fractional technology and operations leadership
Direction without a quarter-million-dollar hire you are not ready to make. Operating strategy, leadership-team alignment, and an execution cadence that holds when you are not in the room.
Architecture, build-or-buy, and platform decisions
Where to consolidate, what to build, what to buy, what to retire — decided deliberately, before the complexity compounds and the cost of changing your mind triples.
Operating systems and clear ownership
Roles, decision rights, and handoffs written down. Planning discipline that survives a bad quarter. One set of metrics the leadership team stops arguing about.
Diagnostic and 90-day roadmap
For when you know something is wrong but not what. A structured review of your people, systems, and spend that separates the symptoms from the cause, and a plan you can actually run.
04 / A case study
Most AI efforts stall in the same place.
Not at the start — the start usually goes well. It stalls in the gap between a good kickoff and anything reaching real work. At one healthcare company, leadership had done the right first things: brought the right people together, authorised budget, made the intent clear. What was missing was the connective tissue underneath it — a next step small enough to take, and somewhere safe to take it.
So I ran an assessment, found where it was stuck, and started building.
The first move was not technology. I surveyed the team to find the people who were already curious, put them in the same room, and gave them explicit permission to experiment — lunch-and-learns, hands-on sessions, and the room to try things without filing a request first. The barrier was never capability. It was that nobody knew where to start.
The constraint
In a regulated environment there are hard limits on what can go near sensitive data. So the guardrails were written by the team and leadership together rather than handed down — which is the reason people actually followed them.
The rule that mattered
AI is a tool. The employee owns the output they put their name on. If it is slop, that is on you.
The discipline
Early adopters want to try everything. The rule was that you put one tool down before you pick the next one up, and you share what you found.
What changed
Someone with no engineering background built an internal tool in a day — the kind of thing that would previously have needed a developer, if it got built at all. Hours saved immediately, and a pile of inconsistency gone with it. The volunteers became a standing internal group, and a lot of the busy work that used to fill people's days went with them.
Bring me the hard problem.
You do not need to diagnose it first. Tell me what is happening, what is at stake, and what feels stuck. We will find a practical next step from there.