The Skunk Works Manifesto
A circus tent, a jet airplane, and a startup walk into a bar...
People often ask me about my methodology.
They expect me to say Agile. Maybe Scrum. Perhaps some fancy framework with certifications and consultants and three-day workshops in hotel conference rooms. They’re ready to nod along, to recognize the familiar acronyms, to mentally check the box that says “this guy knows what he’s doing”.
Instead, I tell them about a circus tent that smelled like a distillery. About a Swedish immigrant who could see air. About a group of engineers who built America’s first jet fighter in 143 days while the country was at war, working with hand tools and slide rules, fueled by coffee and cigarettes and the kind of determination that only exists when failure isn’t an option.
I tell them about Skunk Works.
And then I watch their faces. Because this is where people either lean in or check out. The ones who lean in - those are my people. The ones who understand that the best ideas about how to build impossible things don’t come from business schools or methodology certifications. They come from people who’ve actually done it, usually under circumstances that should have made success impossible.
This is the manifesto I’ve been trying to write for years. Every time I attempted it on LinkedIn, I’d hit the character limit and realize I was barely getting started. The philosophy that guides everything I build - from AI that tells stories to technology that helps Deaf people communicate to board games with embedded electronics - it all traces back to a set of principles developed eighty years ago by people building spy planes and stealth fighters.
If that sounds like a strange foundation for a startup in 2026, stick with me. By the time you finish reading this, you’ll either think I’m crazy or you’ll want to burn down everything you thought you knew about building products. Possibly both.
Let’s start at the beginning.
The circus tent where everything started
June 1943. The United States is deep in World War II, and there’s a problem. Nazi Germany is developing jet-powered fighter aircraft, and America has nothing to counter them. The propeller-driven planes that won the Battle of Britain are about to become obsolete, and everyone knows it.
The U.S. Army Air Forces Air Tactical Service Command approaches Lockheed Aircraft Corporation with what amounts to a desperate plea: can you build us a jet fighter? And can you do it fast?
A young engineer named Clarence Leonard “Kelly” Johnson says yes. Not just yes - he promises to deliver a prototype in 180 days. Six months to design and build America’s first operational jet fighter, a type of aircraft that Lockheed has never attempted before, using technology that barely exists.
His bosses think he’s insane. He probably is.
Johnson hand-picks a team of twenty-three engineers and about thirty shop mechanics. He can’t find space for them in Lockheed’s main facility - the war effort has every square foot occupied. So he rents a circus tent and sets up shop next to a plastics factory. The smell from the factory is so overpowering that the team starts joking they work in the “Skonk Works” - a reference to a location in the popular comic strip Li’l Abner, where a mysterious and malodorous moonshine was brewed.
The name stuck. Lockheed later changed the spelling to “Skunk Works” to avoid trademark issues, but the spirit remained the same: a small group of brilliant misfits, working in conditions that would make any HR department have a seizure, doing things that shouldn’t be possible.
Here’s what happened next: Kelly Johnson and his team delivered the XP-80 Shooting Star in 143 days. Not 180 days. One hundred forty-three. They finished weeks ahead of an already insane schedule.
Oh, and one more detail that still blows my mind every time I think about it: the formal contract for the project didn’t arrive until October 16, 1943 - four months after work had already begun. They built America’s first jet fighter on a handshake.
Let that sink in. No contract. No formal requirements document. No detailed specifications signed in triplicate by seventeen stakeholders. Just a handshake, a circus tent, and a team of people who believed they could do something impossible.
The man who could see air
To understand Skunk Works, you have to understand Kelly Johnson. And to understand Kelly Johnson, you have to understand that some people are simply built different.
Johnson was born in 1910 in Ishpeming, Michigan - a remote mining town where winter temperatures regularly dropped to thirty below zero. His parents were Swedish immigrants. He was the seventh of nine children. By every statistical measure, he should have ended up working in the mines like everyone else in town.
Instead, he became one of the most important aeronautical engineers in history.
His boss at Lockheed, Hall Hibbard, once said of Johnson: “that damned Swede can actually see air”. It wasn’t a metaphor. Johnson had an almost supernatural ability to understand aerodynamics intuitively. He could look at an aircraft design and immediately identify problems that would take other engineers weeks of calculations to discover. He could estimate weight, performance characteristics, and structural requirements in his head while other people were still sharpening their pencils.
But Kelly Johnson wasn’t just a brilliant engineer. He was a brilliant leader who understood something fundamental about how innovation actually happens: it doesn’t come from process. It comes from people. Small groups of exceptional people, given the authority to make decisions, protected from bureaucratic interference, and trusted to deliver.
His motto was simple: “be quick, be quiet, and be on time”.
Johnson is sometimes credited as the originator of the KISS principle - Keep It Simple, Stupid. Whether or not he actually coined the phrase, he certainly lived it. He had zero patience for complexity that didn’t serve the mission, for meetings that didn’t produce decisions, for paperwork that didn’t make the aircraft fly better.
After the success of the XP-80, Skunk Works became Lockheed’s secret weapon for impossible projects. Over the following decades, they produced a string of aircraft that changed the world.
The U-2 spy plane, which could fly at 70000 feet - so high that Soviet radar couldn’t track it and Soviet missiles couldn’t reach it. The U-2 gave the United States unprecedented intelligence capabilities during the Cold War and remained in service for decades.
The SR-71 Blackbird, which could fly at Mach 3.2 - more than three times the speed of sound - at altitudes above 85000 feet. The Blackbird was so fast that its primary defense against missiles was simply to outrun them. It still holds the world speed record for a manned, air-breathing aircraft. That record was set in 1976, and no one has beaten it in fifty years.
The F-117 Nighthawk, the first operational stealth aircraft, which could penetrate enemy airspace completely undetected by radar. The F-117 flew over 1300 combat missions in the Gulf War with zero losses.
Each of these aircraft was built by small teams using the principles Kelly Johnson established in that circus tent. Each of them was considered impossible until it flew.
The 14 rules that built the impossible
Kelly Johnson eventually codified his approach into fourteen rules. He first wrote them down in 1954, and they’ve been guiding Skunk Works operations ever since. If you visit Lockheed Martin’s website today, you can still find them posted.
The original rules were written for defense contractors working with military customers. They talk about project offices and security clearances and contractor-military relationships. But underneath the specific language, there are timeless principles about how small teams can accomplish extraordinary things.
I’ve spent years studying these rules, applying them, screwing them up, and learning from my mistakes. What follows is my translation of Kelly Johnson’s wisdom into principles that work for startups, for small teams, for anyone trying to build something that the world says can’t be built.
Principle One: ruthless team size
Kelly’s original rule: “The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people - 10% to 25% compared to the so-called normal systems”.
Read that again. Ten to twenty-five percent of what’s “normal”. Not a small reduction. A savage one. And notice the language: “restricted in an almost vicious manner”. Kelly Johnson didn’t mince words.
This is the principle that most people understand intellectually but fail to apply in practice. When projects get hard, the instinct is to add people. When deadlines loom, managers start talking about “scaling up the team”. When problems multiply, the solution always seems to be more bodies.
It’s almost always wrong.
Here’s what actually happens when you add people to a struggling project: communication overhead explodes. Every new person needs to be brought up to speed. Every decision now requires more meetings, more consensus-building, more documentation so that everyone knows what everyone else is doing. The work that was already hard becomes harder, not easier.
Brooks’s Law - from Fred Brooks’s classic book The Mythical Man-Month - states that adding manpower to a late software project makes it later. Brooks wrote that in 1975, and we still haven’t learned the lesson.
Kelly Johnson understood this instinctively. He knew that a small team of exceptional people will always outperform a large team of average people. Not just in speed - in quality, in innovation, in the ability to pivot when something isn’t working.
But here’s the part people miss: this only works if the small team is actually exceptional. “Small number of good people” is the full phrase. You can’t have a tiny team of mediocre performers and expect magic. The Skunk Works hired the best engineers they could find and then trusted them to operate with minimal oversight.
When I built Beyond Humanity - the hybrid board game with a companion app, IoT-specific electronics, and practical AI applications - we did it with a team that would have made traditional game publishers laugh. They would have told us we needed separate teams for hardware, software, game design, manufacturing, and marketing. Instead, we had a handful of people who wore multiple hats and talked to each other constantly.
We raised over $410K on Kickstarter. The project succeeded not despite the small team, but because of it.
Principle Two: one throat to choke
Kelly’s original rule: “The Skunk Works manager must be delegated practically complete control of his program in all aspects. He should report to a division president or higher”.
This is about decision-making speed. In a traditional organization, decisions filter up through layers of management, get debated in committees, require sign-offs from stakeholders who may not understand the technical details, and eventually emerge - weeks or months later - as watered-down compromises that satisfy no one.
In Skunk Works, Kelly Johnson made the decisions. All of them. He reported directly to senior leadership, which meant there was no middle management to slow things down. If something needed to change, it changed. If a problem needed solving, it got solved. No committees, no consensus-seeking, no death by PowerPoint.
I call this “one throat to choke” because that’s the phrase investors sometimes use, and it’s viscerally accurate. When everything depends on one person’s judgment, that person feels the weight. There’s no hiding behind process, no diffusing responsibility across a committee. You make the call, and you own the outcome.
For founders, this principle feels natural - of course you’re making the decisions, you started the company. But it gets harder as companies grow. The temptation to add layers, to distribute authority, to create structures that feel more “professional” is enormous.
Fight that temptation. The moment decisions start requiring meetings to schedule meetings, you’ve lost something precious. The speed that let you compete with bigger players, the agility that let you pivot when the market shifted - it evaporates once you start optimizing for process over outcomes.
This doesn’t mean being a dictator. Kelly Johnson listened to his engineers. He valued their input. He changed his mind when presented with better information. But he made the final call, and he made it fast.
Principle Three: trust over process
Kelly’s original rule: “there must be mutual trust between the military project organization and the contractor, the very close cooperation and liaison on a day-to-day basis. This cuts down misunderstanding and correspondence to an absolute minimum”.
This might be the most important principle of all, and it’s the one that modern business has most thoroughly forgotten.
Process exists to compensate for lack of trust. When you don’t trust someone to do their job, you create checkpoints, reviews, approvals, and documentation requirements. When you don’t trust your partners to deal with you fairly, you create contracts with dozens of clauses covering every possible contingency. When you don’t trust your team to make good decisions, you create hierarchies and committees and sign-off procedures.
All of that process has a cost. It slows everything down. It creates overhead. It demoralizes people who are competent and trustworthy by treating them like they’re not.
Kelly Johnson started the most ambitious aerospace project of his era on a handshake. No contract. Just trust between Lockheed and the military that both sides would act in good faith. That trust enabled speed that would have been impossible in a more adversarial arrangement.
When I work with investors, partners, or team members, I’m constantly asking myself: is this process necessary, or is it compensating for a lack of trust? If it’s the latter, the real question is whether to build trust or accept that this isn’t the right relationship.
Some of my best professional relationships have operated with minimal formal structure. Daily communication. Complete transparency. Willingness to have hard conversations quickly instead of letting problems fester. The documentation is minimal because the trust is high.
Some of my worst professional relationships have drowned in process. Contracts that took months to negotiate. Weekly status reports that no one read. Formal change request procedures for the smallest modifications. All of that process didn’t prevent problems - it just made them harder to solve.
Principle Four: ship and iterate
Kelly’s original rules emphasized flexibility: “a very simple drawing and drawing release system with great flexibility for making changes must be provided” and “there must be a minimum number of reports required, but important work must be recorded thoroughly”.
Notice the balance here. Flexibility and minimal bureaucracy, but important work gets recorded. This isn’t about being sloppy. It’s about not letting documentation become an end in itself.
The Skunk Works built working aircraft. Not perfect requirements documents. Not comprehensive specification packages. Working aircraft that actually flew. And when something didn’t work, they fixed it - quickly, without convening a change control board or filing a formal modification request.
In modern startup language, we’d call this shipping and iterating. Get something real in front of users as fast as possible. Learn from what actually happens, not what you predicted would happen. Make changes based on evidence, not speculation.
The waterfall model - where you specify everything upfront, then design, then build, then test, and only then discover that your assumptions were wrong - is a recipe for disaster. It’s how you spend two years building something nobody wants.
Kelly Johnson didn’t have the vocabulary of agile development, but he was practicing it decades before the Agile Manifesto was written. Small iterations. Constant testing. Flexibility to change course when you learned something new.
When we’re building Omea, we don’t wait until a feature is perfect to get it in front of users. We ship it, watch what happens, and improve. The narrative AI that powers the experience has gone through countless iterations based on how real people actually interact with it. If we’d tried to specify everything upfront, we’d still be writing requirements documents instead of building a product that works.
Principle Five: know your numbers
Kelly’s original rule: “there must be monthly cost reviews covering not only what has been spent and committed but also projected costs to the end of the program”.
This seems like basic financial management, but the emphasis on real-time cost awareness is crucial. Kelly Johnson didn’t want to find out at the end of a project that they’d blown the budget. He wanted to know at every moment exactly where they stood financially.
For startups, this translates into obsessive attention to runway, burn rate, and unit economics. Not quarterly reviews where you discover problems too late to fix them. Weekly or even daily awareness of exactly how much money you have, how fast you’re spending it, and what that means for your timeline.
I’ve seen startups die because founders avoided looking at the numbers. They knew intellectually that cash was tight, but they didn’t want to confront exactly how tight. By the time they were forced to face reality, it was too late to make meaningful changes.
The bootstrapping mindset - even when you’re funded - is a competitive advantage. Every dollar you waste is a dollar you can’t spend on something that matters. Every month of runway you burn unnecessarily is a month of optionality you’ve lost.
Kelly Johnson delivered projects under budget. Not just on budget - under budget. In an industry notorious for cost overruns, Skunk Works consistently brought projects in for less than projected. That wasn’t luck. It was discipline. It was knowing the numbers and making decisions accordingly.
Principle Six: protect the work
Kelly’s original rule: “access by outsiders to the project and its personnel must be strictly controlled by appropriate security measures”.
In the original context, this was about military secrecy. Skunk Works projects were classified because they involved technology that adversaries couldn’t be allowed to learn about.
For startups, the principle is different but equally important: protect the team’s ability to focus.
Every meeting that isn’t essential is an attack on your team’s productivity. Every stakeholder who demands status updates is consuming time that could go toward building. Every well-meaning advisor who wants to “stay in the loop” is creating communication overhead.
I’m not saying you shouldn’t have meetings or stakeholders or advisors. I’m saying you should guard your team’s attention as jealously as Kelly Johnson guarded his classified projects. The context-switching cost of constant interruptions is enormous. A developer who’s interrupted every thirty minutes might as well not be working at all.
This also means protecting the team from scope creep. From “wouldn’t it be nice if” feature requests. From the temptation to chase every opportunity instead of focusing on what matters.
One of the hardest things about building something is saying no to things that seem good but aren’t essential. Kelly Johnson could say no because he had the authority and the mandate. Founders have to develop that same ability to protect their team’s focus even when it means disappointing people.
Principle Seven: reward builders
Kelly’s original rule: “because only a few people will be used in engineering and most other areas, ways must be provided to reward good performance by pay not based on the number of personnel supervised”.
This is subtle but crucial. In traditional organizations, the way to advance is to manage more people. The path to higher pay is through bigger teams, more direct reports, larger org charts. This creates terrible incentives. People try to grow their empires even when the work doesn’t require it.
Kelly Johnson wanted to reward people for building things, not for accumulating headcount. A brilliant engineer who wanted to stay hands-on shouldn’t have to become a manager to advance their career. The individual contributor path should be just as prestigious and well-compensated as the management path.
This resonates deeply with me because I’ve never wanted to be a manager. I want to build things. The moment I’m spending more time in one-on-ones and performance reviews than in code or design or problem-solving, something has gone wrong.
At Omea, we think about this constantly. How do we create a structure where the best builders want to keep building? How do we avoid the trap where our most talented people get “promoted” into roles that take them away from what they’re best at?
The Skunk Works was full of people who could have been executives elsewhere but chose to stay in the trenches because that’s where the interesting work happened. Creating that kind of environment - where building is valued more than managing - is one of the hardest challenges for any organization.
The failure that taught me everything
I’ve been talking about these principles as if I’ve always followed them. I haven’t. And the biggest lesson of my career came from the time I ignored almost all of them.
ACR Systems - Advanced Cinema Robotics - was my Polish company. I built it starting in 2013, and I poured almost a decade of my life into it. We created innovative hardware for film and video production, camera stabilization systems and motion control equipment that ended up on movie sets around the world.
On paper, it was a success. We had products that worked. We had customers who loved them. We ran one of the most successful Polish Kickstarter campaigns of its time.
And yet I count ACR as a failure. Not because the company collapsed, but because it never achieved what it could have. Because I made mistakes that limited its potential, and those mistakes were almost all violations of Skunk Works principles.
Mistake one: wrong country. I built ACR in Poland because that’s where I was, and I told myself it didn’t matter. In the age of global commerce, you can build a hardware company anywhere, right?
Wrong. The film and video industry’s center of gravity is in Los Angeles. The investors who understand the space are there. The customers with the biggest budgets are there. The ecosystem that supports hardware startups is there. Building in Poland meant fighting against geography at every turn.
Kelly Johnson built Skunk Works in California because that’s where the aerospace industry was. Location isn’t just about logistics - it’s about being embedded in the ecosystem where your industry lives and breathes. I learned this lesson too late.
Mistake two: I didn’t build sufficient trust-based relationships. I worked hard. Insanely hard. Sixteen-hour days, seven days a week, for years. But hard work isn’t the same as working smart, and it’s definitely not the same as having the right people in your corner.
I needed advisors. I had some. I didn’t listen to them enough. When people with more experience tried to tell me things, I was often too busy executing to really hear what they were saying. The Skunk Works principle of trust and close cooperation requires actually trusting and cooperating - not just nodding along while you continue doing what you were already planning to do.
Mistake three: wrong co-founders. This one hurts to write because it’s so fundamental. The people you build with matter more than almost anything else. The wrong co-founders don’t just slow you down - they can destroy everything you’re trying to create.
I’m not going to go into specifics because that wouldn’t be fair to anyone. But I will say this: the Skunk Works principle of ruthlessly restricting who has access to the project applies to founders too. Not everyone who wants to be part of your journey should be part of your journey. Not everyone who has something to offer is the right fit for the trust-based, high-intensity, we’re-building-something-impossible environment that this kind of work requires.
I violated Principle One by not being ruthless enough about who was on the team. I violated Principle Three by building partnerships without sufficient trust. I violated Principle Two by diluting decision-making authority across people who didn’t share the same vision.
Mistake four: I underestimated the competition. When we started, Chinese manufacturers were making cheap knockoffs of Western camera equipment. The quality was poor. We could compete on quality.
Then the quality improved. The Chinese manufacturers weren’t just copying anymore - they were innovating. And once the quality gap closed, the price gap became insurmountable. We couldn’t compete with companies whose labor costs were a fraction of ours.
This isn’t a Skunk Works principle exactly, but Kelly Johnson understood something crucial: you have to build things that can’t be easily replicated. The SR-71 wasn’t just incrementally better than Soviet aircraft - it was a generational leap that took decades to approach. Building something that’s merely good isn’t enough when competitors can eventually copy it and undercut you on price.
ACR taught me that working hard isn’t enough. Being good isn’t enough. You need the right team, in the right place, building something that has defensible advantages, with trust-based relationships that help you navigate the inevitable challenges.
Every project I’ve undertaken since has been informed by those lessons. Every time I’m tempted to compromise on team composition, or to avoid having a hard conversation, or to build in a convenient location instead of the right location, I think about ACR and what it cost me to learn those lessons the hard way.
Building the impossible, over and over
After ACR, I could have played it safe. Taken a comfortable job at a big company. Built things that were guaranteed to work because thousands of people had built similar things before.
Instead, I went in the opposite direction. Each new project has been harder than the last. Not because I’m a masochist, but because life’s too short to build simple things. We’re here for a limited time. Might as well spend it attempting something meaningful.
Beyond Humanity was supposed to be impossible. A board game with a companion app, custom IoT electronics, and AI-driven gameplay. The game industry veterans we talked to said it couldn’t be done by a small team. We did it anyway, raised over $410K, and delivered a product that players love.
The lesson: Skunk Works principles work. Small team, ruthless focus, trust-based collaboration, shipping and iterating. We ignored the conventional wisdom about how games get made because conventional wisdom would have told us not to try.
Migam is attempting something even harder. Teaching AI to understand and generate sign language - not just one sign language, but multiple ones across different countries and cultures. The goal is to break down communication barriers for over 70 million Deaf people worldwide.
Working with Przemek Kuśmierek on Migam has been a masterclass in applying Skunk Works thinking to social impact. The technical challenges are immense. The resources are limited. The potential impact is transformative. It’s exactly the kind of “impossible” project that Kelly Johnson would have recognized - too important to not attempt, too hard for conventional approaches to handle.
And then there’s Omea.
Omea - formerly known as StoryWeaver - is my attempt to revolutionize interactive storytelling. We’re building an AI that doesn’t just respond to user choices but genuinely understands narrative. Not chatbot-style responses that feel like a game of Mad Libs, but actual stories that adapt and evolve based on what you do.
The technical approach was controversial. The standard way to build AI systems right now is agentic - multiple AI agents coordinating with each other, breaking down complex tasks into subtasks, creating layers of AI talking to AI. It’s the fashionable approach, and everyone’s doing it.
We went the opposite direction.
Instead of agentic architectures, we built an orchestration system based on zero-shot approaches. One model, carefully tuned, doing the work that others try to accomplish with swarms of agents. The result is something unique: better quality because we’re not accumulating errors across multiple agent interactions, better speed because we’re not waiting for agents to coordinate, better cost efficiency because we’re not running multiple models for every request.
It’s a bet against the prevailing wisdom. It might be wrong. But Kelly Johnson didn’t build the SR-71 by doing what everyone else was doing. He built it by having the courage to pursue unconventional solutions when conventional ones weren’t good enough.
Our proprietary Narrative Intelligence Architecture - what we call NIA - is based on over 155K carefully curated texts. It can maintain context across millions of tokens, which means it actually remembers what happened in your story and builds on it coherently. The voice-controlled interface lets you experience narratives without touching a screen, as naturally as having a conversation.
When people ask how a small team can compete with well-funded AI giants, I point to Skunk Works. Twenty-three engineers in a circus tent built America’s first jet fighter. A small team with the right principles, the right focus, and the right people can accomplish things that should be impossible.
The invitation
By now you’ve either decided I’m onto something or dismissed this as the ravings of someone who’s watched too many documentaries about Cold War aerospace programs. Either response is valid.
But if you’re still with me, I want to extend an invitation.
The Skunk Works methodology isn’t about aerospace. It’s not about defense contracting or classified projects or billion-dollar budgets. It’s about a set of beliefs regarding how exceptional work gets done. Small teams. Trusted relationships. Ruthless focus. Speed over perfection. Shipping things that work rather than documenting things that don’t exist yet.
These principles are available to anyone. You don’t need permission to apply them. You don’t need a certificate or a consultant or a three-day workshop. You just need to make different choices.
What would you build if you stopped waiting for the team to get bigger? Kelly Johnson built the XP-80 with twenty-three engineers. What could you accomplish with the people you have right now, if you stopped assuming you need more?
What would you decide if you stopped convening committees? The Skunk Works manager had complete authority. What decisions are you postponing because you’re waiting for consensus that will never come?
What would you ship if you stopped polishing? The Skunk Works delivered prototypes that flew, not requirements documents that satisfied reviewers. What could you get in front of users this week if you stopped waiting for everything to be perfect?
What would you attempt if you believed it was possible? The U-2, the SR-71, the F-117 - all impossible until they weren’t. What’s the project you’ve been dismissing as too hard, too ambitious, too crazy?
The world doesn’t need more safe bets. It doesn’t need more incremental improvements. It doesn’t need more startups that are slightly better versions of things that already exist.
The world needs Skunk Works thinking. People willing to attempt the impossible, equipped with principles that make the impossible achievable, and stubborn enough to keep going when conventional wisdom says to stop.
That’s what I’m trying to do with everything I build. That’s what I hope to help you do with everything I write here.
Be quick. Be quiet. Be on time.
And never, ever let anyone tell you that the thing you’re trying to build can’t be done.
Less talking, more building. See you next week.
Max
PS. Some acknowledgments are essential.
Everything I understand about the Skunk Works methodology comes first from Kelly Johnson himself - both his documented rules and his autobiography “More than my share of it all”. If you want to go deeper, Ben Rich’s “Skunk Works: a personal memoir of my years at Lockheed” is the definitive account of what it was like to work there. Rich was Johnson’s successor and writes with the perspective of someone who lived the principles I’ve described.
But principles only matter if you apply them, and I’ve been fortunate to work alongside people who embody Skunk Works thinking even if they’ve never heard the term.
Michał Pena has been my partner in crazy IT experiments for years. He’s now CTO at Omea, and there’s no one I trust more to translate impossible ideas into working systems. The trust-based collaboration that Kelly Johnson described - Michal and I have that. It makes everything possible.
Artur Kurasinski and Przemek Kuśmierek believed in my crazy ideas when believing in them was an act of faith. Przemek’s partnership on Migam has shown me what it looks like when two people are fully aligned on an impossible mission. Artur saw potential in StoryWeaver (former Omea) before it was anything more than a wild vision.
Tomasz Kolinko shares my approach to technology - extreme optimism and enthusiasm, grounded in hard work. Talking with Tomasz reminds me why I got into this field in the first place. The future is worth building, even when building it is hard.
And Justine. My wife. My biggest supporter and fan. She’s listened to me rant about Kelly Johnson and the SR-71 more times than any human should have to endure. She’s supported the late nights and the setbacks and the moments when the impossible felt truly impossible. None of this happens without her.
PS2. If you’re wondering what’s next - week 3 will be about the Hero’s Journey. Not the startup journey, though that’s part of it. The actual Hero’s Journey, the storytelling structure that’s been embedded in human culture for thousands of years, carved into our brains as a pattern we recognize instinctively. It’s the foundation of everything we’re building at Omea, and it’s the secret weapon for any founder who needs to make people care about their vision.
It’s also, I’ll warn you now, going to be long. The beast is becoming a pattern. Deal with it.
Awesome story! :)
Thanks, Max, for this one. Not the first time I hear this story, but this time seems like something clicked in my brain.
With my business partner, we created some products, conducted all sorts of weird projects, and put a ton of ideas off on the shelves.
And on one hand - my brain longs to order, having system for everything, tidy sheets, and mapped process. On the other - it feels like our way of doing things leans towards an approach mentioned in the post.
The one thing that needs to be underlined. We all need to be obsessed with quality and shipping. I've got a feeling that some of those principles can be a gateway to sloppiness and waste.
Waiting for more.