Author’s Note: Sources are linked inline, and books I reference are linked to Amazon.

A few days ago, I was discussing my future career path with a good friend and former MACCDC teammate. I mentioned that I am more of a system-level thinker – I love working on complex problems and understanding how and why systems work together. In fact, as a Sophomore in High School, I wanted to pursue a bachelor’s degree in systems engineering. Although I will be graduating in a year with a B.S. in Computer Science, my dream job is leading a team of technical people and providing an environment for them to learn, grow, and do amazing things. And that got me thinking – why do I enjoy both complex technical problems and leading teams? Maybe there are more similarities than appear at the surface level.

Epiphany time! What if teams are systems too?!

Here’s Merriam-Webster’s definition of a system: “A regularly interacting or interdependent group of items forming a unified whole.” That sounds suspiciously like a high preforming team! For reference, here’s Merriam-Webster’s definition of a team: “A number of persons associated together in work or activity.” As that definition doesn’t get at the heart of exceptional teamwork, I prefer my home-brewed ‘definition’: “More than just a group of people, a team is a group of people working together to achieve a common goal.”

The emphasized portions of my definition are what I believe sets a team apart from a group of people. If a group of people fails to work together and/or disagrees on their end goal, they will never truly become a team. The same goes for components of systems! There are many more similarities between teams and systems than just the definitions. Both can suffer from complex problems, and both can produce a greater effect as a whole (instead of in parts). This begs the question: is it possible or even beneficial to approach teamwork and team leadership from a systematic perspective?

YES!

Let’s take a look at complex problems and systematic dysfunction. Perhaps I’m troubleshooting a large codebase with lots of different classes and ‘moving parts.’ First, I’d have to identify the problem, and be able to reproduce it reliably. This allows me to begin to pinpoint which module (or set of modules, or interface between modules) is the cause of the problem. Then, I’d dig in and try to figure out the actual cause of the problem – for me it’s usually a missing semicolon or a fussy pointer!

A failing system is like a dysfunctional team – one bad part can adversely affect the whole. According to Patrick Lencioni in The Five Dysfunctions of a Team, absence of trust, fear of conflict, lack of commitment, avoidance of accountability, and inattention to results are the five dysfunctions that can destroy a team from the inside out. “And so, like a chain with just one link broken, teamwork deteriorates if even a single dysfunction is allowed to flourish” (Lencioni, pg. 189). If you think of a team as an interdependent system, this becomes obvious. If there’s a problem with a module of code, then that problem will adversely affect the modules that interface with it, and so on and so forth. Same goes with teams of people – if even one person refuses to work with others or works towards a different goal, it will throw off the rest of the team, create dysfunction and erode teamwork.

I’ve seen this happen as a team member. I’ve let it happen as a leader. It sucks.

Of course, no team is perfect. Let’s see what happens if we tackle a teamwork problem from a systems perspective. Although people and their interactions are invariably more complex than the typical system, the same principles may apply.

What would a systems approach to a people problem look like? Thinking back to the process I outlined for debugging a large codebase:

  1. Identify the problem.
  2. Observe the problem in action – is it repeatable or a one-off?
  3. Identify the root cause – who or what is likely the cause and why? (It could be a personality clash, or a simple miscommunication that has gone too far.)
  4. Address the root cause, the solution should match the severity and duration of the problem.

As a leader, looking at a team or teamwork from a system level perspective lends a more analytical approach. It’s easy for me to get caught in a narrow view of what is happening, especially if someone I am close to is involved. A system level view can certainly help pull me out and look at the big picture. On the flip side, it is important to not ‘lose’ individual team members and focus too much on the system and not enough on the individual. As an individual team member, a systems perspective clarifies the relationship between team members and shows that one person can have a large effect on the team as a whole.

Taking the analogy a step further – can principles or strategies from optimizing system performance apply to improving teamwork and creating an exceptional team?

First, consider the give and take battle of system optimization… You can’t have it all! I’m currently helping design a database backend for a project that will store all the data for the project as well as track historical data for logging and analysis purposes. The most common optimization dilemma I’ve run into is: do I want potentially null fields that will take up more disk space but have faster access and write speeds, or do I want to add a new table to decrease wasted disk space, but increase access time? Depending on the context, I make a choice, and it’s usually a hybrid of both.

Similar give and take situations arise while leading a team. Many amazing examples and principles are outlined in The Dichotomy of Leadership, including:

  • When to Mentor, When to Fire
  • Train Hard, but Train Smart
  • Agressive, not Reckless
  • Hold People Accountable, but don’t Hold Their Hands

Go read the book… It’s well worth it! (Because there’s already a wonderful book dedicated to the subject, I’ll move on…)

Getting a team (or a system, for that matter) to peak performance is a challenge. The first method of improving system performance that comes to my mind is removing bottlenecks. In a computer system, this would look like replacing a traditional HDD with a SSD, given that other components are “waiting on” the HDD, and the overall system speed would increase when the SSD is put in place.

But what would removing a bottleneck look like in the context of a team?

Removing a bottleneck works because it focuses on upgrading or bypassing the component that is the most significant cause of system slowdown. In the context of a team, this translates to: focus on the significant problems – some things just aren’t worth it and trying to fix them can move you further away from your goals as a leader.

I experienced this while captaining my school’s MACCDC team. As a leader, I have only so much time, energy, and leadership capital. Leadership capital is similar to political capital, but within the scope of a team. It is a combination of interpersonal skills, relationships, and reputation that allow an individual to “attain and wield authority”.

As a leader with little given authority as a fellow student and peer of my teammates, this has been specifically relevant to me. I rely primarily on leadership capital that I can create for myself. A leader may spend this capital however they wish. However, a wise leader should direct their leadership capital towards areas:

  1. Where they can effect change
  2. Where that change will be valuable to increasing the performance of the team

Story time!

Small things bother me – I am incredibly sensitive to sounds, and I like to have things laid out in specific ways (think minor OCD – everything on the top of my desk is in a straight line, and it’s hard for me to focus if it’s not). I have a LOT OF PET PEEVES that I choose to ignore on a regular basis. As a leader, if I were to focus on making sure that “everything is as it should be according to me”, I would be wasting my leadership capital. While I may be creating a more comfortable or productive environment for myself, I may also be effecting a change that is NOT beneficial to the team’s dynamic and therefore, performance.

However, don’t take this concept too far. It’s important to stop small things from becoming big things. If there is something super important but you know that you won’t be able to implement the change, consider bringing in an “outside force” (i.e. superior) to implement it. These aren’t rules, they’re just suggestions. So, what if teams are systmes, too?

Poor teamwork is usually accidental. Exceptional teamwork never is.