Monthly Archives: March 2012

Trick question: What’s the problem?

Maybe the problem goes away if I close my eyes?


Let’s say you witness a boy fall off his bike. What do you see? What do you do? If you help the kid back up on his bike, most would argue that you’ve solved the issue at hand. But isn’t it likely that the boy will soon fall off again? And if that is the case, did you really solve the problem?

If we scratch the surface, there’s a whole range of other problems hidden behind the most obvious one. Why did the child fall off the bike? He probably needs more training in order to reliably control a bicycle. He certainly lacks basic risk management skills. Do we have an equipment problem? Perhaps the bike is of the wrong type or size for the child?

Riding a bike is basically a process. I don’t know about you, but when the rider of the bike ends up face down in a ditch  more often that not, I see room for improvement.

Let’s leave the kid and his bike for now. Say a customer reports a bug in your software. What do you do? Fix the bug, of course! Problem solved, right? Wrong. Why wasn’t the bug discovered before the software was released to the customer? Your test team (if you even have one) should have prevented that from happening. So improving your test and QA process will do the trick, surely? The QA manager raises his hand: Wait a minute, isn’t the developer supposed to test his work before releasing it to us? A lazy developer must be the real problem here!

At this point you’re probably on to me. “I see what you did there,” you say with satisfaction in your voice. These are all reactive solutions to the real problem. The real question. Why did the bug occur in the first place? Lazy or incompetent developers? Maybe. Someone has created a piece of software that doesn’t work as intended. You may guess my next question: WHY?

When I find myself in a similar situation, I often find that the developer wasn’t given enough information to make the right choices during development. Let’s all say it together: Shit in, shit out. If I had a better developer, he may have recognized the turd when I shit in his hand, but I can hardly argue the origin of the turd itself.

So we have established that I’m full of shit, but how did we do that? We did a (somewhat informal) root cause analysis. As a fan of Lean and the heritage from the Toyota Production System, I like the 5 Why’s. – It’s a process where you basically keep asking why until you arrive at the real source of whatever problem you need to resolve.

The kid fell off his bike – Why?
He doesn’t really know how to ride a bike all that well – Why?
His dad doesn’t have time to teach him – Why?
He works all the time – Why?
He thinks making money for his family is more important than being there for his kid.

So there you go. Not only did you learn how to solve problems (instead of just removing symptoms), you also got a life lesson. No worries, you can thank me later. Now put down your laptop and go be with your family. And never solve another problem without asking WHY at least five times!

@TSigberg

Advertisements

How to sell your company

What is the best approach to sell your company to future employees?

In Norway, developers are in high demand. Companies visit the Norwegian University of Science and Technology weekly to tell students about how great it is to work for them. During these sessions, you basically get 20 minutes to tell a bunch of students (who are mostly there to get free food and beer) how awesome you are.

So what do you do? Your weapon of choice is obviously Powerpoint, which usually equals a bunch of slides stuffed with revenue, sales, technical information and possibly some disconnected screenshots of some boring product that nobody ever heard about.

So you got your Powerpoint presentation nailed down, but what do you talk about? You should probably begin by telling your life story, sharing stories from your life that are in no way whatsoever related to your business. It’s also really important that you dig into the really juicy stuff (identified by the fact that you start every other sentence with “this is a bit technical, but..”), and don’t stop before several audience members either fall asleep or perform a decent impersonation of Elvis by leaving the building.

Maybe that isn’t quite the ideal way to recruit people, after all. While going through the first draft of your own powerpoint presentation (dutifully crammed with revenue figures and charts of your organization), you may realize that it doesn’t really reveal anything about what it would be like to work for your company. After a brief discussion, you may opt for the f**k it! approach, delete most of the slides and decide to simply tell the truth.

If you happened to be working at our company (Revio), it might go something like this:

You’d enter the stage and simply explain how great it made you feel to be part of a small company producing great software for large corporations. How delivering quality software and outstanding customer service rewarded you with customers that treated you like a rock star. And how that feeling made you strive to become even better.

The bottom line is that nobody cares how many regional offices you have, or what kind of bonus system you offer your employees. They care about creating great stuff while hanging out with great people. They care about being a part of an environment that pushes them to become a better person, and a better professional.

They care about making a difference.

Sounds like fun to work with us? Well, what can I tell you? It is.

Get in touch!

@TSigberg