Monday, April 03, 2006

Managing Your Manager

I'm a nerd. I have no social life, nothing besides my computers and my love for complex problems. In former times, I would have been called a monk. Now, I'm a highly payed (but still somewhat strange) specialist.

There was a time, when Suits were a kind of enemy for me. They didn't understand. They didn't care. They made decisions which made me weep.

Then, one of them handed me an article.

"Managing Your Manager".

What could be a recipe to manipulate your superior was in fact a short text about decision making and what can go wrong and why.

What's a specialist?

A specialist is someone who knows.

He lives inside the problem.

But as we all know, living inside makes it hard to look at it from the outside.

A manager is the opposite: He looks at the problem from the outside.

Several of them, usually.

So, by my definition, a manager cannot make good decisions because he or she doesn't understand the problem. If your car doesn't start in the morning, you know that something is wrong. But that doesn't make the problem go away.

The key here is to bridge the gap. When a manager has to make a decision, she has to. It's not like she has much choice. So there will be a decision.

And since she's no fool, she'll try to get some facts so the decision is not quite as random as it might seem afterwards.

This is where the tech guys come in.

"Hey Bob, we're behind scedule. Why is that?" asks the manager.

Bob thinks: Hey, now I can tell her about all the insane problems we have with broken computers, paranoid security, insane deadlines, bug-ridden software.

But that doesn't help the manager to make a decision: How to get things done in time.

So Bob drones on until the manager leaves.

Bob feels better but the manager still has no clue what to do.

So she'll make a decision and Bob will be very upset because he can't understand how anyone with a brain could be so stupid. Especially after he explained it!

The problem here is that when Bob talks about buggy software, he probably has some ideas how to solve the problem. Maybe using a different software might help. Or a different version. There might be patches available. Giving the sales guy a hint that the annual license might be canceled if they don't get some important fixes really soon might yield unexpected improvements.

For Bob, this is obvious. For the manager, it might not be.

Things get worse when it comes to deep technical problems. Most nerds will just nod when I say that a problem is exponential.

Most managers will nod, too, because they're as uncomfortable to display the fool like everybody else.

But they won't understand. Not really.

For a manager, a presentation is the way to communicate.

Such a presentation should have four to five pages. Maybe six. No more.

On the first page, you should explain the problem.

If the problem doesn't fit on a single page, you're probably talking about two different problems. Split them and create a second presentation for the other one.

On each of the following pages, put one line with a proposed solution and two lists below: Pros and cons.

Give at least three different solutions. If you can't think of any besides the obviously best solution, have a short chat with your boss to see what he or she thinks.

That should give you something to work with because his or her view at the problem will be a completely different one than yours.

Don't try to prefer one of the solutions, if you can. You will find that when you can keep your mind open, after finishing the last page of the presentation, you often get another idea.

One that is much better than the other three ones.

But even if you have only three solutions, you will quickly see that one of them is much better than the other ones.

Sort your presentation in such a way that the inferior ones come first. Keep the best for last.

If you can't decide one over the other, then that's okay, too: If they are equally good, then they must be equally bad as well, so it doesn't matter which one gets chosen.

When I do such a presentation (which usually goes 10-15 minutes), something happens.

The managers will get the facts for their decision making in small, digestible bits.

They will have several possible solutions to chose from which they like. Nobody likes the feeling being pushed into a certain direction.

Furthermore, they will think that you care. You created a small presentation (thus not wasting their time), you give them control (they make the decision).

And, oh wonder, most of the time, the will chose your prefered solution.

You're the specialist, after all! Who knows better than you?

The net result is that everyone gets what he wants: You get your prefered solution (and probably even a better one than you'd got if you hadn't given the presentation) and the managers get to decide (so it's not your fault when something goes wrong).

So good luck with your next presentation.

And one last piece of advice with animations: Don't. They just distract from the content. The more animations in a presentation, the less meat is in there. Every manager knows that.

Tuesday, February 28, 2006

What's Wrong With ... CSS?

As an internet enthusiast, you will sooner or later get in contact with one of these greater evils: XHTML, JavaScript and CSS.

You will find the css Zen Garden, be baffled at what can be achieved with pure CSS and, typical for something evil, be lured into it's fangs.

Suddenly, adhering to W3C standards will become an important goal. Even if there is no browser which can display all of the W3C standard. Most of the users use a browser, which specifically doesn't support the W3C. Of course, the produce of said product will pledge differently but in the end, what matters is what you can see on the screen.

It ain't pretty.

After you get your HTML to validate -- which means you have already lost countless hours to fulfill a simple several-thousand-page international standard -- and you can finally proudly add the XHTML DOCTYPE at the top of your page.

Now, some simple stylesheet to please the eye and you're ready for the world.

Two weeks later, you find yourself confronted with two choices: You can either concede and show the world that you failed to find an optimum between the deficiencies of the CSS standard and the bugs and incompatibilities of just the two main browsers by publishing another dull website.

Or you can show that you simply don't care and publish something which looks good on just your computer.

Eventually, one of your friends will tell you what they are snickering about when you show up.

When I saw XHTML and CSS for the first time, I hoped that it would solve some or even many of the problems we have today.

Instead, they made everything worse.

Absolute positioning of elements is relative. What's so great about strong that the simple b was dropped? With CSS, the name of the element shouldn't matter anymore.

Instead, we have roughly 200 styles. Many of them are actually supported by a few web browser and some of those are supported correctly.

When I want to emphasise something, Blogger.com wrestles this into my text: <span style="font-style:italic;">correctly</span>

Excuse me? <em>correctly</em> should do, shouldn't it? What will the blind think?

I bought several books about CSS. They all share these common traits: A list of all styles, each with a table when it doesn't work. A very big number of pages how to work around the most important browser bugs (search A List Apart for "box model").

After several years, even the most hard headed CSS evangelist finally admits that some layout problems can still only be solved by using tables.

If you want a div to have a very definitive width and a margin around it, you must use voice-styles to confuse the browsers which get it wrong. Or use negative margins. Float it. Nest several divs. All but position it absolutely relative to a hidden element which must contain a flash animation.

The many CSS resources on the net show every day that you can achieve incredible designs with CSS.

FCKeditor is created by some smart minds. At home, it works. At work, I don't get a toolbar.

I just want my div not to shrink too much because the content becomes a tad unreadable at 30pt. There is a style for that but it's not supported by anyone. Or there are scroll bars that I don't want. Or my readers with their new shiny 1920x1600 LCD screen are locked in a 300x256 postcard (all measurements in pixels).

Everybody screams test driven development today. Why is there no test suite for CSS and XHTML with PNG images how is has to render?

No further confusion how to interpret "padding, border, and margin areas".

But it doesn't even start to become a solution to the actual problem: Separate content from display.

I don't care about "strong" or "b" or <span style="font-style:bold;"> or <span class="bold">. It looks the same to the reader.

When I want to publish something on the net, I want to create a meta language. I want to use XML to specify "this is something someone said". I want to be able to create new tags and then give them meaning (this will lead to the semantic web) and then give them a presentation.

I want a style sheet which defines new elements and how they look on the screen. I want to be able to say "all these elements are top aligned" without having to put them into the same container.

I want to be able to reuse the work of some greater design genius without having to worry about new browser versions. Without forcing my readers to enable JavaScript just to be able to visit my pages (read that is, not interact with them).

I want something like vex. Unfortunately, this project seems to be all but dead.