Principle #1: People
People Matter
In Part 1 of my blog series on Four Principles of Software Development, I proposed the P.E.E.R. acronym (People, Effectiveness, Efficiency, and Relevancy) to describe four principles that set a senior developer apart and define how software ought to be done. The first, and most important, of these ideas, is the idea that people matter.
In software development, the people on the team are the most important part, and one of the biggest indicators of success. Having the right people for the job will make all the difference. A poor idea with a poor plan can be turned around by a good software development team. Conversely, a great idea with the right plan can also be turned around by a not-so-great team.
Leadership
Many aspects that describe a “good” software development team, but the most important aspect, in my opinion, is the leader or leaders of the team. A good leader helps the team stay organized and on track. A good leader helps the team prioritize and prevents them from going down too many rabbit holes for too long. A good leader sets the pace for the team and helps to ensure everyone knows what each other is doing.
Good leaders are inclusive, yet protective. They involve the team in any planning, meetings, and decision making that is going to be important and relevant to them. However, they also protect the team from any of these that are not relevant to them and will only detract from their work.
Good leaders delegate responsibility and allow people to fail, yet don’t shirk responsibilities and won’t allow the project to fail. They trust their teammates and don’t hesitate to get out of the way to let others innovate and take responsibility even if it means they may experience some failure. Good leaders understand the importance of failures. However, they also don’t neglect or pass off core responsibilities such as planning, hiring, team building, etc. And at the end of the day, they will not compromise if it means the project would fail.
Good leaders build an environment of trust. The importance of this cannot be understated. As a team lead and manager, I have read a lot of leadership books, but the one that was most impactful to me was The Five Dysfunctions of a Team by Patrick Lencioni. In his book, Lencioni argues that there are five performing levels of a team. He says that for a team to be truly successful and deliver remarkable results, they must strive to achieve the highest (fifth) level. The first level Lencioni describes is the level of trust. He proposes that if a team does not have trust it will fear conflict, lack commitment, avoid accountability, and ultimately produce subpar results. Unfortunately, I have seen first-hand how this can play out on a team.
Good leaders will take every oportunity to foster trust in the team. If you are a leader on a team, one of the best things to build trust is to be vulnerable. One way a leader can do this is to take responsibility for any project failures while at the same time giving credit to the team for any successes. Even if you’re not an assigned leader on the team, you can still often find ways to lead from behind by fostering these ideas and attitudes on your team even without a leadership title.
An anecdote about trust
One day, when I was doing a performance review with a developer, let’s call him John. I asked him if he had any ideas in areas in which he would like to improve. While most developers would give me answers related to learning the latest version of a framework, completing some certification, or learning a new programming language, John had something, in my opinion, much more insightful. He told me that he wanted to help build trust on our team. He told me that he realized that he had trouble admitting when he was wrong or at least realized that he often felt bad and discouraged when he found out his idea wasn’t correct or wouldn’t work. He said that from now on he was going to emphatically and enthusiastically admit and call out whenever he realized he was wrong.
This sounded like a good idea, but it didn’t sink in until I had more time to reflect on this. I started paying close attention to myself and other engineers on the team to study their reactions when they found out they were wrong or mistaken. The first thing that I realized was that for any engineer that was actually trying to accomplish something, this happened all the time. On a daily basis I could find examples and I realized that I almost never heard any developers say the words “I was wrong.” I even noticed myself. I would dismiss or downplay being wrong by saying something like, “I must be thinking of another framework”, “I must have looked at that wrong”, or “I swear that’s how it used to work”. It’s really a minor offense. It’s not like people were refusing to admit that they were wrong, they were just, understandably, not enthusiastic about it.
However, over the next few weeks, during technical meetings, I’d often hear John call out “I was wrong!” It wasn’t just what he said, but the way he said it. He actually seemed to be excited whenever he was proven wrong. I never mentioned this to anyone else on the team, but it didn’t take long before it started to spread and I started noticing other developers saying it too. It’s something that somehow feels very liberating. It didn’t take long for our team to develop a great sense of trust. It made us feel like it was okay to be wrong and nobody was going to judge us. After that, nobody held back, and the ideas and innovations started flowing.
Hiring
Besides having good leadership, the next most important thing in software development is hiring the right developers. Hiring and onboarding developers should be one of the most important responsibilities of a team. A team should continually maintain and update a documented interview structure. It should be something the entire team is familiar with and has had an opportunity to contribute to. One of the jobs of a developer is to ensure that things will continue to run smoothly even if you leave the team.
A good development team should always be prepared for a team member to depart, and likewise, for a new team member to join. This means breaking down knowledge silos, practicing shared code ownership, keeping good documentation, and maintaining a smooth onboarding process. A good test of a team’s ability to onboard is to see how long it takes a new developer to contribute to the codebase. Ideally, they should be able to contribute a commit on the first day.