You must read this paper by Alistair Cockburn. It's about his experiences with decades of managing and studying projects. It all seems to boil down to variations on a theme. People not doing the work come up with Ways Things Should be Done. People actually doing the work ignore the Ways but get their work done anyway. To make matters worse, he write "I have not yet interviewed a successful project that had accurate documentation, unless either the code or the documentation was generated automatically."
He cites plenty of anecdotes of systems being created to help people do their work, but the people perversely ignore those systems. People don't want to read a project plan, they want face time. People don't like someone coming in and telling them how to change all of their work habits when those same people knew they were already getting work done.
I think what we can gain from his observations is what many of us know in our guts: people can get stuff done regardless of the environment you put them in. Don't tell them how to run an obstacle course. Just let 'em run the damn course. Sometimes my coworkers get irritated when I just walk up to talk with them, but I get irritated when, after five emails, we still find out that someone misunderstood what happened.
Give 'em face time. Take away obstacles. Don't tell 'em they need to fill out reams of documentation. Figure out how to strip away bureaucracy. Give them end users to talk to, not just email. And most importantly, trust them. If you can trust their technical decisions, they're more likely to trust your business decisions.
Reminds me of The Importance of Fudgability. Choice quote:
Part of the problem was how arrogant we were. We believed that we could spend a couple of days watching trained lawyers perform a highly-skilled job, talk briefly to them, and then make their jobs completely obsolete.
Ha! Ha! Ha!
mr_bean on 2006-07-29T04:08:15
This is a good article too.
I liked the part about an inability to recognize the issue of fudgeability:
Software written for life-critical systems may
need 100% solutions - but this is rarely true
for general business systems. Software
programmers will rarely tell you this, because
they live in a world of edge-cases and
perfection and can't bear to write a system
that's not "complete". Software companies will
rarely tell you this, because 90% solutions
usually only cost about a tenth of the price,
and they can't bear to miss out on all that
extra revenue. It's a simple, but valuable,
lesson for companies who choose to learn it.
Perhaps Cockburn's article is similar in saying something that people don't want to hear.
Both of the times I decided that I didn't like where I was working any more and quit was when I hit resistance to fixing issues that were obviously broken: the implementation was obviously not what the users wanted, but software a manager had been carrying around on tape from an old job, so That Is What We Will Use; the other was simply a project that was sloppily set up and never fixed. (In that particular one, it took literally weeks to properly configure the development environment after a checkout, because no one ever either wrote down how to do it, ot spent a few extra minutes writing a script to automate it. Not standardizing the development platform to either Windows or FreeBSD caused that one, in my opinion.)A willingness on the part of team members to address any and all project issues has proven invaluable on many occasion...
Sometimes it was passive - I just couldn't get anyone else to acknowledge that there was a problem, and it wasn't something I could solve solo. Sometimes it was active - like moving me out of an office into a cubicle, with the implied message of "quit doing what you're doing or we'll really make your life insufferable". In that particular case, a co-worker and I actively resisted the status quo, insisting on fixing things properly rather than in a half-assed fashion, and arguing for actually designing to meet user needs. Didn't work. We both ended up in the cubes. We also quit and got better jobs not long after, so it evened out for us. I'm not sure if that's a management success or not
If you can get mangement on your side in one of these cases, you can generally fix them. If management is not interested, or is actively opposed to the necessary fixes, finding another position is pretty much your only option.
If you are a manager and one of your good programmers comes to you and says "the solution we're implementing is not what the users want, and I have proof", or "the project has a problem, and this illustrates it", ignoring the problem or shooting the messenger is not going to help you or the project; especially since you're probably going to lose that programmer and possibly other good ones (if not all of them) as well. Making an example of someone who points out problems leads to people eventually not pointing out any problem, and a distinct chance of eventual Big Failure. Career-altering Big Failure.
Any more, I always ask anyone I'm going to work with how they handle process problems. I'm looking for an understanding that if the process is bad, the quality of the software will suffer until the process is fixed. It doesn't really matter if it's a coding process or a project-management process or the process of understanding the actual user needs: if you leave bad in anywhere, bad eventually comes out.
A project is not a success if you make all your deadlines, but the good people keep qutting.
Re:face-to-face vs via media
Alias on 2006-08-01T17:17:57
Indeed, I think the hackathons are important, so important that it's the primary reason I flew over to YAPC::NA this year. I did hardly any actual talking during the whole time there, but I spent enough time talking to resolve half a dozen major blocking points, unconfuse a few confused situations, and generate enough new clearly structured Things To Do for about half a year.
Well, that and I REALLY needed a holiday:) Re:face-to-face vs via media
Alias on 2006-08-01T17:18:37
That should read "hardly any HACKING"... sigh, it's late.Re:face-to-face vs via media
Ovid on 2006-08-01T18:37:15
It's a shame that people really don't seem to understand how much more important face-to-face communication is to email, IM, or reams of documentation. Hell, even video conferences aren't the same. If only I could find a way to explain this in a few simple words that even PHBs would understand.
Thanks for posting this link, much appreciated. It puts in somewhat more formal language a lot of the features we look for in a team but can be difficult to specify. And many times management looks for some of these beneficial effects without giving up the control and predictability they think they have.
That this is someone who has looked at many different types of projects projects of many sizes over many years makes it even more powerful. (That is, it's not just the 37signals folks preaching to the choir developing applications just like theirs...)
