Optimizing Software Teams

After more than 100 software projects, it has become clear that problems in development come from the development team. While this sounds obvious, few organizations are focused on team building. Instead, they are looking to recruit better developers, implement better processes, require more meeting time, and create new levels of hierarchy.

However, in studying all the successful projects I have been a part of over the past 22 years, the problems always center around four things. I call them the four tenants and they are as follows: communication, motivation, knowledge, and guidance.

When all four of these tenets are done well, the project succeeds. However, if just one is missing, the project will at best be behind schedule but more often than not, it will fail. Discovering this led me to consider other types of teams. One in particular came from television.

Jesse James of reality television fame hosted a show on Discovery called Monster Garage. On this program he assembled a team each week of mechanics, welders, and fabricators. The premise was to take a specific vehicle and convert into something else.

On one episode, the team was to make a three-wheeled motorcycle from a large commercial truck. The team drew out some plans, removed the engine from the truck, welded a frame, and had assembled a working machine by the end of the week. Another episode featured a team that failed. When this occurs, the partial creation was destroyed in some over-the-top fashion.

Since everyone on the show was selected due to their proven skill set and submitted video, the knowledge and motivation parts were covered. Jesse James, an expert fabricator, provided the guidance. So the only factor that was different for each team was communication. If a team communicated clearly with one another, the project was a success. If not, there was an explosion. Not a metaphorical one — actual pyrotechnic destruction.

Communication

Instead of focusing on software tools, let’s discuss the real issues of team communication. In management training it was taught that teams go through four stages. They are: forming, storming, norming, and performing. First, a team is formed. Second, the team begins to argue and fight. Third, they start working with one another. Fourth, the team functions at it’s higher level.

The first stage of forming is when everyone is being polite and/or shy. “Where do you want to go for lunch?” is asked. Followed by a response of, “I do not care.” All the while secretly wishing for a favorite lunch spot. This is not working together. It is just being polite.

In phase two, the storming, all of those polite gestures have faded. Now the guy who blares techno music from his headphone is getting on the women’s nerves who complains about the break-room coffee. In turn, another team member feels as if he is being ignored in discussions. While another person believes they are doing most of the work. So it comes out in the open. That is why these initial skirmishes are healthy. The team starts to share their likes and dislikes with one another while at the same time adjusting personal biases toward a cohesive unit.

Reaching this stage takes time. How long depends on the culture and personalities present. Thus a team put together for just a few days before a project may not hit this milestone until work is well underway.

A great leader can assist the team in reaching this phase by becoming a source of carefully controlled contention. American Football Coaches are famous for this. First, the coach singles out problems with the team — not individuals. Only after the team problems are addressed does he focus on individual improvement. The reason is to focus all animosity on the coach while placing the challenge to improve on the team — regardless of the specific people involved.

Using this leadership pattern instills the idea that success or failure is the responsibility of the team. As a result, individual problems are handled by the team internally. Sometimes this means conflict. However, once everyone has gotten their frustrations out, the team will move toward a focus of helping one another be their best.

Therefore, Management must embrace conflict instead of running from it. Encourage the team to challenge everything, including Management decisions. Doing so with respect. For example, my teams are encouraged to challenge my design decisions with the hope that the overall project is improved.

Once I was able to get past my own ego and ask for suggestions from the team, the delivered products improved. Now, team members are open to critique every technical decision, regardless of who made it. Even stakeholder suggestions are discussed openly. First with clarifying questions then recommended alternatives as needed. The point is the team is free to communicate as needed for the benefit of the project.

Motivation

To move from norming to performing, a team must be motivated. That is motivation to do their best work despite the circumstance. Some projects are more fun than others. However, the team must learn to be motivated by their delivery and not the actual tasks required.

As an Engineering Manager, I was responsible for architecting a solution to a problem previously thought to be impossible. At first, everything we tried failed. Out of ideas, I presented the project to one of our Lead Engineers who had become bored with work. While describing the problem, he immediately became interested — soon suggesting a potential solution.

After testing his idea, the previously thought impossible had not only become possible but feasible given the project constraints. The only issue was it required technology outside the norm for our organization. Looking over the capabilities matrix, a list of who in the company knows what technologies, I created a team from those who were fluent in the technology. Placing the Lead Engineer who solved the problem as the Team Leader.

Next, a meeting was called and the team was introduced. Almost a year later and that team has proven to be the best in the company. They regularly surpass all expectations and currently serve as the model for software team best practices.

It started by coming together as a team to deliver the impossible. Some of the members had worked together before. However, many were working together for the first time. As for technical abilities, most were average for the company — chosen solely on their past experience with a single technology.

Another lesson learned from building this team came from a lack of resources. In the past, my teams enjoyed bonuses for finishing early. However, Senior Management refused to approve bonuses or even awards due to budget cuts. Not having bribes to give led to a new discovery.

In turns out that being offered a bonus for on-time or early completion of a project is not team motivation and will never help a team achieve truly optimal results. Instead, it can serve to fracture the team due to some members resenting others.

Consider a project with a really difficult back-end functionality. The designer and front-end developers are waiting on the back-end group to deliver. Now their bonus is in jeopardy. In turn, the group struggling is frustrated with the other members and now the team is a collection of waring subgroups.

Instead, the team as a hole has to find it’s own cohesive motivation. Our successful team enjoyed the spotlight gained from their stellar performance along with the since of pride that comes from building a truly great product.

Why it took so long to learn this is baffling. Consider the large number of open source projects that developers work on for months or even years with no pay. The reason is to deliver a product they believe in. That is their motivation.

By offering additional compensation or award to manifest motivation is counterproductive. Management often treats work projects like drudgery. Instead, Management must sell the project as worthwhile. Something with value greater than the salary paid to build it. Once accomplished, the team needs no additional motivation.

An important part of motivation is the idea that Team Members should never be required to work after hours. Sure, at times this may be necessary. However, the team needs to be free to volunteer on its own. If the team is truly motivated, they will regularly volunteer to do this.

A few years ago I was working on a high-profile project as Lead Developer. My boss, the CTO, explained we needed to ensure we are ready for “Black Friday.” In the United States, this is part of the Thanksgiving Holiday and the busiest shopping day of the year. Our app tracked people’s spending habits and he was worried about the additional data going through the system.

Over the next few days we tested everything. Then on “Black Friday,” I logged into the system to ensure the data was being captured correctly. Once online, I noticed my boss was doing the same thing. We chatted hello as both were satisfied of the results. No one made us take our Holiday time to do work. Instead we were free to volunteer due to our belief in the product we were building.

In contrast, when developing a product for a company that started selling things before they were finished, everyone was required to work after-hours. The CTO would conference call the team around 9:00 pm and everyone had to stay connected until he was satisfied with the progress made. This killed all motivation by changing the focus from working on a project to working for someone else.

Knowledge

Software Development requires lifelong learning. This includes keeping up with changing technology while learning about the specific domains one builds software for. We as Engineers must be willing to learn about diverse subjects. In my career, this has included: options pricing, aircraft navigation, and foreign language — just to name a few.

Therefore, it is not enough for a team to communicate effectively and be motivated to do their best. In addition, that team must be dedicated to learn. It may a new version of something they already use or even a complete paradigm shift as is the case for Artificial Intelligence.

When building an options trading platform for a hedge fund, I was the only team member with financial experience and that was one three-month project for BB&T. The rest of the team came from the video game industry. Since our goal was to develop a gamified trading system, I had to learn about gaming while teaching about finance. This is how it should be.

Everyone on the team has (or should have) specialized knowledge. Therefore, it only makes sense that team members share their expertise. This can be done formally as lunch-n-learns or informally as discussions within planning sessions. Regardless of how, the team must be able to learn as a group — not just individuals.

Some of the best examples of this include meaningful discussions between related disciplines. For example, a Designer taking the time to teach a Front-End Developer the benefits of mobile first web design. One of the best corporate teams uses its Database Administrator to teach SQL Optimization to the newly hired developers. As a result, they have saved over 50% in software maintenance costs.

When one team changed from Waterfall to Scrum methodologies, the Director of Engineering held a full-day meeting on the new methodology complete with a discussion on best coding practices. This was a day before they began a new project. This resulted in delivering a product two-weeks ahead of schedule. Thus, it is best to reinforce best practices while teaching new things.

Guidance

University level Software Engineering Programs are notorious for reminding us they are not job training. After hiring two entry-level developers, this became clear. The first, we’ll call Bob, graduated from a local University in Computer Science with a high Grade Point Average. The second, we’ll call John, graduated from a software career school with high recommendation from his teachers.

Both did very well with our interview gauntlet — answering memory questions, building a sorting algorithm, and describing Object Oriented Programing principals better than we could. However, the differences became apparent on day one.

My job was to assist them in completing their first tasks. John was first. He was a Microsoft Certified Developer and had no issue setting up his development environment. Next, Bob installed everything correctly but did not understand how to make a database connection. I explained how along with a crash course on Git, SQL, and Visual Studio.

It turns out, Universities do not teach students how to be developers. While understanding all the theories behind the technology, Bob could not do the basic tasks required of a professional developer. At the sametime, John understood how to write code but could not explain the detailed theories the technologies were based on.

Over time, both Bob and John were able to reach the same level of understanding through guidance. While it uses Communication and Knowledge aspects, Guidance differs in the approach. It is not teaching so much as it is regularly measuring progress to find strength.

A Major League Baseball Player once told me that to stay on the team, one has to constantly improve. Once you hit a level where you cannot get better then you are cut from the team. This should be the same for software teams. We need people who are constantly improving while encouraging others to do the same.

Guidance comes in many forms. An easy start is the posting of technology articles for the team. Perhaps it’s the latest news on a favorite development tool or a how-to recipe related to the current project. By posting it, the team can read, learn, and respond — creating the loop of information sharing.

Measurement also plays a key role. That is the metrics related to team performance. For example, a few basics might include: the number of defects per code check-in, the average time on task, and the number of revisions before passing Quality Assurance. These measurements should be shown to the team as achievements. Next, each should be used as a challenge to the team for improvement.

As a guide, one should direct the team towards their strengths. If that is a low defect rate then seek to make it lower during the next iteration. However, it is important to have team buy-in for any goal set. Always come at it from a position of strength improvement and not weakness reduction.

Sometimes, the team may be weak in an area such as time on task. It may be they are very careful with their code and take the time to ensure it is correct. However, it may mean they are distracted. Find out why it is low and work with the team to correct it.

If the team is struggling in an area they are unable to improve upon it may be worthwhile to bring on a new member strong in that area. However, it may be a metric that just does not matter to the overall optimization of the team.

Conclusion

Optimizing a software team is a difficult task. To make it easier start with improving communication then working your way through motivation, knowledge, and guidance. At the same time resist the urge to purchase software tools until you have a process in-place that works for your team. Often, teams are forced into an awkward paradigm due to a tool purchase.

Toyota does this by using manual methods until the process is optimized to the point of justifying automation. At that point, software is made or customized to manage the process. The same is true for your software team. Use manual methods until the team has settled on what works best. Then automate it with an off-the-shelf or custom software tool.

If you want to rapidly improve your team, please visit https://toddmoses.com