The following is my guide on “The Method”, or if you prefer “Executing changes in modern SaaS organizations with over 100 engineers”. I have had quite some success executing such projects in my last workplaces of Miro and VanMoof and typically they included some change that 5 or more other teams need to consent to, review and adopt.

The approach is heavily inspired by the principles of Sociotechnical systems. In short, to instrument change you need both technical and social (or organizational if you prefer) work.

This process assumes you have no direct authority over others (you can’t order them), so it relies heavily on building influence and consensus. If you can just order other teams to do your bidding you probably don’t need this method (though I sure do hope you use that power carefully).

0. Principles

Before we begin, let us lay down the overarching principles that make all of this work.

Types of work and organizing it

The actions here are expected to be carried out by a team, not an individual, though it’s quite possible an individual will probably be driving them more than anyone else.

You will notice that this includes actions that are often done by EMs and PMs. You may be surprised at this. Some may even look to hand these actions over to someone with that title. As a staff engineer (or an aspiring one) being able to perform this work is in my opinion essential. This commonly maps to the Tech Lead archetype.

While it is really helpful to have some EMs/PMs alongside you, ideally you want to have them in a supportive capacity, rather than offload your work to them.

Figure out whether to keep or drop this

  • EM/PM work:
    • Book meetings with other teams
    • Prioritize work
    • Manage meetings
    • Check-in on your team members (and often)

The usual project landmine

The single, literal, worse thing that can happen to your project is this sequence:

Right before you get to implementing, a domain expert with high credibility (e.g a Staff Engineer working on similar projects) becomes strongly opposed to one or more of your ideas. It doesn’t really matter whether their arguments are valid or not. The conflict and division created makes people choose sides. It is now extremely hard for you to make any progress, and even if you do, it will often burn bridges. Your best bet is now to build only a safe subsection of your original vision, and kick the can down the road for the rest.

You may read this and scoff: “Oh that’s just ego and lack of teamwork”. Understand that people often grow into domain experts because they care about a topic. They often have strong opinions on it. These people havee built the things you wanna replace. The most common root cause of how that happens is: someone shows up with a new vision for how to do X that hasn’t consulted the existing experts, and the project appears to have the backing to go ahead. This makes everyone instantly defensive and territorial.

I have seen this happen to countless good projects, that then end up mired in organizational conflict. It has never really happened to any of my projects. A lot of the practices in this method are chosen to eliminate the possibility of this scenario happening at all.

The way you avoid this scenario is by making sure you:

  • Engage every domain expert from early in the project
  • Make those experts feel heard
  • Make sure they see how their ideas morph into solutions, or why you opted against that
  • Involve the experts in reviewing and implementing these solutions
  • Credit the experts appropriately and generously
  • Have a massive public paper trail to point to in case someone comes out of the woodworks with strong disagreements late in the process

Open collaboration

In conferences, we often use the Pacman rule: Always keep space open for someone to join you (and make it explicitly clear they can join). The same should apply to your project.

In practice this means that you explicitly invite folks to help if they want, and there should be space for them to jump in and:

  • offer feedback
  • propose projects
  • help implementation
  • try out solutions

You will find that relatively little folks will actually follow up your offers. They have their own work to do after all! Yet the help they provide will be welcome, and often address completely blind spots. Additionally, your constant openness helps avoid the aforementioned landmine.

When people help you out, make sure to publicly credit them. This rewards the folks who offered you their time, helps show how open and accepted your project is, and also encourages more folks to contribute.

Communication

  • There are different groups you will need to engage with throughout this journey. You need to connect with each in ways that work for them, and that achieve their goals.
    • Perhaps link the sales segment from the 10 years presentation
  • Vibes
    • You need to make the project engaging to engineers, look cool, fun, or solving a problem everyone suffers from
    • You are selling to engineers first, so that when you inevitably need to sell to their EMs, their engineers are on your side
    • Tell engineers about the problem you are solving for them
    • If you need other teams to engage with you for work ALWAYS frame this as you sitting with them. You don’t send a guide (however good) and tell them to follow it. You write a guide, you book a meet with them, you share your ask, and you offer your complete time and attention - we are doing this together
    • Share some links here
  • NO SURPRISES
    • When people see a solution you build they should identify their input
    • People should know what comes next, even expect it

When communicating with the org at large, always keep in mind that people have jobs to do, and those jobs usually aren’t your project. It will always be a struggle to get and hold their attention enough to deliver your message.

  • In your public messaging ensure that you waste 0 words on vague or unnecessary meaning. A couple repetitions are okay, as long as they reinforce a single key message. Respect people’s time.
  • Try and adopt a single consistent theme in your project. I’ve done Matrix, car engines, movie clips and many more. Sticking to a theme will make your messaging more memorable.

Recap

If you like bullet point lists, here’s our list of principles:

  • Expect to wear multiple hats
  • Talk to every expert early, keep them in the loop
  • Overcommunicate
  • Stay open to help and explicitly let people know how they can help
  • Talk and sell differently to different folks

Process

tl;dr:

  1. Connect with existing experts and documentation
  2. Establish authority by becoming a domain expert
  3. Propose solutions, get them reviewed
  4. Build solutions alongside client #1
  5. Advertise the impact on client #1, sell the success
  6. Engage with other teams to make sure they are onboarded to your solutions

Process list:

  • Announce you’re looking into the thing
  • Assemble other interested folks
  • Collect all the previous knowledge in the space
    • Catalogue this knowledge, extract signal from it
    • Share the signal consistently and often! Reference it! Highlight the people
  • Meet
    • Meet all of the previous folks that were involved in the space
      • Gets their input, but also shows respect
    • Meet folks affected by the problem
    • Put out open calls for people who want to join you
  • Weekly public updates, show progress
  • I try really hard to avoid having a public opinion on solutions until it’s solutions time, because otherwise people may be turned off from contributing their inputs
  • Announcements
    • Short updates to developer channels when you hit milestones
      • Has to be fun, engaging, think TikTok short
    • Mid-length updates about the project in spaces like “Tech Talks” (if your company has them), internal blog portal, or internal docs portal - think 10m YT video or good article you saw in Medium
    • Writing your own story - around project closing it’s good to create a single artifact that covers the whole timeline in an easy to consume format and that’s built as a story:
      • There was this problem
      • No really, it was a problem
      • This group of folks banded up to fight it
      • Oh no! A problem!
      • We defeat the problem
      • Things are getting better
      • People saying things are better
      • Numbers showing things are better
      • Thanks, we look to the future now

Groundwork

First contact

Scaling

Closing