Hey!

Welcome back to another week of musings.

I hope you had a great weekend! We're starting March, and I'm spending the next 2 weeks in Tokyo. So issues might be irregular for the next two, hopefully not!

Was this forwarded to you? You can subscribe here!

Things I enjoyed in the past week

• My Personal Skills for AI-assisted Node.js Development by Matteo Colima, I always like looking at people's skills, since they're the only re-usable construct at the moment, but also what people care enough about to make a set of instructions for it.
• Lessons from Growing a Software Leadership Team is a good summary and set of notes from Thiago Ghisi's presentation at QCon London.

I was recently thinking about the quote: "If you want to go fast, go alone. If you want to go far, go together."

I was trying to drive adoption of a change mostly by "being a good example," and I realized that was not enough. I was not managing to get through to all the teams.

If you've tried to do transformations in a large company, you've probably seen this too. Everything becomes a game of priorities, backlogs, planning cycles, and competing roadmaps. You hear "next month," "next quarter," or "let's revisit in the new year."

After a few rounds of failing at this, I wanted to write some lessons and share them with you!

There is no one-size-fits-all transformation

One of the quickest lessons I learned was that a single way of presenting or solving won't work with all teams and individuals.

Some teams can move quickly if you give them a working prototype and a short checklist. Some teams need deeper engagement because their constraints are real: staffing, compliance, legacy coupling, release schedules, and support commitments.

Pragmatism means knowing when to go fast

Sometimes, the most pragmatic move is to go fast and do parts yourself.

That can look like:

• Building a proof of concept to reduce abstract debate.
• Writing a migration path doc with explicit phases and decision points.
• Calling out risks early, including what could break and what a rollback would look like.
• Creating examples that teams can copy instead of asking them to start from scratch.

While there's a bit of my ego in doing things alone, "I can do this faster myself", there are also people who need to see it to believe it.

Pragmatism also means investing to go far

Other times, like in my original example, one person doing the thing will never be enough.

If you want broad adoption, you usually need to support others:

• Office hours where people can ask concrete migration questions.
• Brown bag sessions to explain the "why" and "how."
• Written docs for migration paths, known risks, and common pitfalls.
• 1:1 conversations with key people who can unblock teams.
• Team walkthroughs to help them map the change to their actual systems.

This work feels slower, but it pays off! You are not only moving one project; you're building your organization.

Keep the message consistent, adapt the framing

Your message should stay consistent: what the vision is, why it matters, what success looks like, and what tradeoffs you're making.

But the framing needs to be adapted for the audience.

With peers and ICs, details matter: migration mechanics, risks, compatibility concerns, operational impact, and the amount of work this adds.

With senior management, the framing is usually higher-level: expected outcomes, risk exposure, required investment, confidence in the timeline, and how progress will be measured.

Also, show up consistently. Share progress. Share blockers. Own mistakes when they happen and course-correct in the open. Most of the time, showing up makes people know that there's someone behind this project.

Learn how people process change

Technical transformations are still people transformations.

Two books that helped me think better about this:

• Thinking, Fast and Slow by Daniel Kahneman
• Switch: How to Change Things When Change Is Hard by Chip Heath and Dan Heath

Both helped me understand resistance with more empathy. What looks like stubbornness is often uncertainty, cognitive overload, or fear of local risk.

When we design change with that in mind, adoption gets a lot more realistic.

Your turn!

When you've had to drive a transformation, what worked better for you: going fast first, or going far first? Let me know your thoughts by replying to this email!

Happy coding!