Ryan Scott Brown

I build cloud-based systems for startups and enterprises. My background in operations gives me a unique focus on writing observable, reliable software and automating maintenance work.

I love learning and teaching about Amazon Web Services, automation tools such as Ansible, and the serverless ecosystem. I most often write code in Python, TypeScript, and Rust.

B.S. Applied Networking and Systems Administration, minor in Software Engineering from Rochester Institute of Technology.

When the Tide Goes Out

When the tide goes out, you find who was swimming naked.

As AI has rocked the software industry, I’ve realized how lucky I was to come up when I did. Nostalgia is a shining patina on the past, but if I was starting my career now I would have an unbelievably hard time getting motivated. I was proud to write awk and sed off the dome, of my annotated copy of Regular Expressions (3rd Edition), and building the perfect zsh/vim/git configs. The things I built (mostly) failed because I believed every problem could be solved with the judicious application of the right software.

The craft was my on-ramp to software engineering, and learning the warts and internals was an end in itself. Little did I know, I was majoring in blub studies.

Blub studies is a never-ending treadmill of engineering know-how. It’s the fiddly technical details of … why pip install failed this time. It’s what goes on inside the boiler rooms of your computer. There’s a seemingly infinite amount of it, full of bespoke details for you to stumble over …

I loved blub studies.

Systems Are What They Do

I was recommended this Outcome Engineering, and I realize that the pre-LLM world took so much for granted. In the beginning of my own career I saw building as an end itself. I was blessed to join tech when there was time to learn the dog wagged its tail not the other way around.

Except it was never about the code.

Code is just the incantation transforming computation into magic. The mechanism to deliver an idea. To experience the impossible.

Unleashed, agents remove the constraints of time and human bandwidth. Creation is now limited only by the cost of compute, not capacity. No more passively moving tasks onto backlogs rather than truly exploring the merits.

This is outcome engineering

When you put it that way, duh! It used to be extremely visible when building was happening for the sake of building because it always happened at human speed. Now that capacity for certain has turned from a time to a cost (or 5hr limit…) constraint it’s easy to lose track of the goal.

The tail can now wag the dog at unprecedented speed!

Changing capabilities make it easy to get focused on the tools and forget why you’d want them.

A Long Digression: What Created Tech?

Oh, to recapture the innocence before I grasped the terrible meaning of “the purpose of a system is what it does.” I believed the cybernetic dream of the user-agent: software exists as a tool to improve lives. I was deeply naive to what we now call a zero-interest-rate phenomenon (ZIRP). Before Claude Code could spit out code faster than any human can review, my love for the craft was enough to guarantee a livelihood for me while I learned.

I thought The Cloud was going to be the big wave of my career. AWS turned 20 this year, and most companies still don’t understand how to turn pay-per-use software into a real business. In 2015 serverless seemed transformative: if only you know your COGS, you can scale all the way out to the marginal transaction. I thought there would be a new wave of companies like A Cloud Guru: born serverless, agile, and laser-focused on value engineering.

Up to that point, I thought software would be the forcing function to pull middle-men out of the chain. Given a DIY guide to selling their house and access to Craigslist, who would pay a Realtor™️ to do it? Keep your 6%!

But the Uber for Everything didn’t exist to cut out middlemen, it was ushering in a new generation of middle layers. Two-sided marketplaces were the venture capitalist dream: convert a capital investment in software into a perpetual 25% skim of whatever (housing, transit, lending, delivery, massages, pet sitting, ANYTHING) you can slap an app on. Software engineers were paid a portion of the future profits up-front to build the infrastructure of the new middlemen. Uber was the defining 2010’s company, lavishing their software engineers with perks while breaking local laws. Instead of changing, they’d leverage crumbling transit infrastructure worldwide to make their customers pressure local leaders to let them do it.

Now connect the dots: I thought my career was about making the world smarter, software-enabled, and more refined. I was naive and should have known better. Technology is just a tool, and if you think it’s neutral then you’re a tool too (past me). I didn’t focus on outcomes until I was 25.

And Then What?

All this to say, engineering teams need to take a hard look at what they actually do. Listen to the hype around “Forward Deployed Engineers” embedding in new parts of the business and seeing the daily work of their users. When engineering time was the bottleneck, layers sprung up to protect engineers from interruptions.

Times have changed and it’s time to change with them. You have more time to listen and search for the right thing to build. Go forth, break down a silo and walk in a green field. There is less reason than ever to hide behind layers of program, project, and product management and work in the abstract. Go work with people, study the blub of whatever industry you want to work with.

I don’t know if I would make it into tech today without the drudgery and detail that made it such a fun puzzle. I can’t imagine trying to start when the siren “just a little prompt” song of coding agents promises to let you skip the struggle.

The productive struggle is where the learning is.


Appendix: 16 Principles of Outcome Engineering

These are directly copied from o16g.com on 2026-05-20 because the animations make my laptop heat up.

Part I: The Goals

01 The Voyage: Human Intent

Agents explore paths; humans choose the destination. Do not abdicate vision to the machine. Create with mission, goals, and authorial intent. We decide where we are going; the agents get us there.

02 The Truth: Verified Reality is the Only Truth

Code is a vanity metric; vibes are not tests. The only truth is the rate of positive change delivered to the customer. We grade agents not on the lines they write, but on the binary reality they verify. If we cannot predict, measure, and prove it worked, we failed.

03 The Teamwork: No More Single Player Mode

Chat is a bottleneck, not an API. Whether humans or agents, outcome engineering is a team sport. Define the protocol for debate, decision, and delivery. Ambiguity in coordination is a system failure. Foreground all the debates formerly hidden by the backlog.

04 The Liberation: The Backlog is Dead

The backlog is a relic of human limitation. Never reject an idea for lack of time, only for lack of budget. If the outcome is worth the tokens, it gets built. Manage to cost, not capacity.

05 The Joy: Unleash the Builders

We are architects of reality, not typewriters. Write code only when it brings joy. Delegate the toil. Never again let implementation details, integration, or time block exploration and creation.

06 The Map: No Wandering in the Dark

Never dispatch an agent without context. Map the territory before building. If you don’t know where you stand, you cannot calculate the path to the destination.

07 The Tech Island: Build It All

In an agentic world, code is the cheapest resource. Build to answer questions. Build to test hypotheses. Build to inform debates openly. Build the things you used to buy so you can prove they work perfectly for you. Take every opportunity to get better at knowing you can deliver the outcomes you want.

08 The Artifacts: Failures are Artifacts

Opinions are conjecture; outcomes are data. When an outcome fails, do not simply rollback. Dissect the failure. Understand why the hypothesis was wrong. Debug the decision, not just the code.


Part II: The Building

09 The Orchestration: Agentic Coordination is a New Org

Scaling agents mirrors scaling people, but faster, weirder, and harder. We design the organization chart and employee handbook for the swarm. We engineer against the infinite spins of indecision and the echo chambers of model groupthink. We build the structures that keep a massive, tireless workforce aligned, decisive, and sane.

10 The Law: Code the Constitution

Don’t fall victim to decision fatigue or paper over poor architecture with checkpoints. Encode laws into the environment. Codify mission, vision, and goals. If the agent cannot parse the intent, it cannot provably deliver the outcome. Ambiguity is the enemy of alignment.

11 The Graph: All the Context, Everywhere

Agents cannot reason in a vacuum. Embed context into the infrastructure, not just the prompt. Build the knowledge graph so the agent understands the world before it attempts to change it.

12 The Order: Priorities Drive Compute

No matter how scalable, compute is still a cost. We must always know the next most important task, what would most benefit from compute and attention. We do the hard work to align. We optimize for outcomes. Everything we learn informs our priorities.

13 The Documentation: Show Your Work

Code is the what; reasoning is the why. Do not accept a black box. Agents must record their discoveries, their rejected paths, and their logic. We pay the compute cost to understand the machine.

14 The Immune System: Continuous Improvement

Repeating a mistake is a system failure. Spend compute on the post-mortem. Automate the analysis of what went wrong. Inoculate the system so the error never happens again.

15 The Gate: Risk Stops the Line

Speed is dangerous without brakes. Make risk a blocking function. If the risk is unknown or unmitigated, the line stops. Do not hide danger in a report; encode it as a gate.

16 The Validation: Audit the Outcomes

Trust is a vulnerability. Models drift. Prompts break. Capabilities change overnight. Continuously audit the agent against the domain. Verify the tool is sharp before you use it.

Design by Sam Lucidi (samlucidi.com)