A Hypothetical Consulting Gig

It’s about 3:30 PM, and my phone rings.  Well, it doesn’t ring as much as it vibrates, since my default is to have it vibrate.  It’s on my desk, between my keyboard and my monitors, and it’s vibrating angrily.  I look at it balefully, watching it interrupt my concentration.  602 area code?  Where even is that?

Don’t worry, regular blog readers.  I haven’t lost my mind, and I do remember the venue for which I’m writing.  It’s reader question Tuesday (I’m just going to give up and concede that sometimes I just do this on Tuesdays), and I’m answering a reader question.  This one came from the comments section of a previous post.

Would be great to see how that plays out…Erik consults Sheila to listen to Stan about shortening the company’s lead-time by reducing time to deployment. But especially the non-free parts of the same…how about a fictional account of the gig?

Alright, fair enough.  Let’s do it.  A fictional account of a gig.

Just a few things, before I resume indulging myself in writing fiction.  First, what I’m putting together here is essentially a composite of clients/gigs, with a few liberties.  Think of it as me interpolating a future gig based on past ones.  Secondly, don’t take this as any kind of blueprint for how you should go about looking for work if you’re a free agent.  It’s an account of the way things have gone for me, rather than an instruction manual.

The Introduction

Oh, so I don’t answer the phone.  I’m an intense introvert and, “hey, person I’ve never heard of, calling out of the blue, let’s chat,” isn’t in my vocabulary.  Clearly, I let it go to voicemail.

Hi, Erik.  This is Nick, from MisCorp in Phoenix.  I found a blog post that you wrote for ImpressiveCo about static analysis, and then noticed your Pluralsight course on the same.  I’m a dev manager, recently appointed to the role, and hoping that you can help my boss, Anne, and I, figure out why our team of developers is struggling.

Since I was in the middle of something when the call came in, I don’t listen immediately.  It’s a couple of hours later, after the workday is over.  And the first thing I do is to fire up Chrome and start googling Nick, Anne, and MiscCorp to get the lay of the land.  I’ll also probably go back and re-read the post in question, for good measure.  I do my homework.

The next day, I return Nick’s phone call.  We have a brief conversation, and based on his stated goal of involving his boss, we agree that it makes sense to schedule a call that includes her.

The Initial Consult

A few days later, we have a call that involves both Nick and Anne.  This is where they really get into the meat of the issues that they’re having, and it’s truly a litany of things.

The long and short of it is that the team has struggles across the board.  Features are late and getting later as time goes by.  Talk to the development team, and you’ll hear a variety of different reasons for it, ranging from technical debt to unrealistic requirements to this idiot Josh that used to work there and messed things up badly.  Anne thinks there’s a skills gap, where Nick is more inclined to support the folks that talk about tech debt.

But, in the end, they can all agree that it takes way longer than they should to add features to the codebase.

During this call, I make furious notes.  This includes a number of times where I write a salient quote from each person verbatim, as well as summaries.  But I’ll also make inferences about root cause problems and jot those down as well.  I frequently summarize my understanding of what they’re saying to make sure I have it right.

And throughout all of this, I try to get them to talk about the underlying value of a prospective intervention.  “If we can get your feature delivery back on schedule, what kind of savings are we talking about?”

When the conversation wraps, I tell them that I’ll write a proposal with a series of options.

Submitting the Proposal

Discovery is important, but expensive.  Because of this, the proposal will be relatively short and it won’t include a whole lot of pomp and circumstance.  So I submit a proposal to them that boils down to essentially the following.

As we’ve discussed, MisCorp is losing about $50,000 per month in opportunity cost and overruns from consistent late delivery of features.  To remedy this, I propose the following options.

• Option 1, $10,000.  I will create a custom static analysis of your codebase and version history that tells you whether it is reasonable or not for developers to struggle in this codebase.
• Option 2, $25,000.  Includes option 1, plus a remediation road map to get you back to flat feature delivery time.
• Option 3, $50,000.  Includes both above options and 2 weeks of onsite interviews with personalized training recommendations (including travel).

I really don’t ever price anything based on hours anymore, opting instead to do fixed/value pricing.  This is because I’ve come to fundamentally hate situations where people are paying attention to how I spend my hours and because I’d prefer to focus on outcomes.  It’s also hard to argue with.  Take the hypothetical here.  “If I deliver on this, it’ll help you save $50K each month, so $50K seems like a reasonable ask.”

I submit this proposal sheet to get conceptual agreement on terms, and then I wait as Nick, Anne, and company discuss it.  I tell them that I’ll draw up a more formal contract/SOW if they agree, and we can sign that

The Wa-a-a-iting is the Hardest Part

After a few days of waiting and probably a few rounds of questions, they finally come back to me.  They’ll do it!  Option 3, so time to start booking flights and hotels.

That waiting was tough, but the next phase of waiting is, in some ways tougher.  This is because they’ve given conceptual agreement, but now I have to do a bunch of bureaucratic stuff that’s really not my forte.  There are MSAs to be signed, insurances to obtain, acquisitions departments to deal with and the like.

So I spend about 3 weeks between agreement and making it official, doing lots of errands and busy work in the meantime.  Eventually, though, the paper work goes through, and we’re all good.

The Actual Gig

Onsites are always fun.  It’s a whirlwind of activity and I meet lots of new folks, obviously including Nick, Anne, and the team.  We go out to lunches during the days and even a few dinners after office hours while I’m there.

I did some obvious pre-engagement prep work and stipulated all of the different things I’d need upon arrival.  Nick made it all happen, but, of course, there are some minor snags.  Nothing ever goes entirely as predicted.  So I work some long hours, both onsite and at my hotel.  It’s rewarding and, as I go along, I get a clear picture of the problem.

The team is, in fact, dealing with some sizable technical debt, much of which is, in fact, the brainchild of the recently departed Josh.  But they’re still listening to some folks they shouldn’t and making things worse.  As I present my findings, this creates some awkward moments, but the good news is that I’ve backed my findings in my write-up with a lot of expert, third party opinions and raw data from the code.

I deliver the results to all principals, including to some interested executives.  I then go home and get my check in the mail.

Post Gig

I never like to just do gigs for clients and then wander off never to hear from them again.  So I’ll put a note on my calendar to reach out a couple of times per year or so to see how it’s going.  Part of this is, obviously, to go looking for repeat business (though not as much anymore).

But part of it is just honest curiosity and due diligence.  It’s rewarding to help people, so it’s always nice to tune back into hear that it’s going well.  Plus, if any of my recommendations didn’t make sense or work out, I want to know that to in order to do better the next time.

I’ve had a nice history of relationships with my clients, so Nick and Anne remain good contacts, references, and professional associates.

And, that’s it.  That’s a composite/fictional example of the sorts of gigs that I do and have historically done over the years.