Hi there. I’m now back from my ramble through Scandinavia.

If you were at my seminar in Milwaukee (we had many questions on estimates and schedules), or struggle with bad estimates somewhere else in the world, you’re in luck.

Next week my friend Steve McConnell is doing a free webcast on the ten deadly sins of estimation. As if the regular sins weren’t bad enough, these are the ones that kill. Registration and details here.  Tuesday June 23rd, 10am PST.

And here’s more stuff from Steve’s consulting firm, Construx, on estimation:

• Construx Estimatation tool

• Estimation Poster

• Cone of Uncertainty White Paper

• Software Estimation In-Depth Class

Posted in Management, Software/Web development | 2 Comments »

Recently I’ve been playing tons of Gears Of War 2 for XBOX 360, because of it’s fantastic HORDE mode. I’m not a huge gamer. But find me:

1. A game/mode that has well designed UX
2. Is easy to learn, but hard to master, and fun to fail at
3. Has few annoyances (mandatory tutorials, non-skipable intros, etc.)
4. Has a team based, rather than purely competitive, mode

And I’m in. Great games, as rare as they are, are the perfect relief from long hours of writing. And if I can play with friends on the same team, all the better.

(image from Matt’s Journal)

Like real life projects, where you can can only survive by working together, the HORDE mode is based on co-operation. You can’t get very far without working as a team.

However this doesn’t stop many players from trying to do it all on their own. It’s funny, gut also sad, in HORDE to see players make the same mistakes again and again and again, just like in the workplace, for not recognizing they need a team strategy to win, not just solo tactics.

Here’s lessons from HORDE that apply to many project teams:

• team co-ordination > Individual talents .  Early on you can get by with how good you are alone. But as soon as things get intense, or you fall behind, working solo is a liability. Programmers and Managers who insist on doing everything themselves are set up to fail when that approach reaches it’s inevitable limit.
• Have a fallback position everyone knows. When everything is going to hell there is no time to make a plan. People are too stressed to think clearly anyway. This means you must have a fallback plan defined at the beginning. My friends and I call it the hiddy-hole - a spot where we will all fade back towards, that is defensible, easy to find, and likely to be where other teammates are.
• Over Communicate.  Talking matters. In Horde you have to share what you see, and take advantage of all the viewpoints. Teams that talk more last longer - it’s nearly a rule in Horde. If a minute into the game no one has spoken, it’s going to be a short game. Same goes for project management - teams that are good are sharing useful info with each other prevent things from going from.
• Stay together. The temptation in HORDE, and in life, is to seek your own glory. To go out away from the pack.  But as soon as the waves get hard enough you can’t do it alone and before you know it you’re dead because something snuck up behind you. If you stick together it’s surprise is less likely, and since you have two people dealing with it, survival odds are much higher.
• Watch your buddy’s back. One of the most interesting elements of Horde is when you’re wounded another player must come and revive you. The teams that last longer are the ones who make reviving other players a priority. It’s a reciprocal trust thing - someone has to do it first and if you don’t reciprocate they might not do it again.
• Develop a shorthand. The more you communicate the sooner you develop a shorthand. Novice players say things like “Lookout, it’s coming!” Without telling you where the bad guy is or what it is, which is useless.  He may as well just say “aaaaaaaahh!” You want an efficient shorthand that makes frequent communication efficient. “Butcher at 2′oclock from fallback”. Shorthand makes it easy for many people to communicate without burying people in noise.

Recently I’ve started playing Left 4 Dead with the same circle of friends - It’s been great so far. Also excellent team based, co-operative game design. Easy to learn, fun to play.

Are there any other XBOX 360 games with excellent co-op modes? Let me know.

Posted in Design, Management | 6 Comments »

Everybody likes to criticize NASA for various reasons. There’s the budget problems, various $100 million blunders, and of course the aging space shuttle program.

But one thing they are doing right with the Hubble telescope is planned obsolescence. This current space shuttle mission is the last act NASA will take to repair the Hubble telescope ever.

They know that in order to build whatever will replace the Hubble, they have to let go of Hubble, even if that means letting it die, so they can have the funds and resources to invest in the next thing (It’s called the Webb telescope and it’s made from Beryllium - sounds like Star Trek).

And the space shuttle is also being put to rest. With 9 missions left NASA is finally moving on, using the resources consumed by the shuttle for the next big thing.

What old ideas, products, services, habits, assumptions, excuses, will you let go of to make room for whatever you want your future to be?

If they can ditch the Hubble and the shuttle, I can ditch something too.

Posted in Innovation, Management | 2 Comments »

My essay from the new book Beautiful teams is up online.  It’s about my years on the Internet Explorer 4.0 team. And there’s a string interesting comments up already.

Why Ugly Teams win from Beautiful Teams.

If you dig the essay, check out the book.

Posted in Management, web browsers | 3 Comments »

Interesting thread going on Slashdot about PM for beginners. Making things happen gets a nice mention.

Surprising number of mentions of PMI and PSP and other heavy processes I wouldn’t expect to hear so fast from the Slashdot crowd: Project management for beginners.

It’s funny but I still am baffled by the threading and conversation UI at slashdot. I’ve been there dozens of times but still it’s beyond me.

Anyway, I posted a response, but it’s buried so deep I doubt you’ll find it without magic powers so here it is:

Here’s my 3 (ok 6) steps for getting started before buying a book or doing anything else:

1. I’d recommend talking to your team, individually, about what things on the project are most frustrating or could be improved.
2. In each conversation ask for their advice on what you can do, and also what they are willing to do or try
3. Based on your conversations, propose one simple change that has the best odds of both being accepted, and improving things. If the team has lots of conflicts, pick something very small. If there is too much dissension, pick something you can do with just one or two others.
4. Then make the change.
5. If things go poorly go back to #1.
6. If things go well, propose the next thing from #3.

But without talking to your team, and without establishing credibility and leadership, no book, degree, or IQ, will be of any use to you as a project manager. Start with your team first and earn their trust.

Posted in Management | 4 Comments »

As a positive counterpoint to my list of why managers become assholes, and as a counterbalance to my tendency to write cynically, here’s a list of why people become great at managing others, trying as much as possible not to just do the stupid thing and invert my other list.

1. Enjoy helping people grow.  Few things feel better than helping someone who is new to a role, or who has been struggling, into becoming a productive, confident person. There’s a kind of satisfaction in helping someone figure out how to be successful that doesn’t come from many other living experiences. Great mangers love seeing this happen on their teams.
2. Love creating positive environments. A great manager creates a team and and office environment that makes it easy for smart people to do good things. They love that moment when they wander the halls and see all sorts of amazing things happening all on their own, with passionate, motivated people doing good work without much involvement from the manager.
3. Want to correct mistakes inflicted on them. Some great managers are looking to undo the evil managers they had. Rather than take it out on their subordinates, they want to do a kind of pay it forward revenge: prove to themselves and the world that it can be better that what happened to them in the past. This can create the trap of fighting the last war: your team may not care at all about avoiding the mistakes of your previous manager. They want to avoid the mistakes you, and your blind spots, are probably making right now.
4. Care deeply about the success and well being of their team. Thoroughbred horses get well cared for. Their owners see them as an expensive asset and do whatever they can to optimize their health, performance, and longevity, even if their motivations are largely selfish. A great manager cares deeply about their staff, and goes out of his way to protect, train, care for, and reward their own team, even if their primary motivation is their own success.
5. Succession mentality.  A successful manager eventually realizes their own leadership will end one day, but if they teach and instill the right things into people who work for them, that philosophy can live on for a long time, long after the manager is gone. This can go horribly wrong (See, history of monarchies) but the desire to have a lasting impact generally helps people think on longer term cycles and pay attention to wider trends short term managers do not notice.
6. Long term sense of reward.  Many of the mistakes managers make involve reaping short term rewards at the expense of long term loyalty and morale. Any leader who inverts this philosophy, and makes short term sacrifices to provide long term gains, will generally be a much better manager. They recognize the value of taking the time to explain things, to build trust, to provide training, and to build relationships, all of which results in a kind of team performance and loyalty the short term manager never believes is possible.
7. Practice of the golden rule.  It’s funny how well known this little gem is, and rare in life people follow it. But I think anyone in power who believes in it, and treats all of their employees the same way they truly would want to be treated, or even better, treats employees as they actually want to be treated, will always be a decent, above average manager. A deeply moral person can’t help but do better than most people, as treating people with respect, honesty and trust are the 3 things I suspect most people wish they could get from their bosses.
8. Self aware, including weaknesses. This is the kicker. Great leaders know what they suck at, and either work on those skills or hire people they know make up for their own weaknesses, and empower them to do so. This tiny little bit of self-awareness makes them open to feedback and criticism to new areas they need to work on, and creates an example for movement in how people should be growing and learning about new things.
9. Sets tone of healthy debate and criticism. If the boss gives and takes feedback well, everyone else will too. If the boss is defensive, passive-aggressive, plays favorites, or does other things that work against the best idea winning, everyone else will play these destructive games. Only a boss who sees their own behavior as a model the rest of the organization will tend to follow can ever become a truly great manager. Without this, they will always wonder why the team behaves in certain unproductive ways that are strangely familiar.
10. Willing to fight, but picks their battles. Great managers are not cowards. They are willing to stake their reputation and make big bets now and then (I’d say at least once a year, as a totally random, put possibly useful stake in the ground). However they are not crazy either. They are good at doing political math and seeing which battle is worth the fight at a given time. A manager that never fights can never be great - they will never have enough skin in the game to earn the deepest level of respect of the people that work for them. But a manager that always fights is much worse. They continually put their own ego ahead of what their team is capable of.
11. (Bonus!) Instinctively corrects bad behavior within their team. True story:  on a new team I once saw a mid level manager make a personal attack of a junior employee in front of the VP. I looked at the VP, expecting him to jump in. He did nothing. Not a thing. Message to team? It’s ok to pick on people if you outrank them.  Micromanaging is never good, but correcting destructive behavior, is always appropriate even if you have to jump levels to do it (Sure, perhaps there was an offline conversation. But something like this was so egregious it should have been corrected on the spot). Nothing builds morale and respect faster than a manager who jumps in to the fray to defend someone who is being picked on by a bully, except perhaps a manager who gets rid of the bully altogether.

Also see: Advice for new managers (A popular essay)

What did I miss? Think of the last great manager you had and what traits you’d add to the above.

Posted in Management | 27 Comments »

One phrase that makes me cringe in the workplace is “We don’t have time”.

It bugs me because none of us have more time than anyone else. We all get roughly the same amount of time to do whatever we’re going to do life stuff in. But what we all have, unless you’re doing 5 years at Riker’s Island, is control over how we use our time. I can pick which of the infinite things to do with time to use for this hour, and the next one, and the one after that.

So to say We don’t have time to do X really means X is not important enough for me to use my time on it .

This second phrase is a very different and more useful thing to say. If we’re talking about importance we can compare two uses of time and see which is more important.

Other more honest things to say include:

• Your idea stinks
• Your suggestion is for a low priority issue
• I screwed up and didn’t consider this earlier
• It’s too late to take on the risk of changing the plan
• I don’t like you and you smell funny

But people who say “we don’t have time” are saying it to avoid a conversation. They want, mostly, to blow you off and move on.

Case in point: If I told you I will give you a billion dollars for going to lunch with me tommorow, no matter what commitments you’ve made, you will likely change them so you can get the billion dollars. Time is not an issue - the priority of two competing things is. Depositing a check for a billion dollars will trump most everyday life commitments easily. And by the same token, a sufficiently brilliant idea would cause any leader to make changes, including adding more time to the schedule. The real question is whether the proposed idea is good enough to warrant change.

The Countermove: when told “We don’t have time” by a project manager or co-worker, the best questions to ask are:

• What is (your) time being used for?
• How was this decided?
• What were the goals of this use of time?
• Can I explain why my idea is a better use of time towards those goals?

All these countermove questions force a discussion and more importantly some thinking to take place. Any idiot can say “we don’t have time”, but only a good leader will happily explain why.

Obviously, pick your battles. On healthy teams people can intuit which of the first list of better phrases is actually meant, and on unhealthy teams, the dude who challenges every single decision, every single time, is going to be ignored for that reason alone. But if it’s a battle worth fighting, or it’s a habit you want people to start breaking, use your countermoves.

See also: “We don’t have money”, “We don’t have enough staff”

What phrases drive you nuts? Put ‘em in the comments and I’ll take a shot.

Posted in Management | 12 Comments »

I’m stuck in the Vancouver airport, waiting for them to find a new plane.  Hard to complain about waiting for a new plane, when the old plane broke. Tell me the current plane might explode and I’m happy to wait, thank you very much.

Waiting in at the gate, in between trying not to strangle the kid dancing precariously close to my luggage, and the guy with laptop problems on my left who has his volume set to 11 (I will be hearing the Windows startup song in my sleep), I made a sketch for ideas in organizations.

The arrows are the paths of different ideas. The box in the middle is the organization.

Whenever leaders want more innovation, they typically start by adding more inputs into the process. They seek out more ideas. Hey, lets brainstorm! Or maybe we should crowdsource! Or how about getting everyone to mindmap!

Executives often do this flinchy sort of thing and it’s big news at many corporations to start “idea programs” to encourage people to submit ideas.

These programs are launched, ideas are submitted, and there is much rejoicing.

But little change.

The reason there is little change is that idea inputs were never the problem. The bottleneck was further upstream. Crowdsourcing, brainstorming, mindmapping, and the dozens of other techniques people obsess about help create early idea volume, but do little to help the curators, the people who winnow down the hundreds of ideas down to dozens, and dozens down to a handful. 

It’s much more useful to study where the bottlenecks are, when and why new ideas are killed, and who the people are that are killing them.

If you have 1000 new ideas a month, but 0 prototypes are ever made from them, what good is another 2000 ideas? It’s much better to study why there is no time or rewards for prototyping and focus on getting that number to go up.

An easy diagnostic for innovation is the list of 10 stages - Where do ideas die in your world? That’s the place to study and make changes to help ideas survive longer in your organization.

The real challenge is getting ideas out the door - not how you generate ideas. It’s more useful to study how ideas die - what reasons are used? Who has the power to do it? And when and why are they using it?

Sorting out the lifecycle of ideas in an organization requires study and thought, while slapping more idea generation techniques on the front does not.

Posted in Innovation, Management, creative thinking | 9 Comments »

Rodica pointed me at this article on why requirements stink on ice from the Forrester blog, which asks the question, why aren’t we using social media in helping to sort out what customers want, instead of relying solely on customer interviews and other old school approaches.

My answer? This is the wrong question. Data collection is not the big problem. Sure, forums and blogs can be handy, but rarely is finding better data the big challenge.

Requirements suck for two major reasons.

1. Requirements is not Design.

Here’s a requirements list: Make a $5 car that goes 500 miles per hour, weighs 10 lbs, and is invisible. Those are very clear requirements. They’re also impossible. No matter how well defined these requirements are, or how happy the customer and the VP is with them, the project is set up to fail.

How can you know if your requirements are BS? You probably can’t. Requirements are not a product. The product is the product. A requirement is best seen as a way to help the design/engineering team succeed in making the product. End of story. The design/engineering team is the true customer of a requirements document. They know first hand all the stupid things requirements often include since they’ve been forced to experience them before. Want to avoid these stupid mistakes? Get their input early.

The easy test for how much a requirements document sucks or rocks is what the people who have to use it to do their own work think of it. If they think it sucks, they’re right.  This means anyone charged with requirements should, from day one, be collaborating with the designers and engineers in defining the requirements. Incorporating their ideas, their feedback, and convincing them of new perspectives they need to understand. If they think requirement #21 is stupid, and they are wrong, at a minimum, it’s Mr. Requirement’s job to invest the time to convince them otherwise. I don’t want an engineer working on something s/he thinks is stupid. How I can expect them to do good work on something they find stupid? I couldn’t do good work that way.  So I can’t expect them to either.

However, if you throw a requirement over the wall, which is what most requirements document authors pridefully do, it’s about as likely to succeed as throwing a hand grenade - people will scream and run.  But if instead the requirements document is something they feel they contributed do, that it’s in part their document, they’ll run towards it, love it, and work hard to make it real. Bingo.

2. Too many cooks.

Requirements processes are long and stupid only because authority is spread out too thin across the organization. Talk to any person that is self employed, like your plumber, your gardener, or even your hair stylist. They do requirements gathering with their customers all the time, for important and expensive things, without 20 page documents, committee meetings or therapy bills. How is this possible!? What magic do they know that has yet to hit the business world? It’s simple. They have requirements authority. They have the power to make decisions.

Your requirements process sucks not because you don’t have the right forms, or because you’re not following the right process, it’s because you have too many people involved, all pretending to be effective with a tiny, minuscule piece of the requirements pie.

Pick one person per major area, a person who gets that requirements are part of design and not the other way around, a person who sees the value of collaboration and input, but is confident enough to make unpopular decisions when they are in the best interest, and give them the authority to drive requirements. I guarantee quality will rise sharply by picking the right person and giving them more authority.

Fewer cooks. It’s a simple way to solve  many problems, but oh so rare to see.

The one book anyone working on requirements needs to read is Exploring Requirements by Gerald Weinberg. It points out most of the stupidity that goes on, explains avoidance tactics, and clearly expresses how requirements are part of the design process - that good problem solving techniques can quickly make your requirements documents better than ever.

Weigers Software Requirements has an excellent reputation, but I’m not as familiar with it as Weinberg’s book.

And Chapters 3 thru 7 of my book Making things happen offers one way to get from ideas all the way to specs. There are tons of other ways of course, but if you want my general take on this for large teams, it’s in there.

And Getting Real, by the folks at 37 signals, is a book that puts simplicity first, advocating almost no formal documents, requirements lists or specs at all.

Posted in Management | 18 Comments »

There’s a new book, soon to be released from O’Reilly called Beautiful teams, edited by Andrew Stellman and Jennifer Greene that i want to give you a heads up about.

I’m a huge believer in teams. Team sports. Team players. Team leaders. It’s all about teams. Show me a great project and I’ll show you a good, or not totally sucking team. Show me a project in trouble and the first questions I’ll ask won’t be about methods, schedules or technologies, I’ll ask about the team.

I’m also someone who hates bullshit. Who gets frustrated by phony stories about made up concepts on how good teams are nurtured and how great teams function. I want the real stories from the people who were there. I want the dirt. I want the scars. I want it all.

So I’m thrilled to tell you O’Reilly is finally publishing a book on teams, with chapters from two dozen luminaries from the software world, on what they learned from the teams they worked on. Tim O’Reilly, Cory Doctorow, Grady Booch, Steve McConnell, Barry Boehm, Karl Fogel, Johanna Rothman, the list of kick-ass names who contributed to this book goes on.

The book is called Beautiful teams: Inspiring and Cautionary Tales from Veteran Team Leaders.

I was lucky enough to be asked to make two contributions to the book. A chapter about my experience on IE4 called “Why Ugly Teams Win”, and an extended interview with Steve McConnell about good teams and how they’re made.

As a kicker, profits from the book aren’t going to contributors, they’re going to charity - Playpumps International to be specific.

You can pre-order the book now at amazon.com.

Posted in Management, Software/Web development | 3 Comments »

Next Monday, March 30th, I’m teaching my full day course on how to lead and manage breakthrough projects in San Francisco.

(UPDATE) Winner was announced yesterday.

There are only a few seats left, but as a perk I get one golden ticket to give away - So here’s your chance.

For reference, highlights of the course include:

• A top rated, world class, fun, interactive heavy kick-ass full day course
• Skill development for creative leaders on important projects
• Tools for developing, managing and executing on big ideas
• High energy, fast paced, minimal bs agenda (full agenda listed here).
• Interactive lessons on creative thinking & management from the great innovators of all time
• Covers material and exercises that go well beyond what’s in my books
• Free consulting or Q&A with me over email after the course
• A signed copy of the bestseller, The Myths of Innovation

If you’re in the SF area, or will be on Monday, and want a shot at a $600 ticket, leave a comment. I’ll pick one lucky winner for FREE entry to the course.

How to enter:

1. Leave a comment
2. Wait (and cross your fingers)
3. Winner chosen end of day Wednesday

If you don’t want to gamble, registration details for the course are here. Use the promo code berkunproj25 to get 25% off.

Posted in Innovation, Management, On Tour, Teaching/Training | 20 Comments »

There’s a fantastic little essay over on Noop.Nl about some clever philosophical questions about what projects are. The essay is called Your project has no goal, and he explores why human beings tend to place reasons and explanations into things that are way more about us than about what’s really going on. Includes fun references to Taylorism, and The Selfish Gene.

I doubt I agree with all his points, but who cares - this was the most interesting project management related read I’ve come across in awhile. Good stuff:
Your project has no goal - Noop.Nl

Noop also has several lists you might want to check out, including the top 100 blogs for developers, and the top 100 best software engineering books ever.

Posted in Management, philosophy | 3 Comments »