These maps already exist but are obscured to you. Be alert to facts that affect your projects or organization. Continually sift information out of the noise around you, e.g., a shift in corporate priorities could mean a platform you’d considered but backburnered has become an amazing investment.
The Locator Map: Getting Perspective
Time you spend absorbed in any domain increases your depth and understanding, but it comes with some risks, e.g.
- Easy to magnify the importance of what you’re working on.
- Start thinking of other technology areas as trivial compared to your rich, nuanced domain.
- Stop noticing problems as they come background noise. Do your technical decisions only make sense to people who have forgotten of the world outside your team?
- Forget what the work is for, does the goal no longer matter to the company?
Seeing Bigger
Extending the amount of the map that you can see helps your recognize if your group is a lot smaller, and if you’re far from where the action is. Without this perspective, you can’t do impactful work.
Escape the echo chamber, e.g., an infrastructure engineer might be shocked by a product engineer who considers creating delighter feature is at least as important as those features having rock-solid reliability.
Think of other staff engineers as your team. By being a part of something bigger than your own team, you’ll have a more objective view of what everyone is doing.
Understand what matters right now; the ordering will change over time. If customers are leaving because of a missing core feature, then it’s not the time to push for a focus on technical debt. Ask for skip-level 1:1s and find face time with customers or teams that depend on you.
What do your customers care about? For example, a user does not distinguish between DNS services, ISP, your CDN, or your endpoint – at the end of the day, there are a bunch of websites that work, and a bunch that don’t.
Respect what came before. Many problems are not essentially new. Study what other people have done. Your goal is to solve the problem, not necessarily to write code to solve it.
Use publications in your domain to maintain perspective and spot new ideas that you can explore when you need them, e.g., LeadDev .
The Topographical Map: Navigating the Terrain
Rough Terrain
Without a detailed map of the terrain:
- Your good ideas don’t get traction. Being right is half the battle. You need to convince other people that you’re right, and even more difficult, convince them to care that you’re right.
- You don’t find about the difficult parts until you get there. Had you known, you’d have taken a different path or solved the hardest part of the problem first.
- Everything takes longer. There are times of the year when it’ll be easier to make a case for action than others.
Understanding Your Organization
How much does everyone know? Is information currency that no one gives away easily? Are channels invite-only; how would you know what exists? Is everything open, such that you incur decision fatigue from choosing which information to consume or which documents are official?
How much writing and review is involved in decisions? Does the org prefer quick conversations where a design document longer than a page just doesn’t get read? Will the lack of a design document make you seem sloppy and irresponsible?
Top-down or bottom-up? Do initiatives that need broader support slow down at the grassroots, or come down from above missing local context? If you have a new idea, where do you need to take it?
Bottom-up organizations are prone to coordination headwinds. For a project with \(N\) people to succeed if they invest their time, then:
$$ \mathbb{P}(\text{success}) = \prod_{i=1}^{N} \mathbb{P}(\text{person i expends required effort}) $$
However, each person has other important things on their plate, or has uncertainty into the difficulty of their piece or the probable success of the project. This leads to everyone prioritizing it a bit less. \((.95)^{10} \approx .60\) while \((.90)^{10} = .35\); non-linear effects.
Furthermore, in a team of \(N\) people, there are \(\frac{N \cdot (N-1)}{2} = \mathcal{O}(N^2)\) pairwise connections that could cause friction. While escalation can help resolve a disagreement between Alice and Bob, it is a charged act, especially when there are more layers between them and the nearest common ancestor. Furthermore, the leader’s swooping in may lack nuance and make things worse for Alice and Bob.
Alice and Bob increasingly hide problems from leadership. The fastest path to action is striking out in your own direction, ignoring contrary evidence. Alice and Bob are incentivized by the appearance of heroic motion – accomplishing little in the grand scheme of things, and creating more chaos around them.
Possible solutions:
- Let go of unnecessary detail and coordination. Converging to a good enough outcome on a good enough timeline is good enough!
- Decouple things as much as possible. Aim for eventual convergence.
- Have smaller goals that are quicker to achieve; while sighting off the moon (3-5 years away), iteratively pick a roof-shot step that brings you closer to the ultimate goal, building momentum along the way.
Having a rigorous, plausible strategy that many teams can sight off takes work. Bad strategies and good strategies look superficially similar; takes years before the difference is clear. Celebrate people doing grounded, strong strategic work.
If the org moves like lightning, you’ll want an incremental path that shows value immediately. In a more deliberate environment, you’ll need to show that you’ve thought through the whole plan.
Do people in different groups talk to each other via back channels or front doors? Maybe you need to chat with a counterpart engineer in another org. Maybe you need to send your idea up until the first common higher-up.
If everyone’s allocated, then any initiative that frees up time without major investment will have the most impact. If folks are available, chances are that a Cambrian explosion of grass-root initiatives are nigh and more impact will come from choosing helping over a nascent project over the finish line.
Liquid or crystallized? Did the seniors look for promotion, or did they stay where they were, got a project, got support from the group, and got the promotion when it was their turn? Do you need to hustle for promotion? Should you move from group to group to find high-impact work?
An alternate lens: the Westrum organizational typology model:
| Pathological | Bureaucratic | Generative |
|---|---|---|
| Power-oriented | Rule-oriented | Performance-oriented |
| Low cooperation | Modest cooperation | High cooperation |
| Messengers shot | Messengers neglected | Messengers trained |
| Responsibilities shirked | Narrow responsibilities | Risks shared |
| Bridging discouraged | Bridging tolerated | Bridging encouraged |
| Failure -> scapegoating | Failure -> justice | Failure -> inquiry |
| Novelty crushed | Novelty -> problems | Novelty implemented |
High-trust cultures that emphasize information flow have better software delivery performance. More tech companies aim to have a generative culture.
Points of Interest
Fortresses gate-keep because they care about something, e.g., reliability, code quality, etc.. Know the password to pass through the fortress gates, e.g., proving a mitigation of all risks of your proposed change, completed checklists, replying to many comments with acceptable answers.
Areas of disputed territory (each group says, “Yes, as far as I know, but you should also ask…") are risky. Some areas are uncrossable deserts (e.g., too big, politically messy). You should have enough evidence to convince yourself and others that this time it’ll be different.
Efficient processes ensure that the official ways to do something are also the easiest ways. Sometimes, the official way is the way that everyone learns not to use, e.g., the one person in IT that responds to DMs, saving waiting time.
Where do decisions happen? Is it in a weekly managers meeting? A Slack channel with the leadership team? Is there no “room” at all and decisions are made with 1:1s with the most senior leader? When asking to join the room, show how including you makes your organization better at achieving its goals. Reduce the cost of including you: show up prepared, speak concisely, and be a collaborative, low-friction contributor.
Know the shadow org chart. While Jan is the official technical leader, it might be that her first move in any decision is to check in with Sam, a team veteran. If Sam doesn’t think it’s a good idea, you’ll never get Jan on board.
Proactively build bridges if the terrain is difficult to navigate, e.g., send the email summary that no one is sending; introduce two people who should have spoken a month ago; write a document showing how projects connect to each other.
When you can, define your scope to cross tectonic plates and encompass all of some system or problem domain. That way, you can catch work that is getting dropped, mediate conflicts, and help create a single story about what’s happening.
Keeping Your Topographical Map Up to Date
On an average day, you might need to know: a team you depend on has a new lead; project you’ve been waiting on isn’t happening at all; quarterly planning is about to start; a useful new platform is launching; your product manager is about to go on extended leave.
Join channels and email lists dedicated for sharing new design documents, announcing outages, or linking change-management tickets.
Walk the floor. Pair on occasional changes, managing incidents, or deploying a system that you want to know more about.
Lurk. Pay attention to information that isn’t secret exactly, but isn’t necessarily for you, e.g., reading senior people’s calendars, skimming agenda for meetings you’re not in, sorting Slack channels by most recently created.
If organization has a mature documentation culture, make time for skimming and deeply reading RFCs, design documents, product briefs, etc.
Check in often with your leadership for behind-the-scenes updates. Ensure that the way you’re thinking is still aligned with the way you’re leaders are.
Talk to people outside engineering: product, sales, marketing, legal, etc. Admins know what’s going on, and they tend to be the most fascinating people in the company.
The Treasure Map: Remind Me Where We’re Going?
Chasing Shiny Things
Thinking only about short-term goals can be limiting:
- Harder to achieve eventual convergence. Teams will either go to the wrong place, or every decision will be long, complicated, and full of discussion.
- Inability to solve bigger, long-term problems that take multiple steps.
- Cruft accumulation as teams overcomplicate solutions to accommodate uncertainties or making local decisions with high externalities.
- Multiple people trying to rally enthusiasm around completely different directions.
Taking a Longer View
No need to keep tight alignment along the way. Each team can be more creative in figuring out their own route, with their own narrative for problems they need to solve to get there. They’ll have enough information to make decision, reducing the amount of hedging and technical debt. They can celebrate wins along the way, while remembering that there is a long-term goal where the real celebration awaits.
When choosing a technology to invest in, it’s often because it’s an unavoidable step on the path to something else. You’re building a service mesh to make your micro-services framework easier to use to enable quicker setup of new services, because the real goal is to reduce time to market.
Tell the story to other people and let them understand why it matters. Show where you are, where you’re going, and why you’re taking the steps that you are along the way. Tell the story of where you were and how much progress you’ve made.
References
- The Staff Engineer's Path: A Guide for Individual Contributors Navigating Growth and Change. Chapter 2: Three Maps. Tanya Reilly. 2022. ISBN: 9781098118730 .
- Coordination Headwind - How Organizations Are Like Slime Molds. Alex Komoroske. komoroske.com . Accessed Jan 12, 2025.
How do I keep up with what’s new within Microsoft?