2006 JOLT Awards

The nominations are in: The art of project management is a finalist for the 2006 Jolt Awards, sponsored by CMP.

Here are the General book nominations:

  • Ambient Findability: What We Find Changes Who We Become by Peter
    Morville (O’Reilly)
  • Best Software Writing by Joel Spolsky (Apress)
  • Innovation Happens Elsewhere: Open Source as Business Strategy by Ron
    Goldman and Richard P. Gabriel (Morgan Kaufmann)
  • Prefactoring by Ken Pugh (O’Reilly)
  • Producing Open Source Software: How to Run a Successful Free Software
    Project by Karl Fogel (O’Reilly)
  • The Art of Project Management by Scott Berkun (O’Reilly)
  • The World Is Flat: A Brief History of the Twenty-First Century by
    Thomas L. Friedman (Farrar, Straus & Giroux)

The exceptions to Brooks’ Law

In Fred Brooks’ Mythical Man Month, he states:

Brooks Law: adding manpower to a late software project makes it later.

In the book he notes that it is an “outrageous oversimplification”, but most laws of this kind are. The trouble is that people often use laws like this in a lazy fashion to end debate, assuming it is as universally applicable as an actual law of basic physics. It doesn’t take much effort to see that there are important exceptions. I hinted at them in chapter 2 of Making Things Happen, but here’s a full explanation of the notable caveats I’ve seen.

  • It depends who the manpower is. Brook’s law assumes that all added manpower is equal, which is not true. Given the choice of adding a good programmer, who knows the code base and is friends with half the team, I’d consider it. Knowledge of the code and good relationships with the team offsets the two key reasons for Brooks law (ramp up and communication overhead). And if that individual has prior experience coming in late to a project, all the better. Some people are capable of playing the SWAT team / Ninja role, and that skill is orthogonal to programming talent: some are simply better are getting complex work done on unfamiliar terrain with a minimum of disruption.
  • Some teams can absorb more change than others. Some teams are more resilient to change. They can absorb communication overhead and teaching duties better than others can. It’s well known that there is a wide range among programmers in their speed, but it’s also true there is a wide range of communication and teaching skills. Even if all teams pay a price for adding people, that price will vary widely and is not a fixed cost based on the # of people alone(e.g. n*n).
  • There are worse things than being later. The conclusion most people reach is that, given Brooks law, you should never add people. But it doesn’t say that: it just says you’ll be later. That can be OK if you also get higher quality (not a guarantee of course). Time is not the only success criteria. If the person you’re adding fills an important hole in in the team, being later might be worth it.
  • There are different ways to add manpower. The sad but popular approach is to throw people in without much explanation and let everyone figure it out for themselves. But if the manager clarifies why Sally and Rupert are joining, and defines good roles for them, with input from the team, they’ll be set up to make a smooth transition. This can also include assigning them a mentor who is capable and motivated to be their primary point of contact for on boarding issues. The more experience everyone has with mid-stream personnel changes, the better. Some tasks will always be better suited to assigning new people and it’s the manager’s task to figure out which ones those are.
  • It depends on why the project was late to begin with. If the project was late because of inexperience or poor team practices, adding a small number of experienced people with those missing skills, and directing others to follow them, can eliminate some of those inefficiencies: not all knowledge or skill transfer requires long lead times. Therefore the added value of certain manpower is not just 1 additional programmer unit, but 1+, as they have a positive effect on the productivity of others. But more importantly, there are many reasons for being late that have nothing to do with the programming team personnel: no amount of programming staff modifications will resolve the psychiatric needs of team leaders or the dysfunctions of executives.
  • Adding people can be combined with other management action. Contrary to popular belief, management is not a turn based strategy game. You can do more than one thing at the same time. For example, you can remove someone at the same time you’re adding manpower. This does increase volatility, but if you’re removing your worst, and most disruptive, programmer and adding one of your best, it can be a reasonable choice. Managers also have the option to cut or reorganize work across the project, improve tools and equipment, throw a social event to accelerate team relationships, etc. There are always ways for managers to provide cover fire. These all have disruption costs, but depending on the length of the project they might be offset.

Disclaimer: I’m sure there are specific cases where these exceptions do not apply. I am not suggesting the abandonment of Brook’s law, only thoughtful consideration for how it is applied. All additional examinations or applications of Brook’s law, or these exceptions, are welcome.

See also:

In Love with Pandora: Music recommendations

Pandora screenshot
What’s better than finding a great thing, that works great and makes me endlessly happy without me having to do much work? Well if you like finding good music, Pandora is for you.

I’ve seen many other “auto recommend music for you” type things over the years but these guys have done it right. In my first half hour of use I found 5 CDs I wanted to buy (and was happy with when they arrived: including Neutral milk hotel, Wonderful Smith and an Elliot Smith CD I didn’t know about).

I was so happy with the results I paid the subscription fee straight away. Isn’t it worth a few bucks to get great recommendations for things? (Or perhaps I’m lame and need to make more music savvy friends :).

They now have a free version (ads) available and I highly recommend checking it out. It’s a flash based UI, but they should get an award for the smoothest & least annoying flash UI I’ve seen in some time. The station model took a few minutes to understand (you have to seed the recommendations process), but once I got it I haven’t thought about it again.

This week in PmClinic: Help a randomized team

This week in the pm-clinic discussion forum How to help a randomized team:

“My team is trying to transition from being purely an integration and maintance team into having real customers with problems, feature requests, complaints, etc. There is a customer support organization but they’re often slow and don’t understand enough about the details to be efficient in exchange information between us and the customer.

The primary problem now is we’re drowning – we have figured out how to simultaneously deal with the ongoing maintance work, while also doing planning and customer work for the next major version. The team is frustrated, decisions are slow and everyone is losing patience. In short, we feel randomized and I don’t know what to do to stop it.

Someone in my org suggested having a escalation response team or process to help shield my team from unnecessary interruption, but I don’t know enough about that to know if it’s right or how to put it into place.”

– Signed, Mr. Crispy (Burning at both ends)

This week in UXClinic: Finding UX a home

This week in the UX-clinic discussion forum: Topic #3 – Finding UX a home:

In my previous job, the territory of UI/UX Design was hotly contested.

Early on design came from moderately talented folks in Engineering (full disclosure, me). After growth, design moved to the Marketing Dept with the rationale “UI equals branding”. The subsequent redesign was torture for engineering — not a square edge to be seen; low-contrast gradients, etc. In the aftermath, Product Management demanded UI/UX prototyping rights for new features and added user-testing, relegating Marketing’s role to “adding style” just before production.

But after agreeing to that role, Marketing still provided mockups of new features to Exec meetings, the board and clients — all before PM assignment/involvement. Execs usually preferred the first designs they saw. Engineering abandoned their front-end developers to fall under Product Management rather than get involved as a third claim on UX.

It is obvious the Execs need to make a decision about where design truly lies. But in lieu of a decision, where is a good balance? Has anyone seen companies work themselves out of this quicksand? What kind of job role or training could help get the depts on the same page? Where does UI or UX intermix with branding?

Thanks,

– Still Irritable About That Job

The meaning of New Years Day

I used to think of new years, and resolutions, as silly things. “Why do we need a reminder to change our lives?” I’d say. I laughed when waves of people hit the gym in the first weeks of January, and laugh again as their numbers faded by February.

myths-to-live-by

But now, older, perhaps wiser, I respect New Years Day. It’s the only secular holiday that has any ritualistic meaning – No other day comes with as clear an assignment, or as potent a set of possibilities. It’s the only holiday that forces the question “what change can you make that might make you a happier, better person?”

Over the holidays I read Campbell’s Myths To Live By and one of its points is the role of ritual and tradition in our psychology. They have psychological value to us regardless of faith (Odds are high that any well designed activity that involves atonement, acceptance, forgiveness, or confession is healthy regardless of the brand it comes in). But with the shift to a more secular society, few people replace the possibly beneficial, but religiously themed activities, with new ones. A good community might provide a few, but there is still a debt of ritual and traditional that most of us suffer from.

New years parties date back to 4000 years ago in Mesopotamia (Iraq). The Babylonians and the Romans made promises to their gods on the first day of the year, and some cultures exchanged gifts on New Years day much like many Americans do on Christmas. In the Western world that tradition slowly shifted to being promises made to oneself.

New years day stands alone as a secular American holiday with a positive, self directed, ritual. I used to laugh at people who put resolutions up in their office, or on their refrigerators but now, I ask myself, if I won’t make a resolution, how else will I commit to myself to do something important? If I don’t have a better answer, I better start writing those resolutions.

Many years ago, I came up with my own list of holidays: Scolidays. It included days like silly hat day, movie marathon weekend and Do something you’ve never done before day. But 2005, I chickened out, and only did 2 of the 12 days. But how can I complain? Unlike a religion, I’m the one to blame for all the silly traditions :)

References:

 

Lessons on social bookmarking (Learning from del.ico.us & blink)

Here’s a good short essay about lessons learned from the founder of blink, a 1999 social bookmarking effort.

This really shouldn’t sound too different from what del.ico.us was able to do, and we had something like $13 million to play with to make it happen. Not to mention that there were others with the same idea. Remember Backflip? So (besides the money), why did we fail and del.ico.us and the other Web 2.0 companies succeed?

Kudos to Ari for being honest and open about lessons learned on design, business and timing. Wish there was more of this kind of thing.

PM Clinic: Nominations for think-week

This week in the pm-clinic discussion forum we’re building a think-week reading list. Here’s are details:

One smart thing I picked up at Microsoft was think-week. It started as something that Gates did: he took a week off a year to read all kinds of interesting papers and thoughts that he typically wouldn’t find time to read.

Not being Bill, I’d shoot for a think day. And tried to get my team to do the same: take an afternoon off at the coffee shop with the goal of reading items from a special “think-day” stack. (A good tip for any team).

So: Lets build the first ever pm-clinic think-week list.

Rules:

1. Nominate an essay, paper, or blog post that you think is important, and probably under-read by your peers on the list.

2. Books are allowed, but smaller units of reading preferred. Go for things that strike unusually deep at important problems, come from unexpected domains (film direction? building architecture?) or take an interesting approach.

3. A good think-week pile is highly diverse, challenging and fun to read.

Looking forward to seeing what you think belongs in the pile.

If you’re not on the pm-clinic list, you’re invited to make your nominations as comments – thanks.

Best questions from the Microsoft talk

Had about 120 people yesterday – and was thrilled to see some familiar faces. It’s always good to speak at Microsoft: the audience is always smart and likes to laugh. Here’s some of the good Q&A, from memory, from my talk on why smart people defend bad ideas:

What do you do if your boss is an idiot? Sadly, not much. If they really have some kind of cognitive disability nothing you can do can change that. But you can always look for points of leverage. Who are the smart people who work for your boss that have your bosses ear? How do they influence him? What issues is he smarter about that others and how do you play to his strengths but work independently on areas he’s weak on? And lastly, there are worse thngs than being stupid. Traits like trust, clarity, commitment and leadership skill are mostly orthogonal to intellect. A slow person who listens to the right people might make a better manager than bright person who ignores everyone.

How do you handle a manager that has difficultly making priority decisions? . Take on the burden of setting the plate for them. What can you do to make priority decision easier? This is a very generous form of managing up: where you define for your boss what you need from them to succeed. In this case, you’re going further and doing some of their work for them in order to make your work possible. If that burden is too large, look for other people who work for your manager who suffer as much as you do. You can partner up and set the table together. Also, know that prioritization is the single most important things managers of large teams do. If your manager isn’t doing it well, be worried.

What do you do in a group that doesn’t like to debate ideas? Some people have stigmas about debate: they don’t allow criticism or critique in fear of people feeling hurt. This usually sucks and represents fear of ideas an inability to seperate someone’s ideas from their identity: a death knell for creative thinking. However, in all groups, ideas are debated, just not out in the open. If debates are verbotten in meetings, look to the offices and cubicles. Bring your ideas to people one on one and invite people to come to you.

Why are copouts like ‘We don’t have time’ and ‘This is the way we did it last time? The audience and I discussed many reasons why these statements are problematic: They’re copouts and don’t represent thinking, they put decisions into unquestionable boxes, they imply a we vs. you dynamic which can bully question askers into submission. We agreed that heuristics like these are often right, and are fast to use, but also agreed that there must be a way to over-ride them and force real thinking to take place.

If you were there (or not) and had other questions, glad to answer ’em here.

The good experience live conference (GEL 2006)

Gel 2006I’ve been to tons of conferences and often left disapointed. They’re often so similiar and despite the high prices, make it hard to have a good, interesting time. Design or experience related events are often more disapointing: they fail to make the conference itself a well designed experience for attendies.

With that in mind I strongly recommend GEL 2006. It’s a small two day conference focused on good experiences and how to make them. The speakers are diverse and the day is paced well and highly interactive. I attended in 2003, the first year, and have been trying to get back ever since.

You can read all about last year’s conference and see how diverse and interesting the pool of speakers and sessions are.

GEL 2006: Thu & Fri May 4-5th 2006. 2006 Speaker list.

The conference rates are heavily discounted until Dec: 12th. For both days it’s $900 now, $1200 after Dec. 13, and $1500 on April 1st 2006.

In related news: I’ve been lobbying Mark Hurst, the conference organizer, to let me speak there for years – and have failed every time :) But this year I finally got somewhere – Day one of the event is a set of tours of user experiences in NYC. I’ll be running one called The experience of sacred places. We’ll be roaming around Manhattan breaking down how churches, temples, parks and other special places are designed to have the effects they do.

Google’s 10 rules compared to Microsoft

Microsoft and GoogleMSNBC posted Google: Ten golden rules by Google’s CEO Eric Schmidt, on how Google manages their knowledge worker staff.

I know many people that work at both Google and Microsoft, and I’m sure this will be upsetting to all of them: the spirit of nearly all these rules are shared by both companies.

Having spent time at Google, I know it’s a special place. There are many things about their environment that are very different from Microsoft.

However Schmidt’s MSNBC piece has little to do with what those things are. Here’s a critique on how similiar this list of Google’s CEO’s rules are to my recollections of Microsoft’s approach.

  • Hire by committee. The article suggests (and I’ve been told) Google requires unanimous approval. Everyone you talk to must say yes. Microsoft’s bar is set by the team maanger. They expect a majority, but rarely require 100% consensus. But the basic format, you have intense real-problem focused interviews with 5-7 of your potential peers, each of whom gets to vote hire/no-hire, is the same.
  • Cater to their every need. In the early 1990s Microsoft formalized many of the fringe benefits some software companies gave their employees. Private offices with windows. Free soda. Good and cheap food. Showers in the parking lots. Massages during crunch time. Health club membership. Discounts at museums. Mega-flex time (just get your stuff done, we don’t care when you’re here, or for how long). Today there’s no comparison: Google is still small enough to do things MSFT never did, and currently can’t afford. But the attitude is the same: it’s the level of execution that’s different. It will be harder for Google to maintain those costs as the company grows and the rate of growth slows (It may take awhile, but it will happen): a challenge Microsoft is still dealing with.
  • Pack them in. Gates always believed that co-location was critical to getting work done with others, which matches Schmidt’s beliefs. Unlike Intel, a company that distributes it’s offices across the world, most of Microsoft’s core development teams are within walking distance of each other. Microsoft stops at the office level: Gates always believed that programmers need private spaces to be productive, whereas Google believes in shared spaces. But the core philosophy of easy access is shared. Microsoft does have some shared space teams, but it’s not the standard.
  • Eat your own dogfood . I doubt Microsoft invented the term, but they certainly popularized it in the 90s. This has always been a core value at Microsoft, and it’s been documented in various books about MSFT development practices. Everyone, from VPs to programmers are asked, begged, bribed, and cajoled into using early and experimental builds of new software. The problem eventually becomes this: how many things can you dogfood successfully at the same time?
  • Encourage creativity. Is there a CEO that would say they discourage creativity? Google wins here easily, as the 20% side project rule is a formalized and their campus is built for creative stimulation (unlike Microsoft’s relentless architectural repitition and squareness). But in my time at Microsoft (94-2003) side projects always happened – the difference was that it was up to my manager and I to negotiate what they’d be: I couldn’t argue for them on the basis of a promise the CEO made about encouraging creativity.
  • Strive to reach consensus. Microsoft is the poster child of consensus. For anyone that’s been a manager there, it’s well known that rough consensus is a necessary condition for many senior level decisions. This has become a bottleneck for many groups, as their size makes consensus management a painful and often self-defeating process (A fact that makes many of mini-Microsoft ‘s comments valid. I’m waiting for the mini-google to arrive). But the point is: both Microsoft and Google have management philosophies based on the value of consensus.
  • Don’t be evil. Definitely differences here. First, I never got a “Be evil” memo at Microsoft. The message I did get was this: WIN. There is a difference. While trying to WIN won’t get you sainthood, it’s philosophically indifferent: it’s about a result. Many things Microsoft was criticized for came from someone trying to WIN in the short term, without recognizing the long term consequences of how they won. Call it stupid, selfish or immature, but evil often (but not always) seemed a stretch. Google’s choice to make a public philosophical stance is noble, and puts the rest of the business world in cowardly relief (Although, where is the company that says “We actually do GOOD?”) But the stance is rife with problems. Any time you in are in a zero-sum competition, and WIN, even if you do so graciously, there will often be someone who feels they lost who will point a finger at you and say “You did evil to me”. Watching a major corporation manage a philosophical, moral position is fascinating, and definitely something Microsoft has never done.
  • Data driven decisions. Is there anywhere in the tech-sector that isn’t data driven at the management level? I happen to think we’ve gone too far, and abuse data left and right. But it’s well documented that compaines including Microsoft, Amazon.com and Google are all intensely data driven.
  • Communicate effectively. All hands meetings and beer Fridays are industry and bay area staples, as is the occurance of executives saying “we should communicate effectively with each other”. Is there anyone out there that advocates bad communication? Holds miscommunication rallies? I think the problem with this entry, and the list, is it’s a platitude. The notion of good communication is universal: but the sucessful practice of it is rare. Closing that gap is where the magic is at.

In Summary: there’s little motivation for the CEO of a leading company to reveal what he thinks the true secrets or powerful rules are. There’s more to lose than to gain. But this piece, as fluffy as it is, doesn’t say much about management than anyone paying attention didn’t already know.

This week in UX-Clinic: who to hire

This week in the UX-clinic discussion forum: Topic #2 – Who to hire, design or usability?:

I’m a web development manager for a new, but very popular web service. I’ve lobbied successfully for a headcount to help with UX/design/interface issues. Until now everything (prototypes, heuristic evaluations, etc.) has been done by me or one of the 5 programmers.

The challenge is this: what should I hire? I think I have 4 choices: a designer type, an IA, a usability engineer, or someone that does some of everything.

What questions should I be asking myself and my team to determine the best way to use the one UX headcount that I have?

– Shopping in the UX candy store

PM-Clinic: Where to put the business folks

This week in the pm-clinic discussion forum: Topic #56 – Where to put the business folks.

Welcome to the last month of the year – here’s a situation for you:

I manage a team of five PMs. Another manager runs the (large) production team of designers, programmers, QA. Folks on my PM team draw resources from his team to assemble project teams. Sometimes my PM team brings in Business Analysts (BA) to help with planning.

So, the other manager recently quit. His right-hand guy is acting manager. Day 3 on the job he invites me for coffee, and proposes to take over the BA positions. having them report through the production area to him, and not to the PM team. Just sign here, OK? No way, I said.

Where is the right home for business analysts or product planner types? What is a sound way to make arguments for where they should live? Does placing a role in a specific part of the organization necessarily stack the deck in a negative way? Or is this simply a political play by the acting manager for more power?

(Extra credit: same question, but with marketing or design).

Signed, The Prince

Right For The Wrong Reasons

Funny things happen when human nature collides with reality. In the vast archive of comical situations, none are more curious than our responses to failure.

When failure happens, few care how it happened: the blame goes to the decision maker. The logic is that the results define everything. In turn, when things go well, regardless of how or why, credit goes in the same direction. Even if the thinking was poor and success was complete luck, or something pulled together by others in spite of the bad decision.

Decision diagram

The logical flaw is that sometimes we make the right decision for the wrong reasons. And by the same token, sometimes we do all the right things and the results are bad, because of luck or factors beyond our control. There are always more variables in the outcome than the surface decisions that are made.

Someone who’s made recent mistakes may in fact be a much better decision maker than someone who’s had recent successes. They might be taking on bigger challenges. They might have stronger competiton or fewer resources than others. Without examining how their logic (and situation) matched to the results, it’s difficult to know how much credit they deserve.

Taken to the psychopathic extreme: we sometimes excuse our own failures by blaming circumstance (“But I did everything I could”), but fail to give those around us the same generosity (“I don’t care why it happened: it’s your fault.”). This kind of inconsistency is poison: it’s impossible to to build trust when people are rewarded for making excuses and patted on the back for pointing fingers.

If you’re a leader, and you do this yourself you’re setting an evil tone for others to follow. (When was the last time you distributed credit you didn’t deserve? Or took blame away from those who did not deserve it?) If you’re able to raise the bar on how people deal with these situations, they’ll spend more time working and waste less time stealing credit and dodging blame.

Embarassed in Seattle: The monorail

The monorail busted

If you doubt the ironic powers of the universe, look no further than the Seattle monorail. You see, for those than haven’t been paying attention, Seattle recently passed up its last chance for urban mass transit. We did so in an embarassingly incompetent fashion, with misguided leadership, misinformation and a confused understanding of what the problems and possible solutions were. Even shutting down the project is a sad nightmare. It has been a classic project management disaster.

And as the icing on the cake, the tiny one mile stretch of monorail, the one that’s only here because of the World’s fair in 1962, crashed this week. It will cost several million dollars to repair the trains. And, like the monorail fire last year, makes one wonder what’s next for the little guy.

And to all the armchair urban planners out there, you can see what could have been. For the sake of learning from mistakes, I hope all those architecture and urban planning departments add a healthty dose of political training to their degree programs. Mass transit in Seattle should make for an excellent case study in how a very green city can go very wrong.