Inside the problem. Not above it.
Stephen Diesel
I build the product and operating function inside early-stage companies, usually while the company is already running. At the moment that means product design and frontend work at Airframe, an executive coaching cohort of eight freedom-tech builders through Waye, and a few independent applications I build and maintain myself.
The work moves between strategy and the actual keyboard. I can sit with a founder on what the company should become, and I can ship the interface that tests it. Most of what I do lives in the space between those two.
How the work developed
I came up through product and operating leadership: regulated finance, blockchain infrastructure, institutional platforms. Different industries, the same job. The organization had outgrown the way it made decisions, and someone had to rebuild that while everything kept moving.
Before that, I helped build a social networking product. On paper it looks unrelated to operating design. It wasn't. A social network is a machine for coordination and trust: who connects to whom, what gets shared, what makes the person on the other side feel real. I have been working on some version of that question ever since. The clearest examples are the companies themselves.
First product function. Built the delivery model and sequencing while the organization was already in motion. The first release shipped in two months, against a cycle that normally ran six to twelve.
Shaped the product function before execution began. The savings product passed one billion dollars in deposits within seven months of launch.
Redesigned who had access to which product decisions. The result opened a new business line with Verizon, their largest enterprise client.
Why the human part matters
For a long time I treated this as a structure problem. Get the decision rights right, sequence the priorities, and execution follows. It mostly didn't. I kept watching capable teams stay stuck for reasons that had nothing to do with the plan. People didn't trust the new direction. A leader couldn't let go of a decision. Two people avoided the one conversation that would have unblocked everyone else.
So I went and studied the other half, in and out of companies. None of it was a side interest. It is where I learned that structure tells people what to do, and something else decides whether they actually do it.
The Wider Practice
I study organizations by working in places where their dynamics show up in the open, not only inside companies. None of this is a service line. Each is a setting that sharpened one thing I bring to the work.
Product judgment
Building product and shipping software myself. The plan I give an engineering team is one they can run, and I can separate a real constraint from a preference.
Leading change
Coaching a cohort of technical founders through Waye. Change is something people do, not something you install. Most stuck teams are one unmade decision from moving.
Observation
Research on attention and uncertainty through the Embodied Brain Lab. It trained what I watch for: how a team behaves under pressure, not how it describes itself.
Sensing group dynamics
Years facilitating groups and teaching movement. A hard working session is mostly reading the room in real time and holding it steady.
Creating conditions for trust
Running a co-living community at Casa Chironja. Trust is a set of conditions you design and maintain, not a line in a values deck.
Designing for behavior
Producing gatherings, from Slingshot and Rock the Blocks to small dinners. An event is a system for behavior. The same levers move a team.
What that adds up to
In practice, I can hold a few things at once that usually get split across different people.
I can tell whether a stuck team is a product problem, an org problem, or two executives who haven't been honest with each other, and I am useful in all three. I can design the operating model and stay in the room while it gets adopted, which is the part that decides whether it survives. And because I build, I know what I am asking an engineering team to do, so the plan is one they can actually run. It is why the operating models I build tend to get adopted instead of admired.
The through-line was never a plan. I kept ending up on the same questions. How do people coordinate. How does trust form or break. Why do capable teams get stuck, and what moves them again. A company is one of the places those questions get answered in public.
Outside the work
I live in Puerto Rico, where I help run Casa Chironja, a co-living house and community space. A lot of what I do there is organizing: helping put on gatherings, from larger ones like Slingshot and Rock the Blocks down to a good dinner with the right ten people.
It is the same instinct as the work. I like building the conditions where people can actually find each other, in a product or in a room. That is most of what I am doing either way.
If you are building something and the product or operating function isn't keeping pace with the team, that is the work. I embed, build it alongside you while the company is in motion, and step out when you no longer need me.