In the introduction to last month’s Management Monthly newsletter, I wrote about the fact that my philosophy for both management and personal productivity (which I view as a “managing myself” sort of thing) is one of continuous improvement. As I was writing that introduction, I realized that I have never written about how to get started on a continuous improvement cycle for management. I’ve written a bit about how to get started on improving personal productivity- I think you start by collecting data on how you currently use time, analyzing it, and then fixing the problems you find. What is the analog for management?
I’ve had to really think about this. I like data- hence my use of time tracking as a starting point in improving personal productivity. But I also think that some really important things are hard, if not impossible, to measure. In the personal productivity example, it is my actual productivity. I have metrics I can use to help me gauge my productivity, but the final answer is a fuzzy one: do I feel like I was as productive as I should have been over the time period I’m analyzing?
I think a similar situation applies in management, but in that case the all important fuzzy answer is even harder to get to, because what other people think matters more than what I think. If I’m looking at my performance as a manager of a group, the most important thing is whether the environment I help shape supports my team, both in getting their work done and in living the rest of their life. I’m not a successful manager if I make it possible for the team to get a lot done, but only at the expense of their life outside work. If I’m looking at my performance as a manager of projects, the most important thing is that I deliver the right things, on time, and in a sustainable manner. I’m not really a successful project manager if I bring my project in on time but burn the team out to the point that large numbers of them quit as soon as the project is complete.
That’s all well and good, but how do I know how I’m doing? I could ask my team, but the chances of getting an honest answer are slim, and sadly, the worse my performance is, the less likely my team is to tell me. I could ask myself, but I’m human and no less prone to self-delusion than anyone else. My boss is also working from incomplete information, and is unlikely to be able to tell me.
I don’t really know the “right” answer, but here is what I do:
1. Look for metrics to give a general sense of how things are going.
Looking at home many projects finish on time is a good metric- it covers a lot of different possible issues. However, it can be a bit of a lagging indicator. Things can be going poorly for quite awhile before projects start coming in late.
Turnover rate is another good metric that reports on a lot of possible issues, but again it lags. Ideally, I’d like to know about and fix issues before anyone quits.
Other possible metrics include how many of my team are considered “top performers,” how often meetings run late, and things like that. These report on more narrow sets of issues, but can perhaps provide useful information earlier.
2. Try to gauge how my team feels.
Are they generally happy? Do they joke around and seem relaxed at work? If I know other managers who work closely with my team well enough, I ask them for their impressions.
I also listen really carefully during my 1:1 meetings with my team. People will often drop hints about issues that they won’t raise directly. If I pick up on a hint, I should track it down and try to understand what it means. I can’t always do this by asking the hint dropper directly, but I can usually find some way to figure it out.
3. Try to be honest with myself about what all of this means.
There will always be room for improvement! I can’t improve if I can’t figure out what isn’t working, though, so I need to try to honestly assess what is and isn’t working in my management methods. The first two steps can give me information that indicates problems exist, but they won’t really give me understanding about what those problems are. The only way I know to get to that understanding is to try to figure out what the clues I gathered tell me.
I think the most important thing is to listen to what the data are saying, instead of trying to fit the data to what I want to hear. I have to start by trying to understand what is happening, with no preconceptions about whether it is acceptable or not. Maybe there is a reason outside of my control that three team members have quit in the last six months… but maybe it is a sign that something is wrong. If I jump to justifications before I really analyze the information I have, I may miss a chance to fix a problem.
4. Make changes aimed at fixing the problems.
Once I’ve identified problems, I can look for solutions to fix them. This may take some research, or it may just take reminding myself to do things I already knew I should be doing.
This still feels unsatisfactorily vague. Perhaps an example will help clarify this approach.
A few years ago, I noticed that my projects were all finishing late. I have always prided myself on being able to bring projects in on time, so multiple projects finishing late is a big red flag that something is not working.
So that was step 1: my key metric of number of projects finished on time showed a potential issue existed.
The next step was to check in with my team. I paid extra attention during 1:1s, and also tried to steer the conversation to work load and similar topics. And I listened carefully to what my people were saying, and also what they were leaving unsaid. After doing this, I suspected people had too many things on their plate at a time.
Next, I thought about why people had so much on their plate. I realized I wasn’t doing my job of protecting them well enough. I wasn’t making priorities clear enough, and I was allowing too many external interruptions.
I tried to be a better gatekeeper on the external interruptions, and I addressed the problem with priorities by adopting some methods from kanban.
The key thing in this example is that the metric alone wasn’t enough to tell me what to do. At a different job, I’d also had problems finishing projects on time, but in that case the problem was in getting decisions made, which required different methods to address.
This was the first time I’d tried using kanban methods, so no doubt there was a lot of room for improvement in my implementation. However, both my own personal philosophy and the philosophy of kanban emphasize continuous improvement, so that’s fine. You start somewhere, and you work to always be getting better. The most important thing is to make a start.
Be First to Comment