Managing software teams can be difficult, even for the most disciplined and well-established organizations. Every aspect of the software development process must be carefully considered and balanced, allowing multiple teams to equally and efficiently produce software that customers will truly love. Managing these teams requires an understanding of the details of the project, along with the broader picture of relationships within and among teams, as well as the business requirements behind each executive decision.
To better cope with these management challenges, we've collected a handful of the top 12 tips for managing software teams from around the industry, all of which have been practiced and successfully implemented across many projects over the past few decades. Let's get into it!
Managing software teams shouldn't be focused on digging into the minutiae of every developer's daily work, nor should it be about monitoring whether each member is dedicating a full eight hours a day to producing. Not only is this sort of micromanagement highly ineffective, it's also extremely detrimental to overall team morale. Nobody wants a boss or executive lurking around or taking note of their every move.
Thus, one of the most important roles you have while managing software teams is to hire the right people. What this means will vary from organization to organization, but a tried-and-true litmus test is whether developers enjoy the kind of work they're doing enough to do similar stuff on their own time. Critically, we're not talking about developers that are actually doing work while off the clock (that's a quick route to "Burnout Avenue"), but instead, developers that like to code their own personal projects, just for fun. In fact, Google became somewhat (in)famous for their "20 percent time" policy that allowed employees to spend 20 percent of their time working on their own projects and ideas. In spite of what some reports claimed the past few years, the practice is still in full swing at Google, and has become common practice throughout the industry.
One of the most fundamental rules of software development is that adding more people to a troublesome, delayed project will not expedite the process but will, counterintuitively, slow progress down, which results in an even greater delay. Yet, time and again, executives and managers come to the seemingly obvious conclusion that more manpower equates to more output. This rule may be fruitful in certain realms of production, such as adding more hands on the widget factory line, but even in such fantasy scenarios, at some point those extra hands will get in the way of existing hands-in-progress, causing more trouble than benefit. Similarly, development is an especially complex production, which cannot be brute forced into submission -- software development is an elegant ballet where great ideas meet robust implementation.
Make every effort to avoid falling behind schedule or allowing your teams to experience major setbacks, but, should such a problem occur, one of the worst things you can do is try to bring on swaths of new people to get things back in shape. Outside of mass exodus causing a severe shortage of manpower, your focus should be on reshaping the practices and mindsets of those existing team members who are already intimately familiar with the project and its particular intricacies and requirements. If new blood must be added to an already-bleeding project, make sure it is added through a slow drip, as opposed to a quick injection straight to the heart.
This concept isn't limited just to your personal limitations as a leader, but should also be applied to the rest of the team, along with the problems that must be resolved within a project at any given moment. Put simply, the point here is to always keep perspective when approaching a seemingly intractable issue. Instead of trying to come at it headlong and tackle it in one go, divide it into smaller and smaller tasks, until the scope of said tasks seems manageable and can be handled by the team. If this divide and conquer technique is practiced frequently enough, there will never be any major, insurmountable problem.
Practice actively listening to team members and other managers, to better understand the ongoing status and progress of each team and project. Actively listen to comments, feedback, and inquiries, then be sure to circle back around with your own follow-up questions, such as "What did you work on? Did it come together? Why? Why not? What can be improved?"
Ultimately, your role when managing software teams isn't to manage projects or products, but to maintain the happiness and production of people working around you. As such, you should practice proactive communication, whether that be checking in with team leads or managers on a regular basis, or simply walking around and informally chatting with developers. It may sound formulaic to plan for and implement a technique as humanly basic and "walking around and talking to people," but, if practiced frequently enough and with genuine interest and effort, eventually you'll establish respectful bonds, if not relationships. This will allow and encourage team members to approach you with problems that might have otherwise gone unsaid. Whether these problems are project-related or personal, it's all positive if communication is proactive and not bottled up or hidden behind a facade of worker v. manager.
Managing multiple software teams can be challenging even in the best of environments, but nothing makes this task more difficult then when said teams are completely separated from one another, geographically, chronologically, and so forth. It probably comes as no surprise that studies have shown that teams perform much better when they are working in close proximity to one another. If at all possible, get all teams working in the same building, ideally on the same floor or even in the same workspace. This will dramatically increase the dissemination of information in an informal manner (i.e. around the "water cooler"). Coworkers that are working on completely different teams will tend to naturally share information about their projects, which will invariably lead to outside-the-box problem solving when a member of Team A suggests a solution to something troubling Team B.
Moreover, any animosity between teams tends to evaporate (by force, if nothing else) when teams are collocated. For example, forcing developers and quality assurance testers to work near to and with one another improves relations, while also dramatically reducing problematic code and error rates. In short, team members will scratch each others' backs.
Software development life cycles should not be thought of as an intense sprint, but rather, as a well-paced marathon. Forcing software teams to constantly produce at an excessive rate will quickly lead to burnout throughout the team, which will inevitably cause development problems, bugs in the code, and ultimately a lengthier, more expensive development process. Happy developers produce high quality code, so managing software teams should allow for a healthy work-life balance.
That said, this isn't to suggest there are never situations that call for an extra push. Colloquially, such phases are often referred to as sprints because, just as if you've been running a marathon at a steady pace for some time, toward the end you may need to kick into a sprint for the last little bit to get across the finish line in time. Most teams can handle occasional sprints, so long as these periods are the exception and are offset by moderate pacing the rest of the development life cycle.
Burnout can also occur as a result of spreading manpower too thin. While managing multiple software teams should provide opportunities for teams to work closely and sometimes with one another, it should not present situations where members are working on multiple projects simultaneously. Most people cannot cognitively juggle work on two separate projects at the same time, and attempting to do so will only be a detriment to both projects. Instead, ensure that teams are clearly defined and work is focused on the high priority project for each team.
Attempting to create complex, robust software without any form of requirements in place is like trying to erect the four walls of a house without any support beams -- even if you manage to rig things up, eventually everything will collapse onto itself. The problem with software requirements is that they are finicky, ambiguous, and complicated. Requirements may be over-scoped or underwritten -- one project may contain virtually no requirements documentation, while the next project may include thousands of pages of requirement info. Finding the proper balance between depth and dexterity is a real challenge for most software development projects.
With more traditional waterfall methodologies of project management, it wasn't uncommon for requirements to be thick documents filled with everything under the sun. This often led to projects that were so massive in scope and so packed with requirements that development progressed at a snail's pace -- often, by the time the final product was released, the customer's needs and/or the market had entirely shifted gears.
Consequently, modern Agile practices avoid pitfall this by swinging the pendulum the other way, often pushing requirements off to the side in favor of "getting some hands dirty." That said, requirements are an unfortunate necessity, because they ultimately usurp any and all software development methodologies you may have in place -- no matter how you develop software, the benefits and purpose of the software (and thus its requirements) will not change.
Requirements are particularly important when considering customer/user input, since customers rarely know what they want. Executives, managers, developers, and everyone in between will talk endlessly about all sorts of concepts aimed at measuring the software's progress and potential success, such as requirements, budgeting, scheduling, features, and so forth. However, the final verdict about whether the software your teams are producing comes from users: If people love your software, your project was a success; all else be damned. As such, you should try to manage with that notion beating at the back of your mind at all times: "Will people love this? Why or why not?"
While it's important not to force an untenable development pace (rather, go for a marathon approach), it's also just as important to establish the high quality standards you expect of your teams right out of the gate. Most developers will respond well to positive reinforcement in the first few days of a project, such that demanding a certain quality of code during this early stage, and giving praise for said quality, will encourage developers to strive for that level throughout the rest of the software development life cycle.
By nature of the work they do, developers tend to be logical and intensely focused individuals. Consequently, the last thing they need while deeply concentrating on a tough problem is to be bothered with random meetings or administrative busywork. As such, one of your roles as a manager is to reduce (or even eliminate) these potential distractions. This may take the form of setting aside blocks of time in the day for uninterrupted development work (should individuals want such a thing), managing accessible task lists and statuses, and effectively documenting product requirements well before the first line of associated code is to be written.
If infinite monkeys can eventually produce the works of Shakespeare -- in spite of the near-total pandemonium that would certainly erupt -- then it stands to reason that a smaller group of professional developers can produce valuable, robust software over a much shorter period of time. The challenge, as a software team manager, is finding the correct balance between ordered process and chaotic pandemonium. When too much order and procedure is injected, the whole thing grinds to a halt and little forward progress is achieved because of all the pseudo-red tape. Similarly, too much disorder also halts progression, as chaotic development leads to chaotic software and bugs galore.
The trick is to find that balance between the two, which generally begins with the idea that only the minimal amount of procedure should be injected into the process. For example, establishing a complex process by which software bugs are tested for, reported, tracked, resolved, retested, confirmed, and so forth is a daunting procedure to force onto every team member. Instead, the mantra should be to find the minimal level of acceptable procedure that can be used to accomplish the task at hand.
In this case, your team's error handling techniques need to elegantly scale alongside the rest of the project. Airbrake's powerful error monitoring software guarantees that your team won't need to worry about losing track of production errors! Airbrake provides real-time error monitoring and automatic exception reporting for all your development projects. Airbrake's state of the art web dashboard ensures you receive round-the-clock status updates on your application's health and error rates. No matter what you're working on, Airbrake easily integrates with all the most popular languages and frameworks. Plus, Airbrake makes it easy to customize exception parameters, while giving you complete control of the active error filter system, so you only gather the errors that matter most.
Check out Airbrake's error monitoring software today and see for yourself why so many of the world's best engineering teams use Airbrake to revolutionize their exception handling practices!
Managing software teams, especially in larger organizations, can lead to copious amounts of day to day busywork. Responding to emails, attending meetings, taking calls; all of it can quickly add up and suck up the majority or even the entirety of your day. This inevitably leaves no time for the real meat and potatoes of your job: Encouraging others to create software people love. Thus, it is vital to the success of your teams that you don't get bogged down in the minutiae of daily responsibilities, and always leave yourself enough time and energy to perform the broader tasks necessary for your role, many of which we've covered throughout this article!