(Note: This essay was written for my Foundations of Leadership course.)

Software Engineering is the discipline of Computer Science concerned with “developing and maintaining software systems that behave reliably and efficiently, are affordable to develop and maintain, and satisfy all the requirements that customers have defined for them” [1]. Creating and maintaining such software systems is what programmers do on a daily basis. To those who know about the industry through the news or HBO’s Silicon Valley, the profession is pictured as a solitary endeavor where “rockstar developers” stay up all night writing code fueled by coffee and the dreams of an IPO.

This fictionalized portrayal is far removed from the process-based workflows of actual software development. As developers, we work on teams staffed by programmers, testers, product managers, and a project manager. Each time a feature is requested by a stakeholder (customer or management), we start iterating towards a solution using the following process: (1) explore problem space; (2) gather requirements; (3) mock and vett design; (4) implement solution via code; (5) test final product in production-like environment; and, (6) deliver product to stakeholder. Coordinating team activities is an exercise in patience and communication.

Let’s examine the number of links between teammates. We’ll formally define a link as a two-way communication pathway. On a team of two, there is only 1 communication pathway. Disseminating knowledge requires reaching out to the one other person on the team. As teams grow, we need to communicate with more individuals, therefore the number of communication pathways also grows: a team of five will have 10 communication pathways, 24 links on a team of seven, and 45 channels in a team of ten.

Figure 1: Number of pathways between individuals increases combinatorially as the team grows. This is known as a combinatorial explosion.

Team Size: 2, Paths: 1		Team Size: 5, Paths: 10		Team Size: 10, Paths: 45

It is no surprise that the most frequently cited cause of project failure is “team politics” [2]. This catch-all bucket includes items such as “communication problems, staffing problems, disenchantment with boss or with client, and lack of motivation” [2]. Even though working in technology means that we have to make decisions and adapt in an ever-changing environment, the major problems we face “are not so much technological as sociological in nature” [2].

Understanding that software development is fundamentally a people problem paints it in a different light. On top of managing the technical nuts and bolts of our day-to-day, we have to tend to our workers and their human needs. Successful organizations require internal teams to function at above-average rates of efficiency so they need to start thinking about how they can foster a worker-focused culture. Leaders need to understand interpersonal dynamics so they can take on the role of manager, mentor, or facilitator as the situation requires. This is why Peopleware: Productive Projects and Teams is considered a must-read for “every manager and every programmer who works under a manager” [5]. In the following pages I will outline a few of the thoughts I had as I read Peopleware.

Engineer vs Engineering Manager

There needs to be an industry-wide discussion about the career progression of a software engineer. People who are drawn to this profession love to solve problems, tinker endlessly, and create systems; this is a job for the technically-minded. Managers, in contrast, have to manage individuals and ensure that the end product is delivered on time; this job requires an empathy-minded individual. This is one of the reasons why the standard industry practice of promoting above average Senior Engineers to the position of Engineering Manager does not make too much sense. While there are definitely some Software Engineers who would make great Engineering Managers, the industry practice of a single-career track needs to change.

Once you become a Senior Engineer and start building a portfolio of successful projects, you hit the ceiling of your current position and pay band. The only way to get more money is to leave or to become a manager. Change is difficult and a promotion is a promotion, so you take the opportunity and become a manager. Even if it’s not in your best interests.

Fortunately, large organizations such as Google, Facebook, and Groupon have started to rethink this philosophy. These companies have created an engineering track which is separate from the standard management track. Engineers can progress through salary bands and not be forced to deal with aspects of the job that they are not suited for. This doesn’t mean that these individuals cannot be leaders within the organization. As highly competent specialists, they will be looked upon to “lead from the middle” and take on additional team-based roles such as system architect, knowledge expert, and mentor. This concept of “Team Leadership” (Northouse) lines up with Peopleware’s idea of jelled teams. Successful organizations needs to support internal teams by building a culture of member involvement. Said another way, we need to put people in situations where they can be successful.

Smart and Gets Things Done

Joel Spolsky, the co-founder of Fog Creek Software and CEO of StackOverflow, has a simple principle for building teams and organizations: hire people who are smart and get things done.

Smart and doesn’t get things done means that the person is always tinkering on whatever strikes their fancy: they can’t buckle down, get to work, and ship code to deliver the requested feature. People who are not smart, but get things done results in a project that is cobbled together without much thought, i.e. coding by the seat of your pants. Well designed software is modular and able to connect together like Lego blocks. Poorly architected software can be compared to the vision of an artist where the end product is a vague concept in their head; an artist will spend hours creating something and deem it complete based on gut instinct.

Peopleware takes this concept of smart and gets things done to another level entirely. Once you have a team full of your people, the organization needs to put them in an environment where they can be productive, motivated, and constantly challenged. The Peopleware authors spend a few chapters talking about a quiet office environment that is free of distractions. At my company, developers sit by high-traffic meeting rooms so there is constant noise from 9 till 4; in order to drown out noise, programmers listen to music the entire day. I have been known to step out of the office to work out of Starbucks or the Harold Washington Library when I have a complex task I need my entire brain to process. I recently set up an arrangement so that I can work from home one day a week. While this does not seem like leadership in the strictest sense of the word, it brings a bit of empathy to the workplace. These are the types of things that leaders in technology need to think about.

Tech companies that have made their offices into playgrounds don’t quite understand what employees are looking for. It’s more about having a place where you are valued versus a place you have fun. If leaders want to keep their technical employee turnover low, they should treat them well; happy people can be in flow states for longer periods of time. This does touch on the idea of “Authentic Leadership”, Joel Spolsky’s philosophy has been to lead by example and create an environment where smart people want to work. It has worked out as his company is behind some of the biggest products in the tech industry: Trello, FogBugz, and StackOverflow. It is easy to identify organizations that fake their culture; Glassdoor publishes employee reviews which can be used to get a sense of what things are really like versus how they are portrayed. An organization that succeeds in building a satisfying community tends to keep its people

SkunkWorks

The act of creation is a powerful drug. You can spend hours bashing your head against a wall trying to figure out why something isn’t working. I did it right, why isn’t it doing what I’m telling it to do? 😡But that feeling you get when the program runs and does what you tell it to do makes the entire process worthwhile. I am programmer, hear me ROAR! 🦁

Organizations are a conservative bunch. While they took risks to get to the top, their strategy changed once they had something to lose; this mindset is counterintuitive to what is required to sustain growth. Internal innovation should be encouraged so that the organization can be at the forefront of the next big market trend and not end up like the Xeroxes or Kodaks of the world. Companies should embrace their innovators and let them lead teams that are conducting R&D for the sake innovation, i.e. skunkworks projects.

AT&T Bell Labs is the perfect example of this type of organizational mindset. A lot of the early innovations in the field of computing came from Bell Labs researchers being able to run free with an idea. Individuals such Dennis Ritchie, Ken Thompson, Brian Kernighan, and Bjarne Stroustrup became leaders in their field based on the work they did at Bell Labs [9]. This relates to the concept of Trait Leadership where organizations identify individuals who have the leadership traits that can be cultivated to enable individual and organizational success.

Conclusion

Reading Peopleware was a catalyst in getting me to think about the dynamics of a successful software development organizations. Recall that most of the problems in software are not technological, but sociological. Therefore organizations need to be cognizant of the barriers that prevent teams from jelling: recognize that not all individuals are suited for manager roles; put people in an environment where it is easy for them to become successful; and give them the freedom the innovate.

While Peopleware and this essay are not explicitly about leadership, we can apply the lessons learned and manage people in a manner in which they can productive; this will lead to our project being delivered on-time and on-budget. Understanding interpersonal issues and using the behaviors outlined in Northouse provides leaders with a playbook they can be used to lead teams and organizations.

Personally, reading Peopleware has given me a better sense of how to approach the people-aspect parts of my job and it has convinced me to “lead from the middle”. I am now more vocal about my expertise and best practices.

References

[1] Association of Computer Machinery. (n.d.). Software Engineering. Retrieved from http://computingcareers.acm.org/?page_id=12

[2] DeMarco, T., Lister, T. (2013). Peopleware: Productive Projects and Teams (3rd Edition). Boston (United States): Addison-Wesley Professional.

[3] Brooks, F. (1995). The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition). Boston (United States): Addison-Wesley Professional.

[4] Wensel, A. (2018, Feb 12). Emotional Intelligence for Engineers. [Video File]. Retrieved from https://www.youtube.com/watch?v=yD0kzU4Pu-Q

[5] Spolsky, J. Atwood, J. (2009, Jul 2). StackOverflow Podcast #12. [Audio podcast]. Retrieved from https://stackoverflow.blog/2008/07/02/podcast-12/

[6] Northouse, P.G. (2015). Leadership Theory and Practice (7th ed). Thousand Oaks (United States): SAGE Publications

[7] Reynolds, Tom. (2017 Jan 19). Team sizes and communication pathways. Retrieved from https://www.beliminal.com/team-sizes-communication-pathways/

[8] Spolsky, J. (2006 Oct 25). The Guerrilla Guide to Interviewing (version 3.0). Retrieved from https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-interviewing-version-30/

[9] Gertner, J. (2013). The Idea Factory: Bell Labs and the Great Age of American Innovation. London (United Kingdom): Penguin Books.