On an episode on the Accidental Tech Podcast about “Software Methodologies”, it was enlightening to hear the conversation on waterfall versus agile development practices from someone who really doesn’t see the need to implement project management because he’s worked alone for the past few years. Nothing beats the operational efficiency of one software developer, though the one-man/woman-shop can realistically only work on software of limited scope, e.g., simple mobile apps.
A particularly salient point made was that these techniques for wrangling time estimates and measuring work efficiencies are dehumanizing. That is, they treat engineers as interchangeable, and that a team’s collective output is a communication-discounted sum of its constituent parts. For most engineering organizations of decent size, this is the standard and accepted way of keeping everybody pointing in roughly the same direction, and their work is then attributed to the manager/lead in charge, hierarchically up all the way to the CEO.
Much has been made about the clear exceptions to this type of organization. Valve is famous for not having formal managers, Medium opines and boasts about its lack of structure, and lest you think it’s only applicable in trendy creative software companies, the produce-processing company Morning Star has run on the no-manager model for years for all its workers. As far as I can tell, teams and project management are alive and well within these companies; the big operational difference is that these processes are driven from the employees themselves rather than from a formal (project) manager.
It’s not so much that employees hate managers: they hate the bad managers who instill the wrong processes or force together incompatible teams. It’s not that the responsibilities and work of a manager magically disappear when the company decides to do away with the position. Rather, that work is picked up by the individual team members, or sometimes just falls through the cracks. With a team coalescing organically, there is a higher chance, though not guaranteed, that the management work would be distributed.
For the vast majority of us who aren’t working for these firms, the takeaway is that teams should matter. Complimentary team members should be a major consideration, and giving the team time to know each other and gel is an important aspect of stabilizing the structure. The compelling argument made revolves around optimizing work efficiencies and greater output, but I’d like to think of it as making people happy, thinking of teams with its members at the forefront.
To think of “resources” as actual people.
- And I’m struggling to come up with something other than agile and waterfall.↑
- Morning Star is particularly interesting, as it employs many workers who we’d usually think of as line workers who don’t normally have opportunities for creativity. This Harvard Business Review article (pdf) is a great read on how they made it work.↑