Dr. Dobb's | Software Manager Basics

Software Manager Basics

Most software managers didn't start out as managers, but began their careers as developers.

May 16, 2006
URL:http://www.drdobbs.com/architecture-and-design/software-manager-basics/187203587

Mark is a management consultant with 25 years experience in the software industry. You can check out Mark's blog at www.heavenstone.us.

Most software managers began their careers as software developers. They either had some ambition, some skill recognized as good management material, or were in the right place at the right time. No one I know who manages software was trained to be a manager.

Managers serve multiple masters: The customer, the company, their own manager, their employees, and themselves—and each will tell you what they mean by a good manager. You are stuck with balancing those efforts.

For instance, when I was interviewing for the job of running Solaris Engineering at Sun Microsystems, I asked my interviewers what they would consider success. The (somewhat strange) answer I got was that if they were better managed, it would be a success.

So here's what we have so far: You haven't been, and probably won't be, trained for a job that has too many bosses who either don't know what they want or want everything! What do you do? For starters, you go back to basics—execution, communication, and empowerment.

Execution

In the end, you, your team, and your organization will be rewarded if you develop and release software that customers need in a timely fashion. This is what I label as "execution."

Here are 10 questions involving execution that let you grade yourself:

Do you have your customer's requirements?
Do you have an approved budget?
Do you have an approved roadmap?
Do you have an approved schedule?
Are you delivering the product on time?
Do you hire developers in a timely fashion?
Is your team capable of dealing with change?
Are you capable of keeping your team focused and resisting change?
Do your customers encounter a lot of quality issues with released products?
Do you and your team measure how well you do your work on a regular basis to find ways to improve?

Someone once asked me what they should do when management wants something that is unreasonable or impossible. My answer had two parts: First you must ensure that management is informed and understands that this is unreasonable or impossible, and second, you must decide if you can disagree and commit. If you can't, then you need to examine your own career options.

While the second and more dramatic answer may have caught your attention, it is the first answer that leads us to the next basic skill—communication.

Communication

As a manager, you must communicate with each master you serve. For each action or event that affects you or your team, you should be thinking about to whom and how you communicate it. It doesn't matter whether the item is positive or negative.

You must also learn to communicate in different ways with different constituents. For example, you might do formal presentations for your boss's boss, but be more casual with your direct reports. Or you might use e-mail for officially documenting agreements between you and your peers, but need face-to-face meetings to explain that agreement with its rationale and implications to your developers.

Here is a second set of 10 questions with which you can grade yourself on communication:

Does your team understand your company's strategy?
Does your team understand engineering's roadmap?
Does your team understand why the roadmap meets the goals of the strategy?
Do you have regular communication meetings and e-mail with your team?
Are people on your team willing to tell you bad news?
Do you hear information about your team from your team before you hear it from others?
Do members of your team communicate with each other and the rest of the company in a respectful manner?
Do you provide information to your boss before he or she has to ask for it?
Do other people in the company know what your team is doing and accomplishing?
Do you communicate in a positive fashion?

How you communicate is as important as communicating itself. The attitude of your words, the respect for those with whom you communicate, the body language or inflection of voice, or choice of words all contribute to whether you communicate well. Cynicism, sarcasm, and negativity could remove all of the advantage you might otherwise realize by communication.

Unlike being a developer, a large part of your job is interacting with people. Just as my final words on communication reflect a care you must have in communication, you must also show care in how you treat your team and peers. I searched for the word that represents this skill, and "empowerment" came to mind.

Empowerment

You can't do it all yourself. You must develop an organization that breeds the next managers and leaders, and an organization that can focus, innovate, and succeed.

You should communicate requirements, work with your teams to develop plans, and then let them execute those plans. If you dictate plans or micromanage the execution, your teams will not succeed. They must feel ownership. Only you can make them feel ownership.

With this in mind, here are 10 questions on empowerment:

Does your team develop and buy into their schedules?
Do you avoid micromanagement?
Do you delegate tasks and let your reports proceed without interference?
Do you make it clear what your employees are accountable for?
Do you provide leadership opportunities for your employees?
Does your team have a sense of urgency in addressing issues?
Do you set clear roles and responsibilities for your employees?
Do all the members in your team know what they need to accomplish each week before they can go home for the weekend?
Do your developers understand the difference between accountability and micromanagement?
Do your developers consider your organization a positive work environment?

Empowerment also requires accountability. If you delegate without some checks and balances, you and your team may never accomplish your goals. Do not misconstrue accountability with micromanagement. Many developers take any accountability as micromanagement and you must disabuse them of that notion.

Here are some signs you are micromanaging:

Ignoring previously agreed upon reporting points and asking for status more frequently.
Getting angry with people for missing deliverables.
Constantly changing working assignments.
Dictating implementation instead of requirements.

You have to give people a chance to do their jobs in a positive environment. You need to look at problems as just things to be solved. You need to engender trust so you can get the truth when you ask for status. Empowerment also means letting your employees help develop their own schedules. While you can set a goal for a release, you must rectify any mismatches between the goals for the content of the release, the goals for the timeframe for the release, and the resources at hand.

You always have the same four things you can adjust in making a schedule—resources, features, dates, and quality. If you go back to the same thing each time you are planning a release in order to make your dates, your company can get out of balance. For example:

If you remove too many features, you won't have a competitive product.
If you add too many features, you won't make your dates.
If you scrimp on quality, you'll get a bad reputation.
If you wait until the product is perfect, you'll miss the market window.
If you make your engineers work extra hours all the time, they'll burn out.
If you add too many resources, you can run out of money.
If you slip the schedule, you make it hard for the sales team to sell and you might miss a market window.

When you define your product or release correctly and develop aggressive but accomplishable schedules, you may find resistance. The industry is so used to unreasonable schedules and unreasonable goals that many people will think your team is not working hard enough because there is no crisis!

Companies and their customers are best served by creating teams and products that can serve them over a long period of time. The sky is always falling somewhere. You should be aggressive and demand the best from your developers, but you should not abuse them as a resource.

Final Words

Obviously, each question posed here may spawn many more questions, and they may also have responses somewhere between yes and no. Take the time to answer them—and manage wisely.