Software Manager Basics

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:

1. Does your team develop and buy into their schedules?
2. Do you avoid micromanagement?
3. Do you delegate tasks and let your reports proceed without interference?
4. Do you make it clear what your employees are accountable for?
5. Do you provide leadership opportunities for your employees?
6. Does your team have a sense of urgency in addressing issues?
7. Do you set clear roles and responsibilities for your employees?
8. Do all the members in your team know what they need to accomplish each week before they can go home for the weekend?
9. Do your developers understand the difference between accountability and micromanagement?
10. 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.