This is the last of the three pieces I pulled from the archive for this trip. Normal service resumes next week, once I’m back. This one is a reader favorite on getting up to speed fast in a new role.
You’re eager to make an immediate impact.
You’ve just started a new role or a challenging project, ready to dive in and prove your worth.
But instead of hitting the ground running, a lack of understanding is holding you back. Everyone around you is speaking fluently in what might as well be a different language. While you’re nodding along, you secretly grasp maybe five percent of what is being said. You feel like you should be understanding closer to eighty percent by now.
You realize you now have two full time jobs. There is the work you were brought in to do, and there is the task of getting up to speed. Both feel like they are falling further behind with every passing moment of confusion. If this sounds familiar, you are not alone. I have been there.
After nearly two decades at Amazon, operating as a Principal Engineer, often parachuting into complex, high stakes projects, I’ve developed a system to cut through this chaos. In this article, I’ll share with you that exact framework to help you get up to speed unbelievably fast.
The New Guy Trap
How does this scenario unfold?
If you are like most people, your first instinct is to gather information. You ask for every document, every link, every resource available. Soon, you face a digital mountain of material to read and videos to watch, often more than you can consume during working hours. You start at the beginning, only to find that much of what you are reviewing is outdated, irrelevant, or not applicable to what you need to understand. You realize the critical information, the context you need, is not written down.
Your next step is to schedule meetings with colleagues. After fifteen minutes of introductions, the next fifteen minutes become an avalanche of details. You try to capture notes, filled with jargon and acronyms, when someone knocks on the door for the next meeting. You attempt to schedule more time, but colleagues are busy and their availability is limited.
You then return to your notes. They are a jumbled collection of three and four letter acronyms, specialized terms, and sentence fragments. You remember understanding something about it when you wrote it down, but looking at it now, it often feels more confusing than before. “Fine, I’ll look it up myself,” you say to yourself. But you find that answering one basic question such as “What does this mean?” only leads to two more questions. As your list of unanswered questions grows, so does that feeling of falling behind.
Not All Knowledge Is Created Equal
So how do you deal with this avalanche of information and your own jumbled notes? There are only so many hours in the day. What you need is a reliable way to sort through the incoming details and filter for the things that truly matter. But how can you do that when you do not even know enough to determine what might be important?
This brings me to my core underlying principle. Not all knowledge you encounter is equally useful, especially when you are trying to get up to speed quickly. Based on the type of information coming in, you need to treat it differently. The key is to begin bucketing the information for your notes as it arrives. Let’s focus on categorizing information by its type. There are three primary buckets here. Information can be a fact, details about a process, or a concept.
Facts are true statements that describe something.
Process information explains how something is done.
Concepts are ideas, and importantly, how those ideas relate to other ideas.
It is a big mistake to treat all these types of knowledge the same. Your approach to learning and retaining them should differ based on their category.
Here Are The Facts
Let's begin with Facts. When it comes to factual information, it is useful to make another distinction. There are facts that need to be in your working memory for you to function effectively, and there are facts that you can simply reference when needed. I remember this distinction clearly from my first job at Amazon working on the "Search Inside the Book" feature around 2006. This feature allowed customers to search and browse the content of physical books online. Certain facts needed to be part of our team's working memory. For example:
The core purpose of Search Inside the Book (or SITB as we called it internally) was to enhance book discovery and improve customer experience.
All book content processed for SITB had to be associated with an Amazon Standard Identification Number (ASIN).
The content processing pipeline involved several key stages: scanning book pages, optical character recognition (OCR) to extract text, and then indexing that text for search.
We had a service level agreement (SLA) for how quickly new book content should appear in SITB after publication.
These were fundamental principles and operational realities we needed to know to do our jobs and communicate effectively. Then, there was a vast amount of factual information that we could, and should, reference when needed. These might include:
The complete list of specific error codes generated by our internal processing platform and their detailed troubleshooting guides.
The exact specifications for image quality and format required from publishers or scanning operations.
The comprehensive list of all publisher series codes that were flagged for special processing rules.
The specific server names or configuration details for the different environments like beta or production.
You would not need to memorize every single error code or server name. Knowing where our team's documentation was and how to look up these details was what mattered. For the facts that do need to be in your working memory, the key is consistent exposure and understanding their direct relevance to your daily tasks.
Tip: For those essential working memory facts, create a running list on the first page of your project notebook or a prominent digital note. Review it for a few minutes periodically. For reference facts, do not just assume you will find them again. Maintain a simple, personal directory of links to key documents, dashboards, or contact people. This habit of actively sorting and organizing facts as you learn them will pay off immensely in how quickly you feel competent.
Process: Learning the How-To
The second bucket of knowledge is Process Information. This type of knowledge is all about the HOW. It explains how you bill clients, how you check in code, or how you troubleshoot customer issues.
Now, this is different from how you might handle facts. With processes, it generally does not make sense to try and write down every single step in exhaustive detail and review it like you would a list of facts. When you are new to a team or project, the existing process should ideally already be developed and documented, perhaps as a standard operating procedure (SOP), a playbook, or a similar guide. If such documentation is missing or inadequate, as the new person, it is typically not your immediate job to create it from scratch. Your primary goal is to learn the current process, warts and all, mainly through doing.
Of course, if your role specifically includes creating or refining processes, that is a valid goal. However, you can only contribute effectively to that kind of work once you are genuinely up to speed on the existing situation, something I will discuss more later.
I saw this principle of running through procedure play out many times at Amazon. For example, software developers always carried a pager. If a critical system went down, what we called a sev-2, the on call engineer would get paged. If there was a major issue, like the Amazon website not accepting orders, it was a sev-1. A sev-1 meant pretty much everyone needed to join a call to resolve the problem quickly.
Most teams had some sort of playbook or published SOPs for people who were on call. Having these SOPs was helpful as a reference. I recall this very well from my time on call for Search Inside the Book. Our playbooks detailed procedures for common issues, like when new book content failed to appear on the website. But it was not until I was paged in the middle of the night for that exact problem, and had to personally trace the data through our content pipeline under pressure, that the deeper lessons emerged.
That intense experience didn’t just teach me how to fix that one stall. It provided real knowledge into the types of things that can cause data pipelines to break. It highlighted how to design more effective monitors and gave me a framework for how to proactively investigate and uncover potential issues before they escalated into outages. This hands on work went further than simply referencing any written procedures. Reading about how to handle a critical event is one thing. Experiencing it and working through the steps yourself is how procedural knowledge sticks.
Tip: Instead of just asking colleagues to explain a process, ask if they can shadow you or pair with you while you perform it for the first time. This active participation is the fastest way to get up to speed. For instance, a new software engineer eager to get on call quickly will find most teammates are very willing to shadow them during their first few on call shifts, providing real-time guidance and a safety net. This accelerates learning and builds confidence much faster than passive observation (and will get them a lot of brownie points with the team).
Concepts: The Real Learning Accelerator
We have covered Facts, which describe things, and Processes, which explain how things are done. Now we arrive at the third, and arguably most powerful, type of knowledge: Conceptual Information.
Concepts are ideas and importantly, how those ideas relate to other ideas. While facts give you the 'what' and processes give you the 'how,' concepts give you the 'why.' Understanding conceptual information is about building a mental model of the system, the business, or the problem domain. It is about seeing the bigger picture and the underlying principles at play. How do you actively build this crucial conceptual understanding, especially when everything is new and feels complex? The key to processing conceptual information effectively is to focus on actively constructing the relationships between these ideas. Essentially, you want to build a mental map that shows how different concepts connect, influence each other, and form the larger picture. This map becomes your framework for understanding.
Let me show the power of this with another example from my work on the Search Inside the Book feature. My time on that team was an introduction to the concept of a large scale digital catalog system. It went beyond the facts like specific ISBN formats or the process of scanning pages. I began to build a mental map of what a catalog fundamentally is, a structured system for uniquely identifying items, managing their metadata, handling different versions or editions, and making that information discoverable and useful. I learned core concepts around data ingestion pipelines, the importance of consistent identifiers like ASINs, how catalog data quality impacts search and discovery, and the complexities of mapping external data (like publisher feeds) to an internal canonical representation.
This conceptual understanding of catalog systems in general was a massive accelerator years later when I joined a team tasked with selling tickets for events like concerts and shows. The challenge was new: how should we model things like a selling Justin Bieber concert tickets in Amazon's system? Should the artist be the core item (the ASIN)? The tour? Each individual show date? Or even each seat? While the items (tickets vs. books) were different, the underlying conceptual questions about unique identification, inventory structure, metadata for discovery, and mapping to Amazon’s existing ASIN based architecture were similar to the problems I had been exposed to within Search Inside the Book. Because I already possessed that mental map of how catalog systems work, the patterns were clear. I could contribute to designing our approach for this new business far more quickly than if I had been starting from zero.
The same conceptual toolkit was just as critical when I moved to the Prime Video team years after that. They managed a vast catalog of movies and TV shows, which, while logically separate from the physical product catalog, needed to integrate seamlessly for search and customer experience on the Amazon retail website. The Prime Video org. was facing a complex rewrite of their catalog systems. Again, the surface details were different, video encodings instead of page scans, streaming rights instead of print editions. But the fundamental catalog concepts were the same: understanding vendor SKUs from content providers, the challenges of matching and merging data from multiple sources for the same title, handling errors and inconsistencies in metadata (Type I and Type II errors), the requirements for localization and globalization of content, and the profound effect of catalog structure on search relevance and content discovery algorithms.
My pre-existing conceptual framework meant I could get up to speed and contribute meaningfully to this highly complex video domain much faster than anyone might have expected. The core conceptual understanding was already in place. I just needed to learn the new domain specific facts and adapt to local team processes.
This Prime Video project, with its immense scale and complexity, and my role in leading the technical vision for the catalog rewrite, was the one that led to my promotion to Principal Engineer. This is why focusing on conceptual understanding is so powerful. Concepts are incredibly transferable across different projects, teams, and even industries. They form the bedrock of rapid learning.
You will encounter these same core concepts again and again throughout your career, just in different packaging or with a new layer of complexity. While the specific facts and processes are likely to change, the fundamental concepts within any given field are surprisingly finite. Learn about them once, and you carry a toolkit that allows you to adapt and excel wherever you go.
Tip: When building a mental map for a new domain, start by identifying what you believe is the most central concept or system. Place this at the center of your page or digital canvas. As you learn related ideas, facts, processes, or sub-components, draw them as branches from this central point, or from other related concepts if that makes more sense. Focus on labeling the connections and relationships between these items (e.g., 'is caused by,' 'is a type of,' 'depends on,' 'leads to'). This act of defining relationships is what clarifies the structure of the domain. Your mental map is a living tool, revisit, redraw, and refine it as your understanding grows. If you’re able to get time with experts, share your map with them. Walk them through your understanding. Ask them: "Does this make sense? Are the connections I've drawn accurate? What key concepts or relationships might I be missing or misinterpreting?" This will maximize your time with these busy people.
The Power of Your Questions
Throughout this guide, we’ve focused on how to acquire, categorize, and understand new information. But there is another crucial element in your journey from newcomer expert: the questions you ask. Think of your questions not just as requests for information, but as markers that define the borders of your current understanding. They illuminate the boundary between what you know and what you are still exploring.
This is why I strongly recommend keeping a running list of the questions that arise as you learn. Do not just focus on just getting the answers, log the questions themselves. Over time, this list becomes a record of your progress. Looking back at questions you jotted down weeks or months prior, you’ll find that what once seemed confusing is now clear, or even obvious.
This list of questions is also a signpost that indicates when you’re no longer the new guy. Initially, your questions will likely be about basic facts, established processes, and foundational concepts. But as you get up to speed, you’ll eventually notice a shift.
Your questions will become more nuanced, more probing, perhaps even challenging existing assumptions or exploring new territory. You will know you have truly arrived when your open and unanswered questions begin to align with the complex, open questions that experienced subject matter experts on your team are also grappling with. When this happens you are no longer just learning the ropes, you’ll be the person that others want to sync up with to ramp up themselves.
Turning "New" into Your Superpower
Getting up to speed quickly is not magic or something you’re born with. It is a skill just like anything else. By treating Facts, Processes, and Concepts, differently you’re accelerating your learning. This approach, coupled with tracking your questions to map your journey, will help you get up to speed unbelievably fast.
My hope is that by applying this framework, the challenge of tackling something new becomes an exciting opportunity. Your life will change when you lean into learning new things, rather than shying away from them.
amazing...i resonate with the concepts outlined in this article..will put this to practice
Amazing stuff! I'm going to put this in practice and share an update soon!