Communicating with Software-Development Managers

Putting Yourself in Your Manager's Shoes

Put yourself in your manager's shoes and try to determine what he or she really wants to hear from you. The main thing any manager wants to hear is that you will deliver the promised software on time, with the expected functionality, and without serious bugs.

Unfortunately, many projects are late, lack some of the expected functionality, and/or have a significant amount of serious bugs. If you find yourself headed towards these problems, you won't be telling managers what they want to hear. Instead, you will be trying to explain why the project is behind and/or buggy. Your manager might be sympathetic, which is helpful if you are looking for a shoulder to cry on. However, if you are hoping to get whatever it is you need to meet your deadlines, you need to aim for respect, not just sympathy.

So, if you need guidance, questions answered, or new infrastructure components, how should you communicate with your manager in a way that builds respect and helps you get whatever you need to complete the project as expected? The answer really depends on what type of manager you have.

Managers: The Good, the Bad, and the In-Between

Here are some clues that you have a good manager:

• Good managers truly know what you are doing. They can understand what developers are doing without micromanaging. They do not need to nitpick because they understand the technical details. If you ever try to deceive them by showing them a lot of code that is not quite right, they will call you on it and put you in line.
• Good managers can understand what you are doing at a high level, and guide you in directions that help you complete your projects. They give you ideas about how to implement functionality, but provide you the freedom to choose whatever strategy you think is best. However, they also expect you to be able to explain and defend your choices, if asked.
• Good managers check that you are following best practices. They not only establish requirements for metrics, code testability, and test-case creation, but verify that these requirements are actually being satisfied.
• Good managers do not believe something unless they have facts to support it. They will not, for example, believe that code works unless its functionality can be verified. They also will not believe you are on track to meet a deadline unless they see you are progressing as expected on the project.
• Good managers rarely have meetings where everyone gathers to boast about what they have accomplished. Instead, they sit with you, read your code, and offer advice in hopes that you will learn from that advice. If you do not learn, you might get fired, but at least you will know why you were fired.
• Good managers understand that writing software sometimes leads to dead ends and mistakes, and that you occasionally need to rethink and rewrite code. As software evolves, good managers give you the freedom to rewrite code when you think it makes sense from a design perspective.

Talking to this type of manager is easy. Simply explain what you are trying to do and why you are trying to do it. If you construct a good defense of your choices and leave out the excuses, good managers will guide you on the project and ensure that you have the supporting infrastructure needed to complete it successfully. The manager should be responsible for providing the infrastructure that supports your role within the group as well as the proper group behavior; managers need this infrastructure to assess the group's productivity.

Here are some clues that you have a bad manager:

• Bad managers do not have a clear understanding of what you are working on—at a high level or a technical level.
• Bad managers micromanage developers. They use multiple project-management tools, producing volumes of reports and spreadsheets and forcing you to record a lot of information that is irrelevant to your code and design. Basically, they try to generate as much paperwork as possible, then hide behind it when talking to higher management.
• Bad managers do not have a way to accurately assess the project status, but hope for the best.
• Bad managers never think about things that would help you do your job because they do not understand what you need to do, how you need to do it, and how you can be helped.
• Bad managers panic when the project is in trouble, get the team revved up, but do not know how to save the project.
• Bad managers are not specific about what needs to be done.
• Bad managers follow developers instead of leading.

Communicating with bad managers is difficult. When you need to talk to them, the best strategy is to be a politician. Always provide some information that they can use to look better in the eyes of higher management. If you need to ask for assistance or for infrastructure components, do not be overly optimistic. These managers do not have a deep enough understanding of what you are doing to offer you much valuable guidance; you are likely to get more useful advice from fellow developers than from these managers. Moreover, these managers will make it very difficult for you to improve your infrastructure. They are typically afraid to ask their superiors for additional funding, and will demand that you produce insane amounts of product evaluation paperwork before they even consider asking for the purchase approval. If you have your heart set on getting new software, hardware, or training, be sure to collect volumes of literature about it and set aside a fair amount of time for evaluation.

If you have a bad manager, you might find some consolation in the fact that these managers typically do not last long. It is very possible that the project they manage will be delivered late, without the expected functionality, and with a lot of critical bugs. At that point, the manager is likely to be fired. However, sometimes the project developers' jobs are also in jeopardy. Just in case a new manager or higher-level manager walks in one day looking for a reason to eliminate everyone that worked on the bad manager's failed project, make sure that you are ready to communicate—and prove—that you have been writing good code and making adequate progress.

In most cases, your manager will probably be neither the saint nor devil I just described, but rather have some traits of each. In this case, you can mix and match the aforementioned communication strategies as needed, and apply some general communication strategies as well.

Virtually no manager wants or needs to hear about your projects and problems in excruciating detail. The better managers do not need this detail because they understand what you are working on, and the worse managers typically would not understand the details anyway. Moreover, all types of managers are typically pressed for time. Before you communicate with any manager, take a little time to think about the situation from a higher level and decide how to abstract the essence of your question, issue, or request.

At the same time, try to articulate what you really need to boost your performance and the entire group's performance. If you need automation, figure out why you need it and explain this—in high-level terms, of course. Do not expect that you can—or should—produce a return-on-investment study (ROI) on every infrastructure purchase that you request. Think about return on investment in this way: Developer salaries are the highest cost in software development; so anything that makes you more productive is going to help the company get more for its money. In other words, your best ammunition for requesting a purchase is to explain how it will save you time so you can produce more code and better code. By showing your manager that you are taking the initiative to improve your productivity, you are likely to gain respect as well as unconditional support for whatever training or product you requested. For instance, consider how likely a manager would be to support a purchase request if you explained that the requested product or training would help you spend twice as much time writing code and thus be 100 percent more productive. In fact, in today's economy, being able to effectively lobby for tools that increase productivity can mean the difference between keeping your job and losing it. In this economy, the bottom line is everything to management, and managers seeking to maximize their bottom line are turning to overseas developers who are willing to develop code for significantly lower pay. If you successfully increase your productivity and widely communicate your desire to be more productive, managers will be more likely to recognize that you are giving them a good return on their investment (in your salary), and keep you on board in these unstable times.

One last tip: Never promise to meet a deadline that you know is impossible, then postpone the delivery for hours, hoping that the product will miraculously be finished and flawless. If you have a lot of bugs or if you are behind on implementing functionality, the best thing to do is identify why you are off track, think of some possible solutions, then approach your manager as soon as possible. You will save your manager from the unpleasant job of making a last minute announcement that the product is not going to be ready after all. Moreover, you will likely save yourself a lot of grief because most decent managers will offer you some guidance that will help you get your work back on track.

DDJ