The Program

In the previous post, Building in Public, I outlined the current state of my life and where I aim to go. I looked at my work history and skills, and defined “The Stage” – the venue where future goals will play out. As a follow up, this post expands further upon that idea, defining “The Program,” and the next will define “The Script.”

I'm making all of this up as I go, but shamelessly lifting the language of theater feels intuitively like the right framework for grounding a very abstract process. In theater, brilliant creative and logistical minds work tirelessly, often unseen, to bring a concept to life. The "Program" is the run-of-show. It’s the logistics, the cues, and the underlying mechanics that ensure the performance happens.

Thinking through what goes into a theater production, there are 1000s of hours spent both front and back of house bringing the show to life. While the outputs are slightly different – a creative piece should be a good mirror from which to emphasize problems, versus solving that problem – the goal is the same: delight and surprise the audience. The fact that both worlds use the word “company” for the entity nails the similarities perfectly. Both sides rely on talented teams, experts in their specific fields, and shared responsibility to reach goals together. The script covers the idea, the program covers the waypoints, the stage is where it all plays out, and the actors (behind the scenes, ushering, or actually acting) make it happen. This is exactly why I think this is a perfect framework to start from. If the stage is the “where,” then the script is the “what” and the program is the “how.”

The Program is my operating system. It consists of four layers, moving from the abstract to the concrete:

1. The Primitives: The mental models.
2. The Strategy: The planning tools.
3. The Processes: The decision-making frameworks.
4. The Foundation: The technical infrastructure.

The Program

The goal of the program is to define my approach to building. This is the “how.” Going in blind here, right now this is just a set of tools and strategies that I've found useful in my previous lives. The primitives – the lowest level examples of these tools – are very conceptual: loops, maps, and augmentation. Each informs how the framework fits together and works internally. Built on top of these tools are higher level practices and processes, some of which are shamelessly swiped from previous employers. Things like PRFAQs (Press Release/FAQs) and Mission/Vision/Tenets, two Amazon-specific writing tools that aid in working backwards from the customer and then working forwards from the customer's goals. Even higher up the stack are mindsets and perspectives: service-oriented hospitality, one-way vs two-way door decision making, building vs buying. Like the software stack, each level builds on the previous while still communicating up and down. And, this is where it gets absurd, that process is in and of itself a loop.

The Primitives

Loops (Iteration)

The idea of the loop is the same as the idea of iteration. Given a set of inputs, some process occurs, and an output comes out. Iteration is a core component of building a company, and the loop is the lowest level definition of what that looks like. In software, time is spent closing loops and tightening loops, and when features are built sometimes new loops are required. Loops are inescapable, and in the same way that computers rely on loops to define context for problems and process data, the script and the program are forever intertwined in a loop – a feedback loop, where each iteration informs the next.

Maps (Context)

Maps are tools, part of the program, conceptually telling us where things may end up, in turn informing the how, in turn informing the what, and circling back to the beginning to start the loop over again. There are actual, honest-to-god, geospatial maps that do this literally. There are mind maps and concept maps. There are product roadmaps. In software, maps are data structures ultimately providing a “schema” that will influence how a product behaves and how it gets built. Ever since reading The Hobbit as a kid and staring at the map of Middle Earth for hours, I've been obsessed with maps.

Augmentation (Force Multiplication)

Augmentation, interchangeable with force multiplication, is the idea that certain processes by nature can amplify their inputs and generate more powerful outcomes. This can be the catastrophic failure of a bridge where the actual forces are amplified as individual members fail and result in actual destruction, or something like fission where the process of splitting atoms results in huge amounts of efficient energy generated relative to the inputs. AI is a force multiplier, and smart people thinking strategically about levers and inflection points is too. Even thinking about it in terms of “lenses,” like I'm using often as a stand-in for “perspective,” can focus energy into a laser. Force multiplication is a tool that encourages me to think about where I can focus the smallest amount of energy to generate the most impact.

The Tools

When shifting thinking towards more long-term and strategic goals, two peculiar Amazonian practices help lay a strong foundation and “north star” guides that work backwards from a desired customer experience. These are PRFAQs and Mission, Vision, Tenet documents.

The PRFAQ

The PRFAQ (Press Release/Frequently Asked Questions) is a long-ish form written document that envisions a product press release and a set of frequently asked questions that any ICP (Ideal Customer Profile) or user persona may ask. These documents start with the customer – what is being released and what is it solving – and capture a product or feature that addresses the customers' goals. The initial press release serves to identify the ultimate launch goal and will in turn become a technical roadmap for delivery. The FAQ section, impossible to complete without ICPs and personas, forces authors to shift into the customers' perspectives, which helps ensure that the proposed launch will actually solve a problem and that the author has thoroughly considered the needs and features to achieve that.

Mission, Vision, Tenets

Another very Amazon process is the reliance on Mission, Vision, and Tenets documents which act as a similar future-forward strategic foundation for organizational roadmaps. Each of these is a discrete artifact, focused on specific aspects of organizational vision. A mission statement captures the reason the organization exists at all: it covers the day-to-day activities, the present state of the org, and is focused on the near term future. The vision statement applies the mission statement and describes the long term vision of the organization. The vision is aspirational and defines what the organization will focus on over a period of years, which will inform product roadmaps and strategy. Tenets serve both of these, and act as guiding principles for all contributors within the organization.

These are two very distinct writing tools that I would like to use when defining what this company and product do, who they serve, and why they exist. There will be many more to add here but these are two that I know now that I will use.

The Processes

In service of the more tangible tools listed above, the processes focus on “soft” tools: perspectives, mechanisms, and strategies that will be used as frames from which to view problems. These come from my previous experience in the service industry, as well as working as an engineer at startups and larger companies. Much of that work includes defining processes, and these can be seen as processes for building processes.

Hospitality

One of the most important perspectives is service-oriented hospitality. The customer may not always be right, but their satisfaction is more important than anything else. White glove service is the lowest bar, and no single person is above getting into the weeds to make a customer's life better. This is ownership of not just a product, but the full end to end experience of using that product.

High Velocity Decision Making

In addition to a strong spirit of hospitality, maintaining high velocity decision making is very important. Many decisions are reversible, and the art of finding data with just enough fidelity to make an informed call is extremely important. If a decision will bring irreparable harm to people or products, it's not reversible, and will need dedicated time and focus to ensure the safest and most hospitable outcome. Part of this process involves “disambiguation,” which is another important component in diving deep into problem spaces and being able to chart a course and create a plan that makes smart trade offs. For the vast majority of decisions we make every day, they are all reversible – I can choose to get onto a subway train, and if it's delayed I can change trains. I can check a map to confirm that other trains exist, and I can disambiguate the potential routes (maybe a bus is better?), but at the end of the day the specific train does not matter. If I want to build a tool that fundamentally alters a customer's experience of something – maybe for some reason I need identity verification, or I want to kill off a scheduled email – these can be one-way doors.

The Foundation

While there is no need to overengineer initially, there are some key things that I do want to do right off the bat to ensure that when we need to push the lever to start scaling, things are built in a way that makes that easier to start doing when the time comes:

• CI/CD set up to deploy code to three different environments (development, staging, production) on each push.
• Unit and Integration tests before merging PRs
• Infrastructure as Code modeling and wired up to CI/CD
• Domain-Driven Development and a clear separation of concerns for front and back end services
• Security and FinOps from Day 0
• Repeatable processes, codified where possible

These few bits of effort "shift left" some of the core considerations when building: deployments are fast, constant, and repeatable; changes are safe and will not break existing features (and cost money and trust); guardrails prevent manual errors; isolation between "domains" makes for a safer and more intuitive developer experience; security and cost are the highest priorities behind the product itself; everything must be repeatable.

These decisions cover many of the inflection points that come up in scaling later, and create a strong foundation for one day adding more than a single developer. For now, nothing needs to be super modular or extensible, but we can build in such a way that leaves the door open to truly expand. In future posts, I'll expand upon each of these points more in depth, but for now this is the engineering core. And it's totally irrelevant without a problem to solve.

Hospitality, decision making, and problem solving are all intertwined, and keeping these tools as core pieces of a larger framework ensures that we are always keeping potential customers as the number one priority.

What's Next

The Stage is set. The Program (the execution engine) is defined.

Now, we need the most important piece: The Script.

The execution engine is useless without a problem to solve. In the next post, I will walk through the process of finding that problem, auditing industries, and defining the "Wedge."