Quote of the day
“An intelligent hell would better than a stupid paradiseâ€
-Victor Hugo
Author: Scott Berkun
And the $600 Golden Ticket winner is…
First, thanks to everyone for entering the contest.
The overlord / demigods at O’Reilly saw the long list of people who wanted a free ticket to Monday’s class in SF and blessed me with two tickets.
The winners are Brandie and Chris. Woohoo! Congrats guys!
I sent an email out to both of you. Please RSVP to me with 24 hours, otherwise I’ll give the tickets away to someone else.
For the rest of you: as of this writing there are still one or two seats left. You can still sign up for Monday’s class, and at a nice juicy %25 discount, by going here and using the code berkunproj.
Why Requirements Stink
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.
New O’Reilly book: Beautiful Teams
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.
Free $600 ticket to Monday’s MasterClass (San Francisco)
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.
Your project has no goal
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.
Live webcast, why designers fail (and what to do about it)
On Tue April 14th I’ll be doing a live webcast for UIE on Why designers fail and what to do about it. This will be the full 90 minute version of my talk, with some new twists and updates specially designed for this webcast, and it includes tactics and approaches to thinking about failure and how both to change your philosophy about experimentation, but also tactics for learning as much as you can from your failures, and failures of designers and creators throughout history.
For this 90 min live talk, a talk you can participate in from anywhere in the world, wearing only your underwear if you choose as I won’t be able to see you, for $129 – Here’s my promo video for the session, with audio voiceover, including a last slide that details the value you’ll get from tuning in.
Why designers fail and what to do – PROMO
View more presentations from berkun.
Details and registration info here – Use my promo code BERKUN to get the discounted price of $99.
Q&A from today’s webcast
Thanks to everyone who tuned in – we had almost 300 people according to WebEx.
The webcast will be posted soon on O’Reilly’s youtube channel.
Next time I do one of these I’ll be sharper – there were lots of good snarky comments I missed in the chat room during the talk, plus a twitter stream (#berkun).
Here’s some of my favorite snarky comments:
From Melina: How to make things happen: 1) Have a good idea. 2) Be willing to implement that idea. 3) Be persistent until you get your way. $39.99 please.
from Steven: Now you see the repression inherent in the system…. (watch this if it makes no sense)
From Keith: First they ignore you. Then they laugh at you. Then they fight you. Then you win. (GandhiCon).
from Andy: If you’re getting coffee at the risk of getting shot, you might have an addiction.
Questions:
From Kathy: How can you initiate change in today’s environment when colleagues/managers are scared and increasingly entrenched?
All emotions have power. If people are afraid or worried there is energy a persuasive person can use to support an idea. Anyone scared wants change – they want to feel safer from the thing they are afraid of. If you can propose an idea that makes them feel safer, they’ll be interested.
From Margaret: How do you recommend becoming better at persuasion and intuition?
Watch the ShamWow guy 50 times.
Ok, only half kidding. My next book is about public speaking and I will talk about this. But persuasion involves two things: 1) know your stuff 2) know your audience. I’d pitch very differently to Steve Jobs than I would Bono. I’d tell different stories and emphasize different things. So one easy local tip: if ever you have to persuade someone, ask for advice from other people who have tried to persuade that person. You’ll learn from what worked, and didn’t work, from them.
From David: are there systematic methods for coming up with innovations? can you recommend?
I think not. Systematic is not a word I would use. There are systems for experimenting, including what scientists and researchers do, but that’s not the same thing as a systematic method for innovation. They have a systematic way of creating an environment where innovation is possible, perhaps likely, but there are never guarantees. Most start-ups fail: it’s hard and risky no matter how good your ideas are.
Much of the time the biggest hurdle for an idea are other people. Whose approval you need, what resources you need loaned to you, and convincing customers to try your new thing. There are no guarantees with these kinds of challenges. Many innovations sit around ignored and rejected for years, only to accepted later, the same exact idea or concept, when people’s attitudes finally change.
That said, you can systematically breakdown all of the challenges you have to overcome, and decide where you need the most help.
From Jeffrey: Scott, consider a situation where a small company is acquired by a larger company, and change means giving up the way things have always been done in favor of fitting into and aligning processes with the larger organization. Any special tactics/recommendations?
If you’re the smaller company, the time for this is before you sign. You have leverage then to ask for whatever you want, including keeping certain job roles, working conditions, etc.
If your the larger company, I’d ask the smaller company. I’d invite them to visit our offices (not just their VPs, but some of their line level employees too) and ask them to consider what provisions we can provide them to keep their culture, or their secret sauce, intact. Just inviting them into the conversation scores points and builds trust.
From Clinton: What to do in an environment where there is so much change being driven by the customers as a result of contracts? Really so much change that you can’t keep up.
All contracts are signed by two parties, you and the customer. If there is too much change to be successful, or sane, it’s not the customers fault. It’s yours. Saying No is always important. Saying yes to everything, including deals with customers, dilutes your focus, stresses your people, and makes priorities impossible. If a client asked me to do more than I could, I’d tell them it’s in their interest I say No.
From Praveen: How to control creativity to make it safe.
I don’t know that you can. Like the example of moving your desk in the webcast, change always effects someone negatively, or will be perceived as such, by them. However if I’m the boss I make creativity and change safe by funding it, supporting it and nurturing it. It starts by providing constructive criticism of ideas and accept some of them. When people see one idea get approved, they’ll suggest more and trust you to be fair in how they’re judged.
If you tuned in and have a question, fire away in the comments.
Live webcast, in 45 minutes (10am PST), today
Coming up in less than an hour is my live webcast on how progress happens . A few hundred people are signed up, but it’s not too late to register and listen in.
Wednesday Linkfest
Tons of good stuff this week:
- The evolution of a project manager – Interesting take on the various levels of impact a project manager can have, from paper pusher to team leader (hat tip, Raven)
- Harry Beck: The Paris Connection – Some of you may know I worked on a book about the london subway system. Beck is the guy who designed the famous 1930s version of their map, the basic design that lives on today. It was news to me, but he also proposed a map for the Paris subway system (hat tip, Paul).
- 8 Brilliant Scientific Screw-ups – the problem with articles like these about accidental inovation is they overlook the important part. After the accident, all these people did tons of work to figure out why the accident happened, something few of us ever do.
- Wall of Deliverables – I love the idea of a place for designers to share prototypes and work for critiquing and exchanging ideas. Hopefully this will take off. It’s funny to me how most dialog in the design community is over text based email – for all our tech, we still mostly describe our designs with words instead of showing them.
- A Medical Madoff: Anesthesiologist Faked Data in 21 Studies: Scientific American – another reason to always ask basic questions about research that seems too good to be true.
- Mapping the Innovation Gap – This is the most important chart I’ve seen in months about understanding how innovation happens.
- Abraham Lincoln: A Two-Way Innovator – Nice article about how important problem defining can be. Many creators I know can work either way, they might have a preference, but once they have an idea they like, or a problem they’re interested in, they don’t really care.
- BrokenPictureTelephone.com – The Game of Miscommunication – Home – If this doesn’t make you laugh you need to seek help. Only gripe is registration is a bear and there’s no easy way to just invite 5 friends to play. This one about a tornado is one of my favorites.
- Book Vs. Film: Watchmen | Books | A.V. Club – Interesting website focused on writing reviews of books made into films. This review is about the watchmen (a book and film I liked in both forms).
Review: WordPress 2.7
I hate upgrading WordPress for one reason: hand copying files. Hand copying files, even as few as are required for WP, always runs the risk of doing something trivial and stupid that blows everything up and is hard to recover from. As a mostly non-practicing geek, I don’t write much code or touch command lines often, so despite my CS degree, I don’t trust myself and I wait to do this until I think it’s worth it. And this upgrade to 2.7 totally was.
First and foremost, they finally have auto-updates – it should be the last hand-copying of files I ever need to do. WooHoo!
But more importantly as a usability expert I rarely use things that I can’t find something to complain about. Well, after using this thing heavily for a couple of weeks I don’t have one yet. I like EVERYTHING they did. Can’t recall last time that happened. Possibly never.
Summary: This thing is great. Best blogging software I have ever seen ever. It’s a fantastic piece of design excellence and simplicity. Definitely the best software I use regularly, hands down.
Highlights:
- The Dashboard rocks. Previous versions never made me feel warm and fuzzy. All the stuff I did first was obscured and it all seemed like news about WordPress details I didn’t care about. Fixed. The default view emphasizes what I do often, by default, approving comments, replying to comments, tracking drafts, etc. Plus they added a quickpress tab, which allows short posts without a single extra click.
- Core UI now left pane. The major UI change is shifting navigation to the left pane, which seems trivial but works great. It reduces confusion with the UI stack I’ve complained about before. This also allowed the category chooser UI to move up where it’s easier to access.
- Various non-intrusive UI smarts. This is where the love comes in. Many small design choices that over time make a huge improvement. Lists now give a short set of commands on mouse over, so one click can now approve, delete, or edit or even reply to comments. The plugins are now auto-divided into active and non-active. There are various non-intrusive UI additions like these and they all made me smile, I knew they saved me extra clicks that i do several times a day.
- The promise of auto-upgrade. My hand copying of files may be over. WordPress 2.7 includes what appears to be a built-in install program, so I shouldn’t have anything to fear in the future. Haven’t had it work yet, so I’ll report back when it does.
Minor gripes:
- See. I told you I’d find something. The dashboard uses the color red to indicate the count of spam comments. Sure, spam is bad, but Akismet, their built in spam catcher does a great job and I never need to look at Spam. Red is a danger color – it means something is broken or wrong, but since there is always spam, I always see red on the dashboard even when things are ok. It should be regular text, yellow, anything but red. I should only see the color red on my dashboard if there is something urgent and bad I need to deal with.
- I’m still confused and scared by plugins. There are big improvements on plugins: there is now an auto-upgrade UI in the plugins manager that lets me know when plugins are out of date, and even auto-upgrades them from within WP. But I run a site with very few plugins because when they break, they BREAK badly. There are tons of these made, but it’s hard to find reliable ones that I’m confident will be supported into the future, or will stay in sync with wordpress upgrades. I’d happily pay $$$ for a pack of premier plugins that are top quality and come with some kind of promise of service. I bet other people whose blog is their business would as well.
- The add picture/video UI is still a bear. It’s a flash based UI that jarringly takes over the screen only to show a progress bar. It’s slow and complex – not designed for the simple/common cases first. No matter how many times I use it, I’m slow with it. As best I can tell it’s unchanged from WP 2.5.
If you were waiting to upgrade or are looking to switch, now is a great time. WordPress 2.7 is an excellent upgrade.
When your VP doesn’t understand your job
A common problem experts have is working for an executive who has no idea what they do.
The trap is often that the expert is hired before anyone understands what changes are needed in the organization for that expert to be effective. So the expert, lets say it’s a designer, sits on the sidelines, frustrated, while the VP is happy since now s/he can say “We have a design expert on staff” even if that expert isn’t contributing anything at all.
As frustrating as it can be, this situation is common. It just means you have to be an advocate for your role, instead of just performing it. Here’s a battle plan:
- Make small wins. Pick one specific problem you can solve that the VP, or their organization, already values (e.g increasing profits, improving customer satisfaction, reducing costs) and go do it. Do it well. Then point to what you did and ask for a little bit more responsibility. Focus on making simple and clear contributions to earn basic respect from your peers on their terms.
- Use their language, not yours. Stop using your domain language, and translate into the language of the people in power. This may mean learning about P&Ls, marketing plans, test regressions, or other terms, but speak their language and offer your value in terms they know, instead of insisting they learn yours. You are on their turf and should act accordingly. Think of yourself as Navy SEAL, adapting to the terrain you land in. If you can’t translate your work into terms they understand you will fail for that reason alone.
- Get a supporter. Of the people interested in your work, who has the best combination of power and interest? They’re your ally and you need to cultivate their support. Share your goals and ask for their advice. “I’d like to be involved earlier in the decision making process. How do you suggest I make this happen here?” As an outsider, you need insider support to have any chance of growing political capital.
- Find something small and specific to ask for. Anyone who does not know what you do has no reason to invest in you. Your relationship with them begins with you asking for something small and reasonable, and using it for the benefit of the entire team. Ask for a small amount of money, ask for a small amount of time from programmers, but ask. Offer something in return: higher quality, greater efficiency, higher profits. Something. When you get what you ask for, hit it out of the park – do an amazing job. You may only get one shot so make it good. Show the results and if everyone is positive ask for something a little bigger. Repeat.
- Show an example from a company/team they admire. If there is another project in your company where you role is well understood, use them as an example. Show how your counterparts in that organization interact, and how they benefit from it. If you can’t find an example in your company, look to other companies your VP admires.
- Worry about your peers first. It’s hard to score points up the food chain without a good reputation at your own place in the org chart. It’s daft to take on the VP when the middle level managers don’t know who you are either, or worse, think of you as someone who complains all the time but adds no value. You might have a local manager who is well connected up the food chain: if you can get a small amount of support from them, it will open doors you can not open yourself.
- Maybe the VP doesn’t need to know. VPs often have less power or influence than you think. There may be a team lead or group manager who is the true power source for your project. Think carefully about what power you need to be successful and who can grant it to you. It’s likely someone more within reach in the org chart than the VP. And of course, consider this: the best way to be introduced into the VPs power circle is by invitation. If your reputation for making big contributions precedes you, they may in fact seek you out, and not the other way around.
Related:
How to deal with people who are jerks
Christian recently asked, in a comment on how project managers get power:
How did you work with those infamous programmer-jerks? How did you handle rough inner team situations?
The best place to start is empathy. Why is someone acting like a jerk? There are basic psychological reasons for this: Either they are insecure, unhappy, or angry about something.
Ok, there is a fourth reason, that they are psychopathic hell spawn put on the earth to torture all living things in a 10 foot radius, especially you, but lets assume that’s not the case for a moment.
In all three cases it’s possible they have good reasons for behaving like a jerk. Perhaps they are angry at upper management for the same reasons you are, but they see you as part of management (which, if you’re a PM, you are). Or maybe their last project manager was incompetent. Who knows? Not you. You don’t have a clue.
Odds are good it has nothing to do with you – it has to do with how they feel about what’s going on around them. Starting with a little empathy opens the door to finding a solution. If you start with “Fred is a jerk so I will treat him like one” you are likely perpetuating his reasons for behaving like a jerk, and everyone loses.
That said, there are four assets you have: charm, ability, roles and allies.
- Charm to connect. Being likable goes a long way in dealing with people. I don’t mean false niceness or being a cheezeball. I mean using your sense of humor, your natural generosity, your shared interests with someone to establish some basis for positive interaction with another person. It could be almost anything, but look for it. Good morale events help make these connections happen. If you happen to like Metallica, or Porsches, and they do, you now have something positive to talk about where it’s safe for everyone to share and connect.
- Demonstrate your ability to help . If they love making great software, if that’s really what they want, then you just need to show you can help. Even if it’s just helping meetings run better, or eliminating stupid annoyances in how decisions get made, defusing politics, reducing meetings, etc. There are a thousand easy things a decent PM can do that the programmer will noticeably benefit from. Start by asking “what can I do to make you more effective? more productive?” And listen to their answer. Do some of what they ask, come back and ask if it helped. Even if it’s a small thing, you’ve now built a tiny basis of respect for how you can help them.
- Agree on the roles you both play. More than half the time PMs suffer because people do not understand what the PM is doing. What you need to do is sit down with the programmer and make three lists: what I do (write specs), what you do (write code), what we both do together (triage bugs). Invariably there will be disagreements as to who does what work, but by listing them you’ll find all the sore spots in your working relationship. If you strongly disagree on roles, and he thinks you should wash his car, you should be able to go to your respective bosses and ask for clarification.
- Get help from your Allies. Which programmers do you get along with best? These are your allies. Ask them for input on working with Fred. Get their perspective on the frustrations on being a programmer in your organization. You may be able to see Fred in a different light. Have other PMs worked with Fred? What insights do they have?
Of course if after investing some of this energy you decide Fred is, in fact, demon spawn hellbent on destroying all positive energy in the universe, talk to your boss. If Fred is as bad as you say, others will complain and it will become your managers job to solve the problem (fire Fred, move him to more isolated work, get him a therapist).
Most of the time the real problem is people not sharing goals, and not listening to each other. Two things that your average project manager should be good at identifying and resolving.
See also:
- Why project managers get no respect
- Top ten reasons managers become assholes
- Asshole driven development (Now with 285 comments)
Palm centro: follow up review
A few months ago I finally purchased a new cell phone, a Palm Centro, first in about 5 years. My review was positive, but as with most reviews, them come early in the life of using the thing, and you never get to hear what happens after months of of usage. So here’s a follow up review – Steve asked for one, so here it is (Hi Steve!).
In short: I still love this phone.
The good:
High ease of use, simple design, I love the keyboard (YMMV – see picture), it’s small enough to slide into any of my pockets and has decent to good battery life. There are various little UI design elements they got right, such as reply to a missed call with a txt message, a nice vibrate switch right on top of the phone (can switch it without taking it out of pocket), and an easily toggle-able flight mode for being on planes.
It has a handy pseudo-GPS feature, that uses cell-towers to triangulate position in google-maps. Works great. I use it all the time. It’s accurate to within 500-1000 feet which is enough to get a map I can figure out no matter where I am.
I rarely use the stylus that comes with the device – a finger works fine 90% of the time in all the UI I use.
The bad: There are a few minor complaints. Trying to be thorough here, but despite the list these things are minor. Rarely encountered or little impact.
- Minor performance issues. The phone can get lost when you have too many apps working – switching between them sometimes can be slow. In these moments it feels like the device needs more RAM.
- Web browser is adequate. I use it often and its fine. It’s definitely underpowered for large pages and it doesn’t handle this well. So if you happen to hit a complex 500kb table or something, the browser chokes – it will time itself out after 20 seconds or so, but it’s not fun. This is rare, but does happen if you’re doing heavy web browsing and end up on heavy duty pages. The close window button is too small to hit with a finger, so you need the stylus to kill the browser.
- The sync plug is a bear. It’s a strange plug, with a wide two pronged adapter. It’s impossible to get this thing out without a lot of force, and I’m always afraid I’m going to break it, which would make the phone impossible to sync. It is a durable plug, it’s just designed in a way that makes me nervous when I use it.
- PDF support is slow. There may be a better PDF viewer than the one I have, but the I have makes sleeping turtles look fast, and its UI is frustrating – feels like a bad port of a standalone viewer, not one designed for a small screen. It works, but is slow and annoying. I tried to read a restaurant menu through it once, scrolling around, trying to zoom in and out, and simply gave up.
So if you can’t wait for the Palm Pre, which looks pretty sharp, The Palm Centro (product info here) could be a good choice.
A lesson in customer service (why my site was down today)
I was out and about today, and got home to find email from a friend telling me my site was down (Thx Livia). Hmmm. Ok. Checked it out, and they’re right.
So I check the dreamhost status site, and there’s nothing for today. Ok, so I contact dreamhost directly. I hear back quickly.
I’m told they suspect there is a script running on my site that used too much memory, shutting down the entire site. I’m sent a reference for how to investigate this myself to figure out what might be the cause.
Meanwhile. My site is still down.
I say WTF. I can’t fix this if I can’t get to my site. And moreso, why not charge me $50 or whatever you want for going over my memory limit, a fee I’d gladly pay, instead of HAVING MY SITE DOWN AN ENTIRE DAY.
I ask them to temporarily bump my memory to get the site up, which they thankfully do, and fix the likely cause of the problem (a plugin I didn’t update when I upgraded to WordPress 2.7).
Lessons:
- Always inform customers if you are turning their service off, regardless of the reason. I should not need a friend to let me know, or be surprised on my own, even if I’m to blame for the reason the site is down. Always notify me when, and if possible before, you turn off what I’m paying for.
- It’s better customer service to charge extra for doing the right thing, and keeping *my customers* out of it by loaning me more memory. It’s done for bandwidth, for overdraft charges at the bank, why not for memory usage? Charge me whatever you want – just don’t ever let my site go down.
Anyway, end of story is I’m sorry the site was down. And end of the line I’m to blame. Dreamhost has always been a mixed bag of good and bad. They suggested their PS service, which does allow for variable memory use at a price, which I’ll check out.
Live webcast: How progress happens, Free! March 19th
Next week I’m doing a fun, live, one hour webcast on my latest thinking about progress and innovation.
The best part is, if you’ve got a question you want me to answer, read below and I’ll work it into the presentation.
Description: Talking about innovation is easy – but making change happen in organizations is ridiculously hard. But there are things we can learn from the history of technology, political revolution and change, and there is a playbook we can reuse to help us avoid easy mistakes and seemingly popular, but actually self-defeating approaches. This fun, interactive and entertaining talk will prime you for leading change, managing true innovation, and enhance your skills for motivating, managing and leading people in the real world. And Scott takes requests: if you have a specific question or situation you want Scott to try and work into the presentation, leave a comment, or drop him a line at scottberkun.com/contact.
Attendance is limited, so register now. We’ll send you a reminder before the webcast. And please feel free to share this invitation with others.
Date: Thursday, March 19 at 10 am PT
Price: Free!
Duration: Approximately 60 minutes
To register: oreilly.com/go/progresshappens
Questions? Please send email to webcast@oreilly.com
How project managers establish power
I remember the day I started working as a program manager on the Internet explorer team. On my second day, Joe Belfiore, my boss, came to my office, closed the door, and told me two things:
1. Your relationship with programmers is everything
2. There are only two teams at Microsoft to care about, Windows and Office.
Forget for a moment these specific points. Joe did the most important thing in the world as a boss. He gave me clear priorities. Even if they were wrong, from day one (ok, it was day two) he imparted his private view of how to succeed and how to make sense of things. It was amazingly empowering. I could slice through all of the work being thrown at me from across the team and the company, and divide into two neat piles: a) things to care about, b) things not to care about. Joe was a great boss and provided this kind of clarity all the time.
It turns out both bits of advice were right.
Your relationship with programmers is everything
As a program manager (glorified title for project manager), all of my power actually came from the programmers. I only had a job because of the programmers. No programmers means no code, no product, no revenue. End of story. My power was an extension of theirs. I had to treat them with respect and go out of my way to earn their trust over time.
This meant first and foremost I had to earn their respect. Help them make decisions. Bulldoze organizational road blocks out of their way. Prove I was smart, that I could help them make tough decisions, and could make the product much better even though I couldn’t write code as well as they could. And only after establishing that value could I be a team leader and be of true use to the project. With programmers as allies, working with marketers, testers, executives, or leaders of other teams, became easier, and my role as a team leader became possible.
When I visit companies or talk to people, and they tell me they rarely talk to the programmers, a red flashing light goes off in my head. How on earth do you have any power? I wonder. You don’t know the people who actually make the thing you are managing! You have no idea if they believe in what they are doing or not, or if they have better ideas than yours. Something critical is broken if project managers don’t have collaborative and trusting relationships with programmers. If there is a problem between PMs and programmers, it’s the PMs job to fix it. Odds are they’re better at communication, conflict resolution and have more perspective, all of the key skills for resolving differences and building relationships. Put another way: if you’re a PM and your team hates you, what else do you have? Your relationship with your team is everything.
There are only two teams at Microsoft to care about, Windows and Office.
Back in 1995 when Joe gave me this advice, it was true. There were only two groups at Microsoft that were successful and brining in sizable revenue. The problem was working on Internet Explorer during the browser wars, every one of the 100 teams in the company wanted something from me, and every other PM on the team. They wanted us to add features to help promote their work, code changes to fix bugs that bothered them, etc. There was a huge pile of people who wanted to influence the work I managed. My phone rang all the time and my inbox was always full. If I treated everyone equally I’d be doomed. Couldn’t be done. I had to ignore, or say no to, most of the people who wanted something from me. With Joe’s advice I had a rough guide for sorting it out. Tons of exceptions of course, but the baseline advice was right and useful.
Good managers give these little bits of power insight all the time. Dividing up the complex, stressful working world of projects into two piles. A project manager derives his power from this kind of clarity, especially if he can articuate it to others like Joe did to me.
Program Managers vs. Interaction designers
Recently Joel on Software posted about how to be a program manager and he lists UI design as one of the skills program managers should be responsible for. It’s no surprise that people who call themselves UI designers, such as the folks on on the interaction design mailing list, have taken notice and are mostly unhappy.
(Back story: The idea of program managers, roughly a sergeant level generalist who drives projects, is an idea I like. It’s a job role Microsoft started in the late 1980s . It’s a job I had in the 90s).
Which gets to the question of should PMs do design.
The easy answer is yes, if they are good at it. Most are not. Most do not know this because they’ve never met an interaction designer, someone who does it professionally for a living. Simply because Fred is better at it than his peers, he assumes he is good. It’s not his fault exactly. Most computer science programs and business schools never talk to design schools. Certainly not about how much they need to learn from the other. And most program managers in the world are hired from computer science and business schools.
Anyway, the better teams at Microsoft figured this out over a decade ago. They did one of:
- Hired full time UI designers and usability engineers. (In 2003, when I left, there were over 400 of these people employed at Microsoft).
- Created a special role called a UI PM, who was the PM good at design who led the UI work.
- Or both.
VPs that cared about ease of use invested in these assets, and just as important, built a culture around ease of use taking priority over other considerations.
However, in most cases the above investments had moderate impact on product quality because these people never receive sufficient power to overcome the other 20 PMs running around. Sometimes all the PMs are ignored anyway by the programmers but they are in denial about it, so it’s moot until that fight for power gets sorted out.
The program manager model is just one idea for diving up work. It’s a good model, but does have it’s problems. On larger teams it’s too easy for PMs to get lost in their egos and self-interests, each one fighting to make a great feature, inside of what becomes a mediocre product. It’s also a role that depends on culture, you can’t just graft it on and expect it to work as it impacts everyone.
Program management works best on smaller teams, or in organizations where the PM can have significant power. Once you have 15 or 20 of them running around it gets hard to sort things out. Imagine 15 or 20 film directors trying to work on a film together. If you give them enough power, you don’t need many film directors. And if you don’t need many, it’s easier to find ones with all of the talents you want, including the ability to design user interfaces.
The bottom line: program managers are generalists
At the end of the day it doesn’t matter who makes the UI design decisions provided they are good and they ship. If you’re a PM, your primary obligation is the quality of what goes out the door. If you have someone other than you available who is good at design, your top priority should be to get out of their way, just as you would for someone good at programming, testing, or any other role. Find other things to do to keep busy – I’m sure they exist. The value of the PM, or any manager, is their ability to fight for the best use of everyone’s time, including their own.
If ease of use is truly important in what you’re making, odds are it deserves the attention of a specialist or two who can dedicate their energy to it. If nothing else, they can teach you some of the stuff you don’t know you need to know. PMs can rarely dedicate their attention to anything, as their value is their ability to co-ordinate and lead.
The bestselling book I wrote about program management, Making Things happen, has several nice chapters about how to lead design and customer research, and advocates the above advice.
Wednesday linkfest
Here’s the good stuff I’ve found recently:
- How the ideas for Raiders of The lost ark were developed. The transcript of conversations between Speilberg, Lucas and Kasdan for the plot and characters for Raiders of the lost ark. There’s a well written analysis as well as a link to the actual transcript.
- The mark of a minimalist blog. Some good examples of how less is more. I think everyone knows this instinctively, but can’t resist how tempting it is to add more.
- Writing for a living: joy or chore? Nice list of short interviews with writers who answer the question.
- Serious problems at nations airports. Anyone who flies knows how silly the security procedures are, but this report captures on video airport workers getting in without security checks. It’s certainly not news, but a better read on all this is this essay at the Atlantic on airport security as theater.
Best advice I’ve seen for web startups
In 25 minutes, David Heinemeier Hannson of 37 Signals slices through most of the nonsense and hype around startup companies that I’ve heard over the years, including several myths around innovation (I don’t think he even uses the word once, until someone asks a question that includes it). It’s by far the most bs free talk about start-ups and web entrepreneurship I’ve seen. Peter Drucker would love this.
Jump to 28:50 to get past the introduction if you get bored early.