In 1943, Kelly Johnson built a team inside Lockheed that would change aerospace forever. Working from a circus tent next to a plastics factory, they designed and built America's first jet fighter in 143 days. The smell from the factory inspired the nickname: Skunk Works.
Johnson ran his operation by 14 rules. Rules about autonomy, about small teams, about cutting bureaucracy. Rules that let a handful of engineers outpace organizations a hundred times their size.
We're not building jet fighters. We're building WordPress plugins. But the principles that made Skunk Works legendary apply just as well to software as they did to aircraft.
This is how we operate.
1. Own Your Vision
“The Skunk Works manager must be delegated practically complete control of his program in all aspects.”
At Skunk Global, there are no committees designing products by consensus. No stakeholder meetings watering down features. No approval chains slowing decisions.
One person owns the vision for each product and has the authority to execute it. This isn't about ego. It's about speed and coherence. When you know exactly what you're building and why, you can move fast without second-guessing every decision.
The buck stops here, and that's exactly how it should be.
2. Focused Environment
“Strong but small project offices must be provided both by the military and industry.”
Deep work requires a dedicated space, physical and mental. We don't build products in the gaps between meetings or while context-switching between twelve different projects.
Focused blocks of uninterrupted time are sacred. Slack notifications are muted. Email can wait. When it's time to build, we build.
The environment shapes the output, so we shape the environment for building great software.
3. Small Team
“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.”
More people doesn't mean better products. It means more coordination overhead, more meetings, more miscommunication, more compromise.
A small team of excellent people will outship a large team of average ones every time. We'd rather have one person who deeply understands the problem than five who sort of get it. This isn't about being cheap. It's about being effective.
Small teams move fast, make decisions quickly, and build coherent products.
4. Ship & Iterate
“A very simple drawing and drawing release system with great flexibility for making changes must be provided.”
We don't spend months perfecting features in isolation. We ship early, learn from real usage, and iterate.
Our systems are designed for change, because requirements always change, users always surprise you, and the market never stands still. Flexibility isn't a nice-to-have; it's survival.
A simple, adaptable codebase beats an over-engineered one that's afraid of change.
5. Build Don't Talk
“There must be a minimum number of reports required, but important work must be recorded thoroughly.”
Every hour spent in meetings is an hour not spent building. Every status report is time not spent shipping. We minimize bureaucracy ruthlessly.
But we're not careless. Important decisions get documented. Key learnings get recorded. Code gets commented where it matters.
The goal is maximum building, minimum talking about building. If a process doesn't directly help us ship better products, it gets cut.
6. Know Your Numbers
“There must be a monthly cost review covering not only what has been spent and committed but also projected costs to the conclusion of the program.”
Financial clarity isn't optional. It's oxygen. We know exactly what we're spending, what we've committed to, and what the runway looks like.
No surprises. No “we'll figure it out later.”
Monthly reviews keep us honest and help us make informed decisions about where to invest and where to cut. A sustainable business requires sustainable finances, and that starts with knowing your numbers cold.
7. Right Tools
“The contractor must be delegated and must assume more than normal responsibility to get good vendor bids for subcontract on the project.”
Every dependency is a decision. Every library, every service, every tool we rely on becomes part of our product.
We choose dependencies carefully, favoring simple, proven, well-maintained options over shiny new ones. We'd rather use boring technology that works than cutting-edge tech that breaks.
When we do need external tools, we evaluate them like we'd evaluate a hire: will this make us better or just add complexity?
8. Trust the Ecosystem
“Push more basic inspection responsibility back to subcontractors and vendors. Don't duplicate so much inspection.”
We build on WordPress because it works. We don't rebuild authentication, we don't rebuild database abstractions, we don't rebuild what the ecosystem already provides well.
Our hosting partners handle infrastructure. WordPress core handles content management. We handle the product layer that makes our tools unique.
Reinventing the wheel isn't innovation. It's waste. Focus on what only you can build.
9. Eat Your Own Cooking
“The contractor must be delegated the authority to test his final product in flight. He can and must test it in the initial stages.”
We use our own products every day. SkunkCRM manages our contacts. SkunkForms captures our leads. If we won't use it, why would anyone else?
Dogfooding isn't just about finding bugs. It's about understanding the user experience from the inside. When something frustrates us, we fix it. When something delights us, we double down.
You can't design great products from a distance.
10. Clarity First
“The specifications applying to the hardware must be agreed to well in advance of contracting.”
Before we write code, we know what we're building and, just as importantly, what we're not building.
Scope creep kills projects. Unclear requirements create wasted work. We define success criteria upfront, document deliberate omissions, and resist the temptation to add “just one more thing.”
Clarity at the start prevents chaos at the end.
11. Self-Funded
“Funding a program must be timely so that the contractor doesn't have to keep running to the bank to support government projects.”
We're not running to VCs for runway. We're not dependent on the next funding round to survive. Revenue funds development. Customers, not investors, are our stakeholders.
This means we can say no to bad deals, take our time on important decisions, and build for the long term instead of the next board meeting.
Independence isn't just nice to have; it's how you build something that lasts.
12. Mutual Trust
“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.”
We treat customers like partners, not ticket numbers. When you reach out, you get a real person who knows the product and cares about your success.
Trust goes both ways. We trust our customers to give us honest feedback, and they trust us to actually listen. Close relationships mean we understand real problems, not just symptoms.
It also means less back-and-forth, less misunderstanding, less frustration on both sides.
13. Build Before You Announce
“Access by outsiders to the project and its personnel must be strictly controlled by appropriate security measures.”
We're not here for the spotlight. No chasing podcast appearances, no angling for conference keynotes, no building a personal brand on the back of products that don't exist yet.
The original Skunk Works built in secret because secrecy enabled speed, and because the work mattered more than the recognition. We operate the same way: heads down, building.
We don't need to be honored on stage or featured on screen. We just want to build software that doesn't stink. You'll know we're doing our job when the products speak for themselves.
14. Results Over Empire
“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.”
In most companies, success means managing more people. That's backwards.
At Skunk Global, success means shipping great products, not building an empire. We reward results: products shipped, problems solved, customers helped. Not headcount grown, meetings attended, or org charts expanded.
The goal is impact, not influence. Quality of output, not size of team.
Why This Matters
Most software companies optimize for growth. They raise money, hire fast, ship features to hit metrics, and hope the business model figures itself out later. Sometimes it works. Usually it doesn't.
We're optimizing for something different: building tools that actually help people, sustainably, for the long term. Tools that creatorpreneurs (the freelancers, the solo founders, the small teams) can rely on without getting locked into enterprise pricing or abandoned when the VC money runs out.
These 14 principles aren't aspirational. They're how we actually work. Every day, every decision, every line of code.
Kelly Johnson proved that a small team with the right principles could outbuild organizations a hundred times their size. We're betting that's still true.
And if these principles resonate with you, maybe you're the kind of person we're building for.