June 29th, 2010 by Mark Ramm
Lean Manufacturing people go around saying “it’s always a process problem.”
Meanwhile Gerry Weinberg, who wrote several books that I love, and gives lots of great advice, including the some of the best advice I’ve ever read about how to give advice, says “every problem is a people problem.”
So, which is it?
Are bad things that happen the result of bad processes, are they the result of things people do?
I’ve been party to a bit of discussion about this in the last month or two, and in the end it’s all pretty silly.
Processes are created by people, implemented by people, and are designed to accomplish the goals of people.
People run processes!
So, whenever something is broken, it’s people who will need to find the problem and fix it.
People can and do think of ways to improve processes everyday, but I’ll eat my shoe if you find a process that thinks of a way to improve people.
But there’s still a HUGE problem.
Modern companies seem to have a persistent failing — they look for people to blame when something goes wrong — and ignore the context in which those problems happened.
When something goes wrong, fire some people, and replace them with new people who make the same mistakes all over again.
Sometimes you “get lucky”.
The company might get lucky and find a person who’s able to raise awareness, reveal the larger contextual problems, and succeeded in spite of the fact that everything’s stacked against her.
More often than not though, the poor new guy doesn’t see the systematic pressures that caused everything to fall apart, at least not until it’s too late.
Sometimes replacing what’s broken isn’t enough.
Sometimes it’s the equivalent of a mechanic replacing your car’s engine several times in a row, because it keeps burning up — without ever checking to make sure oil is flowing normally, and the cooling system is working.
The easy way out.
It’s often easier to blame people because they don’t “control” them they way they do the context. This blame game is as old as the hills, but definitely not as pretty.
Help people fix processes
The solution is to ask people to look for the systematic pressures, give them the tools to find them, and to empower them to change the way work gets done.
In the end, people will improve the processes, if they believe they are allowed.
Sometimes a design isn’t working because you think you can’t change the one element that needs to be changed.
–Ryan (via svn)
The same thing is true when you are designing the processes by which work gets done.
December 1st, 2009 by Mark Ramm
It’s easy enough to say that you don’t have enough time, but the reality is that time is the medium in which we live. Complaining you don’t have enough time very much like a fish complaining that he doesn’t have enough water. So, rather than complaining about the amount of time I have, I’ve been learning to think about my time management issues differently.
Where David Allen lead me wrong
The first insight I had is that Getting Things Done (GTD) has steared me wrong. This is hard to say because I think it’s a great book with a lot of great insights. In particular the strong admonition to get everything you need to do down on paper has changed the way I live and think. That list includes all the major and minor commitments I’ve made, and having it out of my head and in a system that I trust reduced my stress levels imensely.
But I found that I still have a lot of stress. And I found that I was still thrashing back and forth between projects without making the kind of decisive progress on any of them that I wanted to.
Why wasn’t the GTD process enough?
Because, as I eventually learned the GTD “inbox processing” strategy as described in the book is broken. You are supposed to choose between three options for each input: do it, deligate it, or defer it. But really there’s a key fourth option that is the really important one if you’re life is anything like mine.
What is that all important forth option?
- Don’t do it. Say no. Avoid adding another commitment to your list.
Wait, there’s science behind this!
This is really critical because like any queue that’s processed by a limited resource (in this case my time and attention) filling it too full actually causes the system to break down. This process of breakdown even has a technical name that feels exactly right, it’s called “thrashing.”
Every programmer and computer user knows what this is like. Open too many apps at once, and your machine grinds to a halt, data keeps getting swapped out to disk and the rate at which the machine can process information goes down exponentially.
Ok, so know I knew the name for my problem. Naming it is good, but it’s not the solution.
So, how do I stop thrashing about and get stuff done?
At some point, i’m not exactly sure where, I had a realization that in life, just like a manufacturing line, or a software resource issue, there are two keys to preventing thrashing.
- Avoid too much multitasking. A system spends time switching between tasks and is less efficent when time-windows for work are too small, and task-switching happens too often.
- When multiple commitments are being made that require real-time or near real-time responses, you have to keep the task-switching window short enough that high-priority tasks can be scheduled immediately. This, of course, creates a tension with the first principle which suggests larger time windows between task-switching.
This is where Getting Things Done’s todo list system provided me with a lot of help. It helped me reduce my task-switching costs, and that’s allowed me to get a better balance on these two pressures.
Letting the work FLOW
I think there’s a very clear analogy with what happened at Toyota in the early days. Manufacturers had die presses which took a long time to change, so they would run them for a long time. This was great in that it helped keep the machine working and limited the downtime. But it also meant that there were long delays in the system since the switching time and the time for the long runs added up. Toyota decided that since they couldn’t afford more machines, they needed to figure out ways to reduce the cost of switching, which reduced total cycle time, made them more responsive to bugs (quality problems) and helped them to get more done in less time.
Reducing the cost of switching made it possible for the system to run differently, rather than batching up lots of work and pushing it through, it Toyota discovered that you could pull what you needed through the system just in time. This same thing works for time management, when you aren’t overloaded you can be more responsive to today’s needs, and you avoid the inevitable mismatches that come with long delays between request and response.
What happens when there’s still too much to do?
But, to come back to my main point, even when you’ve done everything you can do to reduce the task-switching costs, you still can have significant thrashing problems when the resource (that’s you or me) gets overscheduled.
Most projects I’ve worked on ended up in this situation at some point, where working harder stopped producing results because of schedule pressure and resource contention.
This is why saying no is a critical skill.
If you limit the commitments you make, you can provide rapid turn around on the commitements you do make, and everything runs much more smoothly because you’re thrashing less, and wasting less time on task switching.
Beyond the basics, I’ve discovered that one really critical notion is to have enough slack in your system to handle emergencies. If you schedule the system full, any high-priority, high-urgency task that enters the system can break the whole process.
Without slack in the system emergencies snowball…
I know this from experience, as I’ve had my share of emergencies in the last couple of years, and when there was slack in the system things settled down quickly, and when there wasn’t I ended up with new emergencies caused by the first emergency delaying things just a little bit too much.
So, when you are tempted to take on another commitment, think about what would happen to your life if you had to take a week off to deal with a death in the family, or to help a sick relative. If you don’t see any path to recovery, perhaps you’re over-scheduling your most important resource — you.
When No, really means Yes
In the end I discovered the biggest irony of time management: it’s only when you say No to some things, that you have the ability to say Yes, and make real commitments.
When you say no to helping a friend move, or to visiting family, or whatever feels valuable to you you will feel terrible. But, if you don’t say no sometimes to at least some of these things, you’ll end up not being able to do any of those things anyway, because you’re always behind and never quite able to fulfill the commitments you make.
I learned the hard way, hopefully you don’t have to ;)
May 12th, 2008 by Mark Ramm
Last week, I ranted a little bit about motivational meetings. Today I’ll make the opposite case.
Why have motivational meetings?
The right way to use motivational meetings is to reaffirm the purposes of the group, and help people to connect the dots between their individual efforts and the collective goals of the group, and to connect those goals with their own individual aspirations.
Basically, motivating people is easy:
- Give them work that is meaningful to them and to the organization
- Treat them with respect
Treating people with respect includes paying them a fair wage, and not doing any of these things.
Among other things it also means not letting people who aren’t contributing to the common goals of the organization hold back the group by not doing their job.
Research has shown that one of the survey questions most highly correlated with motivation and performance is:
Does my supervisor, or someone at work, seem to care about me as a person?
Which is another way of saying does your boss respect you. At the same time the single highest correlation for any question was:
I get to do what I do best everyday at work.
So, it’s really important to line people’s intrisic skills and internal long-term motivational drivers with the work you ask them to do.
If you’re not doing those two things, motivational meetings are a loss. If you are doing them you can use a meeting to remind people of how their deeper motivations are connected to what they are doing now.
P.S. My info on the top questions and their correlation to performance comes from Gallop research via the very interesting book First Break All the Rules, which is one of the best, and most evidence based, books on managing for exceptional performance I’ve read.
May 5th, 2008 by Mark Ramm
It think the very idea that motivation can be “imparted” in a morning meeting, or a half day seminar is kind of demeaning.
Motivation is a complex network of hopes, dreams, fears, needs, frustrations, incentives, and personal morality. Motivating people is as much about connecting their individual aspirations to the goals of the organization as anything. If people can do what’s right, become who they want to be, and get paid to do it, that’s a far more powerful motivator than you can get from any meeting.
If those things are true, you can skip the motivational meeting. Everybody would rather sit down and get some work done. And if they aren’t true it’s not likely that another meeting will help.
April 30th, 2008 by Mark Ramm
Paying people too well can lead to all kinds of social and motivational problems. Of course, you can also run out of money, but I’m not going to talk about that problem. I’m talking about salaries that are maintainable but significantly above the market norm.
Clark Ching recently blogged about something I’ve seen a couple of times. He worked for a company that paid developers very well. You’d think that would be good for morale, but it wasn’t. Clark puts it this way:
It was horrible. Everyone who worked there agreed.
People who hated their jobs stayed just because of the money. This meant that everybody had to work with people who hated being there, and that meant that nobody wanted to be there ;)
Good pay reduces turnover, which is generally a good thing. But some turnover is good turnover, so too much pay can actually hurt you. Beyond that great pay keeps people around, but bad experiences with managers and coworkers can do more to kill morale than you can ever replace with money.
The long and short of it is that you can’t paper over morale problems with money, and you can’t fix them by instilling a sense of urgency. Paul Graham suggests one solution — do something good. If you’re doing something good for the world people want to help you. I’d extend that to say if you’re building something people can be proud of, you’re far more likely to create the kind of positive morale which lasts through hard times.
Case in point, this story of a couple of apple employees worked on the graphing calculator that was shipped with the original Macintosh computer. The interesting part is not that they were excited to work on the project, but that they kept working on it under-cover for months and months after they had been laid off.
Why would they do that?
I had long been proud of the elegance and simplicity of our design…. I had designed it for all users, even those who know little about computers and hate math.
I wanted to make mathematics as easy and enjoyable as playing a game.
They did because they were proud of what they’d done, and because they wanted to make mathematics more accessible.