The World of Tech Consulting

Before I started as a consultant at Red Hat, I knew little beyond the title, what Consultant meant. What was the role, what did it mean, what would I be doing on a day to day basis? People ask, “… tech consultant? What is that?” And I’ve seen it described as a career path that is “less traditional” for those going to work in the software industry.

True that the role requires a range of skills beyond what would be expected in a typical or traditional software engineering role. Today I thought I’d dispel the role of a software consultant and talk about key goals, functions, and terminology related to successful technical consulting.

PART 1: GOALS

Understanding the goals of any role is one of the best ways to succeed in any organizational function. Here are some core goals I found myself having throughout my software consultancy role:

• Delivering on the scope of work as a trusted advisor: Consultants cultivate a trusted advisor relationship with the customer’s software teams to deliver on a scope of work. Consultancy is about bringing expertise in an area of interest. If someone wants to implement a new application feature as a microservice, a consultant is the trusted advisor for that goal. They’ll answer questions developers may have around microservices, establish themselves as a trusted advisor with best practices around breaking features into services, and deliver on the scope of work. Through and through, we are a resource to our customers. A lot of consulting is building up credibility through communication and produced work. A consultant may come in and improve the implemented microservice, or they may even extend what the customer already knows. If it’s something they are interested in, they’ll provide a proof of concept (POC) for the proposed direction. An example is changing a microservices architecture to a serverless architecture.
• Sharing findings across the organization: Consultants will often run into similar problems across the organization and even across projects. Solving problems using quick, consistent, repeatable, and sustainable practices will make you a successful consultant. Often this means collaborating with engineering to share use cases and or any exciting findings, speaking at conferences or internal events, and sharing with other consultants.
• Training and knowing what you need to know: Technology is always advancing; part of the job is sharping the skills needed to stay one step ahead of the customer. Often this means remaining current with the best practices and what sort of solutions exist in the technologies you are consulting. It’s a role that demands problem-solving curiosity. Don’t be afraid to reach out and ask the right questions. You’ll learn a thing or two.

PART 2: ROLES

One point about organizations that I would like to highlight is that consulting often falls under the umbrella of Services. A company’s Services organization will have groups of people handling different “services” like support, training, technical account management, and of course, consulting***.

***Note that companies will often do this differently, and you can end up in an organization where sales and services are under one group. Or (and this is common in smaller organizations), you’ll have cross-functional roles. You will interact with other people in sales, marketing, and engineering even when organizationally, their role falls under services.

Therefore the success of the customer is not only owned by the consultant on the project/engagement. We may be the boots on the ground, but many other factors can contribute to the project delivery's failure or success. So I wanted to talk about the different roles related to consulting involved and how to leverage some people next time you are on a project.

• The Consultant: We talked about this. They are the hands-on keyboard, shoulder surfacing peers guiding you along as a trusted advisor. You’ll be apart of critical conversations around the work that needs to be done. They ask questions during meetings and keep a healthy amount of documentation for reference to repeat their work. Don’t underestimate how much experience you get in this role. Don’t be afraid to ask this person to reference their past experiences on projects to make an informed decision on your project.
• The Consulting Architect: This person serves as a resource to consultants and customers for technical expertise and reference. They may have been a consultant or have had long-term experience delivering and working with the software and or business domain in the past. Invite this person to any critical conversations you plan to have with the customer, ensure they are ready to back up or present any technical findings and direction the team is headed.
• The Project Manager: This person is a manager for the project. An excellent way to think about project managers is that they’re there to ensure the project's success and the consultants. They’ll often handle any questions you have around team/project progress, questions like “what should I work on next. “ They’ll also have the logistics for travel and expenses if you’re sick, or out for the week, whatever. This is the person that coordinates the what, where, and when. Don’t be afraid of mitigating questions around workflow to the project manager. They’ll work with everyone involved to prioritize work on the consultant’s behalf. They should be included in, if not leading, any planning sessions and daily conversations around the status of the work in progress.
• The Services Manager: This person helps manage the relationship between the consultants and the customer. They’re usually the ones on calls making sure things are ok, and they’ll be the ones that hear about project extensions and budgets. Services managers will work with Project managers to help staff new or potential projects. They’ll also have multiple relationships with accounts instead of only working with one project at a time. Any escalations can go to the Project Manager and or Services Manager. This person should be aware of any changes in the scope of work and potential future opportunities to extend the work to be delivered.

PART 3: TERMINOLOGY

Nice! You now know some goals consultants may have and who they interact with. Next, we’ll discuss some key phrases you may hear.

• Engagements: These are the projects you’ll be involved in. Typically consultants work one engagement at a time—40 hours a week billable to a client.
• Bench: The time in between or off of engagement is known as bench time. It’s a good time to catch up on training and other internal initiatives. At the same time, on the bench, as you typically won’t be traveling to the customer’s site and putting out the fires that occur during an engagement (hey, there’s a reason why you’re there).
• Utilization: This is a measure and percentage of how many weeks billable you are to a customer. 100% utilization is if you were on an engagement(s) 100% of the year.
• Scope of work (SOW): A sales architect. Consulting architectures and/or services managers will work with the customer to put together a document detailing the work to be done by the consultants assigned to an engagement.
• Thought-Leadership: It’s considered a giveback at Red Hat. These are the artifacts you share and develop through the findings and solutions you’ve developed while on engagements. Thought-leadership driven by customer implementations and delivery of work goes beyond the traditional value offered by a proof-of-concept or hello-world demo.

That’s all for this post. If you’d like to see more content around what it’s like to be a consultant, let me know it below!

Thanks!