"Ugh, leadership is bringing in a bunch of consultants from Evil Co to audit the team and point out our inefficiencies… this can't be good, right?"
Consultants get a bad rep sometimes, and often for good reason, specially due to powerful top tier consultancies involved in everything from privatization of public companies to disaster relief. They're everywhere these days.
Software engineering consultancies like Mainmatter are nothing like that, but still "consultant" is a title with plenty of loaded meanings and associations.
Outsiders can be helpful. External experience and a fresh view on things can be very useful. But, as with any collaboration, it's important to respect context and history, and to get the client's team onboard.
anchorMaking sure we're welcome guests
When starting with a new client, we're mindful that we're coming in during a time of difficult change - be it in technical terms (changing stacks or merging systems, for example) or organizational ones, say when a team is expanding and re-organizing.
And, as often happens, both at once.
We discuss that with the leadership team and with different stakeholders who might be involved in bringing us in to prepare the terrain for the engagement.
anchorHappy path
When the client's team is bought-in, we get an environment of trust, a sweet spot where we complement the client's team seamlessly.
Context and knowledge are shared proactively, affording us smooth onboarding. Once we have some recommendations to give, these are discussed constructively. Decisions on what to implement are naturally done in alignment.
A virtuous cycle ensues, where implementing changes is progressively faster and more effective, and ideas flow freely back and forth. Together we shift into continous improvement mode. Everybody wins.
So. How do you get buy-in?
anchorGet the team involved early on
The earlier the intention to bring us in is communicated, the better. Before even making a decision, hearing the team out and addressing any concerns is a very good idea - building trust in the engagement.
Sometimes it's hard to get that trust, of course. But when dissenters have been heard in earnest, that goes a long way towards getting people to disagree and commit.
anchorWho invites us
Sometimes we are invited by people from the tech or product teams, who are closer to where the action happens. In this case, the team is already bought-in - the invitation addresses specific demands from the teams we'll be working with.
In other instances, the invitation comes from a client's leadership. In these cases it makes a huge difference when they openly talk about it to the teams that will directly be involved in, and impacted by, the engagement.
anchorFraming the engagement
And how the engagement itself is communicated is key.
anchorAssessments, not audits
Some of our engagements begin with an assessment of a client's current state of tech and organization. This can be either a high-level x-ray, or a more specific analysis of a team or of a system component.
An assessment can be super helpful for a client to find blind-spots, to get an independent point of view in the context of conflicting internal assessments, and when planning for big changes.
This is most successful when a team is willing to show what's under the hood in the tech stack, and behind the scenes in terms of team interactions and processes.
If instead a team perceives the assessment as an audit, a quality control inspection where blame is distributed and people eventually get in trouble, transparency (and morale) will obviously suffer.
Some discontent might start brewing, understandably. In turn, potential future interactions and collaborative work might be seriously affected.
That's a very bad start.
Hence, Mainmatter doesn't do audits. We offer blameless assessments as a resource to help teams plan their future work, possibly leading us to a fruitful collaboration down the line.
From a client's team perspective, blameless assessments can help them advance internal improvements they might already have been pushing for: more budget or people, better tooling, leaner organization, more knowledge sharing, among many other possibilities.
anchorCollaboration, not intervention
In a similar fashion, when we augment a team (with engineers, architects, designers or managers, sometimes all of the above), we work hard to ensure this work is collaborative and not perceived as an intervention.
We're making suggestions, sharing knowledge and practices, pairing and planning together, constantly building consensus.
We're complementing the team until they no longer need us.
anchorAlignment on scope
An engagement can take many shapes and forms. It can have a tightly bounded scope, like updating the runtime and dependencies of a given codebase, or a much broader and open ended one, into architecture, engineering processes and practices.
Whatever the scope, the earliest it is clearly communicated, the better.
People can become territorial over their work. Nobody likes having someone unexpected looking over their shoulders, nor receiving unsolicited advice.
If there's a misunderstanding over the scope of our work, that's exactly how it'll feel to the client's team.
So being aligned on scope and objectives is fundamental.
anchorDuring the engagement
Client team buy-in involves accepting to at least hear recommendations from us, and for this to continue, our recommendations have to resonate and make sense, even if they the team doesn't totally agree with them.
Addressing pain points is a great way to ensure this relevance, and build trust. We're solving real problems, removing slogs. Improving productivity. Making work more pleasurable.
Often we'll find issues that weren't raised before. Or ones where a priority and solution weren't yet agreed upon. In these cases, we study and discuss until there's enough alignment.
And then we help them implement it. As part of the team.
Reach out to talk about how we can help your team.
Find further information on how we can help you to burst through the bottleneck.