How to Become a Management Consultant

I originally posted this on my blog a little under two years ago. If it's interesting to you, I post new content on daedtech.com roughly weekly.

Last week, fate (via Hacker News) sent a lot of people to this post, about becoming a software consultant.  This actually resulted in a lot of new readers and followers.

So, first of all, hi to all of the new readers and followers.  But secondly, I'm about due for another consulting post.

So let's talk today about how to become a management consultant.

This is going to be a guide to charting a course for yourself from working as an individual contributor to a management consultant.  And it doesn't involve dues-paying or working your way through any degrees or even any other jobs.

It's a lot more direct than that.

First of All, What Is Management Consulting?  It's Not as Pretentious as it Sounds

First things first, let's get to definitions.

I've often referred to myself as a management consultant.  (If you want a more detailed history of my consulting, you can find that here.)  Sometimes I call myself a strategy consultant or, perhaps, an executive consultant.  In a sense, this is all kinda the same thing.

So let's define that thing.  What is a management consultant?

You could probably find all sorts of definitions out there of varying complexity.  Let's go with a simple one, though.

First of all, as I've explained before, consulting is when people pay for your expertise and opinions.  (Not your labor.)  Management consulting is thus a narrower variant of general consulting, with the following two caveats.

1. You are specifically offering advice to organizational leadership (i.e. "management").
2. The advice you offer is related to leadership's main charter: making organizational decisions and running the business.

That's really it.

You give advice to organizational management about how best to execute their leadership duties and oversee their organizations.  Naturally, there are a lot of different kinds of advice that you could give, but I'll get to that a little later.

Should You Become a Management Consultant?

If you're reading my blog, you're probably a software developer or at least software-developer-adjacent.  So given the post title and introductory section, you might be looking behind you and wondering if I'm not talking to someone else.

You might just want to write code, either for a company or as a freelancer.

Is this advice really for you, then?  Yes, it is.

I've previously advocated that every software developer become a consultant.  So it's not much of a reach that I think, if you're going to become a consultant, you might as well become a management consultant.

Developer Hegemony, aside from being a book, is the crazy idea that software developers should be in charge of software development.  And if we're going to be in charge of our own industry, it stands to reason that we should know how to run it well enough to offer advice about the same.

So yes, you should become a management consultant.  It's an excellent way to establish a practice, credibility, industry contacts, and authority.

And the pay isn't bad, either.

You don't have to live out of hotels or wear slacks everywhere, or adopt an insufferable vocabulary, either.  Heck, you might not even need to leave fulltime employment, if you get creative.

You just need to establish yourself as an expert in some facet of leadership in the software world.

"Try To Get a Job at PWC" and Other Things This Guide Isn't

Alright, one more bit of housekeeping before I lay out my suggested playbook.  I just want to talk about what I won't talk about.

If you go look up management consulting and how to get into it, you'll see a lot of similar kinds of really, REALLY long-play advice.

1. Do well in high school.
2. Get a college degree in business or something.  Also, get an MBA, maybe.
3. Make an eye catching resume, network a lot, see if you can get a job at a big 4 consulting...

Ugh, I'm sorry.

I'm so bored I can't type any more of this example of what I'm not going to say.  Hopefully you get the idea.

You don't need any specific degrees to offer advice to people.  You don't need to go work for some up-or-out firm, fetching coffee for Harvey Specter until he trusts you with your first real, solo assignment 7 years later.

Forget all of that stuff.

I honestly know nothing about getting the right education or working for the right companies.  I have computer science degrees and I've never worked for a "big-anything" consulting firm.

The only "consulting" firm for which I've been a salaried employee was many years ago, and it was a shop that sold mostly low-code app dev solutions and where you'd really have to squint at a mirror to call yourself a consultant.

So I know nothing about how to walk those roads.  What I do know is that I've spent a lot of time over the last 5 years giving a lot of advice to a lot of executives at a lot of big companies about software.

If that seems promising, please read on.

Step 1: Start Learning about Org Structures

Alright, with all of that out of the way, let's get down to brass tacks.  You're sitting in your cubicle, writing code, and wondering why no one in organizational leadership takes you seriously when you warn them that the mounting tech debt in your codebase is going to create real problems.

Let's change that.

Your first assignment in this mission of having credible authority is pretty straightforward.  Start teaching yourself about organizational structures.

For instance, learn what the following things are.

• Flat organizational structure
• Matrix organization
• Division/program-based organization
• "The Spotify Model"
• Functional organization structure

There are more besides, but that should be a starting point.  And don't just learn what they are.

Learn who would adopt them, when, and why.

What are their pros and cons?  Put in your back pocket examples of each being successful and also blowing up spectacularly.

When might an organization having bad luck with one want to try another?

Why this?  Well, it gives you practical understanding of org philosophy with a lot of breadth very quickly.

You can add depth as you go.

But remember, you're going to be advising people in leadership who have probably been steeped in one of these structures for a long time.  Being able to impart lessons learned from many other types of structure will have value to them and help you establish credibility quickly.

Step 2: Develop an Understanding of Office Realpolitik

Next up, become a student of office realpolitik.  Frequent travelers here on the DaedTech blog will recognize this as a frequent theme here.  But this if often me riffing, venting, musing, and doing whatever one does with a hobby blog.  You'll want to make a more deliberate study.

How to navigate office politics could be a book in and of itself, so I'll limit myself here to offering heuristics and basic guidance.

First, evaluate where you are currently.  When I say to you "what do you think of a 360 degree review" what comes to mind?

If it's "wow, that sounds like a great tool for transparency and valuable feedback," then you're going to need a lot of work.  If it's "ugh, that seems like an iffy idea, but I can't put my finger on it," then you're on the right track.

And, finally, if you could explain to a manager why this activity has real potential to torpedo morale without providing her meaningful feedback, you're in good shape.

You need to develop a savvy understanding of how professional org chart relationships tend to work.  This means understanding and navigating power dynamics, which takes practice.

The good news is, you can start to work on this immediately, right in your own office setting.

Step 3: Start Focusing on Data with Everything You Do

Have you ever read Freakonomics (or listened to the podcast)?  If not, check it out.  If you have, this is the style of thinking that you need to adopt.

Leadership is responsible for an awful lot of decision-making in organizations.  All too often, this happens with experience, "gut feel," anecdotal evidence, or all other manner of imprecise approaches.

And that's not a knock on decision-makers, per se.  It's just really hard to find good data in an efficient way.

If you want an example of this, ask yourself how management might get insight into code quality when making decisions about an application's fate.

What do they do, exactly?

Ask an architect or two?  Measure it by defect counts?  Install some dashboard and measure code coverage?

These aren't great options.

But if you can come in with better ones, you will create nearly instant trust.  So focus on teaching yourself how to measure and gather data on just about everything, even if it's not obvious how to do so.  It's a skill you can practice.

Step 4: Get Good at Interviewing People

Speaking of skills you can practice, teach yourself to interview people.  I'm not talking about the inane practice of job interviews with games of trivia and stump the chump.  Think more journalistic style interviews.

You need to get good at talking with people.  But you'll be talking with them in a specific way, asking them questions, taking notes, eliciting important information, and then assembling the results of these interviews into a coherent narrative.

Most of the time I've engaged with organizations, I've wound up interviewing many different people in the groups I engage.

This makes sense, because your charter will often be fact-finding on behalf of the person engaging you.  If you're doing something like helping a company adopt a new development methodology, you'll need to talk with at least a representative portion of the people in the group.

This helps you uncover potential obstacles and pitfalls.

I can't enumerate all of the different reasons you might have for talking to a lot of different people, but trust me, they exist.  You come in knowing almost nothing about the organization and have to get up to speed fast.

Having a good demeanor, knowing which questions to ask, inspiring at least some trust, and getting the information you need are acquired skills.

So practice in your own organization.  Schedule occasional meetings and exploratory calls to learn more about how your group and those around you work.

Step 5: Develop a Solution for a Problem that Leaders Have

So far, I've been talking about laying groundwork.  If you're working a 9-5 job, you can practice all of the preceding stuff there.

If you're a freelancer doing mostly labor in the form of app dev or else non-management consulting, this also provides you room to hone your budding management consulting skills.

But now, let's move on.

Oh, you can practice this next step at a job or client site, too.  But this one involves getting more focused and laying the groundwork to actually start doing engagements.  In this step, you start to find pains that folks in leadership have and to develop a way to help with those pains.

I actually got this completely wrong, in retrospect.  I'd been a CIO and had great inbound marketing game, thanks to this blog.

So I got calls.

• "Hey, can you come recommend training for our group and maybe do it or bring someone in to do it?"
• "Can you tell us if this app is worth saving?"
• "This expensive program is getting behind budget and off the rails -- can you help us get back on track?"

Management consulting gigs, all.  Sometimes I'd subcontract, sometimes I'd do it on my own paper.

The clients ran the gamut, too, and I was just kind of a rent-a-CIO figure as I wandered around.  (More on my story here.)

This worked out alright, but learn from my relative ignorance.

It'll take you far longer to establish yourself if you say "hey, I give advice to management."  It'll go a lot better if you establish a practice, the way I did eventually by trial and error.

Mine is providing detailed, data-driven dispensations about codebases.  Yours might be identifying sources of low morale or telling management whether Scrum would or wouldn't work for them.

Find something specific.

Step 6: Build a Playbook of Suggestions and Guidance in and around the Problem You Solve

Once you've got your pain-dream-fix value proposition in place, you need to develop a playbook around it.  To understand what I mean, let's use an off-the-cuff hypothetical.

Let's say you decided on a value proposition of the aforementioned identification of low morale.  To make it really specific, say you audit code review and pair programming practices for morale problems, and offer advice for how to fix them.

If you build a consulting practice around this, you're going to want more solutions to the problem than just "tell your employees to be nice to each other" or "fire Doug."

You need a playbook.  You're going to find yourself in lots of different organizations.  Some will say "be nice, that's genius!"

Others will say, "we've already tried being nice and it didn't work."  You need a plan B.  And then also C, D, E, F, and G.

But more than just a bunch of empty suggestions, you're going to want experience, case studies, and data (as I mentioned earlier).  "At ACME Inc. I saw something a lot like this and we had good luck switching to an email based review scheme and rotating reviewers regularly."

Doesn't that sound a lot more powerful than "you should try being nice?"

It'll be a challenge at first because you'll be short on field experience.  Make up for that by reading about what other companies have done and asking questions of friends and colleagues.  4

Then as you get more and more engagements, you can start to supplement your speculative playbook with one forged from the fires of experience.

Step 7: Engage with Leaders and Stay Engaged with Leaders

The last step moves you out of preparation and into actual engagement.  An actual manager or executive with budget authority will engage you, and you'll get to work.

When you do, remember that this buyer is your partner and your one and only customer through the engagement.  The buyer's boss or board of directors is not your customer.

The company is not your customer.  And, for goodness sake, don't go trying to out-technical-minutiae the devs, either, because they aren't your customers, either.

This style of consulting is a word of mouth business and a referral business.  Your job is to furnish expert advice to your buyer in service of helping that person.

Your job is to save her project, get her group back on the rails, and get her promoted if humanly possible.  If you think you're there to serve her reports, her boss, or "the company," go back and review step (2) about office realpolitik.

Setup regular check-ins with your buyer and have her be the main point of contact throughout.  Resist the impulse to start acting like an employee by not outstaying your charter.

You're there to help her with a specific problem and then to move on, hopefully with glowing recommendations and many thanks.  If you fail to resist the siren song of long term engagement, and hang around finding more and more ways to rack up billable time, you'll wind up as your buyer's subordinate and not a partner.

Further Reading and Resources

This is a pretty involved topic and I'm already 2500 words in, so I'll cut it here.  If you want more content and suggestions about becoming a consultant, feel free to Tweet at me or comment or something.

In the meantime, here's a list of resources that I'd personally recommend checking out if you want to become a management consultant.  This is not exhaustive -- just stuff that I can think of right now.

• Any of Patrick Lencioni's books.  He's a management consultant (not in software, specifically).  If you're going to zoom in on a few, I've found Getting Naked (yes, really), Silos Politics and Turf Wars, and The Three Signs of a Miserable Job to be particularly helpful.
• I linked to the original Freakonomics book, but all of the Freakonomics books are good.
• This book, called How to Measure Anything, speaks a lot to methodology for measuring things that seem impossible to measure.
• I'm a panelist on the Freelancers Show, and we tackle a lot of these topics there.
• Million Dollar Consulting is another must-read.
• It might seem a little off-topic, but the Lean Startup is really about applying the scientific method to business, which really ties in with Freakonomics and How to Measure Anything.
• I won't list them all here, but read the actual, original ideas behind eventually tiresome management fads.  Read the agile manifesto, the Scrum guide, etc.  Read accounts of companies that did unusual, inventive, or novel things, like Zappos, Basecamp, etc.
• And, of course, feel free to go digging through the archives here for any insights I have on office politics and consulting.  And feel free to fire reader questions at me.  I answer a few of them a month in my You Asked for It segment.

If you do all of this, I can't promise you that you'll someday be asking Tom Smykowski what it is that he'd say he does here.  But you will be well on your way to organizational leaders engaging you for your expert opinion and advice.

If you'd like to ask a reader question, you can do so at the "ask me" page.