Bold Decisions Pays Off

Taken over the project from subcontractor and trying to finish it with your team? Nice move – now you have a lot of additional work to do, but you also have control over the whole process and you can manage things effectively.

Agreed with the customer that they would order hardware passing by your standard vendors? Delivery date is now (magically) 2 weeks earlier and chances are better that you won’t go over time, although your vendors don’t love you anymore.

Fired your primaballerina and struggling to delegate her duties to the rest of the team? Morale +2. Respect +1. Integration +1. Cost-effectiveness +3. Sleepless nights +3.

Stopped your work when the customer is not willing to sign terms agreed before, just days before launch date? Signed agreement will be on your fax another morning. Or maybe you’ll lose the project, but in that case chances are good that it wouldn’t be profitable anyway.

I know I flatten a bit above, but all those cases really happened. All of them were risky. A couple of them very risky. But every one of them appeared as a good decision after all. We’re afraid of bold moves but, when done with serious thought before, they’re usually right thing to do. Usually we’re just forced to choose those paths by circumstances, but that doesn’t matter. The most important thing here is to be able to make a right choice (even when it’s bold). Many people can’t do that even when this is the only rational way of acting. Even when keeping status quo is the straight line to catastrophe.

I’ll be on holidays to the end of June so expect some silence here.

Which Features Are Important?

Several days ago I had a quite insightful discussion about software functionality and usability. Among others we went through Google Spreadsheets and features which should be on the top priorities in a team working on that project.

Maybe I’m a bit controversial here, but I think Google Docs are in the point where there’s a lot of toilsome and dull work ahead. The thing which should be improved now is generally an editing area. I don’t say it doesn’t work. On the very basic level it works well. However, quite a few of us use the very basic features only. When asked, no one would really answer consciously which “advanced editing features” he uses, but after a couple of hours of playing with the application most of us will find a series of small but annoying flaws. These are non-standard features we use.

Highlight B2 and C5 cells. Only those two. Mark a group of numbers to quickly check their sum on a status bar. Change text or background color of cells with only one click. Mark several columns with shift+left-click. Make some simple formula using keyboard, e.g. type “=sum(“ and move to cells you want to sum using arrows. Doesn’t work.

Yawn. Boring. Nothing about on-line collaboration. Nothing about Google Gears (although I believe that’s another extremely important area). Nothing about adding advanced cool features like pivot table. But all that boring work is something what disheartens users when it isn’t done properly. Typical user who tries out Google Spreadsheet is the one who is familiar with Microsoft Office. The one who is familiar with ways she uses Microsoft Office, to be exact. As far as she doesn’t find similar (and working) paths in new spreadsheet she won’t be happy with it. And she won’t stick with it as a consequence.

Yes, when you’re able to keep the user and show him your unique features (collaboration in that case) and make him thinking about them as key functionalities – you’ve won. Unfortunately in most cases you won’t reach that point because few stages earlier the user becomes annoyed with the new software and goes back to old, well-known Microsoft Office telling all his friends: “Oh, that was cool, but sooo immature.”

By the way, similar problem we face in Overto. After first stage of rapid development we have on one hand a bunch of great ideas how to expand the service with new functionalities, but on the other there’s a lot of work to do within the basics: availability, performance and usability. With heavy heart I choose the latter.

Patience

I’ve just poured off my home-made apricot-liqueur to bottles. It took almost a year to produce a bit more than two liters of that noble beverage. You can’t shorten the process, at least not when you expect good results.

Exactly the same situation you’ll find when you implement reorganization. Even the best-planned reorganization, which is well-designed and needed, takes a lot of time to show its results. The most boorish case you’ll find with lay-offs. Any savings can be made after some time (usually 3 months in Poland).

However the schema works universally. You’ve had the idea. You’ve planned everything. You’ve even convinced the decision-makers to your plan. And somehow it takes long months to implement all those great ideas and quarters to see results. You expected them right away, didn’t you? No, no. Not so easy. Do your job day by day until you see the light in the tunnel.

It’s exactly the same like with making liqueurs – you need to be patient. The best recipe won’t bring the results quickly just in sake of using it. It will test your patience. You can have it fast, but you’ll have it poor. On the other hand you can have it outstanding, but you have to work with consistence and patience.

And the results are usually worth waiting.

Role of the First Job

It’s been told a lot about managing your career. How to plan the career, how to get position you’d be happy with, how to push your way through the recruitment process, etc. You can find a lot of reading about the subject (personally I think Rowan Manahan has nice insights in that area), but I think we usually miss one thing here. We kick-off our careers and define our starting point usually quite unconsciously, when we start the first (longer) job. Of course the kick-off doesn’t limit our potential, but usually defines how painful it will be to achieve the final goal.

The environment which gives you first professional lessons forms you as an employee. And I don’t mean company culture only – one thing is how the organization as a whole is set up but another, even more important, how your team looks like and what kind of persons are leaders. Well-managed, integrated, team with influential leader is a great kick-off to your career. And it really doesn’t matter what programming language you use or what kind of projects you work on. The most important things you learn aren’t technology specific – team work or accountability can be learnt anywhere, customer/user-centric mindset isn’t the thing which is exclusively available in IT only. And a new programming language or project management technique? You’ll learn it when you need it.

When I think about my career I always come back to my very first team, where I learnt all those basics. I always considered the first professional environment as important but still when I’ve made a little analysis some time ago and results have surprised me a lot. I’ve taken people from my CDN XL team, where I’d grown up and listed what they’re doing now.

• Our director now co-owns a company
• Three of team manager owns or co-owns a company
• One more is a VP
• Three developers got director ranks
• One more is a team manager now
• Three consultants owns or co-owns a company
• Another three of them are directors now
• Three more became team managers
• Four testers moved to more prestigious developer role
• Two of them got their teams to manage

Wow. I mean, really, wow. I’ve just counted about two third of the team back then, and it was just a few years ago. What more, I can think about almost no one who wouldn’t appreciate the role of being there when looking from the perspective of their careers. For majority of us that was the first job, for another group that was first job they stuck with for a longer time. Definitely most of us set up our professional standards during that time. I believe the team, the way it was organized and managed and the atmosphere were very important elements of mixture which brought us wherever we are today.

Guerilla Risk Management

Craig Brown writes about one thing you should track when joining the project team late. No surprise here – you should look for, name and address risks. That’s exactly what experienced project manager will do when you drop him in the middle of chaos (called the project in some circles): look which direction his ass will be kicked from.

A little surprise comes when you analyze methods of risk analysis Craig describes. They’re definitely far away from what you can find in structured methodologies, like MSF. It’s more like a quick reconnaissance with small commando than a regular operation which includes planning, execution and a division of marines. Asking, listening and thinking. Risk management in a pill.

That approach isn’t specific for people who join projects on late stage only. I also catch myself (and not myself only) using the approach either when I talk with project managers from my team or when I report projects’ status. The first thing I think about is what can go really wrong. OK, we’re two weeks behind the schedule already, but what about that darn hardware which is going to be delivered 6 weeks after planned date? That’s the main pain in the neck for today, so let’s try to solve that one or at least minimize it to the level where no one is going to get Medieval on our asses.

Risk management is the most natural way to judge the status of the project. Although it should be done in a structured way on a regular basis, it’s almost never a bad idea to do some guerilla risk management when the situation isn’t typical or you aren’t involved directly in the project.

Flaws of The Chaos Report

Jim Highsmith criticizes the methodology standing behind The Chaos Report provided by Standish Group. His main points are:

• Wrong qualification of projects. While The Chaos Report treats all projects which overrun budget and/or time as challenged, Jim would like to see them rather as successful. He sends us to business background, different goals projects have to achieve and constantly changing environment.

• Wrong priorities on recipe for success. Jim would like to see competent staff as one of the essentials, while Standish Group focuses on executive support, user involvement etc.

I agree with the latter, but The Chaos Report was never a manual of achieving a success for me. It was rather a knowledge base about current state of IT projects. From that perspective the more important is the first argument Jim makes – the one which is hard to accept for me. When I look at projects which are finished I usually ask myself several questions. Was that a success? Could the time/budget overrun was smaller? Is the 3-moth delay in the final acceptance justified with changes of business environment?

Using common sense and not giving excuses answer usually is: “We could have done it better. We should have done it better.” Running away from statistics, that’s my definition for challenged projects. With that definition statistics aren’t far away from what The Chaos Report brings.

Yes, you will find projects described by Jim Highsmith, which should be qualified as successful even though time or budget has been overrun. However, from my experience they’re much less often than situations where overrunning one of constrains is a sign of something wrong happening in projects. In my opinion The Chaos Reports bring quite real overview of quality of IT projects. Trends which are confirmed by the last report from 2006 don’t differ greatly from what you can see every day. Unfortunately, that’s nothing to be very happy about – there’s constant improvement, but barely slight.

Eliminator Questions during Job Interview

Two sources made me thinking about recruitment process once again. One was Rowan Manahan with his post about eliminator questions. Another was a series of interviews with potential summer interns I had last days.

Rowan lists several questions which, if answered badly, can ruin your chances for a hire. On his personal list you can find:

• Telling about your career

• Telling something negative about you

• Giving reason why you should be hired

• Questions you ask

I asked myself if I can make a similar list in my case. I followed my last interviews with potential interns and I can’t make similar blacklist as Rowan. I can’t think about any single question which answered poorly can ruin chances of the interviewee. On the other hand, it’s possible to ruin the chances giving really poor answer for any of questions.

There’s another area where I can’t consider myself as a typical interviewer, described by Rowan, as I usually start with a positive (not neutral) attitude to the candidate. When I recall my last recruitment meetings I try to enter the room with a slight will to hire the person. This helps me to create friendly atmosphere and (I hope) moves some pressure out of the candidate.

I think that’s fair. You have never a chance to make the first impression for the second time and interviewees are stressed, they want it or not, when they meet you at the very first meeting. And no, I don’t have a problem with overrating people. With some experience in that field you’ll easily recognize all yellow or red lights which appear – you don’t need eliminator questions here. I rather try to be sensitive on specific phrases which can be heard all over the conversation which can be translated into “Don’t hire me.”

I’m curious if you have your eliminator questions and, if yes, what can be found there.

Long Career as a Developer

Software development is a specific role. Acceptable quality is on much lower level than in different areas of our lives. The product is more virtual. New technologies are invited much faster. And people stick to the role for shorter period of time.

The last thing isn’t typical for all positions in software business. For example there are many long-serving project mangers. By the way that makes much sense, because one of essentials for PM is experience. Although for developers experience is also one of key factors, which decide about quality of their work, long careers on that position are much less often. In the long run developers struggle to outgrow their role and escape to architecture, project management or running own business.

While I don’t judge that attitude (I used to have the same back than when I was a developer) I think we’ll see more and more positions requiring 10+ years of experience in software development roles. On one hand complexity of systems increases, on the other software goes deeper and deeper into our lives. It’s hard to imagine a hospital without any software working somewhere inside. It’s hard to imagine a new car without at least a couple of processors. It’s hard to imagine a jet without all those cool-looking systems, powered by (what a surprise) thousands lines of code. And it’s so easy to imagine losing life in any of above places. Over the years it’s more and more about the software, its quality, performance, availability and reliability. And developers.

Developers who make everyday code-level decisions basing on their best knowledge and experience. The more different solution they’ve co-created, the easier is to make the right choice. The fewer mistakes they’ve already made, the bigger is the chance to choose the wrong path. Sure, the team doesn’t have to be built from experienced developers only – it would be neither wise nor cost-effective choice – but leaving young wolves without experienced leader doesn’t guarantee you a success.

Yes, I hear you talking about Bill Gates or Larry and Sergey, but they were wunderkinds. You don’t see many of those around and most likely you won’t find any in your team. If I was asked who would lead the new complex project when high availability, high performance and high reliability were on the top of the requirements list I’d look for an experienced developer. Someone who has already dealt with performance issues and optimized the code, not the one who doesn’t even know where the performance traps are. Someone who has already designed a couple of poor architectures, not the one who is yet to make those mistakes. Someone who has tried different technologies, not the one who is all hot about the coolest Ruby-on-Rails only. I’d look for that particular type which isn’t very popular among developers.

That’s why I believe there is high demand on people who stick with development role for a longer period of time and it will grow over time. There will be more and more complex systems to be developed. Definitely that’s an idea to consider if you’re a developer and you’re planning your career.

Bring Energy to Your Project

It’s a typical situation when after weeks or months of working on a project energy is systematically drained from a project team. The first enthusiasm is forgotten long time ago. The most creative design stage is already a history. Everyday work is now tracking down unrepeatable bugs or trying to arrange reconfiguration of customer’s systems to give you at least a chance to run the whole thing before deadlines. This is the moment when usually slips appear and somehow almost no one is surprised. Standard risk management techniques are used, project is moving slowly towards more or less successful final.

And then something happens. A project manager gets serious illness. A lead developer starts planned-since-the-last-year holidays. Almost all forces are thrown into a new, super-important contract which has just been signed. The issue forces you to rearrange the project team, find replacements for some positions. And to everyone’s surprise things start moving faster. Life is brought back again.

I’ve seen that so many times. CEO who approached the final stage of the project and helped to negotiate the terms of the final acceptance with the customer. CTO who had to take over sale process and led it to the end on the double speed. Project manager who replaced a colleague for ten days and moved through a couple of milestones which couldn’t have been achieved for weeks. Senior program manager who pushed R&D project from “doomed to failure” to “we’re the heroes” status when worked instead of the R&D leader for a couple of days. The list could be much longer.

Why is it so? Why the new member of the team, who definitely isn’t as familiar with all the details as the rest of the people, can become a locomotive of the group and fasten the project?

• Because the new person brings a new energy and enthusiasm to the group which is more or less tired with their work done for fifth consecutive month by now.

• She usually throws all of herself to the task to cover initial lack of knowledge about the project details. This inspires the rest of the team. Hey, should the new gal be the best of us?

• Fresh blood is injected into the project organism. Now someone looks at things from a different perspective and refreshes everyone’s point of view.

It usually has nothing to do about bringing more knowledge to the project team. 9 times out of 10 teams, during final stages of the project, team doesn’t lack knowledge. They lack energy and enthusiasm and falling into traps of monotony and tiredness. And, lucky for us, it’s usually easier to bring energy to the project instead of bringing more knowledge.