Are you a Consultant or Contractor? Score Yourself Against these “Patterns of Successful Contractors” from a 1963 Leadership Masterpiece

I am a fan of the Jocko Podcast. Over the past few months I have been listening to the episodes on General Bruce C. Clarke’s 1963 book, Guidelines for Leaders and Commanders. I highly recommend this series to anyone in a leadership position. This series is also valuable for contractors and consultants, many of whom act as technical leaders for their clients or are lead their own small team of employees and/or subcontractors.

Jocko’s coverage of the book extends across six episodes, starting with episode 251. There are countless gold nuggets of information contained in this book and in these discussions, so I’ve had to listen to each episode 2–3 times to absorb everything. The book is currently out of print, but I hope that either Stackpole or Jocko Publishing puts out a new edition soon so that I can get my hands on a physical copy.

Note: The U.S. Army has collected a few excerpts from pamphlets and speeches which will give you some insights into General Clarke’s ideas. Since originally writing this article, there has also been a re-release of General Clarke’s book

In episode 253 (starting around 32:40), Jocko relayed General Clarke’s notes on what makes a successful general contractor. As a consultant and contractor myself, I am naturally drawn to these ideas. Here are the notes that I thought pertinent to share with you. I have added my own emphasis below.

The Patterns of Successful Contractors

General Clarke relays these ideas from his graduate work in Civil Engineering. The head of a prominent and successful general contracting firm spoke to the students “about what made a contractor successful, or, really, what kept him from going broke.”

If you’re going into a new area and want to find the most astute individual, look for a contractor who has stayed in business for 10+ years. “If you analyzed his methods of operation, this is what you would find undoubtedly:”

  • He collected and kept up to date on detailed costs
  • He had his staff available to him as needed, with expert advice in the fields of engineering, finance, purchasing, taxation, law, etc., and he used them
    • Phrased another way: he had experts on staff and actually talked to them when he needed them and actually put their advice into practice
  • He had competent foremen (aka managers, front-line leaders) and took the time to orient and train them
  • His relations with his work force were good, so that his turnover was small
  • He provided key personnel with steady work
    • This one especially hit home for me. I’ve always left jobs that left me idle for any length of time
  • He obtained good equipment and kept it operating through a positive program of inspection, maintenance, and operator training
  • He understood the problems created by special conditions such as storms, weather, temperature, seasons, flood, climate, and estimated and planned around them
    • Examples here are relevant to construction, but the embedded field also has its own seasonality and exceptional conditions
  • He had a good supervision and inspection setup to ensure quality, prevent delays, and quickly overcome unforeseen obstacles and to ensure acceptance without costly adjustment or doing over
  • His plans always reflected much thought in economical methods of construction
  • Most of all, he was an expert on timing in that he programmed the flow of the following [items] to the job at proper times, in proper amounts, with proper specifications and proper quality, in order that none [of these items] was overlooked, work was not delayed, and none [of these items] arrived too early and too much or too little:
    • Cost data
    • Plans
    • Decisions
    • Layout of the area
    • Flowcharts
    • Supervision setup
    • Inspections
    • Financing
    • Workforce
    • Field offices
    • Field storage
    • Power and light requirements
    • etc.

Jocko’s summary of this last point: Make a list of what’s important and take care of it!

Analysis

I don’t have to stretch my mind to recognize how these ideas are relevant to success as a technical embedded consultant or contractor.

First, being aware of what is actually going on in your business is key to survival. I have known many contractors who do not track key metrics for their business, defer bookkeeping until there is a monstrous pile of receipts, and don’t have a good system for tracking outstanding tasks or the location and status of assets. I have rarely known contractors in our industry who perform regular inspections of their equipment (including non-physical items like source code, programs, and services) and have processes in place to ensure they are in good working order before a new project kicks off. I have been guilty of this myself, losing valuable time during a project while fighting with VMs, software problems, poor soldering iron tips, and broken debugging hardware. But I’ve learned that lesson and put these processes into place.

A general bent toward disorganization impacts you in other ways. While we earn the ability to create and execute detailed plans through experience, we can greatly improve our planning abilities through detailed record keeping. With detailed records for each job you’ve performed, you can improve your planning accuracy and begin to notice patterns across jobs. You will notice common “special conditions”, missing process steps, or errors in judgment that cause project delays, allowing you to preemptively put in place risk mitigations or adjust your schedule.

The note about special conditions, particularly with respect to seasonal impact, really stands out during this holiday season. Every year, we receive a flood of requests for urgent assistance starting around mid-November, right when the U.S. is heading into Thanksgiving (2–5 days off) which is followed soon after by Christmas (1–5 days off), and New Year’s (1 day off). This is a popular time to take long vacations, because people often travel to visit their extended families. Some people with significant accrued vacation time will even leave for Thanksgiving and not return to work until January. Even though this happens every year, there are managers who panic because they suddenly realize that a particular project or task won’t be completed before the year’s end as planned.

This same pattern of behavior also seems to occur every year before Chinese/Lunar New Year. Everyone suddenly rushes to place new part orders and squeeze in manufacturing runs before all of China effectively shuts down for at least two weeks. If only these events happened every year and could be accounted for in the schedule!

Another point that jumps out is that you cannot do it all yourself: you need to build a team, enable them, and rely on them. You need to work to shore up your own deficiencies by relying on specialists and experts – even if it means working with external firms and subcontractors. We all naturally tend to do this for legal and accounting support, but we often overreach and try to do it all ourselves when it comes to the technical work.

I want to close by diving into these points:

  • He had a good supervision and inspection setup to ensure quality, prevent delays, and quickly overcome unforeseen obstacles and to ensure acceptance without costly adjustment or doing over
  • His plans always reflected much thought in economical methods of construction

In most software projects we’ve worked on, we have seen the opposite of these recommendations. Many teams will often choose the non-economical option of building things in house instead of purchasing a suitable solution (the “not-invented-here syndrome”), causing increased cost, risk, and schedule delays. Schedules are often created through magical thinking, where the team sets a target release date (often based around holiday sales) and fails to account for the amount of work that needs to be done, problems that could arise, or the project’s unknowns. Rather than focusing on software quality from the start, the initial goal is to get a “working system” completed as quickly as possible, and then shift the focus to quality during a “clean up” sprint before release. Often, this is justified through the use of over-the-air (OTA) software updates, as management expects that customers will report bugs and the team will quickly release updates to eliminate them.

We’ve watched these approaches sink multiple products. Magical schedules rarely work. Quality cannot be achieved simply by eliminating bugs. Outstanding problems that are deferred to the end of the product development cycle still end up delaying the customer ship date, especially if they necessitate large-scale rework operations. Customers are not happy nor understanding when the fancy expensive product they purchased is full of problems, and frequent updates only annoy them further.

Many employees often remark to us that it’s “just the way this industry is”. What does a delay cost except time-to-market and a few stressful months anyway? But from a business perspective, this pattern is dangerous. It is also illogical to knowingly take this approach. Sometimes, especially as a startup, you simply cannot recover from the wasted time, money, and reputation hit you endure from this type of approach.

The dangers associated with delays and quality problems are even greater for contractors and consultants than they are for our clients. Our clients will not give us the same leeway that they give their internal development team when things go wrong. We will be blamed, and quite harshly at that. We will lose valuable time and money in order to rework the deliverable for free. Or we will take a hit on other projects by suddenly needing to delay them in order to make another job right. At the very least we will take a hit to our reputation, and we will not receive testimonials and referrals – the lifeblood for consultants and contractors. After too many hits like this, you’re going to have a tough time finding new business.

It is better to keep in mind the advice that General Clarke relays – make plans with the most economical approach in mind, and do what is necessary to ensure quality, prevent delays, overcome obstacles, and ensure our work is accepted without rework. Because, as Seth Godin points out:

If you don’t have time to do it right, what makes you think you’ll have time to do it over?

Further Reading

Share Your Thoughts

This site uses Akismet to reduce spam. Learn how your comment data is processed.