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-07-29-preparing-the-terrain-for-successful-engagements.md

@@ -0,0 +1,162 @@
+---
+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-07-29-preparing-the-terrain-for-successful-engagements/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>
+---
+
+"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 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?
+
+## 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 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](https://en.wikipedia.org/wiki/Disagree_and_commit).
+
+## Who 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.
+
+## 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 alignment.
+
+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](/services/team-reinforcement/) on how we can help you
+to burst through the bottleneck.