Tag: analogy

When newspapers are gone, will you miss newsstands?

Marketing guru Seth Godin asked the question today, “When newspapers are gone, what will you miss?” Before getting into the various sections and showing how the web covers each of those areas better, he offers this opinion:

Woodpulp, printing presses, typesetting machines, delivery trucks, those stands on the street and the newsstand… I think we’re okay without them.

But are we?

The presses and trucks — the machinery of creating and delivering the paper — are transparent to most people. But the newsstand is a user interface. Any UI designer will tell you that the interface influences the type of interaction you have with the underlying system. What type of interaction do you have with a newsstand?

Newsstand in web terms

First, the newsstand serves as a “portal” to divergent news sources. It provides a rough snapshot of what the different publishers think is worth reading about today, all in one place. No matter what your interest, you can go to the newsstand and know that it’s represented there.

Then there are the cases where someone discovers an interest while at the newsstand. The user who knows what she is there for, but sees the same screaming headline in 144 pt type on three different papers and decides she wants to see what’s happened in the world. Or the user who wants to read something, but doesn’t know what until he browses. This second type of user is very common in airports.

The newsstand also serves as a feed reader, always showing the most recent issue of periodicals and dailies, with older issues sometimes available behind the counter. Just as there are people who don’t know or care about RSS readers, there are people who have been reading magazines for years who don’t track when the new issues will be out. They just check the stand every day or so until they see something new they want to read.

Don’t make me think

Both of these functions, the portal and feed reader analogues, are zero maintenance for the users. At most they might ask the proprietor to start carrying a new title. But the mechanics of delivery, storage, display, are all handled for them. With no subscription, no ongoing cost, and the incremental cost entirely under the user’s control.

So Seth is right, we probably won’t miss the newspapers. But will we miss the newsstands?

Being Useful Is Better Than Being Right

Being right isn’t nearly as important as most IT people think. Understanding why that’s true is one of the fastest ways to build trust and respect with the non-IT management in your company.

Let’s try an example where it’s better to be useful than to be right

Suppose you find out there is a structural problem with your building. It is severe enough that the building could collapse at any moment.

Being Right

You look up the emergency notification policy in the employee handbook. There’s a number to call. You call it and explain the details of what you’ve discovered. They start asking questions about evidence, as you get frustrated that they’re not responding fast enough to this emergency, and why don’t they get it?

Being Useful

You pull the fire alarm and everyone leaves the building.

Business Prefers Useful

Executives like to get things done. They got where they are by being good at getting what they want. The respect and respond to that trait in others.

So if you want to be recognized as someone who can get things done, you need to actually get some things done. If excruciating detail is what it takes to convince someone they should listen to you, then use detail. If a convenient metaphor will make your point more strongly, then use one. Of course it will gloss over important details, that’s why we use metaphors. They simplify reality in a (hopefully) useful way.

Find a good balance between rightness and usefulness, and you will take control of your career like you never imagined you could.

Do You Demand Flowers From Your Staff?

What are you supposed to buy for your wife for Valentine’s Day? Quick, first thing that pops into your mind …

Right: flowers. A dozen long-stemmed red roses. Because decades of consistent marketing has worked its magic on you. You could debate that it should be a box of chocolates, or jewelry, and I’d say that’s because those two industries have been advertising just as hard.

But have you noticed the hidden assumption? That you’re “supposed to” buy something at all. No matter how aggressively the flower, candy and jewelry industries market against each other, none of them will ever contradict this fundamental belief: That extravagant purchases are the approved way to demonstrate commitment.

Most modern American corporations expect you to demonstrate your commitment, too. But instead of flowers the symbol of your commitment is time. Time above and beyond the forty hours you’re supposed to work. Time eating at your desk instead of going out to lunch. Time on call via the Blackberry they gave you.

Doing good, steady work is better for the company. But late-night marathons of work get noticed. If you plan well and execute, you don’t need late nights, but then there’s never a clear moment for the boss to look at and say, “That moment really showed commitment.”

In a perfect world, the boss would take the extra effort to recognize good, steady performance. And that’s exactly what it takes: extra effort. Which is why it happens so rarely. Even if you’re doing things on time, it seems that sometimes you have to put in the late night to get noticed. Because this isn’t a perfect world.

But you may be in a position to make the world a little better. If you are the boss, make the extra effort. Publicly recognize employees who reach their goals during normal working hours. Make it clear that late nights are a symptom of poor planning. Demand extra work because it needs to be done, not just to show commitment.

It may be less exciting, and less obvious, but in the long run it’s much more productive.

How To Triple Your Output By Cutting Your Output In Half

The fastest typist I’ve ever seen was a guy I used to work with. When he started going it sounded like a machine gun. Our standard line when people asked the rest of us about him was, “Yeah, he types over 150 words per minute … and about 40 of them are spelled right.”

Even after you ran his stuff through a spell checker, you’d have to proof-read very carefully to catch the places where “there” and “their” were mixed up. Where single letters showed up at random because the spell checker skips one-letter “words”. Where he left out words or just plain didn’t make any sense.

It usually took longer to fix his stuff that it would have taken to do it yourself from scratch. So why did we put up with it? Well, he was the boss. Keen.

But like anything else in life, you can at least learn something from the situation. What I learned from him was that it doesn’t matter how much you produce if no one wants it. Or put another way: Anything you do for someone else that isn’t up to their standards doesn’t count.

For an example of an entire industry that’s working as hard as possible to ignore this simple truth, compare television today to what it looked like in the 1950s.

The golden age

Back then there were three networks. How many prime-time shows did they collectively produce per week? Counting 8-11 p.m. Monday through Friday, that’s three 1-hour slots x five days x three networks = 45 hours of programming. Lets say a third of those hours were broken up into half-hour shows, so a total of 60 shows per week.

Let’s assume that to have a consistently great show you needed six extremely talented writers and actors. (Yes, there’s a lot more to it. This is just an example.) The fewer good people you have, the less often your show will be good. To fill 60 shows, you might have the following mix:

Show quality Talented staff
per show		 # of shows Total
talented staff
Consistently great 6 1 6
Excellent 5 2 10
Very good 4 2 8
Good 3 18 54
Sometimes good 2 35 70
Generally poor 1 2 2
Total 60 150

Obviously every network would like their shows to be better. But for whatever reasons there are only 150 people with the level of talent needed to produce a weekly show.

Double the output

Fast forward a couple of decades. Now there are six networks. The talent requirements to produce a good show are the same, but there aren’t suddenly twice as many talented people available to do the work. The chart above might now look a little something like this:

Show quality Talented staff
per show		 # of shows Total
talented staff
Consistently great 6 1 6
Excellent 5 1 5
Very good 4 1 4
Good 3 6 18
Sometimes good 2 21 42
Generally poor 1 75 75
Unwatchable – bad 0 15 0
Total 120 150

Notice how many shows had to drop into the lower categories to make this work. The contrast is really obvious when you look at the two outcomes side-by-side.

writer-chart

With twice as many total shows, there are fewer shows that are even sometimes good. By doubling the total output, there are fewer than half as many shows that are ever acceptable to the audience. And there are only a third as many shows that are usually good.

These numbers are obviously a gross oversimplification, but they illustrate a point: By increasing the output without increasing a limited, but required resource the overall quality declines faster than the total output increases.

500 channels and nothing’s on

Now fast-forward to today. There are literally hundreds of networks trying to fill 24 hours every day. Sure, with the amount of money available in the industry today there may be more people willing to work there.

But if my assumption is at all close to reality, then we would expect to see shows that clearly don’t have anyone talented working on them. We might even see shows where they simply send a camera crew out to film people without a script. We might call this a “reality” show.

So you’re not in the TV business. How does this apply to you? Everywhere in the example above, replace “talented staff” with “attention”. How much undivided attention do you have each day? How many ways are you dividing it? By trying to do more things, are you doing fewer things well?

The difference between innovation and sloppiness

I took a couple of art classes in college. In Life Drawing we were supposed to look at the arrangement or person in front of us and put it on paper. In pencil, then charcoal, then ink … watercolor … oil … etc.

I was always good at photorealism. I might not have been fast, but I had some pencil drawings that could have passed (at a distance) for black-and-white photos.

There was another student, an art major who fancied himself an “artiste”. His work spanned the range from abstract to really abstract. He looked down on my mere technical facility.

But my grades were as good as his, sometimes better. It seems when he talked about his rejection of formal rules, it really meant he wasn’t able to do realism. He didn’t have the command of the tools, the mere technical facility. So everything he did owed as much to chance as to intent.

He may have been right, that I didn’t have the creativity to do modern art. I’ll admit that I appreciate paintings that simply look good, without high-flying pretension or socio-political overtones. I guess I’ll never have a SOHO gallery showing. C’est la vie.

But with all his fervor, and whatever glorious visions he had in his head, he couldn’t reliably get them onto the paper. He couldn’t create something specific, on purpose.

[Cue un-subtle segue … ]

But what does this have to do with the business world? Scott Berkun wrote recently about how constraints can help creative thinking. When a large corporation does “blue sky” thinking, they can wander aimlessly and never produce. Constraints set a direction.

But I think there’s another problem with “blue sky” thinking that goes beyond a lack of direction. It’s summed up by Voltaire’s famous maxim:

The perfect is the enemy of the good.

When a company tries to “blue sky” a problem, they are implicitly seeking perfection: With no limits, what would be possible?

But there are always limits. They may be self-imposed, inconsequential, misunderstood, overblown, or in any number of other ways not real limits. And it helps to know the difference.

When you start out by asking people what they would do if there were no constraints, don’t be surprised when they come back with a solution that can’t possibly work. And then convince themselves that theirs is the only possible solution. By then, you’ve already lost.

Hate the game if you want, don’t pretend it isn’t being played

When I was in college I worked at a bar that had a pool room. I played a lot when it was slow and after hours. I got pretty good on those tables. Only “pretty good” and only on those tables … I knew where the dead spots were in the rails.

If I bet anything on the game, it was usually who bought the next round. Sometimes we couldn’t drink as fast as we played, and we’d go for a dollar a game. We were all friends, and it was just to make the game more interesting.

But every so often someone would come in who none of us recognized. You could usually tell really fast who was better than just a casual player. Sometimes they’d see if they could get a game for $5. I’d always take them up on it. And I always won the first game.

Then they’d ask for a rematch … let them win their money back. I’d take that game, too. Sometimes I’d win, sometimes not. But I was breaking even so I didn’t care. It was usually after the second game that they’d look at their watch and realize they had somewhere they needed to be. But they had time for one more game.

How about one last round for $50?

No.

How about $30?

No.

Come on, give me a chance to win it back!

No, you’re a better pool player than I am. But you suck at reading people. You thought I didn’t know you were throwing the first two games.

That’s when they’d get pissed. It wasn’t fair that I took their money even though they could beat me without trying hard. I was just a punk-ass bitch that couldn’t carry their stick.

Yup. But I had their money, and they were leaving.

If I wanted to, I could have spent the equivalent of a full-time job becoming a professional level pool player. I would have run into diminishing returns as I was going up against ever stronger competition. It would have dominated my life, and the only way to make a steady living would be constant travel.

Plus there’d be no retirement plan. Your earnings stop the moment you stop playing. The skills don’t translate to anything else worthwhile.

So I stayed in school and learned to be a programmer, which doesn’t suffer from any of those negatives. </sarcasm>

Hmm, that came out a lot longer (and a lot faster) than I expected. It all started from one idea, though: You don’t win by being better, you win by playing better. And you start by knowing what game you’re playing.

When you’re in an interview, you’re playing the “get the job” game. Once you have the job you’re in the “impress the decision-makers” game. If you go the uISV route you’re in the “sell the most product” game.

Being better at coding is one of the plays in each of those playbooks. But it’s not the one they keep score with.

Is your resume hot or not?

Getting a job is like getting a date.

  1. There may or may not be rules to it.
  2. It may or may not be fair.
  3. They may be so desperate it doesn’t matter what you say. But do you want to hook up with someone who’s desperate?
  4. Or maybe it doesn’t matter what you say because they’ve decided the answer is “no” before you opened your mouth.
  5. The more in-demand you are, the more choosy you can afford to be. But if you want to get this job — or this date — then you’re probably going to have to say what they want to hear. Good luck figuring out what that is.

What conclusion would you like me to reach?

Why is it that the rest of the world has functioned fine on estimating projects of many sizes and scopes, then sticking to them; while IT screams “OH WE can’t do that!”?

I’ll admit a large reason is because lots of people in IT are really bad at estimating. But part of the reason we’ve managed to stay so bad at estimating, and the main reason all estimates seem to be so far off, is that the business side wants the estimates to be low.

The common complaint is that IT projects are “always over time and over budget”. Since the IT budget (for software) is almost entirely salary, time and budget are synonymous. When you set the budget, you’ve just set the time.

But most IT projects — and nearly every one I’ve worked on — have a budget set before the detailed design is ever done. Or at least the clients have an idea in mind what they’d like it to cost. So without realizing they’re doing so, the clients set the time estimate sometimes before they’ve ever talked to the developers.

I had to help out some less-experienced people who were being asked for estimates. I told them the trick is to figure out a diplomatic way to ask, “What number would you like me to say?”

The funny thing is that this is not just being cynical, either. There’s real value to it. If you’re thinking four months and the client says three days, there’s a good chance you don’t have the same idea in mind for what you plan to do.

For instance, they ask you to write a search engine “like Google” to put on your intranet. You’re thinking a couple of months. They’re thinking end of the week.

It turns out they want you to buy a Google search appliance and integrate it into the intranet. To the client, “write” “create” “implement” “install” and all those other words we use that mean different things … all mean the same thing: work that the IT guys do.

So if you want to get the work — or if you’re an employee and have no choice in the matter — see what number they have in mind already and tell them what they can have in that length of time. If you don’t promise to deliver something in the given time frame, they’ll go find someone who will. Not that they’ll deliver in that time, but they’ll promise to deliver in that time.

Compare this to construction. The client may get five quotes for pouring concrete. If four of the bids are close to $50k, but one of them is $20k, the client will likely assume the low bid is unrealistic and choose among the remaining contractors.

But if a programmer or independent software vendor says some work will cost $50k, the client can find someone who will promise to deliver for $20k. The sponsor will either accept the lower bid, or use it to negotiate the first vendor down to $25k. When it ends up costing $50k, that project goes in the books as “over time and over budget”.

What would it look like if construction bids were awarded the same way? If for instance the client were required by law to select the lowest bid? Then contractors would low-ball every bid to get the contract. You’d end up with construction that always ran over time and over budget. You would need an endless supply of money to stay in business. You would need to be … the government.

The program is not the product

Managers want programs to be like the output of a factory. Install the right robots and tooling, start the process, and good software comes out the end.

WRONG WRONG WRONG WRONG WRONG WRONG WRONG WRONG WRONG WRONG!!!!!! (Can you tell I disagree?)

Nearly everyone who makes the factory analogy misses a very fundamental point: the program is not the product. For one thing, unless you work for a software company selling shrink-wrapped software products you aren’t ever selling the program. Conventional wisdom says most programmers actually work for internal IT, so it’s safe to say most programs are never sold.

Businesses don’t want programs, they want credit reports … and loan contracts … and title searches … and purchase orders … and claim forms …

So what is the right analogy? The program is the assembly line! So measuring bugs in the program is wrong. Even comparing compiling to manufacturing — which is still better than comparing programming to manufacturing — is wrong. What you should be looking at is the output produced by the program. Is your program a website? Measure the number of pages it can produce per unit time, without error. Is it an editor? Measure the number of pages it can spell-check per unit time, and with what accuracy.

When measuring the output of a manufacturing process, you literally shouldn’t care what the process looks like, nor what tools are used, so long as it consistently produces the same output. This is not to say the process and tools don’t matter. A bad process may be prone to unexpected failure. Tools may be harder to maintain or have a shorter service life. You may be locked into a service contract with the manufacturer. And coincidentally [ahem] all these factors apply to software.

So yes, programming can be compared to manufacturing. As long as you remember that the program is not the product, the program is the assembly line.

When design is not design

“How is software production like the car industry?”

Oh no, not again. Yeah, well, most people are getting it wrong. So here’s another shot at it.

There are aspects of car design that strictly deal with measurable quality: performance of the electrical system, horsepower, fuel economy, reliability. But the shape and style of the car are much more loosely coupled to hard-and-fast measurements. That facet of the design — the way it looks, the demographic it will appeal to — is not amenable to Six Sigma processes.

Granted, there are some cars that are strictly (or nearly so) utilitarian. Some people only care about efficiency and reliability. They buy Corollas by the boatload. But the FJ Cruiser is not the result of a logical, statistical analysis, with high conformance to the mean and low variation of anything.

I think what I’m trying to say is that marketing design is building the right thing, while production design is building the thing right. The auto industry is mature enough that you need both. Success in the software industry still relies more on building the right thing.