I was a recent guest on The Geek-Whisperers. On the podcast, the team asked me the question of how did I make the transition from a pure technologist to a management consultant or better put by Matt Brender, What the Hell? I talked about the aptitude of management consultants vs. technologists but not how I made the transition.  I thought it would be beneficial to highlight the transition itself.

1st determine if management consulting is for you

Before we talk about the how, it’s important to answer the “if” question. I’ve discussed the differences between management consultants and technology consultants before. A common task I ask people to complete is to take an IT Strategy course or training. If, at the end of the course, you find yourself wanting to learn more then management consulting may be for you. However, if you walk away bored or frustrated then it’s a snapshot of what your experience will be working as a management consultant. You don’t necessarily have to invest in a course. You can pick up a book on IT business strategy to get a similar result.

Education and experience requirements

It’s very difficult to get into a Big 4 without a minimum of a Bachelors degree. I’ve seen exceptions when engineers possessed highly desirable experience in areas such as big data or Salesforce. These are rare exceptions and upward career mobility is limited. For candidates coming fresh out of school with no experience, a Bachelors is adequate to begin as an associate. If you are an experienced hire the requirements get a little more nuanced.

Most experienced hires that appeal to Big 4’s will have several years of customer facing industry experience. Big 4’s value the perspective that is brought from your years of experience talking with other clients. Engineers without customer facing experience will find it difficult to get far in the interview process. Management consultants have to be comfortable talking in front of customers. So, if you have experience in a pre-sales role then the skill will be directly transferable.  However, if you have spent all your career in a data center or coding and have limited presentation skill you’ll find it difficult to make a transition that keeps you at the same compensation levels. If doing pre-sales is an undesirable way to gain the experience, then management consulting isn’t for you. You will do pre-sales.

If you just haven’t gotten the opportunity to do pre-sales then look into participating in a speaking program such as Toast Masters. Hiring managers love candidates that look to expand beyond their current role. Any work towards a Masters or MBA is appealing as well.

On the job learning

What are the expectations once you’ve gotten the job? I spoke about getting involved in high-level discussions with SVP’s of Fortune 50 companies. Is the expectation that you add this type of value day one? No. Depending on your career level, the expectation isn’t there that you lead these types of conversations. Coming out of a pure engineering role you will be brought in at an individual contributor level. Even if you were a manager in your previous role, you will more than likely be brought in a non-manager role within a Big 4.

A Big 4 manager is expected to interface with senior level clients, as well as sell services. It’s a big cultural shock to move in to a customer facing/management consulting role from an individual contributor engineering role. You need to check your pride at the door. Coming from a people manager role into an individual job title was an adjustment for me. I found that even in my first year, I still managed teams and had the responsibility I expected sans a sales quota. During your first year, the expectation is that you are in learning mode until you raise your hand to lead. Big 4’s do a great job of providing all the training needed to progress in your career.

Conclusion 

So, I’m not special in the sense that I moved from being an engineer to a management consultant. Firms have well-defined transition plans and training. You may need to check your pride at the door. It’s safe to say that after 1 or 2 years at a management consulting firm, you’ll learn more than you ever thought you could. It will also be safe to say that you’ll know if it’s for you long term. The path isn’t as difficult as it seems.

Switching from Technical to Management Consulting – What the hell!
Tagged on:

2 thoughts on “Switching from Technical to Management Consulting – What the hell!

  • March 11, 2015 at 11:27 am
    Permalink

    Just listened to the podcast and I have some thoughts about it.

    Leaving the fast changing technology space for a while to learn the business-side while keeping up with the technology side sounds really hard.

    Where I’m currently at in my life, my first thoughts and gut instinct would be: I wouldn’t even want to try.

    I hope I don’t have to as well, because I’m pretty happy being a techie myself (would have liked to see more opportunities in my neck of the woods though. Not really into moving or traveling if I can avoid it).

    But because you aren’t a tech anymore maybe I should mention what I think about what is going on on the business-side:

    IT is going through some big trends and they are having impact on the business-side. They are driven by the technology, but because of business advantages of course.

    The best descriptions of these changes that I know of have been in these talks:

    About how devops and microservices is changing how technical people do their work and how the business is run:
    https://www.youtube.com/watch?v=nMTaS07i3jk

    The result of that is seeing big organizations get rid of all a whole management layer (like project managers) and just getting people that can manage themselves. Really, doing large re-organisations, effectively changing how the business is run:

    https://www.youtube.com/watch?v=6FPXbQ2WpAM

    Almost seems like they a busy creating one ‘pool’ of people with a lean organization around it, which can do some of the dev and some of the ops (even if for developers that only means developers can do self-service deployment).

    And for those that outsource to the cloud, that group of what previously were ops people, might be a whole lot smaller. If you have smart developers. Especially if you have ‘full stack engineers’.

    Well, that was my off the cuff summary. 🙂

    So what is the result ?

    One example of where microservices is pushing changes are how Paypal got rid of their Java solution on the front-end and only use it for the back-end. Something like node.js fit them a whole let better:

    https://www.youtube.com/watch?v=V5yk5SZxWX4

    Here you can see some pictures if it wasn’t clear yet:

    http://www.nczonline.net/blog/2013/10/07/node-js-and-the-new-web-front-end/

    The result is:

    On the developer side languages are now competing which each other because you are building microservices and the protocols are pretty much standardized (HTTP, JSON, REST).

    And if they don’t fit. You just rewrite that microservice in an other language. These code-bases are very small. And the processes itself are usually stateless.

    All the data is stored in the data-store.

    This means you can do this ‘webscale’ thing with your stateless microservice, because you can start as many of them as you need. All you need to do is put a bunch of loadbalancers in front which disperse the requests over these service specific processes. This also means you don’t only have loadbalancers on the front of your application, but also between parts of the larger ‘application’.

    Most of the time these microservices are just a single process, a daemon. Yes, that is where Docker comes in.

    Sometimes they include a webserver like nginx.

    The same is happening to databases, NoSQL and SQL like.

    You need to create a microservice that handles login ? You give it a seperate datastore, maybe you think LDAP is a good idea, who knows.

    You need to build a microservice which handles checkout ? You give it a seperate SQL-datastore.

    You need to build a microservice which stores the session-information, yep, that too is a seperate microservice, it might be using a noSQL store.

    And remember: that one microservice is the only service talking directly to that data-store. It might talk to other microservices, but they only use their own datastore. That is where that service discovery thing I mentioned before comes in.

    It’s very much about seperation of concerns and using the best tool (read: language and existing other libraries or databases) for the task.

    The other part is:
    Deploying different services seperately (don’t let deployment/update of one service depend on the deployment of an other). That is why different services don’t share their databases. So they can be updated seperately.

    Now comes the business-side again:

    In larger companies, like Netflix, they put a seperate team on every microservice. They are completely self-organising, self managing, like a little startup or something like that. They choose the best tools for the microservice they are supposed to build and develop further.

    Amazon has a maximum size per development team and thus microservice: 2 pizza’s
    https://blog.bufferapp.com/small-teams-why-startups-often-win-against-google-and-facebook-the-science-behind-why-smaller-teams-get-more-done

    Well, I hope there is something in there that you found interesting. 🙂

    Reply
    • March 11, 2015 at 3:50 pm
      Permalink

      You are not a developer, but I’ll post this anyway.

      The ‘endgame’ is a set of open source components developers can use to build their own deployment PaaS-like platform for the microservices they develop. This, to me almost creates a ‘no-ops’ solution. So their is no devops, just dev. Obviously depends on a self-service cloud-service. But doesn’t depend on something like AWS, it just needs a bunch of machines, baremetal or VMs to run and an API to start them. Pretty much any VPS provider can do this.

      Flynn is an open source project to do this. This is a talk from Jeff Lindsay about Flynn:

      https://www.youtube.com/watch?v=iviBZMRLqD8

      Flynn has all the bits and pieces:
      – containers
      – datastore appliances
      – service discovery
      – etc.

      But Flynn is still beta software.

      You might know Cloudfoundry, it has have some of these properties. It’s still more a traditional PaaS, though. That is why VMware, HP and others are interested in it. Deis for example is further along the path.

      Everyone says Adrian Cockcroft is the guru for the organizational side of microservices / devops, etc.

      In my mind Jeff Lindsay is the guru for the technical side of it. Without him Docker wouldn’t have existed in it’s current form, it may not even have been released as open source.

      Reply

Leave a Reply

%d bloggers like this: