---
title: Rules Made Up by You
teaser:
tags: playbook
author: Matt Jankowski
published_on: 2008-06-10
---

![''](http://images.thoughtbot.com/ui/2008-6-10-9188.jpg "Kelly Johnson uses a
speaking device.")

[Kelly Johnson](https://en.wikipedia.org/wiki/Kelly_Johnson) worked at and was
one of the driving forces behind Lockheed Martin's [Skunk
Works](https://en.wikipedia.org/wiki/Skunk_works) group.  As part of an upcoming
project management book I've been writing (it's called SWARM, is meant for
managers of small teams of software developers, and has a picture of
[bees](http://images.thoughtbot.com/ui/2008-6-10-bees.jpg) on the cover), I've
been reading up and thinking about the business processes which are in place at
technology-but-not-software business, including the Skunk Works.

Aside from the success the team had building aircraft, I think they were rather
innovative in their organizational management as well, and I was inspired to
write this post when I ran into this gem - [Kelly's 14
Rules](http://www.lockheedmartin.com/aeronautics/skunkworks/14rules.html).

Reading over this list, I think that Lockheed's Skunk Works might be the agile
developers of the aerospace defense world&#8212;from 60 years ago.  I've
reproduced the list here with an identification of a modern software development
rule or business practice that it corresponds to..

1. 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.

    When we bid on a project for clients we explain that they are hiring us for
    a purpose and because of our expertise.  As a result: the more control they
    can give us, the better the solution that we deliver.

1. Strong but small project offices must be provided both by the military and
   industry.

    We have yet to do military work, but we do send people on site, and when we
    can get them in a small group with the client stakeholders, a lot can
    happen.  1.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).

    Too many cooks ruin the soup, and too many developers or managers ruin the
    software.  A small talented team will consistently out-produce an average
    team many times it's size.

1. A very simple drawing and drawing release system with great flexibility for
   making changes must be provided.

    Design driven development, with rapid iteration.

1. There must be a minimum number of reports required, but important work must
   be recorded thoroughly.

    Invoice based on trust, not paragraph-long line items.  Comment code only
    when it's crucial to a future developer trying to understand the problem.

1. 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.  Don't
   have the books ninety days late and don't surprise the customer with sudden
   overruns.

    Always keep the next milestone in sight, and always review whether you're
    still focusing on the larger business goal of the project.  Don't spent 40%
    of development time and money on a feature used by 1% of the audience.

1. 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.

    We've gone one step further here - and we refuse to subcontract for another
    vendor, or to hire a subcontractor when we're the primary vendor (we've
    learned our lesson on both fronts).  Commercial bids are almost always
    better than non-profit bids (including those for government or
    quasi-government entities)

1. 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.

    We attempt to maintain a set of code quality standards and development best
    practices which are literally **the best** in the industry.  We want to
    consistently exceed, by a large margin, any standards or policies that a
    client has in place.

1. 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.

    You must have a staging server that accurately represents the production
    server.  If you don't maintain your test suite, you **cannot** work with
    confidence as change requests come in.

1. 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.

    Implementation doesn't start until design is done.  Design doesn't start
    until a contract is signed.  A contract isn't signed until the spec is done.

1. Funding a program must be timely so that the contractor doesn't have to keep
   running to the bank to support government projects.

    Work on a milestone never begins if there is a past due outstanding invoice.

1. 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.

    Communication failures kill projects.  Daily scrum style meetings, or at
    least regular communication via an online tool is absolutely critical to
    project success.

1. Access by outsiders to the project and its personnel must be strictly
   controlled by appropriate security measures.

    Honor your NDAs.

1. 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.

    Hours worked, meetings held and emails sent are not metrics for success.
    Quality produced, milestones completed, and profit made are.

Finally, [according to wikipedia][rules], there's an
unwritten-but-sometimes-spoken 15th rule...

[rules]: https://en.wikipedia.org/wiki/Kelly_Johnson#Kelly_Johnson.27s_14_Rules_of_Management

> Starve before doing business with the damned Navy. They don't know what the
> hell they want and will drive you up a wall before they break either your
> heart or a more exposed part of your anatomy.

I'll leave that one as an exercise for any reader who has done client work to
negotiate for themselves.
