Monday, March 22, 2021

Moving Into Consulting 101

Introduction to this blog series

After being laid off by a Great Recession-era mortgage company in 2007, I entered into consulting. I made that switch from in-house DBA to consulting DBA at age 26 out of necessity, and as a professional and SQL consultant, I grew up in consulting. 

I've prepared this blog series as an intro to what it might be like going from an in-house position to a consulting position.

I made the transition myself. I've hired institutional DBAs to work as consulting DBAs. I've observed and coached others making the transition. I worked for more 12 years as a consultant with nationwide clients at an IT consultancy and MSP of ~250 people. Consulting as a database administrator was enjoyable and successful work that constantly sharpened my skills, and constantly exposed me to new challenges and the latest technology.

I enjoyed consulting work and I recommend it, especially for folks motivated to learn and see a lot of projects in a short amount of time. I think it's great for your first or second job out of college, just because of the career velocity you're likely to see. 

That said, everyone's experience is different. I have seen folks get a raw deal in consulting: stuck on old project support, difficult clients, or worst, SharePoint development. But over time, consulting should provide a variety of learning experiences, both interpersonal and for whatever your technical skillset is. This blog series isn't just for SQL data professionals, it's for anyone entering consulting or thinking about it.

After 13+ years in consulting I took a position at Microsoft, a completely different type of in-house spot, and have spent some time reflecting on, appreciating, and unraveling some consulting work habits. I hope you or perhaps someone in your network will benefit from this blog series.

A caveat - I have not done independent or solo consulting as my primary employment. Instead, this blog series is focused on the millions of people working for consultancies both big and small, in any industry or field of expertise. If you're making the transition from in-house whatever to consulting whatever, I might have some wisdom here for you, even if you're not a DBA.

With all that said, let's get started.


from Pixabay

Part 1 - The Patience of a Consultant

My first summer job was at a local independent computer shop when I was 16.

I was asked to count a large stack of printer cartridges. Simple math, I thought, I multiplied height times width times depth, easy. I was told my count was wrong. I stood there and insisted my math was right. (This is not a pleasant memory.) I was told I was wrong again, too low. It was only after walking around the stack that I saw it was not a cube, but an L-shape.  My teenage math was fine, it was my teenage premature assumptions that were flawed. 

Thus our first topic of the series:

Don't jump to conclusions

Take the time to walk around the client environment before doing math. Reserve your recommendations, and hold your tongue until after you've done proper discovery.

If you're brought into a client who is having an issue, definitely listen to everything they're telling you, but don't start based on only that information. I've seen consultants, even Microsoft support techs, too eager to suggest solutions and quickly start grand doomed fishing expeditions. It was frustrating for everyone involved.

Remember, they probably called you in because they haven't figured it out themselves, but they have tried. Don't assume your clients have no knowledge in this field, or haven't searched the internet for standard solutions. 

Similarly, don't assume they've told you everything you need to know up front, the client has almost certainly not given you a complete picture of the environment. In the next blog post in this series, we'll discuss the tact needed to unravel facts provided by clients, avoid blame-storming, and do root cause analysis without making enemies.

Put on your toolbelt

As a consultant, have your own questions and tools. Try to set about your discovery in a way that is methodical and isn't likely to miss anything. It's easy to be distracted by your client's initial diagnosis, or to be distracted by symptoms rather than causes. Before you mention solutions, do some digging yourself.

Also keep in mind that the upfront info you get from your client contact may not be complete. They may be hiding something that is their fault, something they know they should have done, and are just wanting you to get in and fix it. 

Listen before judging. I've heard a benchmark that newly hired managers should do nothing but listen and observe for the first few business cycles. Consultants should absorb as much info as possible before making recommendations. 

The Health Check Findings or Discovery Report documents (you should create these if they don't already exist) are deliverables where you to lay out what you found and what action is recommended to address the client's requests. You should provide your clients your findings in both simple executive terms and detailed technical terms. These deliverables are the place for your conclusions and recommendations - not day one on a new client.

A toolbox/checklist helps you avoid recreating the wheel each time you do a similar engagement. In some industries that have life-critical safety concerns, checklists are crucial. Do the the checklist every time and don't forget anything, or someone could get hurt. Give the same attention to creating repeatable content for your engagements.

Standardize your discovery

Like I mentioned, build a checklist useful in discovery. Assemble tools and stash reusable assets in your utility belt, next to your batarang and batgrapple. Organize and curate it and constantly update and improve it. 

The checklist should provide structure about both process and technical means of delivery:
  • Process: what questions to ask in what groups, what conversations to have, and what information to send and receive.
  • Technical: how to find answers in a standard way, reference for FAQs, talking points for common training opportunities, scripts and/or diagrams for important conversations.
This structure helps you in multiple ways:
  1. It gives you a marketable asset for your partners in sales (or, yourself). Your time and process are valuable assets. 
  2. It gives you a structure to fall back on when doing discovery or health checks. You won't miss anything, and your reporting will be thorough and useful to your future engagements.
  3. It gives you institutional knowledge for your junior team members and new hires to ramp up to your team's process, so that client deliverables are produced consistently.
If you're joining a mature consultancy, they might already have these assets. They exist for a reason. Absorb them quickly, and contribute to them in the institutionally-provided ways. 

Bring your past experiences with you, sure, but make sure to leverage the wisdom of a well-developed toolkit if it exists. If it doesn't exist? Get to work on it.

from Pixabay


Common structured findings concepts

Low-Hanging Fruit = Easily achieved-wins. Oftentimes a Discovery Report or Heath Check Findings will include a variety of tasks of various difficulty. It is always good to identify the easy wins are low effort, high reward. These help both your consulting engagement get positive results, and the clients to realize a return on their investment that looks good to their superiors. Always stress the importance of more difficult tasks while stressing the fast payoff of easy tasks — you want to get paid to do all the work, in the end.

Remediation = You've performed your health check/assessment/discovery/evaluation, and now you've got recommendations to make. Be sure to include not just the problem scenario, but also how you recommend solving it. Don't present the client problems with no solution, always recommend a path to remediating the problem, even if your consultancy doesn't offer those services.  

Sales Collateral - Visual that looks good in a sales pitch meeting. Believe it or not, sales people aren't great at making this stuff. Oftentimes, senior technical folks provide good info and the marketing or content people turn it into go "battle cards" or "solutions pitches" for sales people to take into conversations. Senior consultants should try generating some sales collateral for the projects you want to do, and working with marketing/content folks to refine it. A good first bit of sales collateral kit? "XYZ Health Check" or "ABC Success Checklist".

This is part one of a five-part series on Moving into Consulting 101

Got comments, questions, or guide for your fellow consultants? Comments are welcome below.


Unknown said...

Thank you for taking the time to blog this information. I haven't read the other parts yet however, I will be doing so.

Valerie F. Leonard said...

Thanks for sharing this series. They are just what the doctor ordered!