More on this book
Community
Kindle Notes & Highlights
by
Tanya Reilly
Read between
March 4 - March 5, 2023
By spelling the facts out and sharing them, you’re forcing the conversation (or, perhaps, the argument) into the open.
Shared concerns can be neglected because no one group has the authority or an incentive to fix them alone.
Nobody wants to delay their project for the sake of a long and painful fight to make a controversial decision or choose a standard.
Instead, groups make locally good decisions that solve their own immediate problems. Each team chooses directions based on their own preferences or on rumors about the organization’s technical direction—and
A technical vision describes the future as you’d like it to be once the objectives have been achieved and the biggest problems are solved.
The tremendous power of the written word makes it much harder to misunderstand one another.
Whatever you create, it should be clear and opinionated, it should describe a realistic better future, and it should meet your organization’s needs.
It will likely include a diagnosis of the current state of the world, including specific challenges to be overcome, and a clear path forward for addressing those challenges. It might include a prioritized list of projects that should be tackled, perhaps with success criteria for those projects.
Rumelt describes “the kernel of a strategy”: a diagnosis of the problems, a guiding policy, and actions that will bypass the challenges.
Finally, a strategy isn’t an aspirational description of what someone else would do in a perfect world. It has to be realistic and acknowledge the constraints of your situation. A strategy that can’t get staffed in your organization is a waste of your time.
Will Larson adds, “If you can’t resist the urge to include your most brilliant ideas in the process, then you can include them in your prework. Write all of your best ideas in a giant document, delete it, and never mention any of them again. Now…your head is cleared for the work ahead.”
Creating something that feels “obvious” can feel anticlimactic when you’re writing it: we’d all love to show up with a genius visionary idea and save the USS Enterprise! But usually what’s needed is someone who’s willing to weigh up all of the possible solutions,
Tech companies’ promotion systems can incentivize engineers to feel like they need to “win” a technical direction or be the face of a project. This competition can lead to “ape games”:
“Give your support quickly to other leaders who are working to make improvements. Even if you disagree with their initial approach, someone trustworthy leading a project will almost always get to a good outcome.”
Maximize your chances by bringing the potential sponsor something they want. While a proposal that’s good for the company is a great start, you’ll get further with one that matches the director’s own goals or solves a problem they care about.
Can a staff+ engineer be a project sponsor? In my experience, no, not directly. A sponsor needs the power to decide what an organization spends time and staffing on, and such decisions are usually up to the local director or VP.
Who do you want in your group? Pull out your topographic map. Who do you need on your side? Who’s going to be opposed? If there are dissenters who will hate any decision made without them, you have two options: make very sure that you have enough support to counter their naysaying, or bring them along from the start.
Aim to cover enough ground to actually solve your problem, but be conscious of your skill level and the scope of your influence. If you’re trying to make a major change to, say, your networks, you’d be wise to include someone from the networks team in the core group and to build credibility with that team.
Be practical about what’s possible. If your vision of the future involves something entirely out of your control, like a change of CEO or an adjustment in your customers’ buying patterns, you’ve crossed into magical thinking.
As you make progress on your vision or strategy, you may find that your scope changes. That’s OK! Just be clear that it has.
There will always be more information, so notice when you start to get diminishing returns from this loop.
Think big. If you’re working in a codebase that takes a day to build and deploy, it might be tempting to wish for incremental improvement. “This needs to take only half a day!” But go further than that. If you set a goal of 20-minute deploys, the teams pushing toward that goal have an incentive to have bigger, braver ideas.
Don’t waste their time or yours on things that don’t matter. If you’re getting teams to do an expensive migration from one system to another, for example, there had better be a treasure at the end. The more effort it’s going to take, the better the treasure needs to be.
Your core group’s ideas and opinions will reflect only the experiences of the people in that group. You might not know what you don’t know about what’s difficult in teams other than yours—so put your preconceptions aside and talk to people. Lots of people. Don’t just pick the colleagues you already know and like:
Thinking time is also a good time to check in on your motivations. Notice if you’re describing a problem in terms of a solution you’ve already chosen—this can be a mental block for a lot of engineers.
We start out by comparing problems to solve, but find ourselves talking in terms of technology or architecture we “should” be using that would make everything better.
ask “Yes, but why?” over and over again until you’re sure the explanation maps back to the goal you’re trying to achieve. If the connection is tenuous, be honest about that.
The reason decisions are hard is that all options have pros and cons. No matter what you choose, there will be disadvantages. Weighing your priorities in advance can help you decide which disadvantages you’re willing to accept.
One of the best ways I’ve seen to clarify trade-offs is to compare two positive attributes of the outcome you want. I’ve heard these called even over statements.
Sometimes none of the options on the table can make everyone happy. Do try to get aligned, but don’t block on full consensus:
“lack of disagreement is more important than agreement.”
In other words, take the sense of the group, but don’t insist that everyone must perfectly agree. Rather than asking, “Is everyone OK with choice A?” ask, “Can anyone not live with choice A?”
If rough consensus can’t get you to a conclusion and you’re not ready to flip a coin, someone will need to make the call. This is why it’s best to decide up front if you have, or someone else has, clear leadership authority and can act as a tiebreaker. If there’s nobody in that role, you could ask your sponsor to adjudicate, but make this a last resort.
If you realize you’ll need more information to make an informed decision, what extra information do you expect to get, and how? If you choose to wait, what are you waiting for? Remember that you usually don’t need to make the best decision, just a good enough decision.
“Don’t call for a vote until you know you have the votes,” but I was delighted to learn that there’s a word for it.
Don’t forget that aligning doesn’t just mean convincing people of things. It goes both ways.
A vision or strategy that not everyone knows is of little value to you. You’ll know the direction is well understood if people continue to stay on course when you’re not in the room to influence their decisions.
First, you’ll want to make sure the story is comprehensible. A short, coherent story is much more compelling than a list of unconnected tasks.
“When it gets difficult, everyone needs to know that the difficulties are expected,
Don’t just tell the story of the gold at the end of the journey. When there are problems, you need to be able to emphasize that this is the part of the story where the heroes get caught in the pit…but then they get out again!”
Think about how you can make it easy to read, or share the highlights in another way. Avoid dense walls of text. Use images, bullet points, and lots of white space. If you can find a way to make your points clear and memorable, more people will grasp them.
technical terms they don’t know. You may find it useful to have a second type of document to accompany the one that you’ve written.
What’s the difference between your document being yours and the organization’s? Belief, mostly. That starts with endorsement from whoever is the ultimate authority for whatever scope your document needs.
An officially endorsed document gives people a tool they can use for making decisions.
Be prepared to revisit your document in a year, or earlier if you realize that it’s not working.
You start out by chatting with two staff engineers who have taken a run at rearchitecting the monolith in the past.
The second pattern is that everyone is focused only on the technical problems. There are lots of technically sound ideas, but no plans for how to get the organization to buy in to a path forward.
Some of your colleagues are underwhelmed (and, perhaps, a little angry): your document isn’t more “visionary” than any of the ideas they had; it’s a little boring! Some insist that this problem didn’t need a strategy; you just needed to “just decide” what to do, and this path was the obvious decision.
The grumbling doesn’t change the plan.
A technical vision describes a future state. A technical strategy describes a plan of action.
