Kelly Johnson was an engineer at Lockheed who is famous for his leading role in designing over 40 aircraft. He was the leader of Lockheed’s Skunk Works programme, and it was here that he devised his 14 Rules and Practices for project work. Here we look at those 14 rules and see how they are still relevant today.
Who was Kelly Johnson?
Born in 1910, Clarence L ‘Kelly’ Johnson was a senior manager at the Lockheed Aircraft Corporation (LAC) during the Cold War. At LAC, he developed the Skunk Works programme, which has become the standard for high-risk, high-gain projects. As well as being a leader, Kelly Johnson was a renowned aeronautical and systems engineer. Kelly made a significant impact on a range of important aircraft designs, including the Lockheed U-2 and SR-71 Blackbird. He won the prestigious Collier Trophy twice: in 1958 for the F-104 Starfighter, and in 1963 for the A-11, the Mach 3 design that led to the SR-71 family. Kelly was also recognised for his contributions to the design of aircraft engines and systems. Kelly Johnson’s life and work provide a fascinating glimpse into the history of aviation. In addition, his 14 project management rules and practices are essential for anyone looking to be successful in project management.
The History of Skunk Works
Skunk Works is an official pseudonym for Lockheed Martin’s Advanced Development Programs (ADP), formerly called Lockheed Advanced Development Projects. Some of the most famous and groundbreaking Skunk Works projects include the SR-71 Blackbird and the F-117 Nighthawk. Lockheed Skunk Works was formed in 1943 when Kelly was asked to develop the first U.S. jet fighter to counter the (then) superior jets of the Luftwaffe. Johnson argued that the only way to get the job done quickly was to form a top-secret group outside Lockheed’s normal reporting lines. He formed a very small group of specially selected engineers and mechanics.
Skunk Works was an American success story. The term ‘Skunk Works’ has since been used to define any project shrouded in secrecy and focused on bringing innovative and cutting-edge technology to market quickly.
What are Kelly Johnson's 14 rules of Project Management?
Kelly devised 14 Rules and Practices at Skunk Works. Here they are in full:
- 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.
- Strong but small project offices must be provided both by the military and industry.
- 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).
- A very simple drawing and drawing release system with great flexibility for making changes must be provided.
- There must be a minimum number of reports required, but important work must be recorded thoroughly.
- 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.
- The contractor must be delegated and must assume more than normal responsibility to get good vendor bids for subcontract on the project. Commercial bid procedures are very often better than military ones.
- The inspection system as currently used by the Skunk Works, which has been approved by both the Air Force and Navy, meets the intent of existing military requirements and should be used on new projects. Push more basic inspection responsibility back to subcontractors and vendors. Don’t duplicate so much inspection.
- The contractor must be delegated the authority to test his final product in flight. He can and must test it in the initial stages. If he doesn’t, he rapidly loses his competency to design other vehicles.
- The specifications applying to the hardware must be agreed to well in advance of contracting. The Skunk Works practice of having a specification section stating clearly which important military specification items will not knowingly be complied with and reasons therefore is highly recommended.
- Funding a program must be timely so that the contractor doesn’t have to keep running to the bank to support government projects.
- 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.
- Access by outsiders to the project and its personnel must be strictly controlled by appropriate security measures.
- 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.
Kelly Johnson's 14 rules: rule-by-rule breakdown
Rule 1: Give the programme manager full authority
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.
Johnson insisted that the person running the programme must have the authority to make real decisions on budget, staffing, technical direction, and timelines without navigating layers of approval. Equally important, that person should report directly to someone senior enough to shield the programme from organisational interference.
At Skunk Works, Johnson reported directly to Lockheed’s president, Robert Gross. When the U.S. Army Air Forces asked Lockheed to build America’s first jet fighter in 1943, Gross gave Johnson the latitude to set up an entirely separate operation outside normal reporting lines, with its own engineers and mechanics. That direct line to the top meant Johnson could resolve blockers in hours rather than weeks.
For your PMO: This rule is a challenge to organisations that diffuse accountability across committees and boards. If your project manager needs sign-off from three different directors before approving a scope change, they end up being little more than administrators. The PMO’s role here is to advocate for clear delegation of authority and ensure that project leaders have genuine decision-making power, matched by a short reporting line to a sponsor who can remove obstacles.
Rule 2: Keep the project office small and strong
Strong but small project offices must be provided both by the military and industry.
Johnson applied this rule to both sides of the relationship: the contractor and the client. He didn’t just want his own team to be small; he demanded that the customer’s oversight team be equally lean.
A small, empowered project office on both sides creates a shared sense of urgency and eliminates the communication overhead that comes with large governance structures. On the U-2 programme in 1954-55, Johnson’s team of around 25 engineers worked directly with a tiny CIA project office led by Richard Bissell. There was no sprawling programme board, no multi-layered review process.
Decisions moved fast because both sides could fit in a single room. The result: the first U-2 was delivered for test flight within roughly eight months of the contract being signed.
For your PMO: Take a hard look at your governance structures. How many people sit on your project boards? How many layers exist between the delivery team and the person who can say yes? PMOs are often accused of creating governance that looks reassuring on paper but slows everything down in practice.
This rule is a reminder that governance should enable pace, not impede it. Reams of reports do not always equate to strong project governance.
Rule 3: Restrict the team ruthlessly
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).
This is Johnson’s most quoted rule, and for good reason. He wasn’t just saying “keep teams small.” He was saying that the right team size is dramatically smaller than most organisations would consider normal: perhaps a tenth of what you’d typically allocate.
The word “vicious” is a deliberate choice. It means actively resisting the pressure to add headcount, even when the work feels overwhelming. Johnson built America’s first jet fighter, the XP-80, with just 23 engineers and around 30 mechanics. In 143 days. Conventional wisdom at Lockheed would have called for ten times that number, and it would have taken ten times as long. The small team meant everyone understood the full picture, decisions happened through conversation rather than documentation, and there was nowhere for poor performers to hide.
For your PMO: Every person added to a project team is another node in the communication network, another person who needs to be informed, consulted, and aligned. As Belbin’s work on team roles suggests, effective teams are built around complementary strengths, not sheer numbers. When team bonding and group identity form quickly, which happens far more naturally in small groups, you get that sense of shared purpose that Johnson called “how we do things around here.“
When stakeholders pressure you to throw more people at a problem, push back. More people rarely means faster delivery.
Rule 4: Use a simple, flexible documentation system
A very simple drawing and drawing release system with great flexibility for making changes must be provided.
Johnson understood that documentation is a means to an end, not an end in itself. At Skunk Works, the drawing release system was deliberately lightweight: engineers could make changes to designs quickly without navigating a heavyweight change control process. The emphasis was on flexibility: the ability to iterate rapidly as new information emerged.
In practice, this meant Skunk Works engineers worked directly at the factory floor level. If a design change was needed, it could be sketched, approved, and implemented the same day. On conventional programmes, a comparable change might have required weeks of paperwork, review boards, and re-approvals. Johnson’s approach accepted that early designs would be imperfect and optimised the system for speed of learning rather than perfection of process.
For your PMO: This is not an argument against documentation or change control (despite how those around you may interpret it!). It’s an argument against disproportionate documentation: systems where the overhead of recording and approving a change exceeds the effort of making it. Review your processes honestly. For example, if a minor scope adjustment requires a written change request, impact assessment, board review, and formal sign-off before anyone lifts a finger, you’ve built a system that punishes responsiveness. The best PMOs design processes that are proportionate to risk: lightweight for small changes, rigorous for significant ones.
Rule 5: Minimise reporting, but record what matters
There must be a minimum number of reports required, but important work must be recorded thoroughly.
There are two halves to this rule, and most people only hear the first. Yes, Johnson wanted minimal reporting. But he also insisted that important work (decisions, test results etc) must be captured properly. The aim is to remove busy-work and focus on capturing what matters.
For your PMO: Reports are essential communication tools. But every hour someone spends writing a status update is an hour not spent on the actual work. Ask yourself: for each report your PMO, or project managers generate, who reads it, and what decision does it inform? If you can’t answer both questions, the report probably shouldn’t exist. Focus your reporting on what actually drives decisions, and strip out the rest.
Rule 6: Track costs monthly with forward projections
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.
When it comes to financial tracking, it should not just be backward-looking spend tracking, but forward-looking cost projection.
The Skunk Works had a reputation for delivering under budget (unusual in defence contracting!). Johnson once returned unused funds to the U.S. government on a programme codenamed Suntan when it became clear the technology wasn’t ready. That level of fiscal discipline starts with knowing your numbers, every month, without exception.
For your PMO: Monthly financial reviews with forecast-to-completion should be non-negotiable on every significant programme. Too many projects track what they’ve spent but don’t update their projections on where they’re heading. By the time someone notices the budget is in trouble, it’s already too late to course-correct. If you want to apply Johnson’s approach, insist on three numbers at every review: spent to date, committed but not yet spent, and estimated cost to complete. Then analyse the data to ensure that what’s been forecast has been updated with due consideration for what new information has come to light during the month, rather than simply repeating forecasts that were produced several iterations previously.
Rule 7: Take ownership of procurement
The contractor must be delegated and must assume more than normal responsibility to get good vendor bids for subcontract on the project. Commercial bid procedures are very often better than military ones.
Johnson had two points here. First, the delivery team (not a separate procurement department) should own the vendor relationships. Second, commercial procurement practices are generally faster and more effective than bureaucratic ones. He’d seen how military procurement procedures added months of delay without delivering proportionate value.
At Skunk Works, Johnson’s team dealt directly with suppliers. They knew what they needed, they understood the technical requirements, and they could evaluate bids on merit rather than procedural compliance. When the SR-71 Blackbird programme needed large quantities of titanium (which at the time was mostly supplied by the Soviet Union), Skunk Works set up shell companies to source the material. That kind of creative procurement doesn’t happen when purchasing is siloed away from delivery.
For your PMO: How much control do your project teams have over procurement? In many organisations, the answer is “almost none”: procurement sits in a central function with its own priorities and timescales. Johnson’s rule suggests that the people closest to the work should have meaningful influence over who supplies it and on what terms. The PMO can help here by working with procurement teams to create streamlined pathways for project-critical purchases, rather than routing everything through a one-size-fits-all process and supplier lists.
Rule 8: Push quality assurance to the source
The inspection system as currently used by the Skunk Works, which has been approved by both the Air Force and Navy, meets the intent of existing military requirements and should be used on new projects. Push more basic inspection responsibility back to subcontractors and vendors. Don't duplicate so much inspection.
Johnson observed that both the contractor and the client were often inspecting the same work: two teams checking the same components against the same standards. His solution was to push inspection responsibility back to the people who made the thing, and trust them to do it properly. Don’t layer inspection on top of inspection.
The Skunk Works inspection system was accepted by both the Air Force and Navy, which meant Johnson had earned the right to self-certify.
That trust wasn’t given freely though, it was built through consistent delivery of high-quality work. But once established, it eliminated a massive source of duplication and delay.
For your PMO: Duplicate quality checks are more common than most organisations admit. When the PMO reviews a deliverable, then the project board reviews it, then the client reviews it (with each applying slightly different criteria) you get delay without meaningful quality improvement. Consider where your quality assurance processes overlap and whether responsibility can be pushed closer to the source. This also connects to PRINCE2’s focus on products: define the quality criteria upfront, agree who is responsible for assurance, and avoid duplicating effort.
Rule 9: Let the builder test the product
The contractor must be delegated the authority to test his final product in flight. He can and must test it in the initial stages. If he doesn't, he rapidly loses his competency to design other vehicles.
If you separate the people who build something from the people who test it, the builders lose their edge. The feedback loop between making and testing is what drives learning. Break that loop, and you erode the team’s capability over time.
Every Skunk Works aircraft was test-flown by Lockheed’s own test pilots before being handed to the military. The XP-80’s first flight on 8 January 1944 was conducted by Lockheed test pilot Milo Burcham, not a military pilot.
This approach gave Johnson’s engineers direct, immediate feedback on what worked and what didn’t: feedback they could act on without intermediaries.
For your PMO: In a modern project context, this translates to keeping testing, user acceptance, and quality validation close to the delivery teams – not handing it off to testers operating at arm’s length. When developers or delivery teams never see how their work performs in the real world, they lose the context that makes them better at what they do. This is one of the principles that Agile delivery models get right: short feedback loops between building and validating, with the same team owning both.
Rule 10: Agree specifications upfront and be honest about non-compliance
The specifications applying to the hardware must be agreed to well in advance of contracting. The Skunk Works practice of having a specification section stating clearly which important military specification items will not knowingly be complied with and reasons therefore is highly recommended.
This rule has two parts that work together. First, nail down the specifications before work begins. Second, be explicit about which specifications you will not meet, and explain why.
Johnson didn’t try to promise everything. He actively documented what Skunk Works would not comply with and stated the reasons upfront. This honesty served two purposes: it managed expectations and it gave the team permission to focus on what actually mattered rather than chasing full compliance with standards that added no value.
For your PMO: How often do your projects start with genuinely agreed requirements? And how honest are your teams about what they can’t or won’t deliver? The pressure to say yes to everything is enormous. But Johnson’s approach suggests that deliberate, documented non-compliance (where a standard doesn’t add value for a specific project) is more professional than silent non-compliance or gold-plating. PMOs can support this by building honest scope discussions into project initiation, using techniques like MoSCoW prioritisation to separate what’s essential from what’s negotiable.
Rule 11: Funding without delay
Funding a program must be timely so that the contractor doesn't have to keep running to the bank to support government projects.
When funding approvals are slow or unpredictable, the delivery team burns energy managing cash flow instead of building things. In the worst cases, work stops entirely while people wait for purchase orders to be approved or budgets to be released.
The Skunk Works often started work on a handshake before formal contracts arrived. The XP-80 contract didn’t arrive until October 1943: four months after Johnson’s team had already begun building the aircraft.
That only works when there’s trust in the system though. For programmes that don’t have that luxury, delayed funding is one of the common causes of project failure.
For your PMO: This is a governance issue, not a finance issue. If your PMO runs a portfolio of projects and funding approvals routinely take weeks or months, you have a structural problem that needs addressing. Work with your finance team to establish pre-approved funding envelopes, stage-gate release mechanisms, or delegated authority limits that allow project teams to access money when they need it – not when the next board meeting falls in the calendar.
Rule 12: Build trust through close daily cooperation
There must be mutual trust between the military project organization and the contractor, with very close cooperation and liaison on a day-to-day basis. This cuts down misunderstanding and correspondence to an absolute minimum.
This rule is about the relationship between the delivery team and the client or sponsor. Johnson didn’t want weekly status meetings and formal correspondence. He wanted daily, face-to-face discussions.
When people work closely together every day, misunderstandings get caught and corrected in real time. The need for formal written communication drops dramatically because everyone is already aligned.
The relationship between Skunk Works and the CIA on the U-2 programme exemplified this. The CIA’s project liaison, Richard Bissell, maintained close and continuous contact with Johnson’s team. Problems were raised and resolved through direct conversation, not through letters and memos. This is partly why the programme moved so fast.
For your PMO: Trust between the delivery team and the business is the single most undervalued factor in project success. You can’t build trust through governance frameworks and status reports: you build it through consistent, honest, frequent interaction. If your project teams only speak to their sponsors at monthly steering meetings, the relationship is transactional, not collaborative. Encourage daily or weekly touchpoints, particularly during high-risk phases. And when things go wrong (because they will!) the trust you’ve built through daily cooperation is what allows you to recover quickly instead of descending into blame.
Rule 13: Control access to the project
Access by outsiders to the project and its personnel must be strictly controlled by appropriate security measures.
In its original context, this was literally about security clearances and classified information. Skunk Works built some of the most sensitive military assets of the Cold War: the U-2, the SR-71, and the F-117 Nighthawk. Keeping outsiders away was a matter of national security.
But there’s a broader project management principle here too. Johnson understood that every person who gains access to a project becomes a potential source of interference, distraction, or scope creep. The more people who can wander into meetings, request information, or offer opinions, the harder it becomes to maintain focus and momentum.
For your PMO: Your projects probably don’t involve classified aircraft. But the principle still holds. Think about your stakeholder landscape. How many people have informal access to your project teams, with the ability to drop in with requests, questions, or “just a quick thought”?
Uncontrolled access is a hidden productivity drain. The PMO can help by establishing clear stakeholder engagement boundaries, defining communication channels, and protecting delivery teams from well-meaning but disruptive interference. A RACI matrix is a practical tool here: it makes explicit who needs to be involved and, just as importantly, who doesn’t.
Rule 14: Reward performance, not headcount
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 final rule is often overlooked, but it’s the one that makes all the others sustainable. If you want small teams of excellent people (Rule 3), and you want those people to stay (Rule 1), you need to reward them for the quality of their work – not for how big their project teams are. In most organisations, the path to higher pay runs through management: the more people you supervise, the more you earn. Johnson saw that this creates a perverse incentive to grow teams, which directly contradicts everything else he stood for.
At Skunk Works, engineers were paid for their contribution to the programme, not for their position in a hierarchy. A brilliant engineer with no direct reports could earn more than a middle manager overseeing a larger but less critical team. This attracted and retained the kind of talent that made Skunk Works exceptional.
For your PMO: This rule is a direct challenge to the way most organisations structure career progression and compensation. If the only route to a pay rise in your organisation involves managing more people, you will inevitably end up with bloated teams and talented individual contributors who leave for organisations that value them. PMOs can influence this by advocating for dual career tracks: one for management, and one for technical and specialist expertise. The other way is to recognise individual contribution in project performance reviews and ensure standout performers are recognised in their personal reviews.
The unofficial 15th rule
Johnson passed a fifteenth rule on by word of mouth rather than committing it to paper. As recorded by his successor Ben Rich in Skunk Works: A Personal Memoir of My Years at Lockheed (1994), it was characteristically blunt: never do business with the Navy. Johnson’s frustration was rooted in experience. The Skunk Works thrived on clients who knew what they wanted and could make decisions quickly: the CIA on the U-2 programme being the gold standard. The Navy, in Johnson’s view, was the opposite: unclear requirements, shifting priorities, and a procurement culture that ground momentum to a halt. Rich learned the hard way when he ignored Johnson’s advice and took on a naval stealth ship project, the Sea Shadow, which proved far more painful than any Air Force or CIA programme.
For PMO practitioners, the underlying lesson isn’t really about the Navy. It’s about client selection. Not every stakeholder, sponsor, or customer is ready to work in the way your project needs them to. If the client can’t define what they want, can’t empower a decision-maker, or insists on layering process on top of process, even the best project team will struggle. At the stage in your pipeline when decisions are made about which projects to run with, ensure the decision is not only based on the financial metrics. Consider alignment and other factors too. Sometimes the bravest decision is to walk away from work that will consume your team without producing results.
Applying Kelly's 14 rules and practices for project work
Kelly forged his rules eighty years ago. But they still hold today.
Firstly, there is an emphasis on keeping teams small (rules 2 and 3). Every person that gets added to a project team is another person who needs to be informed of progress and consulted for decision-making. Large groups have greater complexity and can be slower to make decisions and respond to change. Another factor to consider here is team culture. When you form a project team, it is common to develop a way of working that makes the project unique. It is often described simply as ‘how we do things around here.’ Team bonding and group identity are formed much more rapidly and organically in small groups than in large, sprawling teams.
Bringing people together for meetings can be hugely beneficial. Innovation and collaboration thrive when people are together. Also, meetings ensure teams are aligned and understand the bigger picture. But too many meetings can be counterproductive. The same is true of reporting. Reports are essential communication tools. But reporting is time-consuming, and people who are writing reports are not focused on developing project deliverables! On your projects, strike a balance between what is necessary and what is not. Keep reporting to an absolute minimum while ensuring teams have close cooperation and communication. The 13th rule strictly controlled access by outsiders. While your projects may value transparency over secrecy, it is still essential to understand your stakeholders and decision-makers. It is often worth creating a RACI matrix to understand which groups of people need to be informed and consulted while avoiding other parties adding noise and becoming a distraction.
If your project uses contractors and third parties for their expertise, make sure you delegate them sufficient authority to succeed. There is nothing more frustrating for consultants to be engaged for their specialist expertise, only to find themselves hamstrung by overzealous controls and micromanagement. If you bring in experts – treat them as such, and delegate them enough responsibility to get the job done.
Finally, manage upward and actively prevent organisational processes and decision-making boards such as steering groups and financial approvers from impeding the creative development process. Be mindful of upcoming decision points and budgetary checkpoints and do everything you can to avoid these becoming blockers for the team.
Kelly's rules as a precursor to Agile
Many in the world of software development view Agile methods as something modern. However, we can see clearly that many of Johnson’s project rules and practices were similar to some of the principles and techniques applied in modern agile frameworks. For example, at Skunk Works, small teams collaborated and developed iteratively. Documentation was kept to a minimum, and authority was delegated to the team. Long before a group of consultants got together in a ski resort and wrote that Agilists should “Respond to change over following a plan,” Johnson was already advocating release systems with great flexibility for making changes. We have spoken previously on this site about the waterfall vs. agile fallacy. Still, it is worth reminding ourselves that the idea that before Agile came along, the world was following a five-step waterfall model is inaccurate. Much can be learned from delivery methods deployed before the creation of the Agile Manifesto in 2001.
The table below maps each of Kelly’s rules to the Agile principle, or Lean concept it most closely echoes. Not every rule has a direct equivalent, and we’ve noted where Johnson’s thinking goes further than (or diverges from) modern frameworks.
| Rule | Kelly Johnson’s Rule (summary) | Agile Manifesto Parallel | Lean Equivalent |
|---|---|---|---|
| 1 | Give the programme manager full authority | “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” | Empower the team at the point of value creation |
| 2 | Keep the project office small and strong | Small, cross-functional teams (Scrum teams of 5–9 people) | Eliminate waste: remove unnecessary management layers |
| 3 | Restrict the team ruthlessly | “The best architectures, requirements, and designs emerge from self-organising teams.” | Respect for people: small, capable teams with end-to-end ownership |
| 4 | Use a simple, flexible documentation system | “Welcome changing requirements, even late in development.” Also: working software over comprehensive documentation. | Flow: reduce batch sizes and handoffs to accelerate delivery |
| 5 | Minimise reporting, but record what matters | “Working software is the primary measure of progress.” Value outcomes over documentation. | Eliminate waste (muda): unnecessary documentation is overprocessing |
| 6 | Track costs monthly with forward projections | No direct parallel. Agile tracks velocity and burndown rather than cost. This is a gap in Agile thinking. | Value stream mapping: understand the full cost of delivery, not just throughput |
| 7 | Take ownership of procurement | “Customer collaboration over contract negotiation.” Favour working relationships over rigid procurement processes. | Build supplier partnerships: long-term collaboration over transactional purchasing |
| 8 | Push quality assurance to the source | “Continuous attention to technical excellence and good design enhances agility.” | Build quality in (jidoka): don’t inspect quality in after the fact |
| 9 | Let the builder test the product | “Deliver working software frequently.” Short feedback loops between building and validating. | Fast feedback: shorten the loop between production and validation |
| 10 | Agree specifications upfront; document non-compliance | Partial tension. Agile favours evolving requirements, whereas Johnson fixed specs early. But both value honesty about what will and won’t be delivered. | Set-based design (SBD): define constraints early, narrow options progressively |
| 11 | Fund the programme on time | “Agile processes promote sustainable development.” Sustainable pace requires stable funding, not just stable hours. | Flow: funding delays are a form of wait waste that blocks the value stream |
| 12 | Build mutual trust through close daily cooperation | “Business people and developers must work together daily throughout the project.” Also: “Face-to-face conversation is the most effective method.” | Go to the gemba: leaders and stakeholders engage directly where work happens |
| 13 | Control access to the project | No direct parallel. Agile generally favours transparency and open access. This is a genuine divergence. | Limit work in progress: protect the team’s focus from external disruption |
| 14 | Reward performance, not headcount | “Build projects around motivated individuals.” Motivation requires recognition and reward aligned to contribution. | Respect for people: value expertise and contribution over organisational rank |
There are many parallels, but some differences too. Johnson was more directive than the Agile Manifesto’s authors. He fixed specifications early (Rule 10) where Agile embraces change, and he restricted access (Rule 13) where Agile promotes transparency.
He was also more explicit about financial discipline (Rule 6) than Agile has ever been.
These aren’t weaknesses in either approach. They reflect the reality that Johnson was building physical aircraft under classified military contracts, while the Agile Manifesto was written for software teams operating in commercial markets.
The underlying instinct: small teams, empowered people, minimal bureaucracy, and fast feedback is the same. The context shapes how those instincts are expressed.
How HotPMO uses this in practice
We reach for Kelly’s rules when a PMO is standing up a small, high-trust delivery team and needs governance stripped back to what actually matters. The rule about limiting outside interference maps directly onto ring-fencing a tiger team from the rest of the portfolio’s reporting cycle, and the rule on delegated authority is the one PMOs most often get wrong: asking for expert input, then still insisting on sign-off at every step. Where a programme needs pace over process, this is often the starting point for our PMO consultancy work.
Conclusion
Kelly Johnson wrote his 14 rules in the 1940s, in a rented circus tent that smelled of plastics, while building aircraft that would reshape the Cold War. More than eighty years later, those rules still stand out. They predate the Agile Manifesto by half a century, yet they echo the same instincts: small teams, empowered people, minimal bureaucracy, and fast feedback.
The reason they endure is that they aren’t really about aircraft, or software, or any particular industry. They’re about how teams do their best work with clarity of purpose, trust, and the freedom to focus on what matters.
Whether you’re running a PMO, leading a digital transformation, or standing up a new project team, Johnson’s rules offer a useful sense-check: have you given your people the authority to succeed, or have you buried them in governance?