As you might have deduced from some of my previous blog entries, I work as a software engineer for a large consulting firm. That firm works on a project basis, in which personnel works at the client site rather than from a central office. As a result I have quite a bit of contact with our customers; I talk to other developers (who work for the client) to cooperate on development; to architects to talk about software design and the IT landscape; and from time to time to the business for requirements analysis and test coordination. I’ve been doing this for a couple of years now and have developed a style of working based on full honesty and willingness to cooperate as much as I can with whomever I am talking to. I’ve found this to be a style that gets good overall results. I’ve had compliments on my way of working from almost every manager I’ve reported to and it has gotten me a number of promotions.
Some consultants have a different way of working. Some consultans feel that the primary concern of the consultant is to deliver “on time and within budget”. Which means that “managing expectations” and “limiting the scope” and “preventing scope creep” are their primary concern rather than weighing the needs of the customer. For example, I recently had a minor disagreement with a colleague from my firm who sees things differently than I do. Some days ago he was in late, so he missed a meeting we were supposed to have with a team we are working with on a project for the client (referred to commonly as “the business”). The business had come to them complaining very vociferously about response times in our common software. The other team (led directly by people working for the business) had come up with some ideas for improving the response times and asked us (i.e. me) if we could investigate the feasibility of one of the ideas and do an estimate for the implementation. We both agreed that as ideas go, this one was horrible — but we both saw the necessity. So I agreed to investigate on our side and do an estimate, under the understanding that the business architects and this colleague should all agree to the solution before implementing.
The colleague didn’t agree with my course of action. He felt I shouldn’t even have agreed to the investigation. It might lead to extra work on our side and at least discussions. Undesirable. Which left me wondering: what the hell are we doing here?
Consultancy, in case you didn’t know, is derived from the Latin verb “consulo”:
consulo:
- to consider maturely, to weigh, to ponder; (with dative: ) to look to the interests of
- to consult, to ask advice of
The meaning of the word tells us two things. The first is our function as consultants: people come to us for advice, to help them achieve goals they cannot achieve on their own.
The other, looking to the interests of those people, speaks to something less obvious: our professional responsibility. People come to us for help and we agree to give that help. That means we have responsibilities to our clients. To do our best for them, to put in our best effort and to be on their side.
Of course, sometimes we have to think of our own interests as well. Sometimes we don’t quite tell a customer that we don’t know something and take a chance on our being able to learn in time. And sometimes we have to tell one person from the customer company “no” in order to keep our schedule and meet the desire of the company overall. But still, even when looking out for ourselves, our professional responsibility remains. We must still remember that we are supposed to be on our customer’s side. The customer is not the enemy.
It gets even worse than sketched above, though. Sometimes our own interest is temporarily contrary to that of our customer. It is tempting at those times to say “screw the customer” or worse: not just say it, but actually do it. At these times even more than others our professional responsibility must guide us back onto the straight and narrow path. It falls to us to find a solution that satisfies both parties as much as possible and not to allow the situation to deteriorate to the point that the customer no longer trusts us and the relationship becomes unworkable.
What is never acceptable for a real consultant is to follow a course of consistently placing ones own interests above that of the customer. We are trusted (and paid) by the customer not to do that. How can we be trusted advisers to anybody if the customer keeps having to watch out for us showing up behind them with a knife?
There is a challenge though, from time to time, in staying the course. A huge hurdle (in fact) for some. At times it takes tremendous courage to be a good enough adviser and trustee to your customer to admit that you don’t know everything or that you were wrong about something or that something will not get done. For instance if a project simply will not be done on time. Or if it turned out that a choice you made as a consultant was simply the wrong one.
It is very tempting for us as consultants at times like these to go into panic mode. To try and cover up and hide the mistake, to try and throw extra manpower and overtime at the project to get it done on time. With as inevitable result that the effort to hide your shortcomings will come back to bite you in the ass at a later time, only worse. Hiding a mistake usually means covering it up with a quick fix or a workaround, which will inevitably break something far worse in the next release. More manpower, more overtime? Tired developers, more bugs, huge problems in the aftercare phase, next release and possibly even a greater delay as you have to postpone the go-live to fix the bugs introduced by developers who wouldn’t have made those bugs if they hadn’t been working fourteen-hour days.
In his book “Extreme Programming Explained: Embrace Change”, Kent Beck talks a good deal about courage as a principle of software engineering. If something does not work, will not work, or would simply be better if completely rewritten you as a software engineer should show the courage to throw it all away and start from scratch — despite the fact that “gut instinct” and “common sense” normally tell you that going backwards is a bad thing. Something similar applies to consulting: if a strategy for a project, a management style or an advice is not working, you should have the courage to tell your customer so and scrap it. Your customer and therefore you will be better off in the end.
Put another way: “consultancy” cannot and should not be the same as “covering your ass”. Consultancy is about helping your customers. Helping them improve their business by building better systems, for instance. Which means obvious things, like guarding the quality of your code and improving the quality of existing code. But it also means less obvious things, like being willing to take risks in order to reap rewards and benefits for the customer (even if the customer might not see it himself). Sometimes you just have to take a risk and refactor an important piece of software to improve it. Sometimes you have to take a risk and trust the judgment of a junior because he has a good idea or even just because trusting and supporting him now will allow him to grow into a far more valuable employee later on. And helping customers also means branching out: learning their business so you can meet them halfway when talking about goals, desires, requirements and designs. It means being honest about when a schedule is unrealistic or unfeasible or when deadlines will not be met. It even means leading them to the right conclusion, from time to time.
And sometimes, despite the fact that missing a deadline may look bad towards upper management and you fear it will reflect badly upon you, it means sitting down with the customer and deciding that missing the deadline is necessary in the interest of quality. Because your customer will be better off because of it in the end and that (when all is said and done) is the final goal.
After all, if you don’t want to help your customer…. what the hell are you doing working as a consultant?