Blog post: Preparing the Terrain

src/authors/oliverbarnes.md

@@ -0,0 +1,7 @@
+---
+name: "Oliver Azevedo Barnes"
+github: oliverbarnes
+twitter: oliverbarnes
+linkedin: oliverbarnes
+bio: "Software Engineering Consultant"
+---

src/posts/2024-05-21-team-buy-in.md

@@ -0,0 +1,114 @@
+---
+title: "Preparing the Terrain for Successful Engagements"
+authorHandle: oliverbarnes
+twitter: oliverbarnes
+tags: [startups, consulting]
+bio: "Oliver Azevedo Barnes"
+description:
+  "Oliver Barnes on the importance of getting the team onboard when bringing in
+  a consultancy"
+og:
+  image: /assets/images/posts/2024-05-21-team-buy-in/og-image.jpg
+tagline: |
+  <p>A consultancy engagement can be a very productive, gratifying collaborative process. That's _if_ the client's team is onboard with having it come in to help</p>
+
+image: "/assets/images/posts/2024-05-21-team-buy-in/header-visual.jpeg"
+imageAlt: "A rocket icon on a grey image background"
+---
+
+"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.
+
+## Making 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.
+
+## Happy 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 consensus.
+
+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. Just how do you get buy-in?
+
+## Get 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 consensus towards the engagement.
+
+Sometimes it's hard to get consensus, of course. But when dissenters have been heard in earnest, that goes a _long_ way towards getting people to [disagree and commit](https://en.wikipedia.org/wiki/Disagree_and_commit).
+
+## Who invites us
+
+Some very successful engagements happened when we were invited by people from the tech or product teams, who are closer to where the action will happen. This can help a lot in getting buy-in.
+
+When the invitation comes from the very top, it makes a huge difference when management goes the extra mile and talks to the teams that will directly be involved in and impacted by the engagement.
+
+## Framing the engagement
+
+And _how_ the engagement itself is communicated is key.
+
+### Assessments, not audits
+
+Some of our engagements begin with [an assessment of a client's current state of tech and organization](https://mainmatter.com/services/strategic-advice/). 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.
+
+### Collaboration, 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.
+
+### Alignment 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.
+
+## During 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 consensus.
+
+And then we help them implement it. As part of the team.
+
+[Reach out](/contact/) to talk about how we can help your team.
+
+Find [further information](/startups/) on how we can help you to burst through
+the bottleneck.