Category Archives: insights

kelly johnson’s 14 rules of management

Johnson’s famed ‘down-to-brass-tacks’ management style was summed up by his motto, “Be quick, be quiet, and be on time.” He ran Lockheed’s Skunk Works by these 14 rules.

Kelly’s 14 Rules:

  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.
  2. Strong but small project offices must be provided both by the military and industry.
  3. 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).
  4. A very simple drawing and drawing release system with great flexibility for making changes must be provided.
  5. There must be a minimum number of reports required, but important work must be recorded thoroughly.
  6. 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 90 days late, and don’t surprise the customer with sudden overruns.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. Funding a program must be timely so that the contractor doesn’t have to keep running to the bank to support government projects.
  12. 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.
  13. Access by outsiders to the project and its personnel must be strictly controlled by appropriate security measures.
  14. 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.

Note that Kelly had a 15th rule that he passed on by word of mouth. According to Ben Rich’s book Skunkworks, the 15th rule is: “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.”

please stay home next week tuesday

if you’re undecided. If by now, with a week left, you haven’t picked who you’re going to vote for as President (and I almost don’t care who you pick [I do, but that’s another story]), don’t vote.

I’d like to tell you to vote for the guy I want to win, but I don’t like even most of the third, fourth, and ninth party candidates this year.

I’m going to write-in, as long as I can get back to the state to vote on time.

But honestly, if after the past two years of campaigning you haven’t been able to make up your mind, you shouldn’t vote – or you should write yourself in.

i love traveling

I hate not being home.

I travel for a living now, performing site installations, upgrades, customizations, and on-site support for our customers. The travel’s a blast – see new places, try new food, drive different car. But not being home except weekends does kinda cut into one’s social activities.

At this point, I wouldn’t trade the type of work I’m doing, unless someone offered me large piles of green paper, but I’d like a little more notice than just a few days (sometimes less!) before hopping on a plane and heading out to another customer.

Even 2 weeks would be nice (which is supposedly the minimum time we’re allowed to book travel etc for work anyways). That’s happened once so far, in 3 months of being in the job.

On the other hand, you all get to find about great places to eat all over the country 🙂 .

queuing the next generation

Like many people, I work for an under-staffed segment of a remarkably under-staffed company.

Before transitioning to professional services, I worked for support, and they are even more under-staffed.

I see a simple solution to this problem, but the company is too short-sighted to implement anything like this, sadly.

Problem: We need new people. Desperately. Especially in support, though we will need more in professional services, too.

[My] Solution: Establish an on-going co-op/intern program to bring new ideas, young people, and energetic minds to bear on the issue of handling customer service.

How can this be done? I think it’s a combination of trust and energy on the part of the management of the company: they need to be willing to trust people without “experience” to learn how to do the job, and that means they need to expend energy on aggressive recruiting of new talent.

I think the best way to start this is to go to local colleges and trade schools (including tech and community colleges) and look for people who actually want to work. There are certainly a lot of students who don’t want to work. And there are certainly a lot of students who won’t want to do what you need them to.

But I will maintain that there is a notable subset of students (even if they are not in “related” majors) who are both willing and able to handle the high-stress, interrupt-driven environment of technical support. And those are the folks you (we) need to find and recruit to handle your (our) technical support backlog.

One way to do this would be to hire them on as full-time, but hourly workers, and pay for up to 9 or 10 credits per semester at the school they are attending. This will give them an incentive to continue their education (after all, their employer is paying for it), and to want to stick around with the company when they’re done with school. Pay them, say, $20k per year, but cap their weekly hours at 40. Make sure they go home when the day is done so they don’t burn out. With the company paying for their school, it might take an extra year for them to graduate, but when they do, they’ll have both experience, and – probably – a desire to continue working for the company that helped them through.

The big selling point on this, though, needs to be that you only recruit outstanding sophomores, juniors, and seniors. Too many freshmen don’t know what they want to do, nor do they tend to have the drive – yet – to get to where they want to be. The other component needs to be to at least annually, if not semi-annually, issue 5-10% raises for those folks who are performing well – as a further incentive for them to want to continue.

The big advantage for the company is that when those students graduate, they’re very well trained of the company’s product(s) and procedures. This makes bringing them onboard as “real” technical support personnel much easier as their need not be a long orientation and familiarization period.

Unfortunately for where I work, though, the company is too focused on this quarter to worry about how they can improve the next decade.

preparing for change (part the second)

As with knowledge capture, so must any successful organization pursue training.

Training need not be formal. It can be self-paced, on-the-job, as-you-go, or formal. I know that I have learned the most about the product I support not from formal training, but from actually supporting it.

Part of that is because we have had a tribal knowledge base, that needs to be captured. But part of it is because what we do varies from customer to customer, based on their environment.

Training must also be focused to the folks who will be undergoing it. Some people learn by doing, others by reading, others by hearing. An effective training program in bringing new people up to speed must, then, combine all of those methods. But training cannot last too long as individual sessions. It would be better to have 1-2 hours of training per day, a couple days a week for 3 months than to have it all in one week, 8 hours a day.

preparing for change (part the first)

I have recently been preparing to change jobs within my company from Support to Professional Services. This has lots of caveats, concerns, and corners to shine light into, alleviate, and circumvent.

The first thing that I did when I found out that I would, in fact, be able to move to ProServe from Support was to review all the cases I have had over the past year for commonalities, how-tos, and troubleshooting material. I have been working supporting a very complex server management product since January of last year, and I’ve had a lot of cases in that time.

One of the things I started to discover as I went through my case history was that customers end up having similar issues, but may report them with different symptoms. Like having the flu, where symptoms include fever, nausea, dehydration, dizziness, and more, one core problem can manifest itself in many ways.

So, in reviewing every case I have had in the last year, or at least those that are still ‘owned’ by my user, I was able to generate about 40 articles for other folks in Support to use in diagnosing similar issues in the past.

The core of any organization should always be knowledge transfer. In the company I work for, however, most of that knowledge transfer has been done verbally – so between all of us we know the product, but it’s tribal: if one person leaves, everything they know walks out the door with them.

Knowledge capture, then, must be a priority for any organization. Knowledge base articles, wiki pages, cheat-sheets on a shared server – something must be done to adequately snag everything those involved with the group both know and need to know.

Like the famous Microsoft developer’s conference video chants, “Developers, developers, developers, developers!”, so, too, must any organization chant, “Knowledge capture, knowledge capture, knowledge capture!”

computers were made for americans

Or at least, they were built for people who speak English.

Evidence for my claim: the first electronic computers were built during WWII by the British and Americans for code breaking; the first programming languages were designed, written, and implemented by Americans and British; the transistor, which led to the IC, was developed by Americans; the integrated circuit was designed by Americans; the Internet project was funded by the Defense Advanced Research Projects Agency (DARPA); Tim Berners-Lee was born and raised in England, and invented the World Wide Web.

Most programming languages are written from left-to-right. Interfaces are designed to be read and processed from left-to-right.

I wonder how different computers and interfaces would appear if they had been originated in a non-English-speaking country, or non-Western culture?

Would they seem more intuitive to us, or less? Would they be easier to use, or less? Would countries like China be leading the world in technology, with the US being some kind of feeder economy if computers had been invented elsewhere?

What do you think might be different if computers hadn’t been invented for Americans?