#9 The Two A's Framework 🏗️

Engineer's Guide to developing the Archaeologist and Architect Mindset

Early in my career, I saw (and made) the mistake of jumping into some technical decisions without fully understanding the problem at hand. This often happened either because people, including myself, thought we knew “everything” needed to solve the problem, or because we were pressured by time constraints to come up with a quick solution. The latter is especially common in technical interviews.

I've conducted 90+ interviews in the past 4-ish years and I have seen many candidates rush into making decisions during system design interviews. My friends and I have shared stories about times when we accidentally rushed to a specific solution or maintained complex solutions without considering simpler ones (no KISS principle there). And the list goes on.

Situations can vary a lot, but they all share a common issue: A weak decision tree.

Engineers face many technical decisions and are responsible for “building their own decision trees” before entering the design or implementation phase. If they don’t have a strong decision tree, chances are they’ll end up making suboptimal decisions, leading to unwanted maintenance or potentially exhausting sacred resources like time, budget, or developer effort.

For example, which one is more “awkward” or harder to maintain?

1. Designing an “okay” internal app for 10-20 users? Or

2. Designing an “okay” real-time analytics platform for 60,000-80,000 users?

At each decision point, there is a risk of either:

• Not solving the right problem (i.e., building the wrong thing), or

• Solving a future problem rather than today's problem (i.e., over-engineering).

That’s where the Two A’s comes in. In this post, I'll introduce the Two A’s framework and explain how we can apply it to both our daily work and technical interviews, using a system design interview scenario.

---

What is Two A’s?

Two A’s is short for Archaeologist & Architect. The framework is simple. As an engineer, whenever you’re working on a problem, there are two hats you need to wear, in the following order:

1. Archaeologist: Ask clarifying questions until you reach the core value.

2. Architect: Design a solution for that core value.

---

I. Archaeologist

As an Archaeologist, your role is to dig into the problem by asking clarifying questions until you understand exactly what needs to be solved. You’re “building your own decision tree” so you can leave the room and focus on building a solution for the core value that stakeholders are waiting for.

As a rule of thumb, you should not take a generic problem at face value. If you’re in a room with clients or stakeholders and they tell you they want X, ask clarifying questions to narrow down the problem space to a specific pain point, XYZ. If you’re not sure what they meant when they said Y, communicate with them. Make sure you understand what’s being asked and highlight any engineering risks associated with it. If it takes some time to identify and share the risks, so be it.

Remember, you’re not only an executor (i.e., a coder); you’re also a problem solver. You help others figure out the solutions they need. Users often tell you what they think they want, but may not know what they actually need.

Notice the no parking sign? Don’t stop until you have all the answers you need to start the engineering work. Make sure everything is crystal clear before you leave the room. Sometimes asking clarifying questions can shift the conversation from solving one problem to another.

---

II. Architect

Now that you’ve left the room with all your questions answered, it’s time to wear the Architect hat and start building!

You have a clear vision of the project’s goals, timeline, and available resources. It’s time to focus on designing / building the solution. Depending on your role and the situation, this might involve one of the following:

• Write a design document to share with your team or leadership to get buy-in.

  • (more on this in a future post).

• Build a small prototype and present it to your stakeholders.

  • (Think MVP here)

• Develop the actual solution (if it’s a small one) and ship it.

  • (For Scrum folks, think of it as a sprint)

Now, let’s see the Two A’s in action, before and after a system design interview.

Picture the following scenario: Alice, the interviewer, and Bob, the interviewee.

Scenario: Bob’s System Design Interview

Alice: Hey, I’d like for you to design YouTube.

Bob: Uhhh, sure (😱). We’ll need a blob storage for storing the videos, a PostgreSQL database for storing the metadata… and maybe another database for the comments section.

Alice: Wait, why do we need a PostgreSQL?

Bob: Because its a relational database.

Alice: Okay… but why do we need a relational database?

Bob: Because it’s “great” for storing the videos’ metadata.

Alice: Okay, let’s take a step back. Could you tell me more about the data model you want to store? Also, don’t worry about the comments feature; this is out of scope.

Do you see what happened? Bob jumped into wearing the Architect’s hat and started designing things, while Alice now has to wear the Archaeologist’s hat and keep asking him for clarifications.

Now let’s playback the same scenario using the Two A’s framework.

Bob The Archaeologist

Alice: Hey, I’d like for you to design YouTube.

Bob: Sure. *pauses for few seconds* Just to set the scope, I have some questions:

• What are the core set of features our YouTube must support?

  • Can I assume the system only requires video uploading and streaming?

  • Can I assume that comments, likes, and monetisation is out of scope?

• How many users do we expect to use the system?

  • Is it fair to say around 10K daily active users (DAU)?

• How many videos do we have?

  • Can I assume our system has ~100K videos and new ~10K videos every year?

As Bob asks for clarification and communicates his assumptions, he is able to narrow down the massive YouTube system into a minimum viable product (MVP) for a streaming platform that he can now design.

Bob: Okay, based on our discussion, here is the list of requirements I have to design our system. Does that look good?

Alice: Yes, sounds good.

Quick Interview Tip: Voicing what is in / out of scope highlights your product thinking skill 🌟

Bob The Architect

Bob: So based on the requirements, here’s my design proposal. The system has two flows: (1) user upload flow and (2) user watch flow. Let me walk you through each of them.

Sample Design (feel free to ignore the writing)

Since Bob did the legwork by gathering all the information he needed, he was able to sketch out a design for the core value that Alice wants. He can walk-through the high-level design, and go into the details when needed. As an Architect, he did his homework by designing a specific solution for that specific problem.

---

Conclusion

• Two A’s framework is a powerful guide for approaching technical problems. This can be applied for both your daily work and technical interviews.

  • Archaeologist: keep digging until you reach the core value.

  • Architect: design only to serve that core value.

• Two A’s help you make better decisions, and the bigger the decision, the more critical it becomes for you and your team to manage its complexity.

• Take some time to fully understand the problem before solving it.

• Users will come to you with problems, and your role is to ask clarifying questions to pinpoint the exact issue they want you to solve.