Basic Principles for New Managers
Let’s talk about what makes a good weekly report for a manager. We’ll look at a typical bad report from an inexperienced new manager, then contrast it with a good report. This will set the stage to introduce you to some important conceptual building blocks of the management world: projects, metrics, and taking ownership.
At Relationship Hero, we pride ourselves on training managers to write good weekly reports. If you’ve never been a manager before or never written a weekly report to your boss, I hope this explanation will be a helpful resource.
A Bad Weekly Report
Let’s start by diving into an example report from a new manager who’s used to being an individual contributor. They usually email me something like this:
* Wrote 17 pages of informational materials and emailed them to the appropriate people
* Called all of our suppliers and purchasers to speak about next month’s orders
* Organized the company bookshelf by jacket color
What does this report tell me? It lists their tasks, which merely indicate how they spent their time. If the tasks seem easy, maybe I’ll think they’re being lazy at work. If the tasks seem hard, maybe I’ll think they’re a highly motivated worker who is putting in 16-hour days. But guess what? It doesn’t matter!
What matters is what results they’re getting. Is organizing the company bookshelf a high-priority task? If not, then I would rather have them work a 4-hour week and do something that matters, instead of a 100-hour week organizing the bookshelf. So their report is focusing on the wrong stuff here.
A Good Weekly Report
Here’s how this manager should have written their report for this same week:
Creating an Instruction Manual72% of all sections are now written (was 60% last week). Wrote 17 pages this week.Completion date: Still March 3
**Repainting Office Walls**Stalled this week due to unexpected snowstormCompletion date: March 15 (was March 11)
**Warehouse Reorganization**All supplier and purchaser data is now recorded in our spreadsheet (task 3 of 5)Completion date: Still March 20
Believe it or not, this report is about the exact same week as the bad report. But clearly there are major differences.
First, the good report is organized by the company’s projects like “Creating an Instruction Manual”, not by the employee’s individual tasks like “wrote 17 pages”. In fact, “wrote 17 pages” is the least important thing in this whole report, just a minor note at the end of a section. The bad report had made it seem like such an important piece of information to share, but in the good report it could even be taken out entirely.
Second, the good report is about each project’s status and progress. For the “Creating an Instruction Manual” project, its status is that its completion deadline isn’t slipping; it’s still on track March 3. Its progress is that it’s 72% completed, up from 60%.
The “status” is a claim you’re making about your ability to deliver the project’s end result at a certain time, and the “progress” is evidence in support of that claim. Seeing the progress makes me more convinced that you’re actually going to deliver on the completion date you’re promising.
Note that while both status and progress are important, status is more important than progress. Hypothetically, if you were saying that the completion date is holding firm at March 3 but your progress only went from 60% to 61% this week, I’d figure you must be planning to kick things into higher gear soon, like by pulling an all-nighter on March 2. As long as you deliver the project in an acceptable state on March 3, that’s fine with me, I just appreciate knowing the progress to date or lack thereof.
Ok you’ve learned that a good report is organized by projects, and tracks each project’s status and progress. Now you can see why the first report is bad. For example:
Wrote 17 pages of informational materials and emailed them to the appropriate people
In order to process the significance of “wrote 17 pages this week”, I’d have to know how many pages you’d already written before this week, and how many you have left to go. Do I know these things off the top of my head? No, and I don’t want to know, because I’m not the one managing the project. I just want to know the project’s status and progress.
Also look at the “Repainting Office Walls” project, where nothing happened this week. It’s still a project that I asked you to manage. It was never even mentioned in the bad report, and this is a common mistake that new managers make, which makes me feel like they are “dropping projects”.
You might think that if no progress was made on a project this week, then there’s nothing to report on. But without seeing the project and its status written in your report, I’ll worry about whether it’s still on track to get done by its March 11 deadline. In our example, the manager realized (I hope) that the completion date for Repainting Office Walls would probably end up being later than March 11 due to an unplanned lack of progress, but their bad report didn’t provide any visibility into the project whatsoever.
Tada!
By the way, did you notice that the good report doesn’t contain anything about organizing the bookshelf? Why is that?
…It’s because I never assigned them to manage a project relating to our bookshelf.
If organizing the bookshelf were somehow related to the “Repainting Office Walls” project, like if we’re trying to make our walls match the colors of our books, then you should report that the “Repainting Office Walls” project has made some progress toward completion this week. Otherwise, not every task that you do needs to show up in the report. If you report every task that you do, it then you’re just focusing on how busy you are, but not how productive you are in the big picture.
Know Your Projects
Knowing your projects is key to organizing your weekly reports, as well as to actually prioritizing and doing your tasks.
In the bad report, I can see from your reported list of tasks that you’ve been taking actions to help out on various projects. But as a manager, you need to fundamentally shift your thinking to be about the projects instead of the tasks.
The corporate matrix has just been revealed to you
Before you do any task, you should be clear on which project you’re managing, and what the definition of “success” is for the project. If you ever don’t know the answer, then you should talk to your boss, and maybe you’ll learn that there is no answer yet! So then you’ll need to work with your boss to define your project. Defining projects is actually an important part of being a manager.
Once you know what projects you’re managing, consider how your tasks relate to your projects. For example, let’s say you’re a manager at Relationship Hero and a task you want to report on is “recorded an example of taking a new client’s phone call”.
Why did you do that task?
…Because it helps train our relationship coaches to do their job.
Ok but what I’m really asking is, what project did you do it for?
…You did it for the Phone Operations Training project, which is a sub-project of a larger project that we call Operational Skills Training & Maintenance.
So in your report, instead of writing an action you took (“recorded an example of taking a new client’s phone call”), you’ll want to first identify which project you’re reporting on (Phone Operations Training) and its status and progress. After that, sure, you can potentially mention the actions you took if you think it’s valuable to do so.
Know Your Metrics
What does it mean to report on a project’s “progress”? Here’s an example of progress from the good report:
Creating an Instruction Manual72% of all sections are now written (was 60% last week). Wrote 17 pages this week.
Presumably, when the Creating an Instruction Manual project first came into existence, you and your boss had agreed that the percentage of sections written is a good measure of progress for this particular project.
(Note that if there are other important pieces to this project, like if you’re also responsible for getting each section reviewed with the engineering department, then your project’s metric should reflect the progress of those other pieces too; it shouldn’t just be “percentage of sections written”.)
Another example:
**Warehouse Reorganization**All supplier and purchaser data is now recorded in our spreadsheet (task 3 of 5)
For the Warehouse Reorganization project, you had originally sat down with your boss and written up a list of five tasks that must be done to make the project complete. Now, in your weekly reports, your metric for the project might simply be the number of these tasks which have been accomplished.
Different projects have different measures of progress, known as metrics. Defining a project’s metrics is part of defining the project itself, which, again, is an important part of being a manager.
Think of NASA’s Mission Control:
Tracking a project’s metrics
These people in the picture are holding their breath during a rocket launch, hoping it’ll reach its destination successfully, because there’s always a big risk that it might veer off course or blow up.
That’s how your boss feels when you’re managing a project. The boss knows that the project has its own guidance system on board (you’re managing it), but they’re still holding their breath and hoping that the project doesn’t veer off schedule or create other headaches.
From looking at the picture above, we know somebody at NASA decided that the biggest TV screen at mission control should show a map of Earth with a bunch of curved green lines on it. No doubt this visualization is highly informative to Mission Control about the rocket’s current status and progress. A project’s metrics are like the TV screen that your boss (and you) are watching at Mission Control.
In our example good report, you can see how each project’s metrics can be reported with plain text. But when there are a bunch of different metrics, it becomes hard to digest them all in plain text. That’s why managers often report their metrics using graphs and other visualizations. These metrics dashboards are just like the monitors at Mission Control.
Take Ownership
The bad report was written by an employee who considered their actions to be their accomplishments. This is characteristic of an individual contributor, not a manager. The difference between an individual contributor and a manager is that the individual contributor’s accomplishments are the tasks they perform, while the manager’s accomplishments are the projects they own and their metrics.
Taking ownership means putting yourself in a position to take credit for a project’s successes, and also to be held accountable for its failures. It means the buck stops with you and cannot be passed upwards/downwards/laterally.
The author of the bad report is evidently not taking responsibility for the effect that their week’s actions have had on the company’s projects and success metrics. They’re passing the buck to their manager.
Your project
When you take ownership of a project, it means you’re your own mission control, constantly monitoring your project’s status and making all necessary adjustments. Occasionally, you’ll propagate an alert up the chain that a deadline will be missed or help is needed, but otherwise your boss doesn’t have to worry about your project because they know that you’re owning it.
So, back to your weekly report. Now that we’ve explained all the relevant principles, it boils down to just a couple simple steps:
-
List all the projects that you ownIf you don’t know what they are, you need to clarify that ASAP to make sure that your actions are not going to waste.
-
Report on each project’s status and progressIf your progress metrics are too numerous or too complicated to digest in plain text, then make some kind of dashboard visualization.
By the way, this advice is not just for entry-level managers. Every senior manager, director and executive in the company is working from the same basic principles outlined here — the only difference is the scope of their projects. When you take ownership of bigger projects, you’ll get a promotion.