When Double Agents kick off an engagement with a new client, we increase our chances of success by intentionally giving the engagement space to unfold, naturally but not haphazardly. There are several common phases of this unfolding. Let’s talk through them using a conveniently alliterative formulation.
Capture
One of the biggest challenges of consulting, especially with a new client, is that at the beginning we know very little and notice everything; as time goes on, we know a lot more but that familiarity also makes it more difficult to remember the things that we noticed earlier on.
The solution to this is the simplest thing: Write it down. In the Capture phase of consulting we are taking inventory. We’re making a list of all the things that seem suboptimal so that we can come back to it later.
This isn’t a list of things we will fix. In fact, we’re likely to have 63 things or more. The truth is, most of what we Capture will need to stay as it is, if only for pragmatic reasons. The things we do end up trying to change will be a small subset of the list or a higher order concern that encompasses several items. Tracking our observations ensures that when the time comes, we have a healthy backlog to consider. This is pure intelligence gathering; analysis and action come later.
Context (Chesterton’s fence)
Everything that is, is as it is due to some combination of circumstances, decisions, and experience.
The inexperienced consultant begins an engagement and immediately wants to reform this process, rewrite that architecture, or rebuke so-and-so project stakeholder. The experienced consultant starts by understanding how the current situation arose and only then evaluates the options for change.
Building Context is part of the ramping up process. Ramping up goes beyond getting the application running and making contributions to the codebase. It means understanding the users of the client’s product, connecting with the business case of the team’s current project or feature, and learning more about the software patterns that are preferred by the team.
Most of all, the Context stage of the consulting relationship is about asking a lot of questions and really listening to the answers. These questions will come up in all kinds of situations, from pair programming sessions to code review to architecture proposals to team retros.
Listening to the client’s explanations—the explicit and well articulated, the implicit and tenuous, and the tacit taboos—for how things came to be the way they are begins to shed light on what things we’ve Captured have any potential for change.
Credibility
One of the most effective things a consultant can do is deliver value to a client as early as possible. At Test Double, we build Credibility early in several ways.
First, we onboard as quickly as possible and improve the onboarding experience by updating documentation, writing new checks in setup scripts for edge cases discovered along the way, and supporting the onboarding of our fellow agents or new client team members when they join the team.
We also establish Credibility by answering questions and sharing salient knowledge and experience from past projects. Rather than hoarding our expertise, we share freely. Years of experience teach us that solving people’s problems or helping them see the problem from a new perspective is a sure path to Credibility.
Lastly, but by no means least, we establish Credibility by getting to know other members of the client team through coffee times, 1:1s, pair programming sessions, and other touchpoints. Establishing a 1:1 relationship with engineering managers, tech leads, and other leaders and stakeholders in the engagement establishes lines of communication and shared perspective on the client’s project, processes, and team.
For other individual contributors, regular collaborations help reduce the perception of us consultants as outsiders and establish a relationship that serves as the foundation of trust for team members who need an outside perspective or sounding board.
Confidence
Once we have established Credibility and Context, Confidence should be rising.
At this point, we return to the list we Captured and review it for opportunities. In my experience, this step can be extremely eye-opening. Things that seemed so bizarre or detrimental at the beginning might now make much more sense. And the list begins to prioritize itself in light of the gathered Context.
In this stage of building Confidence, we also begin to identify and prioritize the items from our Capture list. Here we look for chains of causality and critical paths in those relationships to identify opportunities for an outsized impact for the client. Regardless of any anticipated domino effects, we will typically identify a small number—less than five in most cases—of recommendations.
Capitalize
As we prepare to make recommendations and bring about change within our client’s team or organization, we begin by clarifying our strategy and tactics.
Effecting change within an organization benefits from a coordinated effort from all participants speaking with a unified voice. Double Agents share insights as a team, align on a strategy, and assign each team member’s next steps based on their role and responsibilities within the engagement. From there, both the Client Partner and the consulting team work with the client to present our findings and recommendations.
The Client Partner is typically working with an engineering manager or director-level stakeholder and discussing these ideas at a high level. At this level, the client might be concerned about the impact of making change on the overall delivery schedule or general productivity impacts.
These recommendations may warrant an expansion of the engagement so that there will be more consultants on the team to tackle the work such as when there is a need for a new testing strategy or a platform-level initiative to establish some stability and consistency in a cross-cutting part of the codebase. In other cases, we may highlight the necessity of some reduced throughput in order to make improvements alongside other work. It’s up to the client to decide how to prioritize these changes.
Collaborate
The consulting team works with with the client directly, depending on their respective roles within the engagement, to take concrete action. We start by securing support for our efforts from the engineering manager and/or tech lead for the project, even if they won’t be directly participating in the change. We also identify which of the client team members we have the most rapport with and who might need some extra convincing about the change’s value.
From there, we introduce the change, respond to feedback, and work with the client to adjust the specifics of the implementation. Lasting change originates from within. The insight may come from us but the change has to come from them.
Customize
Of course, no two consulting engagements are the same. Each client has a unique history, challenges, and opportunities.
From our experience across a variety of engagements, from large organizations with hundreds of engineers to startups with just a few folks, we have found considerable consistency with the process of introducing change. No client will accept the recommendations of someone that doesn’t take the time to understand how things came to be the way they are.
Even correct recommendations are unlikely to be embraced without Credibility. By taking the time to understand our clients and their unique constraints, we are able to effect lasting changes that improve the way at least one small corner of the world builds software.
Join the conversation about this post on our N.E.A.T community
Not a N.E.A.T. community member yet? More info.
Related Insights
New Stanford research shows 9.5% of engineers contribute almost no visible work—but blame won’t solve the problem. Here’s how leaders can fix the root cause.
