How to Become a Management Consultant

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?

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.

Read More

Being Good at Your Job is Overrated

Let me be clear about something.  This title isn’t clickbait.  I mean it.  But I mean it literally.  Being good at your job is overrated.  We value it too highly.

If you’re a long-time follower of this blog, you might think this is a curious sentiment against a backdrop of advocating for practices like test driven development.  And if you’ve wandered here from somewhere else, you might think this vacuously contrarian.

In either case, relax.

Being good at your job has value.  It’s certainly better than being terrible at it.  But it’s not nearly as important as we think it is, in the grand scheme of things.  The world weaponizes our love of mastery against us at times, causing us to lose sight of other considerations.

I’ll back this claim up with more explicit reasoning a little later.  But first, because I’m back to amusing myself with the blog, indulge me.  I’m going to tell some stories.

Read More

Value Proposition Guidance for Recovering Programming Generalists

I saw something awesome earlier this week.  Because I’m in the content business, I was trying to explain the concept of “pain, dream, fix” to a client.  It’s a way to write landing pages that focuses on customers and their pain points rather than on product features.  Anyway, in looking for a good explanatory link, I found this gem from Anton Sten.  It’s great advice for landing pages, full stop.  But I’m going to build on it to offer you advice about your value proposition.

Getting a value proposition right is hard enough.  But when you’re used to being a software developer, it’s almost impossible because of how badly everyone teaches us to get this wrong.  So let’s look at the bad advice we get so that we can then start with first principles.

Here’s the picture from the gem of a post I found.  Let’s start there.

The Basics of Pain Dream Fix and the Value Proposition

About a year ago, I wrote about how to start freelancing/consulting as a software developer.  In that post, I emphasized the idea of a “who and do what” statement.  This is a mad lib that takes the form of “I help {who} do {what}.”  This is a value proposition — a way to convince prospective buyers to buy from you.

In the software world, we constantly get this wrong.  And this image illustrates perfectly how we get it wrong.

We tend to talk about our products in giant lists of features.  Or we sell ourselves as an alphabet soup of skills and tech stacks.  And, in doing this, we completely neglect to mention who should care and why.

“Pain, dream, fix” (and this picture of Mario) is a way to jolt ourselves out of our professional solipsism and to start thinking of others.

1. Pain: Poor Mario is too small and weak to survive in a world of Goombas and Koopas.
2. Dream: But he could be twice the size he currently is and able to slay his enemies with flamethrower arms.
3. Fix: All he has to do is eat this flower.

Flower provider value proposition:  We help undersized plumbers kill their foes by giving them super powers.

Seems simple.  But we really manage to get this comically wrong.

Read More

Stop Arguing with Software Developers on the Internet

I won’t bother pasting the iconic XKCD that we’re all thinking about right now, given the blog post title.  Instead, I’ll just lead with the premise.  You should stop arguing with software developers on the internet.  In fact, you should probably stop arguing on the internet altogether.

Now, before you go any further, notice that this is a post in my “developer to consultant” series.  What follows is thus advice for someone who is looking to be a consultant — someone for whom an internet presence is a marketing asset.

If that doesn’t apply to you, then don’t worry.  If all you’re looking to do is find some catharsis because the expert beginner serving as tech lead in your group has outlawed writing unit tests, then go nuts.  Pick every fight out there on Reddit and in comments sections.  Sharpen your reasoning or debate skills by bouncing ideas off of other people with varying degrees of mutual hostility.  Do you.

But don’t kid yourself — what you’re doing is a hobby, not a hustle.  It might be fun, and it might help you in a vague way, but it hurts you professionally (unless you’re doing it in a very calculated fashion, but this is an AP tactic I’ll return to).

Arguing on the Internet as an Employee is a Lot Different than as a Consultant

When you’re an employee, the internet is sort of a vast sea of potential fights to pick.  You can argue with your cousin on Facebook about politics for a while.  Then, you can mix it up by posting an angry screed to Medium entitled, “[Thing Everyone Currently Likes] Considered Harmful.”  And finally, maybe a few palate-cleansing down-votes on a Stackoverflow before you call it a day of sometimes doing your work.

As long as your Twitter handle contains some boilerplate about how your views aren’t the company’s, you’re mostly good.  From there, you really just kind of need to avoid being overtly offensive when people can trace your words back to you, and your company will just shrug off anything you do.  You play in a vast yard, and the only thing that will trigger your metaphorical shock collar is running outside the generous boundaries of “reflecting poorly on the company.”

Not so when you own your own career and brand.

When you own your own career and brand, your presence on the internet becomes a digital job interview, writ large and made permanent.  As an employee interviewing for jobs, imagine your interviewer being wrong about something.  You’d bite your tongue, turn slightly red, hemorrhage a bit internally, but ultimately keep the indignation to yourself.  When you go on your own, you should approach your online presence this way.

To really underscore why, let’s place you in the role of a buyer through an analogy.

Read More