A Software Development Approach To Technical Management
Overview
The manager of a software development team is often chosen among the best developers in that team. Without formal management training, this transition can be arduous. This article explains how to apply some of the proven techniques of successful software development to the challenges of management of technical teams, offering advice to new managers and some new perspectives for experienced managers.
Call to Power
When I was a full-time software developer, I was frequently frustrated with my direct management. They seemed to lack the understanding of the complexities of software development and were therefore unable to enact and enforce sensible and effective policies. As a result, I found myself spending an inordinate amount of time trying to fight against the process to complete my development tasks, including dealing with unrealistic deadlines, duplicated effort, and poor coordination between teammates and other engineering groups.
During this time, I noticed patterns in the behavior of various software development managers, noting how they reminded me more of software customers than software developers. Rather than welcome the challenge to solve a new problem given certain inputs, requirements and constraints, each manager appeared to accept their new position as one accepts a finished product. In other words, these managers approached their new duties as if management was a closed, unchangeable process, which is counter to their instincts as software developers. Even those managers who came up through the development ranks seemed to adopt the legacy management policies and oppose any kind of feedback that challenged the current system or sought to make improvements. I thought these managers were “good kings”, able to lead subordinates through the sheer power of their position, but “bad presidents” in that they did not represent the best interests or react to the sentiments of the people they led.
This management style, of closely protecting an existing process without any feedback loop or opportunity for improvement, violates all of the guiding principles of effective software development. Just as software only becomes excellent (never finished, mind you) when it evolves based on user feedback from past usage and expected future need, it seemed mandatory to me that a management process must have a feedback and improvement loop. Thus I forged ahead to try to evolve a more scientific approach to software development management, drawing from my day-to-day development experiences.
Best Software Practices Make Good Management Practices
Just as only a few people can look at software requirements and immediately visualize the finished software product with 100% accuracy, few people can design and implement a flawless management approach in the first iteration. To address this, we can apply the same methodical approach that is used in software development. Regardless of which software development methodology, if any, you subscribe to, there are fundamental elements of indisputable value: Analysis, Testing (to get feedback), and Iteration.
Analysis
If one accepts that the most important requirements of software development management are completion within specified time and cost constraints, (internal and/or external) customer satisfaction, and long-term job satisfaction for the development team, then the first important step is analysis. There is no secret or silver bullet approach to this; one must assess the software development process and management practices from beginning to end, noting strengths, identifying obstacles, and constantly seeking opportunities for improvement. The following list of questions and follow-up ideas can be used to yield pertinent dialogue from which a management process can be crafted:
What is my role as the manager of one or more software development teams?
If my former role was as a developer within the team, does my new role as manager of that team still include development tasks? If yes, to what extent?
Tip: If you still code along with your team, be prepared to assign yourself the most mundane or tedious tasks – the challenging assignments should be given to your strongest developers, who deserve and will welcome the challenge and opportunity.
If I came from outside the development team, how much technical knowledge do I need to converse with the development team in a way that I can understand their status and issues without wasting my developers’ time?
Tip: The old adage of “Read The Fun (and exciting) Manual” or “RTFM” applies here. Despite any shortcomings in the technical documentation, you can glean the common terminology and basic principles of the software, systems and processes, making you better able to communicate with your team with an economy of words. If documentation doesn’t exist – write some! As a newcomer you have a mountain of information to gather, so why not compile your notes into the beginnings of a technical document for future reference?
In which processes should I alone represent my team(s)? Do I add value in my role between other groups and my team(s)?
Tip: Adding value can be generally grouped into two categories:
Gatekeeping and Transformation
Gatekeeping is the act of serving as the commander and single point of contact of your team. As manager, you are responsible for your team’s time. Failing to plan it properly, you’ll end up with an overworked (and eventually unproductive) team, missed deadlines, or both. Each request for your team’s time must be reviewed by you and either rejected, or accepted and planned into the current schedule and work plan, adjusting priorities and assignments as needed.
Tip: To properly budget your team’s time, think of it as bandwidth. Each task represents some use of that bandwidth. While short bursts of high volume can be survived, if the volume of work regularly exceeds the total bandwidth, you may be burning your team out. Similarly, excess bandwidth can be allocated to new tasks, whether internal or external. (Important Note: While it may be an effective resource management technique to think of people’s TIME as an inanimate object like bandwidth on a data link, one should NEVER treat the PEOPLE as such.)
Transformation occurs when a vague or non-technical request from elsewhere (like the customer or product management) is converted by you, through questioning and interpretation, into a cogent and concise technical request to be conveyed to your team.
Tip: If you are unsure as to when you are transforming, compare the input (that which you receive) to the output (that which you make available to your team). In a successful transformation, they will differ, including translating into internal terminology, drawing comparisons to past activities, and providing a context based on a manager’s knowledge of external factors.
In which processes should I prevent or allow direct access to my development teams?
As manager, you needn’t insert yourself between your team and all outside parties. You can clearly define and announce, to both your team and those who would contact them, which topics or requests can bypass you for the sake of greater efficiency.
Tip: Open direct paths to your team as needed, but keep yourself in the loop, asking to be copied on written or emailed requests and by instructing your team that any request that sounds out-of-scope or unusual should be discussed before being pursued.
Do my developers have the right tools, in terms of editors, debuggers, and equipment, both at their desks and in a development lab?
As manager, you should assess the situation and be able to petition your (upper) management to purchase whatever is needed by making a strong business case for it, comparing the cost to the expected benefits.
Do my developers have the right training and reference materials?
Harsh economic times have had a severe impact on the training budget of most organizations, so training plans warrant closer scrutiny than usual. Ask your team to identify areas in which they feel additional training or reference materials would help them perform their current (and anticipated future) job functions. Write a training plan even if can’t be executed until a training budget is restored.
Tip: To ease the pain in the short-term, several low cost alternatives exist, including seeking out affordable web-based training and investing in a shared team bookshelf, where the cost of the materials can be justified across an entire team.
How are development effort estimates calculated? Does it include historical data? Do my developers have a voice?
From my experience, nothing deflates team morale more than being handed requirements that are neither prioritized nor negotiable, along with a pre-determined deadline, i.e. being TOLD what you will deliver and when. If this is occurring, find out what methods and data are being used and whether it is appropriate and effective. If it is, share the information with your team. If it isn’t or the estimates aren’t valid, propose a system to replace it, using your developer’s input as the foundation.
What is the current software development lifecycle (SDLC)? Is it too formal, not formal enough, or appropriate for the expected time-to-market and customer tolerance for patches and upgrades?
(This line of questioning takes us away from the pure technical management focus of this article but is crucial nonetheless. Fortunately, these exists a wealth of resources on this topic, ranging from the SEI’s Capability Maturity Model (CMM) which emphasizes order and process, to the more modern Agile and Extreme Programming philosophies, which may offer more speed and flexibility in certain environments. Though outside the scope of this article, improvements to the SDLC are as important as striving towards sound and effective management policies in that successful software development requires BOTH.)
Trial, Error and Feedback
The management practice that I found most successful among technical teams cannot be summarized in a parable about mice, accomplished in “one minute”, or emblazoned on a poster suitable for framing. It is an attempt to present the management process to your developers as a technical or mechanical system, such as a machine with a clear case that allows a view to the inner workings, and input controls that can be used to influence the output of the machine. This is achieved by having honest conversation with your team. Explain to them the objectives, present to them the different alternatives considered and their relative benefits and drawbacks, and then justify the selection of the proposed process. Then: listen. Their feedback is critical not just to ensure that the correct initial decision is made, but it also goes a long way to win their support for the way the team will be managed – essentially, making you a “good president”. And the feedback loop must remain open throughout all phases of all projects.
Evolution through Iteration
Despite a collaborative and carefully-thought-out analysis, some practices may fail. Others will begin successfully but shifts in the business or the technology will dampen their effectiveness over time. For this reason, your primary role as manager of a development team should be to constantly evaluate the effectiveness and efficiency of your team process, plan adjustments that present the least disruption to output, and realize those changes. This analysis can be done through your own observation, by soliciting feedback from other organizations like system test, customer support, and senior technical management, and, of course, listening to your team, especially through the much-hated weekly status meeting.
In my decade-plus of experience as a developer, I noticed that, without exception, the teams that were most effective and successful were those that met regularly to share status, discuss problems, and generally build relationships. Though the time spent (some would argue “wasted”) in meetings must be kept within reason, the benefits of meeting with your entire team at least once a week are invaluable. The primary goal of the weekly status meeting is to discuss both the product and the process, and will give you the feedback you need to tweak the management process to perfection.
Conclusion
Some management philosophies claim that leaders must present a supremely self-confident façade devoid of any self-doubt or introspection to those they lead; otherwise confidence in that leader is lost as is productivity. While this might be true for medieval kings or modern military commanders, it is not the case for managers of technical teams. Technical teams respond to a management approach that is logical, fair and responsive, and such an approach can be formed by applying analytical thinking and the software development best practices of analysis, feedback and iterative implementation.
Agree? Disagree? Send feedback.