Resources for a New Manager

The life of a new manager is full of challenges. You, like many people before you, might’ve gotten into this role without any management training. This article aims to assist you in building your own management curriculum to help you on your new journey.

The job of a manager is very different from the job of an individual contributor. As a manager, you are responsible for your entire team’s work, not only your own. You are accountable for the performance of your organization. You have to enable your team to produce more jointly then what they would be capable of producing alone.

According to Peter Drucker, the guru of modern management, the five elements of management are:

  1. Set objectives
  2. Organize
  3. Motivate and communicate
  4. Measure
  5. Develop people

All of the elements above are important. Unfortunately, many managers get themselves so busy that they forget about developing their team and themselves. As a manager, you get your work done through other people. And this means that you’ll be meeting with people, both formally and informally most of your time. Here are some of the meetings that you’ll need to have to succeed:

  1. Weekly one-on-one meetings with each one of your direct reports. An important part of this meeting is developing the people who report to you.
  2. Weekly project review meeting for all projects that are your responsibility.
  3. Weekly staff meeting with all your direct reports. The purpose of this meeting is to ensure that your entire team is on the same page with the issues that affect your organization.
  4. Monthly department staff meeting (if you have multiple managers reporting to you). During this meeting you have a chance to communicate with the entire organization those topics that pertain to all of them.

The following are resources that you can benefit from as you are developing yourself and your team.


The following podcasts are excellent learning resources:

Manager Tools: Mark Horstman and Michael Auzenne have been producing this podcast since 2005. They provide ready-to-use, practical, and detailed advice on topics ranging from “How to do a handshake” to “How to do your one-on-ones.”

Career Tools: Also by Mark & Mike of Manager Tools. Detailed, practical advice on managing your career one day at a time.

HBR Ideacast: published by the Harvard Business School, provides commentary and advice on a variety of business topics.

Management Books

There are many books targeting the new manager, so picking one is not so easy. Here are some to help you get started:

First, Break all the Rules, by Marcus Buckingham and Curt Coffman. The authors report the findings of a multi-year Gallup survey. Their book represents the conclusions drawn from interviews with eighty thousand managers representing one million employees. Their teams sifted through the data to find which criteria separate the best from the rest. Their advice helps you focus your first actions, and provides a roadmap of what to concentrate on as a manager.

The 7 Habits of Highly Effective People, by Stephen Covey. Free Press. 2004. The undisputed front-runner work  with lessons for developing yourself and your team. Covey’s words of wisdom are just as true today as they were over 20 years ago when he wrote them.

The Essential Drucker, by Peter Drucker. Harper Paperbacks. 2008. This is a good summary of Drucker’s work. He is the “guru of gurus” when it comes to management. He is able to clearly articulate topics that others struggle mightily with. You learn from him about just about any management topics that you will come across during your career. Feel free to pick up any other book by him, including one of the thickest ones, called: Management.

For more books look on my reading list.


Magazines may be old media, however the following have good web editions as well. The Harvard Business Review keeps you up-to-date with both academic and hands-on practitioner articles. The Strategy-Business magazine adds to the mix consultant written articles with sound advice. The Economist magazine keeps you up-to-date on world business and politics.


There is an abundance of material available to help you become a great manager. Commit yourself to using them. You may have a lot to learn, however it will be a lot of fun. It is only appropriate to end with Drucker’s advice to all of us: you accumulate knowledge with one reason in mind, to use it to help your team get better results:

The ultimate test of management is performance. Achievement rather than knowledge remains, of necessity, both aim and proof.

Peter Drucker

Software Development Strategy

strat-e-gy: a plan of action or policy designed to achieve a major or overall aim.

The New Oxford American Dictionary

The dictionary definition points us in the right direction. The software development strategy is your highest level plan for achieving your software project’s objectives. According to Watts Humphrey, the strategy is “the order in which product functions features or requirements are defined, designed, implemented, and tested.”

What does this mean? This means that the plan of action part of your strategy lays out what you build first, what you build next, and so on. It also lays out how are you going to validate the strategy. The strategy also lays out the policies for risk mitigation and decision making. Sections of the strategy may exists both along the developer – customer continuum and also along the system abstraction levels continuum. For details about these continuums see: Multilevel Planning and Component-Based Development.

The System Architect is responsible for the overall strategy. The strategy has to be sound enough that designers and implementors working on parts of the system receive from it the necessary guidance to aid their technical decisions. A well conceived strategy pushes the decision making down to the lowest possible level, closest to where the problems are encountered, while at the same time provides for the oversight necessary to build a coherent system.

Accompanying the development strategy is the testing strategy. The testing strategy focuses on the various testing activities, including the system validation and verification activities. It is constructed similarly and serves the same purpose as the development strategy, only for testing. The owner of the testing strategy may be the System Test Architect, if there is one, otherwise this is also owned by the System Architect.

Why do you need a strategy? Without a strategy it is difficult, if not impossible, to execute an iterative, incremental development process. The strategy ties the iterations into a coherent whole, and allows the team to move confidently toward the goal. Your first attempt at creating a strategy may feel awkward, but with practice you’ll get better at it. Why don’t you get started today?

Essential Software Design Documents

When it comes to documenting software designs, there are many practices ranging from a quick whiteboard sketch to fully specified UML models with OCL to tens of pages of written text. Here is what I found that worked best based on most projects that I have been part of:

  1. Static Structure Diagram: this is a class, module, or package diagram. This diagram (though often it is more than one), shows the relationship between parts of the system at a given level of abstraction. The relationships shown include: containment, references, parameters, inheritance, and so on. Record on the diagram indirect and implied dependencies with a note.
  2. Initialization Sequence Diagram: shows how the system is brought up from being on the disk into the operative memory and “ready to transact business” state. This diagram is part of the dynamic model of the system. It shows the order of messages sent or method invocations. Often also shows resources allocated to get up and running.
  3. Shutdown Sequence Diagram: shows how to put back the system or component into the proverbial “bit bucket.” Must complement the initialization sequence diagram and demonstrate that the system is not loosing resources during its operation.
  4. Sequence Diagrams, Activity, and/or State Diagrams for the key “business” of the system or software part. All other activities took place just to get ready to do the business of the system. Now it is time to get the business done. The key sequence diagrams show what the system does, how it provides the value that it is expected to deliver.
  5. Brief Design Commentary to explain the “why” behind key structural and behavioral elements and decisions. This is usually one Wiki page that ties all other documents together into a coherent whole.

Each of these can be created at “every zoom level” in the system. This means that if you are developing a component-based system, then you would have this set of design documents for the system, subsystems, modules, and components. Within each you represent the unique concerns of each software part.

Read Applying UML and Patterns, 3rd. Ed., by Craig Larman for an in-depth course on how to do object-oriented analysis and design on an iterative software development project. As you do design more, review your results, learn from your mistakes, and over time you’ll get better at it.


  1. UML basics: An introduction to the Unified Modeling Language, from IBM developerWorks, 2003.
  2. Allen Holub’s UML Quick Reference. 2007.
  3. Book excerpt from OOAD with Applications, by Grady Booch.
  4. UML Modeling in Color, from Wikipedia.

What’s the Status?

Regardless of the organization you work in, this question probably comes up daily, but at least weekly. To answer the often dreaded status question you need minimum 4 pieces of information.

  1. When did the project start? This is the Start Date.
  2. When is the project expected to end? This is the Expected, Planned, or Estimated End Date.
  3. Where should we be today based on the plan? This is the Expected, Planned, or Estimated % Complete.
  4. Where are we today? This is the Actual % Complete.

If you have the above information then you are able to judge how well you are doing relative to what you said you’d be doing. There is a lot more to project management, but this is a good start.

To get started make a plan for the work you intend to do this week. Write down at least 2 tasks for each day: one task for the morning, one task for the afternoon. This gives you a total of 10 tasks for the week. As you check off the completed tasks, you’ll see your progress bar move. Once you are able to plan your work for a week, plan the next month. Collect your data and adjust.

There is no need for you to wait for your entire organization or team to start doing this. You can get started alone. You’ll be surprised how much better your work will go and how much better you’ll be able to help your team.

Knowledge You Expect To Learn

Writing an individual project plan for your project work can be difficult. The secret of creating a workable task plan is to consider not only the work you will complete, but also the knowledge you expect to learn as you perform each task.

As you complete tasks from your plan, two things happen:

  1. you create deliverables, and
  2. you learn.

On a short project you may not be able to learn much. If your project is short, only a week long, then to improve the odds of success, you have to make a plan considering only the knowledge you have at the beginning of the project. One week is generally not sufficient to learn something of consequence that will help you get your project done on time. When you make your plan, focus on the deliverables created by each task. When all tasks are done, the output created must add up to a completed project.

If you notice that you have lots of short projects, then you need to take a more systematic view, and find ways to include learning into your work. Teams that fight fires, each fire being a short project, tend to believe that they don’t have time to learn. They feel that there is never time for learning. However, firefighting is really one long project with lots of short iterations. More on this another time.

On a longer project you must learn. If your project is longer, 2 to 4 months or more, then you must factor learning in the work you are planning to do. More so, you may even want to include deliverables that allow you to verify that learning has occurred. Such deliverables are prototypes, proof of concepts, sample code that you create to demonstrate to yourself (sometimes to others) that you indeed understand the work, the requirements, the API, or some other things related to the project.

Outside of explicit learning-oriented deliverables you also must factor learning into the regular project tasks. Let’s look at an example. You make a plan to create component A and component B. B will be using A through A’s public interface. However, at the time of planning you don’t know exactly how that interface will behave. So you plan for learning.

The knowledge you expect to learn is that you will know exactly how A will behave before you start work on B. This knowledge is pre-requisite for doing the correct work on B. Part of the tasks for creating component A include the writing of A’s unit tests. When you perform this task you will learn how to call A through its public interface. By the time you start work on B, you will have acquired the necessary knowledge to perform the work on B. You didn’t have this knowledge when you made the plan, but you planned for the learning to occur by the time you needed it.

After some practice, factoring into your plans the knowledge you expect to learn will enable you to make more detailed plans for longer horizons with higher accuracy. The challenge is that you need to change the way you think about project work. Plan for learning. Make learning an explicit and expected outcome of each task. You’ll surprise yourself, and your team. Your plans will become ever more accurate.