Dr. Neil's Notes
Software > Development
Leading Software Development Teams
Introduction
A topic of discussion that keeps repeating is how to lead a software development team. Often the words used are different, and the semantics is important. The discussion often starts focussed on managers who seem to be struggling to manage the software team that reports to them. When I hear this I understand the problem almost immediately. What most companies want, from a software development team, is the outcome of high quality software, that can scale. It is then curious that, to achieve this desired outcome, the focus is placed on the details of management, process, and control, rather than the outcome desired. In this Note I will describe some of my observations working with software teams for over thirty years.
The Management Myth
In the introduction (above) I intentionally italicized the word manage, as I believe this is the first problem with the semantics of how we describe the act of helping a software development team achieve the desired outcomes. How do you manage creativity and innovation? I propose you cannot manage creativity and innovation, however you can lead people to be creative and innovate.
One challenge I have observed, is that people, who do not love the act of creativity in software development, see their career path as moving into management. These people are looking for a j o b where they can pretend they are in the software development business, and yet not be involved in the creation of software. Another challenge that compounds the previous challenge; people who do enjoy software development that are looking to move their career forward, see that the higher salaries go to managers who do not write code. The obvious conclusion is then to become a manager, and stop writing code.
Occasionally I hear managers proudly state 'I have been a manager for 5 years, I do not write code anymore'. What I hear is 'I do not like building software, so I followed the Peter Principle, and got promoted out of something I am never going to be good at'. The trouble is these same people, who are not passionate about the creation of great software, are now supposedly managing people to achieve something the manager does not care deeply about.
A good software development team leader is never too senior to write code. I have observed this repeatedly in the companies I have worked with, from start-ups to large software companies, the best leaders of software teams (and sometimes big tech companies) keep their hand in the development process. They write code, and review code changes.
I have never observed a great manager of a software team that is not hands on. Please do not fall into the trap of believing creativity and innovation can be managed by people not actively involved in the creativity and innovation.
Generals are not Leaders
The generals sit a long distance from the front line, getting reports of wins and losses, and then making decisions as to who will die next. This is a terrible model for motivating and supporting a team of creative, intelligent people to achieve their goals. Many managers seem to have an aim to be generals.
Supporting a software development team requires a leader that is sitting with the developers, in the trenches, dodging the same bullets they are dealing with each day. The developers you are working with should know you have suffered the shared pain of building the product. A good leader feeling the same pain as the developers, each week, will be actively looking for ways to remove the pain for everyone. The bad leader will look for a way to remove the pain for themselves only, often this is achieved by not being actively involved in the software development process. This person is becoming the general that is loosing touch with reality.
To be a good leader in a software development team, be part of the team, not an outsider. Actively be on the same side as the developer to get things done, get hands on with solving the problems. A good leader is building (compiling) the software multiple times a week, doing code reviews, and actively contributing to the code base.
Motivated and Intelligent
The role of a leader in a software development team is to create an environment that attracts intelligent creative people, supports those people to do their best work, and motivates the team to deliver the required outcomes.
Intelligent and creative people like to work with other intelligent and creative people. Software developers want to know the people, they are working with, are helping the team move forward, towards the goal of delivering the next feature in the product. People that are not actively contributing to the success of the team, are never going to get respect from the software developers working to make the product better.
There is always going to be a certain overhead for each software development team in a large organization, reporting upwards on the progress, PowerPoint programming. However this should never become a full time job for someone leading a software team. If you are an intelligent and motivated contributor to the team, you can be a better leader.
Programmers are People
The intelligent, creative, people building great software are human beings. Any manager who talks about people as resources will lose all respect from the people they claim to be motivating. Software development is a team activity. The team is made up of people, each person has their own personal goals and motivations. A good leader allows people to be their best selves, in the team, and align the personal objectives of the team members with those of the team, and the company.
Treating creative people as movable (or replaceable) resources that can be redirected to work on any other part of the software development, at a moments notice, is to deeply misunderstand how great software is created. If you treat software developers the same way a fast food chain treats staff, it will lead to the equivalent to fast food in the software product. It will not be a great product.
Team = Software.
Software = Team.
The software created will always be a direct reflection of the team, and the people, creating that software product. A dysfunctional team will build dysfunctional software. A functioning team, is made up of people that work well together to deliver a shared vision.
Macromanaging not Micromanaging
The shared vision is important to get the best outcomes. Some hands-on managers lean-in to micromanaging, trying to control the process, and mechanics of how every line of code gets written. This micromanaging does not scale well. A great software leader can perhaps micromanage fifty to one hundred developers. Most leaders will not get far past ten people. The reason micromanagement often happens is because the leader does not believe the people in their team understand how to deliver the correct outcomes. This is a trust issue, that will, most likely, be validated, because no one gets everything right all the time.
A better approach is to move towards macromanaging. Start with the big picture and make sure everyone on the team understands why the work is being done, and the goals of the project. Then work with each person to find out how they are adding value to that team goal. Systems like OKRs (Objectives and Key Results) can help here. The team should have a set of well defined objectives and measurable results. Then each person in the team should define their own personal career objectives and the measurable results. The objectives and results of each person should contribute to the team objectives and results. If they do not, then you have a challenge that needs to be solved, maybe by moving people into a team where they can align their objectives to the team objectives.
Once you have set objectives and measurable results for the team, and the people in the team, get out of the way, and get other things out of the way. The role of the leader is to support the individuals to hit their objectives, with the knowledge that doing so helps reach the team objectives. This is not a once-a-year activity. Tracking the progress for each person and the team should be done monthly, or at most quarterly. Working daily directly with the team to support the objectives allows a leader to keep their finger on the pulse of progress without the need to micromanage.
Macromanaging has the desirable effect of giving each person in the team an understanding of the bigger picture of how their work contributes. Micromanaging often leads to developers not understanding how the work they are doing contributes to the team, or company, goals.
Created: November 13, 2022 01:40:41