Software teams are not platoons

…. and don’t run them like one.

Software engineering is as much a science and as it is an art. Software Engineers take immense pride in their work, and for them building software is an extremely creative process.

At Spurious Software, Mark had recently joined the Lynchpin Division as the Head of Engineering . He came from Core Platform Team at Spurious Software leaving a trail of half-completed features. Features which were rushed to portray a sense of delivery, but left customers dissatisfied. That he came to take over the lynchpin of the company’s product line was a bit discombobulating to a lot of people in the Lynchpin Division .

Mark comes in and looks at what teams have been doing. He makes a few changes about how people deliver and teams become more productive. Then he lands on Kirk’s team wherein they were planning to go GA with a feature which languished as Beta for a very long time. Towards the middle of the release, the team realizes that it was at risk to deliver the feature because of performance & scale considerations. Following is how the conversation goes:

Mark: What’s the deal with delivering Feature X in the release?

Kirk: We have a feature which has been dormant for the better part of 4 years and we are skipping intermediate steps and going GA. Additionally, we have looked at scale and performance tests. We are very concerned about delivering a sub-par feature set. One that would not only lead to bad user experience, but something that could also have brand impact.

Mark: We agreed at the start of the release that the team would deliver it so get it done. When I used to be in the Navy, the team used to work for the leader and get the mission done. As the lead, make your team get it done.

And then Kirk made probably the biggest mistake of his career

Kirk: But the team is already stretched thin and we are working nights + weekends. I am concerned about team health and also product quality

Mark: I’ve tried to couch it nicely, but I guess you need to hear the real message. As a lead you are supposed to get the team to do what you want. I am expecting you to deliver this and expect no excuses. The team should work as a singular unit on a mission. We signed up for the mission and we get it done with no excuses. Just do it and we can fix team health issues afterwards. I need you to deliver this feature, so get it done.

Kirk goes back to the team with the following message:

Folks, we need to get this done as the feature has been languishing for a while and there is brand image at stake here if we don’t get it done. Let’s push forward this release and get to GA.

The team talks through what needs to happen and works through mitigation plans. They push forward and get it done. After the release, the team gets rewarded with a nice party and some spot bonuses. The team members sound happy and we get to working on the second version of the feature.

This time, the team decides to put a united front if there are risks. As in the previous release, the team identifies bigger risks to the product and raises concerns with management very early in the release. Mark does not like the message he is hearing, and gets all the team members in a room. Along with VP of Product in the room, Mark gets on the team’s case and the conversation goes as follows

Mark: Folks, what’s the deal? What are the concerns?

Jack and Jill (the Quality and Dev leads): There are very big risks to rushing delivery and the impact is higher than previous release. The team is already tired from the previous release.

Mark: Guys, we did it last release. Let’s do it again. You can do it now if you did it last time around. We are all adults and should be able to step up our game. Just get it done.

Jack: I am not comfortable signing off on the quality aspect because we just do not have time to do all validations.

Mark (narrowing his eyes): I hate to repeat this, but here goes. I come from the navy where I was a commander in the navy and ran multiple teams. The teams align on a mission as a goal and deliver on it. We brooked no disagreements when we start on a mission because it was a matter of life and death. We are not in a life-and-death situation, but I expect all of you to deliver.

Kirk is cringing sitting at the head of the table and sees all energy in the room dissipate. The team pulls through and deliver on the overly aggressive schedule, but they are burnt out. So badly that at the end of the release, over half the team members either leave the team or the company. The team as a whole was decimated.

After this episode, Mark and his management team looked at Kirk as someone who was not a go-getter and the team as mediocre performers. Management came down with punitive measures like denying all promotions for a year. They even went as far as to tell people explicitly that all their promotions are at extreme risk for lack of delivery and also because of disobedience.

The team kept in touch and reminisced about good and bad times. They also had a candid conversation about what went wrong and following were some key takeaways

Agency was taken away from the team. The team felt they had no say in the quantity and quality of work

The engineers felt rushed and were not happy that they couldn’t do their best job

The message “Just do it” was perceived as bullying

I’ve worked for various managers, but managers who had a military background used this M.O. for leading teams. There are some key differences between military platoons and software teams which these ex-military leaders seem to miss/ignore

  1. Soldiers are trained and expected to obey orders. Disobeying orders or not delivering on missions has consequences — disciplinary and punitive consequences. When engineers do not deliver on commitments, consequences do exist, but rarely punitive unless the failures are patterns/consistent
  2. Military missions are for a large part life-and-death situations. Software Engineering missions are rarely life-and-death situations.
  3. Software engineering has room for creativity and innovation. Military missions are successful when every member follows their role as pre-defined. Deviations/creativity in military missions are almost always a last resort and discouraged.

Engineers do their best job when they feel empowered enough to be creative and also seem in control of their own destiny.

Running Software Teams as platoons is a recipe for disaster

--

--

--

Views expressed on this blog are solely mine and not those of employers, past or present.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Calculus, a different perspective

Auto-generated documentation with AAD authentication and granular role management

Using swagger as validator for express

READ/DOWNLOAD@> Practice of Cloud System Administration, The: Designing and Operating Large…

How big data works?

T-zone series: My version of Cucumber scenario

ROPing Horcruxes, pwnable.kr

Navigation Components: A fix for “Navigation action cannot be found in the current destination”…

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Kartik Lakshminarayanan

Kartik Lakshminarayanan

Views expressed on this blog are solely mine and not those of employers, past or present.

More from Medium

Are You In Control? Don’t Be.

Why are we meeting again?

Don’t let your team’s passion fade away

People in your organization are searching for a sense of direction.