October 12th, 2005 by Mark Ramm
I was at the bookstore last night, and picked up a copy of Purple Cow, by Seth Godin.
The basic premise of the book is that mass marketing as we know it is a dying art form, and the new marketing is going to be a new kind of hyper-word-of-mouth, accelerated by blogs, e-mail, and online social networks. Seth argues that the thing you need to succeed in this new kind of market is remarkable products, like a Purple Cow.
A Purple Cow would be pretty remarkable, wouldn’t it? — at least for a while!
How does this impact me? I don’t do marketing. I don’t build the kind of products that individuals buy. I manage and do software development, along with internal and external support. It is pretty easy to see how Purple Cow thinking can help us better make and market software products.
But how can we create the Purple Cow of IT support?
I don’t have the answer yet, but I know it is a question worth asking.
October 12th, 2005 by Mark Ramm
What is valuable in what you do? What is valuable in what the people who work for you do?
How would you go about answering that question?
I’m sure there are lots of possible answers to these questions. But most of them are wrong.
Perhaps, the single most fundamental principle of Lean Manufacturing is that you are producing value when you give customers what they want, when they want it. Everything else is waste.
If you don’t know exactly what your customers most want, and have the capacity to deliver it at just that moment, and a price they are willing to pay, you aren’t producing real value.
Producing what the customer wants ahead of time is waste because they might not really want it, or they might want it configured differently — and that means re-work which is just another name for waste.
If you are pushing change on your users, you are bound to encounter resistance and therefore waste both your time and your users time. If on the other hand, you lead your users to better understand what they need, and get them to ask you for it, then they pull value from the system. And that means less resistance to change, less wasted time, and more user satisfaction.
October 12th, 2005 by Mark Ramm
As I said yesterday, your customers define value, and they don’t care a bit about some of the things that your IT Department does. They don’t care about weekly status update meetings, longstanding ticket reviews, or maintenance of your Ticket Tracking system. They don’t care about all the time you spend fixing bugs repairing or repairing corrupted files.There is a name for all of these things that your customers don’t care about —
waste!Your goal should be to stop doing these things. Don’t waste your time, or your customer’s money. Where you can stop doing them, where you can’t minimize the time you spend on these activities.
Instead do something that your customers care about! Build systems that protect them from having corrupted files, write unit and functional tests so your users don’t ever see that bug. Get response times down to the point where you wouldn’t have enough “longstanding tickets” warrant a weekly meeting.
And once or twice a month take some time out with the whole team to identify ways to reduce the waste that’s still in the system. The story of Toyota shows that even after 30 years of improvement creative people can still find new areas of waste and ways to remove them.
October 12th, 2005 by Mark Ramm
The sources of motivation are as varied as the individuals who you want to motivate. Some people just want to make money and go home at the end of the day and not worry about work. Others want a cool project that they can talk to their friends about. Some want career advancement, some want public recognition, and others just want to be left alone to get something done, and some just want cold-hard cash.
What can you as a manager do about all of this?
First, you need to recognize that what motivates you is not always what motivates developers. If the studies are right, you are most likely motivated by the opportunity to take on greater responsibilities, and your developers are motivated by the opportunity to build something cool.
That means you will have an easier time getting great work out of developers who get to work on something they think is cool.
Sometimes your project is just cool, and if you don’t get in the way developers will want to work on it. But if you are implementing a new double entry accounting system, the project is probably not all that cool. What should you do then, just give up, and try to motivate people on your project by tightening the screws and pushing harder?
Actually there are choices you can make early in the project that can make your project more cool. You can ask your developers to try out a promising new technology like Ruby on Rails, or TurboGears. You can provide them with a budget and training to let them try out an agile development process like Scrum, or XP.
You can ask your developers what would make this project cool, and work with them to make that happen.
If you play your cards right, you’ll help your developers learn new things, become more productive, and you’ll keep them motivated the whole time. Just remember, your developers — like most people — will work harder on something they enjoy than something they have to do for their job.
Of course, there is a place for just doing the crap that needs to be done even if it sucks. There are ways to help people feel good about this too, but that’s a post for another day.