How Indexing Information Can Make You a Better Engineer
Switching to a new team as an engineer can be challenging, especially when it comes to finding the information needed to be productive. Rather than memorizing vast amounts of data, index it.
Earlier this year I switched teams and I had to learn how to work in a new environment.
What does learning mean if I’m an engineer with experience?
The biggest challenge I found was where to find the information I needed to be productive.
I was used to a certain structure when working in my previous team. I knew all the ongoing initiatives, team structures, projects, and even the progress of those projects.
Now I knew nothing. I’m the same engineer, stripped of all the information sources and thrown into a new environment.
I realized the importance of all the internal emails where teams shared their roadmap and their progress on their deliveries. That information is an enabler for us to function as engineers.
🛒 What are the information sources?
👯 What teams are there and what do they know
When first joining a new organization, you must understand the technical architecture.
Engineers operate those systems and processes. And there are many ways your teams can organize themselves around those systems. Examples could be Amazon’s 2-Pizza-Team model or Spotify's Squad model.
You inevitably interact with other teams. When you investigate issues in production, when you work on a new project, and even when writing a postmortem. Creating a map of the teams always helps.
🖼️ Business roadmaps, project backlogs
Companies want to make money. There is a piece of their resources they invest in keeping the business running. And another piece of resources they invest in making more business, better business.
For the former, you need to understand what are the processes to keep providing service to customers. For the latter, you need to know what are the goals for this year or quarter, and how will business people come to engineering with their requests.
It varies depending on the business. For example, until joining Ring a business goal was never launching a new device to the market.
You are never alone doing your piece of the feature. You’ll need to interact with other teams and knowing how to track their progress on their delivery will help to deliver yours too.
📚 Technical documentation and source code repositories
Source code is king. Documentation falls out of date, and conversations with people are error-prone. But checking the code and seeing a commit description rarely lies.
It feels discouraging to not have visibility over other teams' work because you don’t know where to find the information. You end up relying on what some people remember rather than checking by yourself the source of truth.
If your company’s code is in multiple source repository platforms, identify them and get access to them.
📊 Metrics and operational dashboards
Your production systems rarely work in isolation. An increase in errors or latency of a dependency will impact you.
While it’s important to monitor from your side, you’ll have less detail than the owning team.
Have at hand their operational dashboards, they will help you understand the bigger picture.
🚨 Issue tracking systems and engagement process
You are not a hero. You may be able to troubleshoot things in your systems, but you won’t understand things in other team’s systems.
The best way to troubleshoot anything would be to ask the owners. Or even better, check what the owners are working on.
I had bookmarked the on-call ticket queue of my primary dependencies in my previous team. If something was looking off, I would go to the ticket queue to see if someone already reported it.
There are many ways to engage a team: Message the on-call, engage in a public forum, create a ticket in the on-call queue, page the on-call, go to office hours…
👀 Why pay attention to this?
Because being a “go-to” person is not about knowing everything about your company. It’s about being able to point them to the data or the person who can solve the problem better than you.
Because you are connecting ideas and doing critical thinking. You don't waste time memorizing details your memory may alter, creating hallucinations.
Because you understand how to serve the company better as an engineer. You understand the big picture, and that makes your work more fulfilling.
Because you reduce stress. You still don’t know everything, but you know you can sit down and get the answer to anything. You become more autonomous because you solve your problems. It’s not the same finding the right person and asking about the problem as asking random people because you have no idea where to start.
🎯 Conclusion: How I index sources
Let’s say you have a functionality called User Registration. I would pick the acronym UR and I would save in my browser bookmark relevant pages like:
UR main wiki
UR user flow diagrams
UR technical architecture
UR intake process
UR office hours
I use Alfred as a replacement for Spotlight in MacOS and now just typing “UR” I have access to all relevant sources I saved myself.
I have the entire company at my fingertips thanks to a careful indexing of sources.
🗞️ Other articles people like
👏 Weekly applause
How to get promoted: Lessons from an ex-Amazon VP by
. I agree with Jordan here that the hardest parts about a promotion are not doing the work. The hard parts are setting the preconditions for doing the work: Understanding what’s holding you back, what are the datapoints you are missing, adapting to manager and team styles…I am not a fan of heroism in the engineering industry by
. Software is more complex than a single person can handle and thinking otherwise only leads to burnout.- . Adopt an strategic compromise mindset instead of trying to win all arguments.
The Anatomy of a Successful Team Squad by
. An article about the squad model of Spotify
I discovered that I'm a big note taker, if I have some place to put the notes. So for me, I got into Obsidian. I write pretty much everything down, use tagging where I can, and the search function in Obsidian helps me find what I need quickly.