Blog post: Preparing the Terrain (#2414)

* Outline for approval

* Tack .md at the end

* Profile

* First draft

* Alignment on scope

* Tweak alignment on scope

* Start fleshing out "During the engagement"

* Polish

Try to make it more interesting, less direct and less dramatic

* Keep it positive

* Quote Kevin

* Polish

* Less is more

Co-authored-by: Emma Dell'Acqua <[email protected]>

* Make it more about us, and polish

* Outsiders can be good

* Make happy path section high level

* Change title

* Add Kevin's role

* Rejig Kevin's blurb

* Edit Kevin's link

* Add wikipedia link to Disagree and Commit

Co-authored-by: Pablo Brasero <[email protected]>

* Reword intro

* Be more specific in the title

* Add og, run lint fix

* Update og-image.jpg

* Fix typo

Co-authored-by: Emma Dell'Acqua <[email protected]>

* Implement Sarah's suggestions

* Remove "continuous assessment", and polishes

* More polish

* Remove line wrap (as per Chris' PR), and some small tweaks

* Update link

Co-authored-by: Marco Otte-Witte <[email protected]>

* Add profile pic

* Clean up sentence

Co-authored-by: Luca Palmieri <[email protected]>

* Use 'trust' instead of 'consensus'

Co-authored-by: Luca Palmieri <[email protected]>

* trust, instead of consensus

Co-authored-by: Luca Palmieri <[email protected]>

* Remove unnecessary newline

* Reword invitation paragraph

* Alignment instead of consensus

* Lint

* Rename file and directory for assets

* Remove header image?

---------

Co-authored-by: Emma Dell'Acqua <[email protected]>
Co-authored-by: Pablo Brasero <[email protected]>
Co-authored-by: Emma Dell'Acqua <[email protected]>
Co-authored-by: Marco Otte-Witte <[email protected]>
Co-authored-by: Luca Palmieri <[email protected]>

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.