Senior advisory · AI-first engineering organizations

Your engineering organization is telling you a filtered story.

I come in, talk to the people your managers don’t send to you, and tell you what’s actually happening. Thirty years in engineering, fifteen of them running the organizations — read through the lens of AI-first engineering, because that’s what they need to look like next.

WHOMisha PobirskyLinkedIn →

TODAYChief Engineering OfficerCloudLinux / TuxCare · 300 engineers

BEFOREThirty years in engineering.Fifteen years running the organizations.

ALSOAdvising a small number offounders and CTOs each year

The picture the CEO has comes from managers. Managers have incentives to filter — to protect their teams, to protect their status, to present progress that matches the narrative the organization rewards. Over time, the gap between what the CEO believes and what is actually happening inside the org grows quietly, and nobody is rewarded for closing it.

By the time that gap becomes visible — through a missed roadmap, an outage, an attrition wave, a founder losing confidence in their CTO — it is already expensive. The people in the corners of the organization who saw it coming were never asked.

I’ve spent thirty years running engineering organizations, including the one I run now. I know what the signal looks like from every level — from the IC who’s quietly disengaging, to the team lead who’s being set up to fail, to the director who’s performing competence while the delivery underneath them rots. I read organizations by talking to the people their managers don’t put in front of visitors. And then I tell the CEO what’s true. I read organizations with a particular eye: whether they’re structured to survive AI-first engineering, because in three years that’s the standard they’ll be judged against.

The frame is AI-first engineering — because that’s the standard organizations will be judged against in three years. But the diagnosis is broader. Delivery, people, structure, execution, communication. Here’s what I listen for.

AI-first is the lens. The diagnosis is broader.

Every engagement starts with a diagnosis. What happens after is up to you.

Diagnosis

Two to four weeks. A report you can act on.

I spend time inside your organization. I interview — not just the senior people, but the ones further from the light: the ICs who joined recently, the ICs who’ve been there longest, the people your managers describe as “difficult,” the team leads nobody is grooming for promotion. I read your docs, your tickets, your Slack, your org chart. Then I write you a report: what’s actually happening, where the real blockers are, what you’re wrong about, and what I’d do if I were in your chair. Fixed fee, fixed scope. If we don’t work together again, you still have the report.

Prescription

Ongoing advisory. Typically three to six months.

After the diagnosis, if you want to act on it, I stay on. Weekly working sessions with you and your senior engineering leadership. Decisions reviewed. Documents read and edited. Hard conversations rehearsed before you have them. I’m on call when something escalates. Part-time — I have a day job — but meaningfully engaged. This is the shape most engagements take.

Treatment

Embedded work. Scope defined per engagement.

For organizations that need more than advisory — where the work is execution, not just guidance — I go into the trenches. I write the internal documents, facilitate the difficult meetings, walk the changes into teams, help you recruit the people you’re missing. I bring a small team when needed. This is the largest kind of engagement I take, and I take very few of them. It’s right when the diagnosis surfaces that the org can’t execute the prescription on its own.

This is for you if…

You're the founder, the CEO, or the CTO — and the decision is yours to make.
Something in your engineering organization isn't right, and you don't trust the picture you're getting from your managers.
You want someone who's actually running an engineering organization right now, not someone who ran one in 2019 and pivoted to speaking fees.
Your engineering organization is roughly 30 to 500 people.

This is not for you if…

You want someone to validate a decision you've already made.
You want a framework you can buy, certify, and roll out without changing anything about how you actually lead.
You're looking for a large consulting engagement with a team of juniors billed to your account.
You're not sure whether your organization actually has a problem. (Come back when you are.)

Thirty years in engineering, starting in the 1990s. For the past fifteen years I’ve been building and running engineering organizations — most recently as Chief Engineering Officer at CloudLinux / TuxCare, a Linux infrastructure company serving over 4,000 enterprise customers across 500,000+ installations, with roughly 300 engineers across six departments.

I’ve shipped, I’ve scaled, I’ve made expensive mistakes. I’ve burned years on internal frameworks that we eventually threw away. I’ve trusted engineering estimates that turned out to be wrong by an order of magnitude. I’ve walked into CEO rooms with complete solutions and watched them get rejected — because ego is real and nobody adopts somebody else’s answer wholesale. I mention these specifically because most advisory sites don’t, and because scar tissue is what makes the advice useful.

What I’m genuinely good at — and what I want to charge for — is reading engineering organizations by reading the people inside them. After a long enough time, the same shapes of dysfunction keep showing up — sharpened now by what AI-first engineering demands of organizations that weren’t built for it — and the signals that reveal them become legible if you know what to ask and who to ask. That’s the service.

If you’re reading this and wondering whether to reach out, reach out. The first call is free.

A short note about your organization and what’s not right is enough. I respond personally within a few days.