Thursday 29 January 2009

Why are they never happy?

This is another one of those stories that my girlfriend will tell you explains why we don't get invited around for dinner more than once, but I'll tell you is dead essential to the world of technology becoming a better place - one manager at a time...

Anyway, I'm listening to this buddy complain about how busy he is, how hard he's working, how many hours his team are putting in, and how much stuff they're getting out - yet still his customers aren't happy. They're always finding something to complain about, pointing out the things that are missing rather than thanking him for the things that are there.

When I hear this, what I think most people are really saying is "my team and I are working really hard and really long hours doing the things we want to do for this customer". Whenever I've seen this issue on the floor, it has almost always been because the guys were dedicated and hardworking, but being dedicated to and working hard on the wrong stuff.

Think about it like this; if I really want A, and you give me B, C, D, E, F, and G, then I might be impressed by how busy you've been and how much work you've done, but I still won't thank you for it. Yes, B through G were relevant to my department and they were things I wanted done - no argument there - but if A was the thing that meant the difference between getting that big contract or not, or making this quarters numbers or not, then I would have happily traded it all to have just A.

I'm not saying that there aren't ungrateful people in the world, but I am saying that until you've adopted a partnership-based, customer-centric view of how you deliver technology, you haven't earned the right to complain about them.

Look frequently and carefully at your priorities, and compare them against what your business is being driven to achieve - you never know - you might even end up doing less work and having happier customers.

Sunday 25 January 2009

You ALWAYS Pay for Quality

What if I told you that every single organization pays the same for any given piece of functionality? You'd probably call me crazy, and that would probably be because you know that it's not true, right? You've negotiated different rates, done projects in different locations, used different vendors, and cut different corners - and consequently, it cost you a different amount of cash each time. So I can't possibly be right, can I?

But before you condemn my point entirely, consider this:

If you're buying in software, consultancy, per-project services etc, then the primary levers you can adjust are commercial terms. You might feel exceptionally good about reducing the cost of a project by £5K or shaving a couple of points off margin, but do you really think those suppliers are going to produce exactly the same output for you and just make £5K less on the deal? Good luck with that.

If you're building your own products, and assuming you've got a fixed size team, then the primary levers you can adjust are tradeoffs and shortcuts - i.e. where you spend your time. How you pay for quality is then divided up between how much you're prepared to pay for now up front, and how much you're going to pay later - typically through higher operational or technical support effort (less automation), increased cost of the next features (technical debt), and opportunity cost (revenue lost to product unavailability).


So I'd suggest that you always pay for quality, whether you intend to or not, and I'd add that it's usually less painful to pay for it overtly through a proper project plan, than inadvertently through reactive support, interest payments from future projects, and your customers patience.

I'm not saying that you should never try to sharpen a deal to save some budget or take a shortcut to get a product out quicker, simply that you should keep in mind the longer term costs as you congratulate yourself on the shorter term gains.

Thursday 22 January 2009

Presentation Skills

A few days ago I posted about how important it is to present ideas well, rather than hoping some budget and resources will be conjured up by the sheer strength of the idea alone. I was going to write something about presentation skills in general, but given that last post, I'm going to tailor this slightly more towards doing proposals - and for most of us - proposals make up the majority of the presentations we do that really matter anyway.

The thing to keep in mind about your proposal is your goal; you're not there to do a really great presentation, you're there to convert someone into a mad raving fan of your idea, and how you do that is going to depend on who you're dealing with.

Step 1 for me is always start with the audience, as everything else flows from this. It drives your content (which benefits you accentuate, which risks you focus on) your delivery method (maybe powerpoint slides in the boardroom is best, maybe a casual discussion over a coffee is sufficient), and even the duration you're going to talk for.

Never simply have "your presentation on project X". Instead, have "your presentation on project X for the architecture steering group", and "your presentation on project X for the accountants", and "your presentation on project X for the board" etc. They're all going to want to see a different mixture of things before they get behind it. With some of them, you might want budget, so you'll want to spend a slide on the concept, then spend the balance of the time breaking down cost and benefit over the next few years. From others you might need their change control approval, so the commercials will be lightweight with much more detail about how your system will be deployed and how it will integrate with the rest of the enterprise. You might even be displacing the roles of operational people through a tool you're driving forward, so these guys will want to know how new processes will change their tasks and you'll need to spend a fair bit of time addressing concerns about the team, their jobs, and training.

That's all very good, but something people often ask me is how to handle mixed audiences - when you have to present your proposal to a collection of people in different roles. My answer is - don't. It might seem like a smart idea, get a large number of areas out of the way in one go, but it simply is not effective. You cannot adequately address each persons individual focal points, and you risk convincing nobody.

Granted, sometimes you don't have a choice, and if that's the situation you're in (and you can't get out of it) then keep it brief, simple, factual, and to the point. But do have all the detailed information right there with you - the same stuff you'd have if you were doing the customized versions for each individual - and that way you'll be knowledgeable and organized should anyone wish to drill down into any of the areas they represent. If you've been asked to do something for a multidisciplinary audience like this, then chances are it's at some kind of regular session the participants have anyway, which means they'll have other business to discuss, which means you can't expect a long slot, which means your brevity will be appropriate.

On the mechanics of presenting - and by mechanics I mean how to deliver slides - I will let David Rose tell the story for me. It's worth watching the whole clip, but at the very least watch the last few minutes in which he covers slide design, stance and tone, and using presenter mode in powerpoint etc. Second only to actually doing it yourself, watching great presenters in action is the best way to get better at it, so I'd recommend watching a few more TED talks and definitely subscribing to Presentation Zen.

When drawing up a slide deck to accompany a presentation (note that a deck of slides is not your presentation) I think it's important to resist incorporating all the whizzy features powerpoint has to offer. Animations, sounds effects, charts, and clever transitions are all entertaining, but they distract from your message. Also, avoid complex, cluttered slides loaded with detail and don't, ever, just write a speech onto slides and read it out along with your audience. Slides aren't cue cards, they're important material which backs up what you say, reinforces your message, and helps add impact to the story you're telling face to face.

A couple of final points - firstly, when you're "considering your audience" and thinking about who you'll need to get onside with your idea, don't forgot about thought leaders. It's usually easy to spot the people who will be directly affected by your plan, and decision makers tend to be obvious too, but so many neglect this final category. By thought leaders, I mean people who might not have any official hierarchical power or authority to help you, but nonetheless they set opinion and exert an influence. Getting these people onside with your plans will make adoption everywhere else much smoother.

Last of all, don't overdo it. You are kidding yourself if you don't believe you're selling when you're presenting a plan, but you must also be realistic and present a balanced view of whatever it is you're asking us for. As executives, we know that there is no such thing as an idea with no downsides, and pitching that way will just make us suspicious.

Tuesday 20 January 2009

Don't Tell the plan, Sell the plan

One of the top sources of frustration for engineers is not getting management buy-in for proposals that just obviously need to be done. And here's the kicker, if they really understood the business benefit of your ideas, then management would be frustrated about all the awesome stuff they've been missing out on (and in fact tend to be anyway, it's just that they don't realize that you could have already solved them). Well it doesn't have to be that way, and guess what, you are the ones that need to do something about it - not them.

Just remember the title of this post - don't tell the plan, sell the plan. As engineers, we come up with some pretty clever stuff. We're up against hard problems and we deliver smart solutions. Where we get unstuck is when we go about sharing these with the decision makers that we need to get behind them.

As engineers, we tend to think that "selling" an idea somehow devalues it - sacrifices it's integrity - perhaps we think it is sneaky, cunning, or politically motivated to properly pitch something rather than just retell the facts behind it. But believe me, for better or for worse, the things that actually end up getting done in organizations aren't the best ideas, they are the ideas that were sold the best.

Don't get me wrong - you still need that great idea, a solid business case, and a well thought through execution plan - it's just that those things alone rarely turn your proposal into a funded priority.

On a personal note, back when I was an engineer I always told myself that I'd be different, however as my career moved towards decision maker, I found that I ended up pretty much doing the exact same thing. It's not through any lack of technical knowledge or understanding of how a proposed system will work, it's simply that I do a different job now - and that job is to weigh up all the possible things we could do as a team, work out which ones will make us the most successful, and then not lose sleep over the rest.

I bet you anything your boss does exactly the same thing - he's not an idiot that doesn't seem to trust you - he just wants to quickly understand the core concept, then make a judgement based on the real cost you want today vs the potential future return against a background of all the other things he might choose to do instead. And you know what? We don't need to know exactly how the older cached inserts will be invalidated in the remote nodes once a newer update is detected locally (or whatever) in order to make that decision - but if we ask you then you'd better know!

Even if you look at it cynically - you have the best idea anyway right, so why not have the best presented idea too? If it really is the best proposal, then don't you owe it your organization to give it the best chance of becoming reality? The only danger you'll face by being better at presenting your plans is that they're more likely to get done...

So I hope I've convinced you that the presentation of your ideas is as critical to their success as the ideas themselves, so the next most obvious question is how do you do it effectively? I was planning to write something on doing presentations anyway, so come back in a few days and I'll tell you what I think.

Friday 16 January 2009

No Pain No Gain?

For the past couple of days I've been helping out a friend get a new team organized, and during our of discussions in their canteen, I overheard something that epitomizes the complexity-aholics that really drive me mental.

A couple of data architects were talking about a consolidation project they were kicking off. "Can you believe what they're doing in the Japanese office? Their schema is so basic" one complained to the other. "Yeah, they clearly don't know what they're doing" his colleague replied, "they should leave it up to us." A couple more minutes of the same and I couldn't really let it go.

Deep breath...

Gathering up my most diplomatic tone, I asked the resident geniuses: "OK lads, if you're saying that they have a basic, simple solution which meets the business requirements, and you have a complex, difficult solution which meets the business requirements - then isn't it you who have something to learn from them?"

You see this is why I don't have any friends.

But seriously, what's the attraction to building big, creaky, behemoth solutions where something easy and elegant would meet everybody's expectations? Why is it that we seem to derive satisfaction from making our lives hard? Unless you're very lucky (lazy?), you'll have to troubleshoot, maintain, and support whatever you put in place.

I've noticed before that good engineers can build vast systems with webs of dependencies and many moving parts, but it's the great engineers who realize that this is a bad idea.

Outside of the gym, there are very few places in the world where you'll be better rewarded for increasing the effort necessary to achieve a given outcome.

Tuesday 13 January 2009

The Parable of the Big Hands

This is an old story, retrieved from the dusty recesses of my memory, but it's as relevant today as it ever was. Names changed to protect the incompetent...

A number of years ago I was called in to help an integration company who had been struggling for a number of weeks with a manufacturing client. They had delivered a factory automation system, introducing computer-controlled fabrication and handling machines, replacing the manually operated mechanical kind. The project had been justified upon increased productivity and reduced material wastage - yet reduced productivity and increased metal wastage were being observed. Not really the results anyone was hoping for, customers blaming the vendor, vendor blaming the users etc.

My job was to "troubleshoot the new software" and "find the bugs" before the manufacturing company started firing live ammo.

Step 1 was to get a coherent problem statement. It seemed that in the vendor's lab everything went according to plan - sheet metal machines could be reconfigured in tens of seconds via a new software load - yet at the factory it was taking minutes and materials were frequently being cut to the wrong dimensions.

So what was different between the factory and the lab? I was assured that there was no differences at all - machines had been swapped, the exact same builds had been uploaded to the machines at both sites, error logs had been downloaded etc. But clearly there was a difference, otherwise it would be working (or broken) in both places.

I figured there must be something environmental - how else could the exact same machine, software, and configuration work perfectly in one location and not another. "So, tell me about this factory" I asked. "Never been there" was the answer (believe it or not). Ah-ha!

So off we go to the warehouse/factory thingy. We never even got through the tour of the floor before we made the critical observation - these metalworking dudes have really big hands! If your job consists of throwing around huge blocks of steel, cranking big heavy leavers, and turning giant bolts, then you soon develop a pair of mitts like shovels.

Why was this important? Quite simple. The keys on the small numpad-type keyboard that had been specially made for entering the program parameters on each machine were a standard keyboard size, and were therefore simply far too small for the bunch-of-bannans fingers of the guys that had to use it. These guys are hardcore welders and whatnot, they don't have our delicate little programmer hands!


So what's the lesson here? Know Your Users. It's as simple as that. You have no business even touching a keyboard (of any size) until you know who your users are, where they work, how they'll interact with the system, and what successful use is. Remember - you're not building the software for yourself or your business analysts, you're building the software for them. Get to know them.

Sunday 11 January 2009

Making Decisions

I thought I'd start with this as my first 'proper' post of the year, mainly because decision making isn't usually considered a skill in it's own right, despite being deceptively simple and so commonly done poorly.

Making a decision isn't a stand alone task, when you make one, you really do a small collection of things together. You make choice from some options, you make a plan and delegate it, and then you follow up and review. Most people think that once they've picked their option they're done, but like Drucker says, you haven't made a decision until you have an action plan - you've only made a choice.

So let's talk a little more about effective choosing, as that's the first hurdle to trip over. The behaviors you want to avoid here are essentially procrastination. How many times have you been staring an obvious course of action in the face (or been presented with a fantastic opportunity) but instead of making progress, you're taking bets on which is growing faster - your number of choices or the list of data points people want to see for each one! You have to reduce your number of options to a manageable amount (3 is a magic number if you're stuck for inspiration), and while you should never ignore great last minute ideas just for the sake of rules, most business don't fully appreciate the cost of inaction. The point marked "doing anything is better than nothing" creeps up a lot quicker than you think.

The next thing you have to worry about is the ballooning amount of information on each of your choices. Too many and you risk it being treated like a smorgasbord (can we have this from option A, and that from option B) or being paralyzed by the sheer volume of statistics and technicalities. Try removing things that are the same for all choices - for example, if A, B, and C are all similarly expensive, why compare cost? And how about things you don't feel strongly about? I don't know how many times I've seen stakeholders agonize over details like the difference in reusability between 2 choices in a decision, and then when asked where else they plan to use the technology, answer "nowhere". If it's an attribute you don't feel strongly about, then it's unlikely to influence your decision, so why clutter the process with it?

We've talked a lot about paring things down, and now here's something to add in. Don't forget that for every choice you're comparing you need to know what you don't get if you don't pick it. Most people are generally pretty good at stacking up the costs and benefits, but opportunity cost is often neglected.

Hurdle number 2 is action plans and delegation - the behavior you want to avoid here are those deja vu meetings where you all sit around and 'review' the decisions you made, wonder at the lack of progress and then agree to 'update next week' all over again. Once you've made your choice, don't let yourself off the hook until you've agreed who is actually going to do the work, and by when. Follow the usual rules on delegation - make sure whoever you're going to hold accountable clearly understands their obligations, is empowered to do the work, and has the available resources.

Don't forget to follow up. You spend your time on the things that are important to you, and you're not making unimportant decisions, are you? The things that you focus on will get done - keep track of what's happening, make major milestones public, and use your sponsorship to see it through. And once whatever it is has been delivered (or has crashed and burned), you're still not quite finished. Now comes the feedback loop - what did you learn? How can the experience improve the rest of the organization? What pitfalls can you now help others avoid?

And finally, you shouldn't be afraid to revisit your decisions and change your mind. You should be keeping an eye on your customers, your portfolio, and your team, and continually assessing what any changing circumstances may mean for you. That said, you must resist being flighty as you need to show commitment, but keep in mind that "because we said we would" isn't a business benefit to completing a project - it's a sleepwalker's justification for not being in touch with the market.

Saturday 10 January 2009

Welcome to 2009

It's been 2009 for a little under 2 weeks now, and so far I can confidently say it will continue to be for around another 50 weeks or so. OK - I accept that's not my A material - moving swiftly on...

At this time of year it's customary to make a few new year's resolutions - fresh commitments you somehow feel renewed fervor towards keeping just because we incremented the year counter by 1 - and they almost always involve gym memberships.

If I take a brief look back at last year's resolutions I think I can safely say I hit my top priorities, but just as predicted, the exercise part seems to have slipped through the cracks. No matter, that's what these annual counter-flips are for, getting invigorated about your health for 30 days or so.

I'm always interested in hearing from people out there in the technical community for any reason, and from time to time I am lucky enough to receive some feedback on my posts (thanks by the way!). Over the last 12 months the articles that have generated the most interest have been on management, dealing with people, and being effective in organizations. It seems like you want to hear more about getting things done around technology than about the technology itself. Well there's some resolution input right there...

This year I'm going to try changing the balance of the content I write, aiming for a higher ratio on project management and professional disciplines without completely dropping the things I like to bring up on architecture and computer science. After all, a hundred little things happen every day, and it's just a matter of being a bit more selective about what's captured and shared.

So yeah, welcome to 2009, you can make it whatever you what you want it to be.