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”.
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 news tip? Share it with us here.
Have a question on this topic? Click here to scroll down to the comment link
Enjoy the benifits of membership! Insider news, rewards, & more: Patreon.com/automation
Latest posts by Carlo Zaskorski (see all)
- The Realities of Project Management: Know When to Hold ‘Em, Know When to Fold ‘Em - December 23, 2019
- The Realities of Project Management: The Project Czar - December 5, 2019
- The Realities of Project Management: The Second Effort - November 21, 2019
Click HERE to scroll down to view or leave comments