What differentiates great versus good...
1. Software developer: Ability to see and understand business case lying behind the software.
2. Project manager: Strong organizational skills applied to both themselves and projects they manage.
3. Quality engineer: Desire to dig deep and being caustic.
4. Support engineer: Will to help and creativity.
5. Architect/designer: Listening skills and good balance between conservatism and novelty.
6. Manager: Ability to choose right people.
The difference in quality of delivered services/products/whatever is essential in building good relationship with the customer, which can be leveraged in greater sales volume. I already hear you yelling at me “That’s obvious! Tell us something we don’t know.”
Well, maybe it is obvious but when I consider vast (and I mean vast) majority of organizations I know I see quite different model – putting more pressure/effort/resources on sales process brings greater sale volume, which can be leveraged to put more pressure/effort/resources on sales process and so on until we’re rich enough to buy Microsoft.
I’ve had several discussions about the subject, especially the quality part, but have never really considered the subject from the perspective of possible sales growth. Fortunately David Maister in his post about relationship plans and sales plans has already done that. David’s formula is simple: you build relationship by adding something from you for free. Strong relationships in the long run will result in more money. On the other hand building sales is “about getting straight to what the provider wants: assignments and revenues” but if it works as expected is in doubts. By the way, now I expect David is already looking for sophisticated tortures which I’ll suffer for drastically flattening his thoughts.
Anyway, I did some review about real cases with both approaches. Several examples.
1. A couple of projects with bunches of opened issues and regularly overrun resolution times. We invested a lot of time to clean the mess even though the industry standard (or competitive solutions in other words) is on the same low quality here. One customer said: “You’ve grown from the company which can make small not very important stuff to the one which can deliver mission-critical solutions.” Another customer hasn’t said much, they’ve just given us another contract.
2. Several years ago we had quite good contact between our salesmen and a customer. We were doing quite a lot of different things for them. Or I should say we were selling quite a lot of different things for them. Some of them were done too, some of them partially and some of them weren’t even started. OK, that was a bit below industry standard but the firm hasn’t even tried. It ended up with loosing reputation and soon the customer.
3. When I was support team manager I used to have a kind of informal contact channel with the best of our integrators (the best technical quality, not the biggest sales volume). They could contact me directly, skipping all those formal stuff, whenever they had serious issue. Somehow that worked perfectly as I wasn’t overflowed with piles of unimportant things and integrators knew they always have a backup. Months after I left the support team I was still hearing hither and you “What a pity you’re no longer in support.” That hasn’t brought us significant amount of money I guess.
4. I worked in a company which had average sales but very good engineering team and decent product. After company was acquired the new management brought a lot of investments into sales team. Profits skyrocketed. Growth was steady over 5 years or so. Sure the investments in engineering team followed soon, but the catalyst of success was a sales plan. Not a relationship plan. I think the company has some issues with the image, but profits are still high.
The set of images above is a bit mixed, as I don’t share David’s point that focusing on building sales won’t work well. It isn’t written in the stone. Generally it should bring profits in the short term. However, unless it is followed with hard work on relationships it will end up with some problems with reputation and image.
On the other hand working on relationships is really a safe play. Yes, it’s possible you spend some money on actions which don’t bring direct ROI, but you probably don’t spend bigger amount doing routine firefighting every time when emergency shows up. You deal with more content customers. Cooperation is easier. And at the end of the day net profit should be equal but your team is happier and healthier.
I came across a post from Bas de Baar about customers setting deadlines. Bas points Parkinson’s Law (work will fill all available time) and Student’s Syndrome (job can be done better when given more time) as the main fears which stand behind overly short schedules forced by customers.
I do agree with Bas with his distance to these so-called laws. I do agree that motivated, enjoyed team can deliver software earlier than planned, although from my experience I could probably count these situations on a single hand. However, I really don’t think the main reasons of having customers expecting software delivery by tomorrow lay in that area.
Fixed Deadlines
There are projects where deadlines are written in stone. The ERP system implementation which has to end by the end of the year, because migrating accounting data during the fiscal year is the worst nightmare project manager can dream of. Solutions for the biggest companies (like mobile operators) where dates of marketing campaigns are set quarters before they’ll be kicked off. Features whose development is forced by the change in the law. Components which integrate with external solutions being implemented two moths from now. In that case the customer will probably make fair buffer for themselves from the very last date, will give you your deadline and choice: their way or highway. And it has nothing to do with Parkinson’s Law.
Soft Deadlines
Another case is when there’s no such thing as fixed deadline. Vendor can deliver the solution on the date mutually agreed by both sides. Yes, one side will tend to shorten the deadline, another will tend to lengthen it and everything is a part of the bigger thing – closing the deal (with competitors right behind your back). If you often follow that scenario ask yourself: how many times deadlines were proposed by your side and weren’t kept? The typical situation is we boldly commit we can do it in three months or by Friday or before the 1st or whatever and then, magically, we can’t keep those dates, because we were too optimistic or have too little knowledge about the project or maybe... just maybe... it was the customer who forced tight deadlines. Ah yeees, you’re right, that was the case. Like always. That darn customer wanted it all by yesterday.
I think we have two different issues here:
• Ability to deal with fixed deadlines on both sides of the table. One of the main problems here is small pressure on signing the deal before date planned for that milestone.
• Ability to plan and schedule work on vendor’s side. A lot was written on the subject but I’m yet to see project plan which will go as planned.
And Parkinson’s Law? Maybe it is somewhere there in the back of the heads of customers, but its impact is really overestimated.
Steven Smith throws in an interesting question about hiring half time worker (link from Mike Ramm): Would you hire a person who works only 20 hours per week but produces full time results? Additional assumptions here say the person – Albert – will guarantee he’d achieve expected performance and he expects his time not to be wasted. Especially the former makes the whole case a bit theoretical, but anyway – that’s a hypothetical question.
Both Steven and Mike are surprised with different mangers’ negative answers. Both would hire Albert without much thinking. In most cases I would not.
First that’s a bit of primaballerina approach. I say a bit because it was said that Albert is liked by his colleagues, but still he expects to be treated differently than the rest of the team. Second, software development is quite often a collaborative job and that way you limit that aspect for the whole engaged team. However I could quite easily accept these two. Thing which, in most cases, would push me to “no go” decision is impact on teamwork.
I’m even leaving on the side questions like “He can, so why can’t I?” from other people which would sooner or later appear. Having Albert in the team you no longer can build “one for all, all for one” atmosphere. In emergency situation you’d end with highly committed majority ready to add something to standard 40-hour workweek and Albert who works from 9 to 13 because he hates his time to be wasted. I guess the high level of people’s engagement would be rather temporary.
Strong, integrated, high-performing teams are usually born when things go wrong, not when everything looks easy and you can actually allow to waste anybody’s time. And you need a specific set of people to allow it happen. Albert wouldn’t suit in vast majority of cases. I just wouldn’t take the risk.
1. Lack of quality improvement. Another implementation and the same, not-so-high quality? Haven’t learned on your mistakes from the last quarters? Still hitting the ceiling with the application’s performance? Ops, it looks like you neither learn nor improve, but stand in the same place with your product over the time.
2. Constant, similar problems with finishing projects. Isn’t that fifth time in a row when deadlines are 100% overrun? Wasn’t that the last customer who was making the same problems with signing the final acceptance? Why all of them are so scrupulous? Oh, maybe getting things done (and I don’t mean 90% done) isn’t really as easy as you thought with that application.
3. No energy to overcome technology constraints. Haven’t we just mended that darn performance? Can’t we just do it right once and for all? How many times more we’ll hear about those darn technology constraints? Hey, try to take some time and plan (with details) what exactly you do need to finally leave known limitations in the past. And don’t be surprised with results – as far as you don’t cheat it’s likely to cost a lot of time and money.
4. Mediocre product placement. Have we just spent three quarters on that low-margin project? How come? Why losses when all projects looked profitable on the beginning? Can’t we have just a standard implementations instead of all those integration stuff? That’s just a guess, but maybe your niche requires all those integration work. That way unless you plan your projects to include integration work you’ll always underestimate the costs. What more, maybe your niche expects low price and you need a product which is well prepared to customization to sell it profitably.
5. Low level of stabilization in the team. Maybe it’s a good idea to use our R&D team in that implementation as the other free developers are fresh as grass during spring? How about hiring a couple of temporary programmers to make that one? Wouldn’t that be a great idea to outsource this part as we’re running out of resources? Hold on, I’ve heard investments in team competencies and knowledge pays off. I’ve also heard “every specialist can be replaced with finished number of students” paradigm doesn’t work as perfectly as it was believed. Maybe considering developers and project managers more like people than resources isn’t a bad idea?
When you start a new software business, you need to decide how to set up a business model. Where are your customers? How you will drain money from them? What exactly you’ll sell and what you’ll be just giving away for free? You have to name all those things unless you plan to be charity organization.
When talking about choosing a business model one thing is worth emphasis – the model you’ve chosen on the beginning will most likely change. Assumptions you’ve made on start will appear to be incorrect and the whole business environment (or rather your knowledge about the environment) suddenly will change. And, you want it or not, your business model shall follow.
You can quite safely assume that chosen business model will change. Especially when you run yet-to-be-established company, a microISV for example. Seth Godin mentioned that when he was writing about Squidoo outcome:
“What you start with is wrong. At least what we started with was. Fortunately, we planned on being wrong, and have revamped most aspects of what we built.”
The same thing we did with Overto. On the very beginning we believed people would be willing to pay for additional information we can provide. After service growth and analysis which people come and how they interact with the service we changed our approach much. For the moment we don’t plan to give paid functionality – all features should remain free in predictable future (which in software business isn’t very long by the way). The way we see environment we act in is significantly different. We’ve just learned much about our audience and it wouldn’t be the best idea to keep the old track with that knowledge.
By the way the actual business model is a subject for another post – I hope to reveal a bit of that in near future on the blog.
I’m surprised how often people hide their true intentions in business situations. Instead of explanation of their goals and determination to achieve them they weave their way through unclear actions, change arrangements and strange attitude.
You’re capped at a specific budget in the contract? Why don’t you just send the message to the vendor allowing them to decide if the project can still be a win-win situation instead of using dirty tricks on negotiations which create poor atmosphere and lack of trust? You don’t have money to pay for the invoice? Say that on the very first day you know it instead of waiting until supplier is completely pissed off and see no reason to continue doing business with you. You want to sell your small piece of shares? Try to be honest with other shareholders and/or higher management so they can help you with that instead of playing your little games (one against everyone) which are doomed to failure. I could go with the list of examples for hours.
On the other hand I remind situations when we came to our customers and told the truth which definitely wasn’t the best news heard that day.
“We’ve decided to overtake the project from our subcontractors, what means you should expect the quality will be lower for some time while we’re overtaking the code. We’ll do everything we can to reduce the impact of the action on your systems.” Cold gaze and question if the quality could be even worse wasn’t the reaction I expected, but after all both sides knew what was to be expected.
“You ask me how many developers actually work on your project. Well, actually only 3 of them at the moment.” And I knew my predecessors would aim for the number between 20 and 30. The answer was: “Well, we see that clearly. That way we’ll try to plan our tasks in a way which won’t overload them.”
“Yes, we know you can’t overrun your budget, but we’re in the same situation – our owners expect we won’t take projects which are under water. We can either leave it or try to find a solution which will suit both sides.” And surprise, surprise, we haven’t lost the deal.
Sometimes I think honesty in business is considered as a serious error, while my experience is that it usually helps to build trust. And unless you don’t plan to do long-time business with the customer gaining their trust is essential. What’s your experience in that area? Do you find honesty common in business situations?
What do you feel when you come into a restaurant and you see waiters who are in their forties or even fifties? I always feel the service will be good. And I can’t remember a situation when it appeared to be different. I think, hey, they probably work on that position for years already. They probably like it – in other case they would leave it. They want it or not the experience standing behind them is huge. They had to deal with all sorts of customers, different chefs and wide range of uncommon situations.
That’s why I expect they won’t give me a shit that these are wild mushrooms when I clearly see champignons. I expect a nod will be enough to get another beer. I expect they won’t see a chance to use yesterday’s leavings when I ask which meal they recommend.
On the other hand a waiter in general is considered as a role for young person, something temporary until a better job is found. The role which doesn’t require much experience or specific knowledge.
OK, now change “waiter” with “developer,” “meal” with “code” and “chef” with “project manager.” The story still works well. Surprise? It shouldn’t be anyway.
When I see an active developer, who is in his forties it does mean there’s something valuable out there. Or at least there should be. I can’t think of any of older developers I know who isn’t a real specialist in some area. I can name many projects or products where I’d prefer an older developer over a youngster if given a choice. Unfortunately it’s hard to find one. That’s why they’re even more valuable.
Robert McIlree has commented my recent post about agile methods. I believe one thing from the comment is worth mentioning. Robert says:
“I will take issue that Agile methods are no different from a take-it-or-leave-it standpoint as opposed to traditional process-oriented methods.”
There are two general approaches to implementation of any methodology in software development. One says you should treat the chosen method as a bible and adjust your organization to work exactly like it’s written in the books. Another says: here’s the thing, you can take whatever you want and leave whatever you don’t want but remember every decision brings its consequences.
While almost no one would admin to choose the former approach it’s quite often. Ask people why they don’t like Prince-2.
"- It is sooo heavy and formal.
- Why don’t you cut unneeded things off then?
- Can I??? They haven’t told me that."
Personally I’m on the other end of spectrum. I believe you can use take-it-or-leave-it approach with virtually every software development methodology. Unlike Robert I believe that process-oriented methods are no different here. Even there you can decide to change only several areas and leave the rest unchanged if it works well for you. You just need to know what you resign from and why.
From time to time I’m discussing with my wife issues connected with her workplace. To make long story short she’s not happy with a way things are organized there and she feels like she was a bit cheated during the recruitment by her current director.
My answer for her rants is usually the same.
“You have three choices:
1. You either change things in your firm (using harsher and harsher methods).
2. Or you look for another company where things are different.
3. Or you stop complaining.”
When you don’t like the place where you work, try to change it. Don’t complaint it is hard. Easy things are for janitors, as my former boss used to say. I was able to fuel the transition of the company from place where I had bosses who (mostly) hadn’t understand me, subordinates who didn’t share my vision and quite a lot of conflicts with salesmen to one where on the top of the management there’s only one vision shared amongst all people, team which would be envied by the most of the managers and literally zero significant internal conflicts in a whole firm.
Yes, it took a lot of time, and even more of health, but was worth it. When I look at most of my past jobs, there were usually organizational things I’d change if I had a chance. Over the years I came to belief I can change them. Yes, I know, that’s easy to say being a COO, but I’ve done that stuff earlier with much less formal authority behind my back.
Next time you start complaining ask yourself first what have you done to change things and what more can be still done. Usually there are options to change things successfully.
I believe that:
1. You should keep rotation at the lowest possible level.
2. You should have harsh recruitment process.
3. You should have internship program.
4. You should have balls to fire rotten apples.
5. You should supply the team from the bottom, not from the top (talking about organizational structure).
6. You should have a replacement in mind for every important person in the team or at least try hard to achieve that.
7. You should be honest.
8. You should tell about every important strategic decision just after it was committed.
9. You should publicly attribute successes to the team.
10. You should avoid washing your dirty linen in public.
11. You should say “thank you” more often.
12. You should give people chance to change your opinion about them (for better or worse) at least once.
13. You should have a time for serious talks with people every time when they need it.
14. You should value gentlemen agreements over formal agreements.
15. You should keep your word.
16. You should support people every time they want to improve their knowledge.
17. You should accept mistakes as an occasion to learn.
18. You should value freedom and accountability over control.
19. You should be fair.
20. You should be the heart (no, not necessarily the brain) of the team.
I’ve just come from off-site meeting with our client. We’ve been in beautiful place far away from both our and their offices with old, well-known “no access to e-mail and limited access to phone” message set in our brains. One of points on agenda was a brainstorming session. Its outcome was impressive and that’s not only my opinion.
We go through this kind of meetings with that very client on a regular basis and usually we don’t spring a surprise on us then. We know most of the rules of successful brainstorming meetings (link borrowed from Craig Brown), but when you mill the same knowledge of the same people yet another time, chances aren’t high that you’ll find a gem. This time it was different. Why? There were several crucial elements.
1. Get out of the office. Move from the conference room, notebooks, everyday small distracting issues. Let yourself forget about next meeting in ultimately filled conference room schedule. You need another quarter? You have it. You need to go out to catch some fresh air? No stress. Atmosphere becomes more informal and more creative too.
2. Do it differently. Forget flipchart. Take some photos from magazines, glue, a couple of markers and a pile of A1 sheets. Create a story. Don’t treat it deadly seriously. Play with ideas. Then present it to the rest of the people. You don’t have to hit the jackpot. You need to keep ideas flying all over the room.
3. Make a competition. Split people to several smaller teams. Give them time to prepare a couple of ideas, then make a series of presentations and let everyone to evaluate them. The best team wins. And everyone wins because you gain another stimulant to think creatively.
And after all it was a lot of fun. Of course that’s not the most important thing here, but from business perspective it was a meeting on steroids. I’m looking forward to implementation of some of today’s ideas. I believe one of them is a real gem.
I’ve already mentioned here several times different CEOs and their attributes, the most popular one was about Bill Gates. Generally I think that you need quite a strong individuality for that position. There can be only one leader. Yes, I know, of course Google is different in that area too. In vast majority firms I know you could easily point one person who is a locomotive of a train. Usually a natural leader with strong business and/or technical skills and a vision.
However natural leaders, who are most often (but not necessarily) CEOs need a kind of Alter Ego. Someone who more less shares general vision, but usually has quite different perspective when it comes to lower-level decisions. “Yes, we’re going south, but why do you think the train is the best means of transport?” “Yes, we’re dedicated to take this deal, but I’m not so sure we should take outsourcing of support services.” “Yes, we have some free positions, but we better don’t keep rotten apples just because good men are hard to find.” And so on...
Usually the Doppelganger is weaker than the Leader, but that’s good. His role is to keep the Leader constantly evaluating new ideas, knowing that they’ll face the Skeptic Guy. To keep the connection between the locomotive and the rest of the train. To catch Leader’s feet and bring them back to the ground.
I believe that’s very important, yet not very prominent role. The Alter Ego is sometimes considered as a brakesman or a dream-crusher. But take the company (no, not Google, I’ve already said that’s a bad example here) where there’s strong leader without his Alter Ego. Take the company you know well. Try to analyze their decisions – both good and bad. Then think how many of bad ones could be avoided with “evil twin” as an advisor of the CEO. Someone whose voice is respected but definitely not decisive. I guess quite a bunch of better choices could have been made.
That’s why if I looked for people to run a company I’d try to find both a dreamer and a realist.
In his last blogpost Bob McIlree shares his thoughts after a couple of agile classes he made recently. The whole post is worth reading but my attention was drawn to one general observation – among experienced project managers distance to agile methods is significant and confidence in their effectiveness lays two feet below the ground level.
I was never an agile junkie, I rather prefer agile methods described by Steve Yegge. By the way I guess that’s something which can earn me an excommunication from some Agile Conservatives. What more, I haven’t treated any software development methodology as a religion. Yes, you’ll hear about evangelists, bibles etc, but that doesn’t work like a religion (you just believe and it works). You can easily find environments where agile methods would suit well, but there are some where even implementing a cycle model would end up like a tsunami in a seaside village. That’s one thing which lies behind fear of agile methods. Another is of course lack of will to move from safe and well-known environment. I’m not surprised looking at skeptics among PMs. And to be honest I really don’t think that Bob’s classes will help to overcome distance to anything other what they know.
There’s only one way here – change your environment. Afraid of water? Want to learn swim? Training classes in a classroom won’t help you much. I’d rather try to change environment into more waterish one, like pool or something. I moved to my current firm after several years of working with MSF. My naive point of view was that I’d implement methods I knew and it would work perfectly like during the good old days. I couldn’t be more wrong. Different projects, different people, different teams, different customers, different organization, everything so damn different. Why the heck the process should be the same?
The same rule applies to agile methods. Take from them what you believe can work in that particular environment and leave what you think is useless. There’s none universal and perfect methodology and, excuse my bold statement, agile methods aren’t any different here. In other case we all would use them and I’d be unemployed. My answer for quite often heard “I’m a big fan of agile methods” is “And I’m a big fan of common sense.”
