In 1975, computer architect Fred Brooks published a series of essays on software engineering and project management called “The Mythical Man-Month”.  These cautionary tales and inevitable realities not only stand the test of time, but also can crossover to many applications.

In this third article I will talk about is his essay “The Surgical Team”. The basic theme of this is that a large project should be tackled by a team, but that the “team be organized like a surgical team rather than a hog-butchering team”.

Image by FelixMittermeier from Pixabay

What this analogy means is that on a surgical team, it is the surgeon themselves that are in charge of the group. While they may delegate whatever they wish, they always have the final say over what goes on.

The recent film Ford v. Ferrari has a good example of this in practice. In the movie (based upon a true story), Carroll Shelby was tasked with creating a viable race team for Ford. The goal was to compete in and win the “24 Hours of Le Mans” race.

A former racer himself, Shelby was supposed to be responsible for all aspects of creating the team, from design to staffing to choosing the drivers. Shelby initially didn’t have success due to some corporate micro-management that was sabotaging his efforts. It was only after he was able to take full control that he ultimately was able to achieve what he was tasked to do.

The same dynamic can be true for any large programming project. There can be many layers of management and many different influences that pull the projects in different directions. This can have many negative effects – the project can be delayed or compromised, and a lot of time can be lost.

The other reality is that not all programmers have equal talent. In the computer science world, there is a type of programmer that is referred to as “full-stack”. This simply means a programmer that can do it all themselves, from front end to back end. Obviously, it would be great to hire only “full-stack” programmers, but the reality is that they don’t exist in abundance.

If you are fortunate enough to have a programmer that fits this description, consider putting them directly in charge of a large project – make them the Project Czar.

Compensate them appropriately and allow them to choose their own support staff as needed to handle the minutiae of the project. There will likely be another very competent programmer (who will one day aspire to be a Project Czar themselves) who will be the right-hand person and be leaned upon very heavily. Others can be selected for their acumen with documentation, user interfaces or whatever is needed to allow the project to be completed in a timely manner.

This approach overcomes two main obstacles with any programming project. The first was aforementioned – that some programmers are very, very good while some are, well, not so much. The second regards communication overhead, a topic covered in the first blog in this series. By having the main programmer in charge of the project, this can mitigate a lot of those communication issues (although they will always exist in some measure).

Consider this approach for your projects. While the generalist manager can be effective in some types of projects, having your best practitioner in charge may yield the best results. Specialization is in vogue across many fields and industries and this should not be an exception with managing programming projects.

Written by Carlo Zaskorski
Controls Engineer, Product Manager, and Freelance Blogger
Edited by Shawn Tierney

Have a question? Join our community of pros to take part in the discussion! You'll also find all of our automation courses at

Sponsor and Advertise: Get your product or service in front of our 75K followers while also supporting independent automation journalism by sponsoring or advertising with us! Learn more in our Media Guide here, or contact us using this form.

Carlo Zaskorski


Please enter your comment!
Please enter your name here