“In my experience, innovation can only come from the bottom. Those closest to the problem are in the best position to solve it. I believe any organization that depends on innovation must embrace chaos. Loyalty and obedience are not your tools; you must use measurement and objective debate to separate the good from the bad.” (Greg Linden talks about “a project I was explicitly forbidden to do and did anyway.”)
I enjoyed reading Marc Hedlund’s latest Engineering Management Hack where I found the link to Greg’s story (via an email from Laszlo colleague Scott Evans). I loved the story about David Packard’s award for “extraordinary contempt and definace beyond the normal call of engineering duty.” We’re not all cogs in a great machine, and it’s wonderful to hear about top level managers who know and appreciate that.
This is an extension of the old: sometimes it’s easier to get forgiveness, than to get permission. I definitely believe in a management style that puts more power and autonomy in the hands of the people who do the work. (Not that management isn’t work, but you know what I mean.) You hire the right people and give them responsibility and they make magical things happen. It’s important that I know what’s going on, and often I like to be consulted, but I’ve been known to reprimand employees for doing what I told them to do when they knew better. I hire people who know what they’re doing, who are smart, who I can trust.
I think it creates an enviroment where good people like to work, but I’m not driven by purely altruistic motives. I think it makes people more productive and effective, but I don’t just do it for the bottom line. I, personally, have other things I’d rather be doing. If I trust people and let them do their jobs (and define their jobs to be big enough to take on real responsibilities and take initiative), then I have time to write code myself. People have remarked that it is a great thing in for an engineering manager to be deeply in touch with the tech, but that’s not the real motivation. I, personally, want the simple joys of coding and practical, tangible problem-solving to be an everyday part of my life. It’s not enough to be the “idea guy” — I also want to be “at the bottom” where the real innovation happens.