Some of my journey as a consultant:
Taken right after my final round interviews in Raleigh, North Carolina. Ended up joining!
Did my trainings and screenings to join my first engagement. Travelled to customer site for the first time with my Architect and PM.
Answered a call of proposals to Red Hat Summit about Using Vert.x to create Reactive Microservices and Distributed Tracing to better understand the application. The talk was accepted and I got to present to over 50 people in a mini-session at Red Hat Summit 2019 in Boston. Some services managers, engineering folk and CNCF project maintainers made it to my talk!
I did more talks and worked with the Red Hat Academy team. I went to Las Vegas to speak at their Internal Red Hat event about DevOps, training, and certifications. I also visited my Alma Mater the University of Maryland with a fellow Consultant to talk about Containers and OpenShift.
Taken by my Architect. :) One year into consulting, specialized in my role, and earned consultant of the quarter for contributing to the success and extension of my first engagement. I had a climb out of a few ruts, but I came out more opinioned and determined.
I helped recruit and interview other people into Red Hat Consulting. Shared the best parts about: my job, tech, self-development, and chasing passions.
Got more involved with the Marketing, Engineering and the new consulting practice for App Dev.
Went all in on mentoring and being mentored. Spent time with some of the greatest people. Learned more about myself: what my strengths and interests were. I practiced speaking my mind and being kind without taking any shit. I also learned how to walk the path that’s wholeheartedly mine.
Before I started as a consultant at Red Hat, I knew little beyond the title of the role what I would 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 make improvements to 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. Being able to solve 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 what is called 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 roles that are cross-functional and 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 failure or success of the project delivery. So I wanted to talk about the different roles related to consulting that are 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. In the past, they may have been a consultant or have had long term experience delivering and working with the software and or business domain. 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 success of the project 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 as opposed to 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: Theses 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 while 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 manager 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 being a consultant let me know down below!
Thanks!
