What To Expect When You’re Consulting: Professional Services 101

This post is for those in my field (software development) who have recently gone into consulting, or who are considering making that transition.

As a software engineer, developer, programmer (so many names for what we do…), much of the work you will do as a consultant will be no different that work you did as an employee in a Fortune 1000 company’s IT shop, or the software product development company you worked for. Loops are still loops, unit tests still serve the same purpose, and no, deadlines and the occasional span of crunch time are not gone either.

The differences are in your new set of relationships, and in the way you are perceived by others. The differences are not technical – they are very human.

More Stakeholders

Difference One: Congratulations, you now have two sets of bosses and a split identity. Henceforth, you have two groups to keep happy – your employer (the consulting firm), and the client currently reaping the benefit of your services.

Fortunately, the bulk of the time, what is good for the goose is good for the gander. If you are doing good work, show up to work reliably and on time, are courteous to your colleagues and managers, and have the occasional brilliant idea that saves others a bunch of time and effort, you will please your client – which in turn pleases your firm.

There are, however, differences in the goals of the client and the goals of your firm, which you should be aware of in your role as a consultant.

The goals aren’t that different, really… both have to do with business success and making a profit. But the way that profit is derived can be very different.

Your client, and specifically the client manager you report to, is likely measured (and paid a bonus) based on the success of the project you have been hired to help with. Success, of course, is defined by meeting functional goals, but also in terms of schedule and cost. The faster the project comes in – and the less money spent – the better off your manager will be.

Contrast this with the business goals of your firm, which is more than likely paid by the hour for the services you are providing. (We’ll deal with the special case of fixed-price projects in another post, someday.) In most cases, the more hours you work, the more your firm is paid.

You see the conflict, yes? Given a certain amount of work to do, you benefit your client by getting the work done in as little time as possible. You benefit your employer by getting it done in a reasonable amount of time (you can’t appear to be “dogging it” or incompetent, after all), but certainly not in the minimum amount of time.

Fortunately, your course of action is quite simple. Be diligent, be working when you are “on the clock,” and make smart decisions that eliminate unnecessary effort – but don’t take shortcuts. In particular, don’t take shortcuts that add risk to the project (such as skimping on unit test coverage, or deciding not to undertake that bit of refactoring that really does need to happen).

In other words, be professional. Always be aware of the sometimes-competing business goals swirling around you, but take care not to give in too much to any of them, and you will be fine – and your stakeholders will be happy.

Your Halo

You may not have experienced this yet, but you will at some point. You walk into a new client on the first day, and immediately hear things like “We are so glad you’re here.” “We have really been needing someone with your expertise.” Or one of my favorites: “Please don’t laugh too much at the code base – we’ve been under the gun, and haven’t really had the right team in place.”

Experienced consultants call it the “halo effect.” Before really getting to know you, before understanding just what your strengths and weaknesses are, people will often anoint you a hero – just because you’re an outsider. This is most common in companies where software development is not a core competency – and it mostly comes from managers, who don’t understand the nuances in a technical person’s background and won’t have a clue that, while you are certainly well-prepared for 80% of the work, there’s 20% that will be completely new to you.

My advice to you when you feel the halo effect shining in your direction is simply to let it roll gently off your back. Don’t fall into the deadly trap of growing an oversized ego – that will get you into trouble eventually. In fact, it’s probably best to temper enthusiasm, ever so slightly (I’ve written a lot on managing expectations already). Let them know that you are certainly up to the task, and will do all you can to make the project a success, but remind them that you are, in fact, not superhuman. It will help when you inevitably make some sort of mistake (being human and all).

Your Trident

Oddly enough, while some people in your new client are fitting you for that halo, others are looking over your shoulder for the trident you must be hiding, or for the horns sprouting out of the sides of your head. For to some, you are no angel. You are a threat.

The view of consultant-as-devil most often comes from The Establishment within the technical community at a client. Architects (particularly those whose designs and/or home-grown frameworks are being used on your project). Database administrators. Hot-shot programmers. In short, anyone who is currently seen as “the resident guru” and whose luster could be tarnished if your light shines a little too brightly.

When you encounter a cold shoulder or a glare in your general direction your first few days on a project, try to understand why, and don’t take it personally. You are a short-timer in this client, while many have made it home for their entire careers. You will need these people in order to be successful in your work – they hold significant “tribal knowledge” that will be critical to you – so make an effort to cultivate relationships with them. Take them to lunch. Let them know that you aren’t here to contradict them, or to expose their weaknesses. If anything, you are here to help.

Be humble. You may have wildly differing opinions when it comes to certain aspects of a project (“What? You’re really using a home-grown ORM when there are dozens of perfectly fine open source ORM’s available?”). But remember that your goal – in most cases – is the success of a specific initiative, and not the long-term health of the IT organization. Selection of frameworks and development technologies is often beyond your sphere of influence. Be willing to accept that, and rather than constantly fighting with architects and DBA’s, learn to “save your bullets for fights that matter.”

Certainly, when a particular technical direction causes an increase in effort on the part of you or your team, be firm in calling that out – in private, to your client manager. You can’t be held responsible for project “friction” that you have no control over, and you may be if you don’t raise your concerns diligently. But avoid sparring with the technorati in your client’s IT department. You’ll never win – and if you do, so what? A few months down the road, you’ll be gone, working for another client, and your former client’s staff will still be living in the house they built. If you left that client on good terms – with a project completed successfully and with no lingering ill will with any of the locals – you will have succeeded in pleasing both your client and your firm. Do it consistently, and good things will be coming your way.

Managing Expectations, Part 2

In my last post I talked about the importance of estimating development time/effort on a software project, in the large. In this follow-up, I’ll bring it down to a personal level. A bit of career advice for anyone crazy enough to take up software development as a profession.

In my first IT job, at a public utility in central Illinois, much of upper management in the IT department came from other disciplines (utilities tend to be kind to those with engineering degrees). At one point, my director (boss’s boss) was a nuclear engineer who somehow found himself running software development.

And guess what – he did it better than most of the folks who had grown up debugging PERFORM-VARYING loops in COBOL. (This was a while ago, people.) Why? More than anything, it was his ability to bring us ethereal, software types down to reality. To remind us of the business function we performed, and how we fit into the company as a whole – so we could better provide value. It was quite empowering, in a tear-you-down-to-build-you-up sort of way.

I remember much of the good advice given to me over the years in the form of phrases or sentences. It’s as if there is a fluorescent yellow highlighter in my brain (which is odd, as I never used the things – I thought it a terrible thing to do to a good book).

So, anyway, a key lesson I learned from Dick was first handed to me thusly: “You don’t want to be known as having alligator-mouth, hummingbird-asshole syndrome.” Or, its rough equivalent (but not nearly as memorable): “Always remember, it’s better to be an asshole at the beginning and a hero at the end than the other way around.”

Two different ways of saying the same thing: It is a very good thing to under-promise and over-deliver. You will be remembered fondly – with words like “hero” and “rock star” and “brilliant.” And it’s a very, very bad thing to over-promise and under-deliver. You’ll be remembered, all right – but alongside words from a very different mental pool. “Slow.” “Unreliable.” “Untrustworthy.”

The key point I want to make to you, dear reader, is that the stark contrast has little to do with how hard you work, or how brilliantly you discharge your software engineering duties. Rather, it has everything to do with how you interact with your customers, and how you Mange Their Expectations. Borrowing the analogy I used in my last post, it’s in how you construct the ruler by which you will be measured.

Look. If you’re a reasonably talented software developer, and you have a reasonably well-developed work ethic, you will find a way to deliver your work – whether it be an application, an API – whatever it is – in a reasonable amount of time. You just will.

What far too many of us fail to do is ensure that those who are important to us in our careers – our customers, and our managers – really understand what constitutes “reasonable,” and understand it up front, before work begins.

When we estimate a piece of work, we should always expect that our stakeholders will think it should take less time (and money) than we do. It’s human nature. First, they are probably paid incentives to minimize expenditures on things like software development – so their brains are wired to question every estimate and try to get us to agree to do things “for less.” Second, they are not as close to the problem as you are, and therefore don’t see the complexities, and the risks.

One of your most important jobs as a software professional is to educate your stakeholders. Point out the risks. Explain why something is likely to take as long as you say it will. Be calm, and kind, and try to use analogies and speak in non-technical terms. But be firm, and speak with conviction. Be “the asshole at the beginning.” It might be a little uncomfortable, particularly if the other conversant is the guy who signs your performance review. But remember how devastating it will be if you cave to pressure and revise your own estimates downward – only to be that “asshole at the end” who can’t deliver on a commitment.

If more of us in the software industry took the time and energy to really hone our estimating skills, and our defense-of-estimate prowess, we might be able to reverse our long-running history of time and cost overruns on projects. Managing expectations in the large, at the project level, starts at managing expectations in the small. With the work each of us is asked to do on a day-to-day basis.