One day this week, I think by accident, an essay of mine appeared on digg.com’s home page. The essay was “Why I left Microsoft“, something I wrote nearly a year ago. A big wave of traffic ensued, and then, the flame mail :)

The problem was this: I wrote the essay from my point of view: Why I left Microsoft, which is more about me and my life than about Microsoft the company. Ordinarily, who cares? But when a major site like digg lists a link to “Why I left Microsoft”, everyone naturally expects a bunch of fun insider information (and dirt) about what’s going on in the company. And when the web doesn’t get what it expects, well, flames and snideness ensue (as you’ll find if you skim the digg.com comments).

To make ammends I’m glad to write about Microsoft the company. I did write a short google/MSFT comparison, but when do you want to know? There are plenty of books and sources for insider information for those than want it.

Leave comments here - and I’ll write a follow up called “Looking at Microsoft” more in line with what folks wanted to read in the first place.

(And thanks to all that had nice things to say about the essay - appreciated that)

Posted in Microsoft | 5 Comments »

Someone on the ask Berkun forum requested an essay for new managers. It’s a huge topic - there are entire books on this! - but I took a good swing and here’s what I came up with.

Advice for new managers, part 1

Part 2 will be more on tactics and specific things to do in the first few weeks.

Posted in Essays | 5 Comments »

Essay #50 will be published today - Its been 6 years of writing these things, first for MSDN, then at uiweb and now here. Thanks to everyone that’s been reading and writing in with questions and requests for essays - hope you’ll stick around. The next book is in progress and I’ll have details soon.

For fun I went back through all the traffic logs and looked at what’s been popular. So here is a traffic determined best of Berkun thru 2005:

1. Why smart people defend bad ideas
2. How to survive creative burnout
3. How to give and recieve criticism
4. Why good ideas come from Bad
5. The myth of optimal web design
6. How to pitch an idea
7. How to build a better browser

Full essay archive

Posted in Essays, On writing | No Comments »

Last year Joel Spolsky, of www.joelonsoftware.com fame, published a collection of essays titled The best software writing, volume 1. I thought it was a good volume and a great idea. Most of the essays are from blogs or the web, and were nominated by Joel and readers of his website.

He’s accepting nominations now for Volume 2 and there are already some good reads posted up there.

Posted in Software/Web development | No Comments »

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)

Posted in The Art of PM book | 3 Comments »

In Fred Brooks’ Mythical Man Month, he states:

Brooks’s 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 there are important exceptions that many people don’t take the time to consider when using Brooks’s law to justify something. I hinted at them in chapter 2 of The art of project management, but here’s a full explanation of the notable caveats I’ve seen.

• It depends who the manpower is. The 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 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 resiliant to change. They can 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 for 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 ramp up 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 managers 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 personel: 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 or that religious adherence to the above. All additional examinations or applications of Brook’s law, or these exceptions, are welcome.

See also: the social contexts of open source software, from the Cathedral and the Bazaar.

Posted in Management, Software/Web development, Uncategorized | 4 Comments »

Fortune magazine has an interview with the legendary Fred Brooks, author of the grand classic The mythical man month. 30 years in print and the book still outsells almost every project management or software development book out there.

They asked him about open source, Microsoft Vista, and how Brooks law applies to other fields.

Interview with Fred Brooks.

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

SlackerManager has a fresh review of art of PM:

This is a really great book and ought to have a permanent place on any manager’s (not just project managers) desk. Highly recommended for managers of all experience levels.

Full review

Posted in The Art of PM book, artofpm reviews | No Comments »

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.

Posted in Design | 7 Comments »

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)

Posted in PM-Clinic | No Comments »

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

Posted in UX-Clinic | No Comments »

I used to think of new years, and resolutions, as silly things. “Why do we need a reminder to make changes in 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 1st.

But now, older, perhaps wiser, I respect new years. 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 Cambell’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 regarless 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 religuously 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.

So 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 refridgerators, 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.

Two 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 :)

My first resolution for 2006 is to revive Scolidays and celebrate them all this year.

Update (3/16/06) - List of 2006 Scolidays now available.

Posted in Uncategorized | 9 Comments »