Ward Vuillemot — Writing

You Can’t Direct What You Can’t Interrogate

2026-10-30T00:00:00Z

The throwaway that never gets thrown away

At Amazon, incubating a new business felt like building the train while it ran, laying rails just ahead of it. Everything was a prototype, and everything would be rebuilt later.

I've seen the same pattern at nearly every company I've worked for. The proof of concept ships, the first revenue arrives, and "later" never does.

Vibe coding didn't create that failure mode. It amplified it. When a working demo takes an afternoon, every demo looks 90% done.

Confidently wrong

Ask an agent to build a chat feature and it may well key your messages with UUID v4. It will work in the demo.

Then real traffic arrives, with messages landing back to back. A v4 ID is random, so it carries no order. You fall back on timestamps, and timestamps tie, drift, and arrive out of sequence. Ordering breaks, and ordering is the whole product.

The agent wasn't being careless. It picked something reasonable-sounding and said so with total confidence. You only catch it if you know why v4, v7, and sequential IDs behave differently under load. (Even v7 needs care when many messages land in the same millisecond.)

Works on your laptop is not the same as works well at scale

Getting something running on your laptop is not remotely the same as working well at scale, or even across two running instances. Ask yourself:

Data

Can you interrogate an ERD? Do you know the three normal forms, why they matter, and when to deliberately break them?
Do you understand race conditions, and what happens when two instances read, modify, and write the same row?
Do you know when a relational database is the right tool, and when a document, key-value, or wide-column store earns its trade-offs?
Can you change a schema without downtime? Do you know how to run a migration safely on a table that is being written to right now?
Disaster recovery: do you have recovery targets, and has anyone rehearsed a restore from backup? Can you upgrade the database version without an outage?
What happens when a request is retried, or when two systems briefly disagree?

Scale and performance

Do you know why a traditional CRUD app can choke on its own reads and writes at scale, and what CQRS buys you? (And when it's overkill.)
Do you know the difference between scaling horizontally and vertically? Can you build for autoscaling that works under real-world conditions: stateless services, cold starts, the right scaling signal, and a database that can't autoscale along with you? Autoscaling is never a toggle you switch on and walk away from.
Caching: do you know when to cache and where (browser, CDN, application, database)? Do you know the trade-offs between cache-aside, write-through, and write-behind, how you'll invalidate, and when and how to warm a cache before traffic arrives?
CDNs: do you know how to set one up and manage it thoughtfully? What to cache and for how long, how to purge, and what must never be cached?

Security, identity, and compliance

Do you understand security beyond "add login"? OWASP, CSP, encryption in transit and at rest, end-to-end encryption, key rotation?
Networking: are your VPC and network rules controlling every way into your environments? Do you know how to audit for open ports, and what is allowed to leave? Would you notice if data were being exfiltrated?
Authentication: do you know when you need OAuth, OIDC, or SAML, and what each one actually proves? Who owns the identity, you or your customer's identity provider?
Auditing: can you answer "who did what, to which record, and when" for an auditor? SOC 2, HIPAA, and their cousins turn that from a nice-to-have into a requirement.
Privacy: do you know what counts as personal data, where it lives, and what GDPR, CCPA, or data-residency rules require you to do with it?

Quality and operations

Do you know what each layer of automated testing buys you (unit, integration, contract, end-to-end, synthetic, load, stress, performance), and what it costs? Every layer up is slower, flakier, and harder to maintain. Do you know what belongs at which layer, what mocks hide, and what a green suite doesn't prove?
CI/CD and infrastructure: do you know what a pipeline should gate, and how to ship small and limit the blast radius? Do you roll forward by default and roll back only when you must? Is your infrastructure code, or clicks in a console that nobody can reproduce (ClickOps vs. DevOps)?
Environments: do you know what local, dev, sandbox, staging, and production are each for? How closely do they match, and how do you keep production data and credentials out of the others?
Monitoring and alerting: do you know what to measure, and what deserves to wake someone at 3 a.m.? Silence from a system is not the same as health.
Reliability: do you know what happens when a dependency is slow or down? Timeouts, backpressure, graceful degradation.
Cost: do you know what this costs at 100x the traffic, and when optimizing is a waste of time?

Design and dependencies

Interfaces: can you design and version an API without breaking everyone who depends on it, and do you know which seams to expose?
Do you know when to reach for a synchronous API, RPC, or events, and what each costs in coupling, latency, and failure handling?
Build, buy, or adopt open source? What do a dependency's license, upkeep, and supply-chain risk cost you later?
Dependency management: do you know what is actually in your build, including the dependencies of your dependencies? Do you track CVEs, pin and update versions deliberately, and know what to do when a critical vulnerability lands in a library you never chose directly?

AI features

How do you evaluate output that is non-deterministic? What can prompt injection reach through your agent? What does each call cost?

That's a sample, not the list. Engineers answer them daily, often without noticing. An agent answers them too, quietly, whether or not anyone asked. Agents optimize the happy path. Judgment is mostly about the unhappy ones: failure, scale, abuse, change, and confused humans.

Start with a monolith. Don't stay a blob.

A monolith is the right way to start. It's fast, and it avoids splitting services around your org chart too early.

But the seams, meaning how you'd decompose into services along single-responsibility lines, have to be drawn from day one. You can't bolt them on later.

I've watched a single code base run everything from the public website to the internal CRM. Every production push took down the sales team's VOIP calls. That is the bill for a throwaway nobody ever revisited.

It isn't only code

The same holds for product and UX. Does the early praise for your prototype count as signal, or are five friendly users telling you what you want to hear? What is the smallest thing worth shipping, and what should you refuse to build? What happens on the empty screen, the error state, the slow connection, or the accidental click on "delete"? Is it accessible?

A demo hides all of this as well as it hides the engineering gaps.

The vocabulary is the interface

If you can't read what the agent produced, you can only accept or reject it by feel. You can't tell it why it's wrong.

Fluency means the patterns Fowler and others spent careers naming, and automated testing with all its nuances, including TDD red/green. It means PRD → ARD → HLD, and functional vs. non-functional requirements. Without that language, you'll never direct an agent with enough clarity or nuance.

For product managers and non-technical founders

Agents are the biggest lever you've ever had, and you should pull it hard. But the less you can interrogate the output, the more you operate on trust, and trust without verification is how throwaways become production. Learn the vocabulary, or bring in someone who has it.

For engineers

Agentic engineering solves one problem: compressing code generation. Edge cases, tradeoffs, scope, and collaboration across silos stay human, along with the hardest skill: knowing what not to do.

Sketch vs. system

Vibe coding is a sketch. It's valid and cheap, and it produces signal. Just call it a sketch. Agentic engineering starts with a measurable goal and an automated SDLC that lets an agent reliably reach it.

The rule

Set a decision point before you start: at the first customer or the first dollar, you either rebuild or you consciously accept the debt.

Agents made code nearly free. That makes judgment the scarce part. Software engineering was never about the code, any more than building a house is about the nails.

Why I Wrote a Personal Operating Guide (And Why Every Leader Should)

2026-03-08T00:00:00Z

Over the years I’ve led teams, built companies, and worked with a lot of very smart people. Yet even in strong organizations, the same problems kept appearing:

Engineers frustrated with leadership decisions
Leaders wondering why teams didn’t move faster
Teams debating solutions without agreeing on the actual problem

Eventually I realized something uncomfortable. People weren’t struggling because they were bad at their jobs. They were struggling because they didn’t understand how their leaders actually think.

Most leaders keep their operating system in their head

Every leader has one. An internal model that governs things like:

How decisions are made
When speed matters vs. when caution matters
Whether mistakes are punished or learned from
Whether systems thinking is valued over quick fixes

But most of the time, this “operating system” is invisible. Which means teams are left guessing.

Guessing creates friction

If you don’t know how your leader operates, you spend enormous energy trying to interpret signals:

“Why are we spending so much time on architecture?”
“Why does he keep pushing back on scaling this?”
“Why is disagreement encouraged in meetings but silence afterward bothers him?”

Without context, these behaviors feel arbitrary. With context, they become predictable.

So I wrote mine down

I created a Personal Operating Guide that explains how I think and work. It includes things like:

I think in systems, not projects. Projects end. Systems compound.
Speed matters, but only after clarity. Moving fast in the wrong direction is expensive.
Signal before scale. Most companies scale ideas that haven’t actually proven themselves yet.
Celebrate errors. The fastest learning organizations surface mistakes quickly instead of hiding them.

None of these ideas are revolutionary. But writing them down changes how teams interact.

The surprising result

Once expectations were explicit:

conversations became shorter
decisions became faster
disagreements became healthier

Because people understood the framework behind the decisions. They didn’t need to reverse engineer it.

Leadership is a systems design problem

One thing I’ve learned over time: organizations behave like systems. And unclear leadership expectations introduce friction into that system.

A good operating guide removes that friction. It aligns incentives. It clarifies thinking. And it helps teams operate with far more autonomy.

My recommendation

If you lead people, whether it’s five or five hundred, write your own operating guide. Not a corporate values document. A real one. Explain:

how you think
how you make decisions
what behaviors you reward
what drives you crazy
what good work looks like

It doesn’t need to be perfect. But it will save you and your team a tremendous amount of time.

If you’re curious

I published mine here: Personal Operating Guide.

I’d be interested to see more leaders do the same. Organizations run better when the operating system isn’t hidden.

Code Was Never the Unit of Value

2026-03-08T00:00:00Z

Anthony Mendonca recently wrote a thoughtful article titled “The Code is Dead, Long Live the Craft.” It captures something important about the moment we’re in. But I think the shift runs even deeper.

The real change isn’t that code is disappearing. And it’s not that code is becoming less important. The truth is simpler.

Code was never the unit of value.

It only appeared that way because software was historically opaque, specialized, and difficult to commoditize. For decades, writing software required rare expertise. Systems were complex. Tooling was immature. Feedback loops were slow.

That created a kind of professional insulation. If you couldn’t understand the code, you had to trust the people who wrote it. And because of that, organizations often treated lines of code, complexity, and engineering effort as proxies for value.

But those were always proxies. Customers never bought code. They bought:

working products
capabilities
reliability
speed
outcomes

Code was simply the artifact required to produce those outcomes. AI isn’t changing where value lives. It’s simply making that reality impossible to ignore.

My first lesson in software engineering

I’ve been programming for more than 45 years, since I was 5 years old.

My father believed computers were tools for productive work, not entertainment. If I wanted to use our Apple II for games, I had to write them myself. So I did. At five years old I started learning BASIC and assembly to build simple games.

I didn’t realize it at the time, but that experience taught me something fundamental: the code was never the point. The goal was the game. The code was simply the artifact necessary to produce the outcome. That lesson has never stopped being true.

Learning Lean from the source

Later in my career I had the unusual privilege of working closely with Shingijutsu Consulting, widely regarded as the world’s foremost experts in the Toyota Production System (TPS).

While working at Boeing, first as an aerospace engineer and later as a lead software engineer, I spent about a year working full-time as a simultaneous interpreter for Shingijutsu’s Japanese consultants. Being fluent in Japanese allowed me to translate directly between Toyota veterans and Boeing engineering teams. It was an extraordinary education. For a time I also served as an AIW (Accelerated Improvement Workshop) facilitator, helping bring Lean thinking into engineering organizations.

Watching Toyota-trained practitioners analyze complex systems was eye-opening. Their perspective was relentless and simple: Where is the value? And equally important: Where is the waste?

That lens has shaped much of how I think about engineering systems and leadership. I’ve written about related themes in On Lean Thinking and On Leadership.

Lean’s brutally simple definition of value

Lean thinking defines Value-Added (VA) work very precisely:

Anything that changes the fit, form, or function of a product in a way that a customer would willingly pay at least one penny for.

Everything else is Non-Value-Added (NVA). That definition is brutally clarifying. Every meeting. Every email. Every status report. All NVA.

If you can’t go back to your customer and say, “We had a fantastic internal meeting today,” and have them respond, “Great, let me pay you for that,” then by definition the meeting is not value-added.

That doesn’t mean it’s useless. Some NVA work is necessary: planning, coordination, architecture alignment, progress checks. Lean calls this Necessary NVA. But a large portion of NVA is something else entirely. Waste. Toyota calls that muda.

The math is brutal

In most traditional organizations the distribution looks roughly like this:

~20% Value-Added work
~80% Non-Value-Added work

A familiar pattern. It’s essentially a power-law distribution. Inside that 80% NVA bucket, roughly 50% is necessary and roughly 50% is waste.

Which leads to a startling implication. If you simply eliminated the waste, nothing else, the math looks like this: Monday and Tuesday, Necessary NVA work. Wednesday, Value-Added work. Thursday and Friday, nothing at all.

You would deliver exactly the same customer value, at 40% lower cost. That’s the power of eliminating waste.

AI is compressing non-value-added work

For decades software engineering required enormous amounts of NVA work:

writing boilerplate code
wiring integrations
infrastructure scaffolding
repetitive implementation
environment debugging

Important work, but rarely where customer value actually lives. AI is rapidly compressing these categories. Large language models can now generate infrastructure code, glue code, repetitive implementations, test scaffolding, and documentation in seconds.

Which forces a new question. If AI eliminates large portions of NVA work, where do engineers create value now?

Engineers become systems designers again

The best engineers were never just coders. They were systems thinkers. AI simply makes that reality visible again. The role increasingly becomes:

defining objective functions for success
structuring incremental feedback loops
designing environments where progress can be measured
assembling tools agents can reliably use

In other words: systems engineering. Because once you understand value creation, engineering stops being about writing code. Truthfully, it never really was, any more than building a house is about hammering nails. It becomes about designing systems that reliably produce outcomes customers are willing to pay for.

Discipline matters more, not less

Ironically, the rise of AI makes disciplined engineering practices more important, not less:

test-driven development
small composable components
deterministic tooling
clear interfaces
reproducible environments

These practices aren’t academic ideals. They are how you build environments where AI agents can operate safely and productively. Without structure, AI simply produces chaos faster.

Working with AI agents feels familiar

If you’ve ever led an engineering team, working with AI agents will feel remarkably familiar. The pattern is almost identical. You:

Describe the outcome
Ask for approaches
Evaluate options
Select a direction
Delegate execution
Measure results
Iterate

The difference is speed. Instead of sprint cycles measured in weeks, you may run dozens of iterations in a single day.

Toyota already solved this problem

The deeper lesson from Toyota was never about manufacturing. It was about systems thinking. Design systems where value is visible, waste is eliminated, feedback loops are tight, and improvement is continuous.

AI doesn’t invalidate those principles. It amplifies them. Which means the engineers who will thrive in this new era will not be the ones who write the most code. They will be the ones who best understand systems, value, outcomes, and how to orchestrate humans and machines toward them.

The future engineer

The future engineer looks less like a programmer and more like a systems architect directing teams of human and machine collaborators. You describe outcomes. You build environments. You assemble tools. You design feedback loops. You guide systems toward measurable results.

Code still exists. But it is no longer the center of gravity. It never really was.

Works in Progress Told in Three Truths

2020-10-06T00:00:00Z

Sadly I do not know who to properly attribute the below to, but when I recently heard these it quite literally stopped me in my tracks. Partly for the alliteration (who does not love good alliteration?), but largely as it encapsulated something I think is hugely critical for us to never forget as leaders, especially as we endeavor to create environments that allow our people to realize the best versions of themselves.

The three truths are:

Be forgiving of your former self
Be firm of your present self
Be flexible of your future self

Permit me to unpack and elaborate, and in so doing I hope to connect it back to leadership fundamentals.

First and foremost, we are all capable of amazing things. But along the way to these amazing accomplishments, we are also fallible; more so, we can be our own worst enemies in the face of these seeming failures. I say "seeming" because where we fail in life and business is not per se actual failures (the only real failure is not getting back up after getting knocked down), but more that we failed to satisfy unrealistic expectations. While it's beyond this article to fully unpack how the root of so much suffering rests upon our expectations, suffice to say that our failures are more that we are divorced from a simple reality: we are all works in progress.

In the first truth, this is where it's important for us to forgive our former self, as it were, and to allow ourselves to fail gracefully by acknowledging that while we sometimes miss the mark, it's more important that we never stop trying to do so. In short, remember to find grace in our humanity, both in our accomplishments and our fallibility.

In the second truth, we focus on the present moment; it's the only moment we can ever truly live in. This is where (or when, to be more precise) we must fully and purposely exercise our free will and intent. It's important for us to stand firm in our beliefs, and make decisions grounded in the best of intentions. Have conviction, and hold yourself accountable to those things you hold most dear and most true by being firm, by being true.

Finally in the last truth, no matter how firmly we live in the moment, let us not forget humility in face of the fact that we cannot anticipate or plan for all things. Keep an open mind, knowing we are all inherently ignorant. Leaders peer fearlessly into the unknown of not only the business but of themselves and others, and learn deeply. Do not let principles, heuristics, or past successes turn into tired dogma whereby we become defenders of the status quo; instead, remain flexible to what might be, what you and others might become.

Suffice it to say, I really enjoyed hearing those three truths. They are good grounding statements that I think we can use to celebrate our shared humanity: we are all works in progress. I do not think these are just words to live by, I think they are words we lead by, too.

A part of our role as a leader is to reflect back to others what we see of the situation and of themselves. We want to see our people be successful, and we do this by providing unflinching feedback. The essence of good feedback is grounding it in reality absent judgment. And once we give feedback, we layer on sound advice, when and where appropriate. These two pieces, feedback and advice, are well-married to each other not dissimilar to giving directions to a traveler. We cannot get to where we are going without first knowing where we are leaving from. We cannot become whomever we might become without first knowing who we are. When an employee comes to us asking about a promotion, we sit down with them and help build them a map with this kind of navigational thinking. The goal of feedback and advice is not to admonish or otherwise be punitive, it's meant to be a gift that helps illuminate and instruct. When we are talking with a fellow employee, we want them to clearly see where they are both hitting and not hitting the mark, but we also do not want them to fall into the trap of shame or embarrassment. And this is where I think the above three truths are of value: they remind us of a shared humanity, helping us to find grace in who we were, hold true to who we are, and remain open and flexible to who we will become.

This is how we take care of ourselves. This is how we can help take care of others in our charge. And is this not, at its most basic parts, what leadership is all about?

Fate or Destiny, What Do You Choose?

2020-09-22T00:00:00Z

Fate versus Destiny has always fascinated me in their natural juxtaposition to each other. On the one hand we have the Fate of yore with its Three Sisters weaving us into the very eternal tapestry of humanity's shared experiences, as if any semblance of free will is illusory. On the other hand, Destiny stands vigil and vanguard, obliterating these Sisters, turning its gleaming visage upon us mere mortals to ask that we step into our present moment and decide what our future will be. It is this that I want to talk about: do we decide our future, or is it decided for us.

Destiny is, at least for the purposes of this article, the choices we make for ourselves to decide our future. Destiny is in some very real ways the manifestation and end result of us exercising our free will. Fate then is what happens to us when we don't decide.

If Destiny is active, then Fate is passive. Where Destiny is us owning the pace and shape of our futures, Fate is waiting for it to arrive in whatever form it decides to take. Where Destiny is we caring, Fate is our indifference.

While there are no guarantees in life, I'd rather be an active participant in what happens to me. How about you?

I recently gave a small talk with some of my leaders on lean thinking. The talk centered on something that I call "the fate box." I ran across this idea some two decades ago. I've since used it repeatedly as a gentle reminder to humble myself to my ignorance, but I'm getting ahead of myself. To begin, it's a simple 2x2 matrix that breaks knowledge into quadrants.

The fate box: a 2x2 matrix crossing "I know" and "I don't know" with "what I know" and "what I don't know".
	I Know	I Don't Know
I Know	Things we know we know	Things we know we don't know (yet)
I Don't Know	Things we knew and now forgot	Our FateThings we don't know we don't know

As you note, it's a simple enough matrix as it's really just two statements: 1) I know; and, 2) I don't know. We combine these two straight-forward statements to create four more, or: 1) "I know what I know"; 2) "I know what I don't know"; 3) "I don't know what I know"; and, 4) "I don't know what I don't know."

As professionals and thought workers, we pride ourselves in all that we know. Our resumes are filled with nods to this. We celebrate it in others as specialists and experts in their fields. We operate on a daily basis, moment from moment, going from what we know to another thing we know. It defines both who we are, but what we do. And herein lies the danger. If we are to be honest with ourselves, then our jobs are to operate deep in unknown territory. Our jobs must be focused on rolling back our ignorance and filling it with knowledge. If what we do was already understood and known then the rewards we seek would evaporate as everyone would join us in a race to create cookie-cutter products and experiences.

Building companies, and experiences they are charged with creating for its customers, is not for the faint of heart. We put ourselves at the very forefront of the boundary between the known and the unknown, trying by crook or hook to glean insights that will create differentiated experiences that matter to our customers. As leaders, our job is not to arrive pre-loaded with answers, but instead always be at the ready to ask the right questions at the right time. Just as hubris kills, humility is a prerequisite to finding success in these endeavors.

Everything we do must be armed toward shining a light into our collective ignorance. Our ignorance is not a liability, it's our shared treasure of opportunity we must mine with every question we ask, every A/B test we conduct, every new feature we rapidly prototype all in the hopes of turning what we don't know we don't know into things we know we know.

To turn a blind eye to our ignorance is all but a clarion call to Fate and its sisters to decide for us our futures. Instead, when we never cease asking questions with the bold courage and egoless inquisitiveness of a three-year-old child wondering upon azure heavens then truly the sky is the limit to our destiny.

What will it be? Fate or destiny? It is, after all, your choice.

Leading Remotely: Creating Culture From Afar

2020-07-03T00:00:00Z

In my last article, Leading Remotely: Lessons from 5+ Years in the Trenches, I talked about my experiences thus far as C-suite executive working for the past 5+ years 100% remotely.

North Carolina Outward Bound School asked me in the comments: "I'd be curious to hear about your ideas for building culture in a remote setting and how it is different than in shoulder to shoulder environments." Below is a revised and updated response to what was originally broken across multiple comments.

What is Culture?

That is a big question; permit me to start by giving a definition of (company) culture largely to establish how I think about it:

"Company culture can be defined as a set of shared values, goals, attitudes and practices that characterize an organization."

Note that culture is not about whether you have open offices, ping pong tables, fun end-of-the-workday happy hours, or even unlimited time-off. Those things are not culture; these things are just benefits that best fall under total compensation. Culture is defined by shared set of values and behaviors established and reinforced by what we expect of ourselves and everyone around us. Period. Full stop.

It's important to point out that culture happens whether you want it to or not; that is, to say, whether you are thoughtful or not, a company culture will form around you. In both in-person and remote, the distance or lack thereof is not the defining characteristic that develops a culture; instead, it's purely a function of how you treat people. Whether you decide to take ownership of your culture through thoughtful behaviors, or not, is entirely a matter left to the presence of, or lack thereof, leadership, in my opinion.

Say What You'll Do, Do What You Say

Another thing to recognize is that the best determinant of the kind of culture you will create is not by what you say it is, but by how you behave. Actions speak louder than words, and this is most true as leaders at a company. I've met many a "leader" that speaks a very good game, and on paper can nail the most advanced leadership exam you give them, but in practice their own foibles as a human being ultimately make them mostly, if not entirely, ineffectual. So much so that they create a very real and very toxic culture in their organizations. We've all met these supposed leaders; we may all have been one of those leaders at some point in our careers. As a leader, you must always be setting the example of the values and behaviors of what you ask and expect of people in your organization. You must be the most accountable of anyone in your organization: say what you'll do, do what you say.

While actions are more important than words, next in line of importance is establishing the expectations you have of your people and making it explicit. The single biggest failing that causes the most disruption on a nearly daily basis is people have implicit (aka unsaid) expectations of others. My job is largely establishing explicit expectations for the people whom I work with to ensure they clearly understand what success looks like, and when necessary ensure they know squarely where the goal posts are. Culture is no different; set explicit expectations around the values and behaviors everyone is expected to abide by. Hold people accountable to them, but also ensure you reward people when they meet those expectations. I do not recommend more than 7-12 of these values. For many companies I worked at, typical values include: 1) bias toward action; 2) think like an owner; 3) obsess over our customers; 4) think big; 5) simplify; et cetera.

Three Simple Things to Create Culture

And then what you do, as a leader, is all about how you reinforce these things. Again, whether in-person or remotely, you get what you enforce as a leader. For myself, this is largely achieved by 1) ensuring I demonstrate the values and behaviors I expect of others; 2) setting clear and unambiguous expectations of said values and behaviors; and, 3) reinforcing through praise when people meet those expectations. That is really it to creating company culture. As simple as that is, point 3 is where most leaders will fall short, as it's the one that takes a ton of time and investment of energy that is measured in months and years of consistent behavior from you as a leader. Some fall short as they incorrectly assume that "this is people's jobs so why should I praise them for doing the job I pay them to do", they simply underestimate the value people put on being recognized and acknowledged, or they are too short-sighted thinking everything is an annuity (i.e. always looking for short-term wins) when culture is the biggest equity you create for your company as a leader.

Now, to your question on how is this different shoulder-to-shoulder vs remotely, it's largely just the tools and some resets you need to make with regard to your opportunities to communicate. Because you have less random interactions when working remote, every opportunity needs to be leveraged as a leader ... especially since culture is largely established, for good or bad, from the top down. I say this, as noted above, some of the worst leaders I've ever met are ones that talked the talk, but nonetheless walked to something very different that they created company-wide toxicity. The higher up you are in leadership at your organization, the more good (or harm) you can and will do. Be mindful.

As noted in my previous article, one thing to remember is that meetings are not just transactional, they are also community building and culture-setting opportunities. I spend much of my time in meetings listening to others, partly so I can enforce larger themes around cultural norms I want to establish. Every interaction is an opportunity for me, or anyone at RealSelf, to show up as a leader to point to or otherwise exhibit behaviors we want others to emulate.

One thing people forget about leading remotely is you generally have near perfect information on what is happening in your organization, more so than you'd ever have in-person. Minus private channel communications, I can see every exchange in Slack. This allows me to audit not only what is being done, but also how people are showing up. Try doing that in an office where most of these conversations are ephemeral. I spend a lot of time reading random channels in Slack looking to praise and reinforce whenever I see behavior exhibiting the cornerstones of the culture I want. And I do the praise in situ whenever possible so everyone sees it so they, too, connect that when they do X it's both noticed and appreciated. And if I do it directly outside of public channels, I include their managers to help also demonstrate to their managers how to give praise, but also to laud the managers and individuals for doing a great job.

Another aspect of creating culture - at least the ones I believe in - is all about creating psychological safety for everyone. I'll reserve this for another article; but some quick examples to create this kind of safety include: 1) we do not focus on who made a mistake, we focus on the mistake, and we focus on learning from the mistakes together as a team; 2) we spend a lot of time not just mentoring (tell people WHAT to do), but also coaching (helping people learn HOW to do what they need to do); and, 3) we focus on our processes, not people, as the root of our opportunities to improve.

Finally, remember that whatever culture you create at your company is not for everyone. Be ruthlessly transparent about that to yourself, your employees, and any future employees. Just as I'm not the right, best leader for everyone, the cultures I help create are not right for everyone who might apply to our company. Know what your values are and are not, and know where you cannot compromise when it comes to company culture (values and behaviors). Beyond meeting the base requirements of being able to successfully perform their job, you always hire and retain for company culture as the ultimate discriminator. Culture first. Always.

Parting Thought

Culture is an investment; it's something that you nurture with love and sincerity through explicit expectation setting of shared values and behaviors. Remember this: you get what you sow. Culture is no different. Leadership, like love, knows no bounds. The difference between creating culture remotely or shoulder-to-shoulder are only ever so slightly different, in my experience.

And finally, it bears repeating: Culture first. Always.

Leading Remotely: Lessons from 5+ Years in the Trenches

2020-06-27T00:00:00Z

I really appreciated Adam D'Angelo's, CEO of Quora, write up on Remote First at Quora. He shares a lot of great insights.

For context, for the past 5 years I've been working 100% remotely as a technology leader, including as CTO at two companies. At my current company, RealSelf, as CTO/CPO I've helped introduce our work-from-home and remote-work policies shortly after joining about a year ago. As you might imagine, I'm very bullish on remote work, and more specifically remote-first companies. To be blunt, I have staked my career entirely on this modality of working: remotely.

I want to unpack Adam's excellent article, and then layer in my own experiences having worked this way quite successfully while receiving 4 rapid promotions to the C-suite in the process. My hope is that this can prove useful to other leaders looking to adopt remote-work best-practices at their company.

Office-First, Reflections on

Before I dive into remote-first companies, let me address another question implicit in this topic: Do I think office-first companies are bad? Nope. I do not think they are inherently flawed; but, I can say that as a person with high-functioning autism, they are not ideally suited for me. And I credit my career advancement to the C-level due to my ability to work remotely, helping me offset some of the challenges I can face due to my autism.

That said, I do think office-first companies inherit problems such as housing compression and extended commutes, both of which we'll unpack a bit more in the next sections. More so, I argue that office-first is really an artifact and vestigial of earlier times when we had no other means to work together but than to work physically next to each other.

For me, remote-first companies are the tip of the spear heralding a new age where we are able to rethink not only how we work, but how and where we live.

Remote-Friendly is Not Remote-First

There are a number of forms of company distribution that are not truly remote in the way I mean when I write "remote-first" or even "remote-friendly." A lot of companies, even where you might think they're minimally remote-friendly due to their globally distributed nature, are actually very much grounded in office-first cultures.

For example, when I worked at Unity Technologies, while they were a "distributed company", it was (and may still be) a largely office-first culture. To wit, they have offices around the world, but the expectation was that you were mostly if not entirely working from one of their offices, even if some or much of your team was not geographically co-located to you.

These are still office-first cultures, albeit distributed globally. Amazon, Microsoft, and Boeing had similar cultures during my tenures at each of them. There is nothing wrong with this per se, but this is not the same as a truly remote-first culture, or even a remote-friendly one, either.

Remote-First is Not Remote-Only

I want to clear up another misconception. Remote-first is not about being remote-only. The conversation of moving to a remote-first company is not to eliminate offices, but redefine them away from being the central, pivotal focal point where all key decisions are made. Instead, remote-first moves this role online where everyone has a choice to collaborate and communicate from the location(s) ideally suited to their needs.

As we will discuss a bit more below, I fully expect to see offices remain a part of the vast majority of companies, even those transitioning to remote-first. The office does not go away, just its role as a setting for major company communications and collaboration.

Remote-Work Benefits

Let me begin talking about remote-work benefits by unpacking parts of Adam's excellent article. Two of his four major points in favor of remote-work are: 1) commute; and, 2) focus. Both of these are largely true of any company, office-first or remote-first.

And, just to add some color, here are my quick thoughts on these two benefits to remote work, whether you are remote-first or just remote-friendly.

Commute: largely, depending on the percent of time working remote, you can eliminate or severely reduce your commute time and expenses. When I was working in Seattle at XBox, my commute from North Seattle to Redmond was anywhere between 2-3 hours a day, or some 10-15 hours a week. When working at Amazon, even when I took an express bus to downtown Seattle, over the course of 10 years that commute on the same bus with the same route went from 15 minutes to 45 minutes. As a single person, the commutes were manageable. But once I was in a meaningful relationship, I discovered that I could not healthily do all 3 things (work, commute, relationship); something had to give.

Focus: There is a lot of mounting evidence that office environments are not conducive to productive collaboration, especially open-space offices. By moving to remote, you can replicate closed-office spaces of yore, whereby you can close a door and get heads-down work done free of interruptions. For myself and my autism, while I absolutely love being a people leader, it does require a lot of energy for me to remain heart-centered and actively listening. When in offices, there are a lot of energetics for me to manage, many of which just come at me without any forewarning. By working remotely, I'm able to take micro-breaks throughout the day to rediscover my equilibrium, and give more to my team throughout the entire day. I attribute my rapid rise to C-level largely due to me working 100% remotely; I do not think I could do what I do today if I did it entirely from an office. Or if I did, I need my office with a very thick door and a lock. :)

Remote-First Benefits

The next two benefits listed by Adam, or 3) housing, and 4) Visa and immigration, are possible for any company, office-first or remote-first if, and only if, you largely restrict to your non-management personnel, or your individual contributors (ICs).

To see the true benefits you need to move to a remote-first culture, not just remote-friendly. And as I will argue, I think Visa and immigration are trade-offs as they imply a globally distributed team that then inherits timezone decoherence, something you must weigh the pros and cons of relative to the merit of finding talent truly anywhere.

For Everyone or No One

As noted above, unless you flip to a truly remote-first company, then you exacerbate a two-tiered culture between ICs and management by restricting management to office-first, and you end up with some portion of your ICs at an inherent disadvantage by not being co-located physically to upper leadership.

It's not hard to see how this creates its own internal politics and inherent biases toward only noticing people around you. And as Adam rightly notes, this leads to company cultures where the only way to advance your career, above a certain level, is to re-locate to the company HQ.

Sound familiar? I've known many great leaders in Disney's Seattle office re-locate to either California or Florida to continue their career advancement, and many more leave because they did not want to disrupt their families with said relocation. I am not critiquing Disney, but drawing them out as one example among many. The same can be said of companies I've worked at, including Amazon, Microsoft, and Boeing. At each and every one, if you wanted to grow your career, you had to make sure you were in the right buildings at the right time to be noticed.

It's important to emphasize that a remote-first company creates a more egalitarian structure whereby everyone from the CEO down to the intern is working from the same set of advantages and disadvantages, as it were. And where every employee can talk to anyone else with a simple click of a button. There is no one at RealSelf who cannot, and many do every day, send me direct messages in Slack or set up a quick video chat without wondering if they can even get into the building I'm in to see me.

And just to round out Adam's four points, here is some of my commentary on his original article on the two specific merits of remote-first companies, or:

Housing: Obviously, if you need to be in an office you need to live nearby. Given that a lot of jobs, at least in tech, are co-located in real-estate hot areas such as Seattle, San Francisco, Chicago, New York, et cetera, people are finding even with high-paying jobs they cannot afford a mortgage in the city they live. Or just as bad, they are forced to take on longer and longer commutes (see point on commute) by buying houses farther out of the city center. Adam does a great job of pointing out that mobility in the US has declined in the past 50 years, a staple of healthy wealth redistribution in a free-market economy. Instead, this decline has led to a concentration of wealth largely restricted to cities, and further reduced innovation pipelines found through diversity inherent when people flow in and out other areas in a free exchange of ideas. With the rise of remote working, we will quite likely see an increase in the migration of tech workers to second-tier and third-tier cities where they can be within a morning flight of the office, while enjoying better real estate and lifestyle. And to be clear COVID-19 did not start this trend, it has only accelerated it. The migration out of first-tier cities was well-underway as early as the late 2010s as people started to leave California and Washington to places like Boise, Idaho. Heck, I did it myself 5 years ago to central Washington.

Visa & Immigration: As I will unpack a bit later on, remote work will only partially address this, and largely dependent on how synchronous (to use Adam's terminology) you want your workforce. If you are sufficiently large enough and sufficiently global enough, you will be forced to adopt asynchronous work schedules (aka, people living in vastly different time zones will generally not have much, if any, synchronous (real-time) communications.) That said, I believe that synchronous communications and work schedules are superior, especially for small- to medium-sized companies such that this particular merit, which I love, is largely unrealized for a lot of companies that might be considering remote-first policies.

All of these have merit in and of themselves, even for companies that remain largely office-first. But as I argue above, to fully realize these benefits, you really need to pivot from an office-first, remote-friendly to a remote-first, office-friendly company.

This pivot is not for the faint of heart, and requires a strong, steady hand as you navigate the waters of culture, collaboration, and company cohesion.

Synchronous Working Together

As noted above as critique of Adam's point of Visa and immigration, I strongly agree that synchronous coordination is a key constraint you need to impose on teams for reasons of collaboration, communications, and well, coordination when moving to support remote work. As a consequence, this dilutes some of the strength of the argument that Adam makes for hiring talent anywhere in the world, unless you require they adhere to the same working timezone as everyone else.

Otherwise, you will need to adopt patterns similar to Amazon by moving entire verticals to countries versus a hub-and-spoke model of centralizing command and control at some specific geographic location, and farm out work to globally distributed centers of work such as engineering.

And to be clear, most older models of moving portions of work overseas are fundamentally broken because they break the synchronous work model. There is a reason why near-seas is considered a better model, and it is one that we employ at RealSelf ourselves for some portion of our engineering.

Picking A Timezone

For point of reference, we at RealSelf have written into our remote work policy that all work needs to conform to our Pacific coast timezone. There is obviously more leniency for ICs who can largely work whenever they want due to the lower number of meetings and daily contact points with others, but for more senior folks who cannot avoid having meetings and daily context-rich communications, they have to shift most if not all of their routine to meet our West coast timed meetings regardless of where they are.

Staying Within 3 Time zones

One consequence of this is that we largely do not hire outside of North America because, in my experience, people are challenged to adjust to working more than 2–3 hours away from their local time zone. Single persons may be able to tolerate more, but generally married folks with family have other time boundaries they need to honor, and unless they do not want to see their family, it's better they stay no more than 3 hours off our company timezone.

Impact on Working from Parts Unknown

This makes permanent relocation to say, Europe, problematic for any of our employees who might want to pursue working for us. And as noted, we do not, as a policy, support it.

That said, we do allow temporary remote work from other countries as long as it conforms to that country's export compliance laws, and for some countries where export compliance is challenging we expressly forbid even temporary remote work.

Beyond export compliance laws, we also only permit this kind of work arrangement as long as their direct team is comfortable working around some of the challenges inherent in more asynchronous communications and coordination.

Offices Necessary, but Optional

It's natural that some people will prefer offices to working from home (or cafe). Unless you build from the ground-up a remote-first company, you will likely retain offices for quite some years. Beyond the fact that the duration of corporate leases are minimally 5-8 years in most large cities, you will have hired and will want to retain employees who joined your company for its office culture.

Even if I do not regularly choose to work from an office, I think it's important that people have choice at a company to figure how best they are productive. In a remote-first company, the office moves from a core place for all communications and collaboration, to an optional space for co-located work.

Employees may opt to visit the office only once or twice a week, and the rest they can work from home or their favorite cafe. Others still prefer the boundaries that an office can impose between professional and personal life. And for some, the office may be the quietest option they have available to them.

While the utility function of offices will change, offices themselves are not eliminated from remote-first companies, in my opinion. They provide a critical junction point for people to gather, have high-context collaboration sessions, and still be a meaningful place of work from a subset of your company who prefer offices to their home.

In-person Time Still Necessary

Even if you were to build a remote-first company, do not think that in-person time is eliminated. There are a lot of reasons that in-person time is important.

Well-known pioneers in remote-first, remote-only work, Automattic of Wordpress fame, still makes time for teams to get together in-person 1-2 times a year.

In-person time is generally useful for two kinds of activities:

Establishing Rapport: In my experience, especially when teams or companies are merging, there is a lot of tension around the unknowns. Who are these people? Why are they here? People may feel threatened, and leaving folks to learn about each other through text and video is fraught with danger that leads to passive- or micro-aggression and low morale. Whenever you start to see signs of this, especially with a group of people, it's prudent to force them to meet together for 1-3 days largely to learn about each other through team-building activities and collaborative workshops. Whenever I've joined a new company where I'm going to be 100% remote, I tend to spend the first 2-weeks entirely onsite, and then move to office visits every 6-8 weeks for 1-day each, largely just to maintain friendships and rapport with folks. Of particular note, I try to avoid meetings while traveling, but instead focus on jamming my time with 1-on-1 walks, conversations over coffee, and anything where I can have more personal, intimate interactions with my team members.

High-Context, Extended Collaboration: As noted with building rapport, one of the best team-building exercises is using in-person workshops. I do not think that everything requires an in-person workshop and there is a lot of great ways to collaborate online; but, for really massive projects, or even just yearly planning, having planned in-person workshops can be well worth the costs to fly and house everyone.

False Negatives of COVID-19 on Remote Work

A few observations given COVID-19 was, for me, a non-event to my working style. I noticed a lot of first-timers to remote work really hated it the first few weeks, but then got acclimated to it. That does not mean everyone is in love with remote, and I fully suspect some of our employees will return to our offices once we are able to reopen. That said, some of these issues were largely transitory: who moved my cheese, and who likes forced change? And some of the issues are unique to COVID-19, in my opinion.

Nowhere To Go

With COVID-19, entire families were all at home at the same time. If both parents normally worked, now one or both of them had to also monitor and help school their children. The home, which may have had a single office, might be crammed with two souls. With a lot of little, louder souls opening and closing the door to the office throughout the day. This kind of dynamic is not useful or recommended if you work remotely, or even if you work from a company office! We all generally need to have a quiet work place, and during COVID-19 for a lot of people, this was just not possible.

And even some of the strategies for a crowded home we all use from time to time as remote workers was not available to us during COVID-19. While I work 99% time from my home office, I do occasionally roam to nearby cafe or an outside venue. During COVID-19, your only choice was to work from a cramped apartment or house with literally no other options available to you.

My point in all of this is that for many people, they did not experience remote work under ideal circumstances, so I suspect that more people may reconsider working remotely when things are a bit more normal, and they can create a more ideal remote work environment.

Remote Work is a Choice

Beyond the constraints of do no harm, I'm a strong believer in personal choice. While I'm not willing to return to an office-only job, I appreciate that many people love working from offices just as much as I love working from home.

Self Selection, In or Out

Another observation is that generally extroverts dislike working remotely more than introverts; which seems pretty common-sensical on reflection. In the past, the only people I knew who worked remotely were people who self-elected it for themselves. But COVID-19 was a bit of an experiment in so much everyone had to try it, even if they'd normally never choose it.

This is not to say extroverts must be in an office-setting to get recharged. They, too, can work well in remote environments but again, with COVID-19, they lack key extra-work activities like going to a cafe or hanging out with friends to get the kind of energetic re-charge they might get as a daily dose of normal office-life.

Again, this goes back to remote-first does not mean no offices. In most cases, I think it's prudent to retain a physical location to allow people to select the right, best option for themselves. There is nothing inherently wrong with wanting to work physically near other people. And if you want to maintain diversity in the broadest sense of the word, it's critical to not build a one-size fits all kind of approach to working at your company.

Remote-Work is a Right, Not a Privilege

On the small matter of choice, one of the concerns I've seen with companies transitioning to support remote-work is how to manage around it. Namely, what happens if a person decides to work-from-home, but their productivity declines?

At a previous company, the prevailing opinion was that working-from-home was a privilege, not a right. Namely, if you under-perform from home then the expectation was that you were to work from the office; largely on the assumption that in-person presence of a manager would motivate you.

While this is an approach a company can take, I do not advocate for it. I believe that remote-work is either a right the employee has or not. (Yes; there are exceptions where the work itself is anchored to a physical location - you cannot restock the office frig from home; or at least, not yet anyway). Once you give an employee this right, it's their responsibility to meet their obligations. As I instruct all my team members, say what you will do, and do what you will say. Beyond that, where you work is entirely your choice. As such, if you cannot work productively from home then you, as the employee, need to find a different environment. It does not need to be the office per se, but that is an option, but you do need to figure out how to meet your deliverables.

In short, leave the question of how to be productive to the employee. There are other means already in every manager's toolbox around performance management, but restricting remote-work as a privilege should not be one of them.

COVID or Not, Remote Work Requires Change

The biggest changes for people working remote is learning how to calibrate to: 1) discipline; and 2) a new norm in communications, both scheduled and ad hoc.

Lack of Rhythm (or Pacing) Will Get You

It's pretty obvious that when you work remotely, especially alone, there is no one to distract you which is great for generating focus. But it also means there is no one around to help maintain rhythm or pace.

I'm abnormal in my ability to just concentrate for multiple hours, even tens of hours, without getting distracted. Autism for the wins! But for many people, left to their own devices in their own home, it's easy to find reasons to do laundry, take a nap, or play a video game. The reality is that none of these activities are bad to do at home while working. Honest! Most companies in tech I've worked at took great strides to intentionally add these kinds of distractions to their office environments as a way to attract and retain people.

So what is the difference? When working alone, you may lack some of the social pressure you feel when surrounded by other people do similar work. We are all humans, and we all enjoy being a part of our community. Our community protects us, supports us, and also provides a natural meter to our movements. This is why even if you do not go to your company-office, many people prefer working co-located to others in a shared space. Artists do this as entire communities, partly to share costs but primarily to help provide inspiration and motivation.

So how do you replicate this for yourself at home? Some people will keep a Zoom room open for anyone to join; partly to socialize, but partly to replicate the sense of being around other motivated folks. Others do daily check-ins, or even set up a list of things they want to do by the end of the day at the very start of the day. I've even heard of one person that moved 8 stones from the left-side to the right-side of their desk. When they completed a meaningful task, they moved a stone. When all 8 stones were on the right-hand side, they considered the day done. There is always tomorrow, there are always more stones to move.

If you find you really like those external cues that an office can provide you, along with the sense of boundaries between personal and professional life, then office-like environments can be superior to you working remotely, or even working alone in a closed office at work.

That all said, learning to have discipline with a clearer sense of what you want to accomplish today, this week, and in the near future can help you pace yourself. Too much pacing and you can burn out; too little and you can start to fail to meet your deliverable.

When I was doing long-distance running of 20-30 miles at a time, I learned to generally pace myself within some range of speed. 7.5-minute miles was fast but not sustainable. 9.5-minute miles was leisurely, and a good way to recover a bit. 8 to 8.5-minute miles was my sweet spot. I never beat myself up if I went "too slow", and reminded myself that I had upper limits. The goal was not to go the fastest, my internal goal was to go the farthest distance possible in a sustainable manner. Sound familiar? It is. It's your career made as analog.

No matter where you work, whether at home, at a cafe, or at the company office, you need to learn the discipline and grace of pacing yourself. Working remote only puts more of the onus on you to provide that internal clock; a skill that is a gift that keeps on giving throughout your life, no matter what you decide to do.

Meetings are for Meeting People, too

In terms of scheduled or planned meetings, it's important to not make every one of them a purely transactional exchange of information.

We've all had those meetings that seem to have no agenda, where they meander to no conclusion. In office-first environments, you might even find "rules of meetings" as a way to drive more utility value out of a meeting.

While some of these rules are valuable both for in-person and remote meetings, it's important to recognize that when you have part or all of your employees working remotely, meetings serve both their aforementioned utilitarian purpose of building consensus and making decisions, but also a more humanitarian purpose of building team cohesion and rapport.

While a good practice even in-person, it becomes critical for remote-workers that meetings include some more casual exchanges of checking in on each other. Coming from a purely in-person environment this can feel unproductive, but is vital that people maintain social cohesion. This is the non-transaction part of a meeting, more a meeting warmer or meet-and-greet.

Don't Wait, Just Reach Out and Call Someone

Another piece that is challenging is more of the random, ad hoc conversations that can happen in offices more naturally do not happen when working remotely. For example, you walk past a colleague's desk and see they are available so you start up a conversation. You might do something similar as you swing past the coffee machine. These kinds of exchanges can both build rapport, but also be where important decisions can be made. All without pre-planning or putting a scheduled meeting on the calendar.

Personally, I think is one the biggest headwinds I think everyone needs to overcome when transitioning to working remotely: discovering how to duplicate this kind of spontaneity. There are few strategies for this, that I've found useful.

Create Closed, Private Channels: I live and breathe inside of Slack (or Microsoft Teams, if you prefer). I have a number of closed channels with different, small groups of people that are more unofficial channels for free-form exchange of ideas. I tend to give them names to help set the tone and expectation that these are meant to be fun exchanges. Real work can happen here, too; but, largely I use them to just stay connected with various team leaders throughout my departments. Here we are just a bunch of folks sharing the ups and downs of our day together in a supportive manner. We use them throughout the day to pepper each other with questions and laughs.

Reach Out Now: Another thing is to build muscle to just reach out directly to people to jump into a video-chat. Do not just wait for the next meeting you have with them to discuss. Do not even schedule a meeting. Just ask them to hop on Zoom or Skype or even just call them. And do it now.

Know When to Hold Them, Know When To Fold: Finally, do not let text communications go on too long. If there is a lot of debate or differing opinions in a channel, it's useful to gently stop it, and have everyone jump into a real-time video chat. If it's not too contentious, you might find 15-minute chunk that works for everyone later that day or the next. But if it's brewing into its own version of a Reddit forum, get everyone into a video chat immediately. Generally speaking you build consensus faster, and avoid any unintentional micro- or passive-aggression that can befall any text-only exchanges, especially where there may be dissenting views.

Remote-First, Parting Thoughts

I truly believe that in coming years we will see more and more remote-first companies, not just remote-friendly ones. It is not possible in every industry, and it is not necessarily right for everyone even when they can choose to work remotely; but, I think that the technology is here today to make it exceedingly possible for most technology-driven companies to make the transition if they so choose.

Time will tell, but I think history will say that COVID-19 helped us rewrite the rules on how we work, at least within the technology sector. Till this year, it was largely a fringe idea that was primarily adopted by very small companies, and a few medium-sized ones. But till this year, there was definitely a bias toward office-first as the norm. I recall at a previous company that had been remote-first, that upon their Series B raise that investor basically said "Welcome to the big leagues; you need an office to be seen as legitimate." I think that kind of thinking is quickly being outdated, and replaced with a more open mind, especially as most concerns of remote-work has been proven to be unfounded: people are just as, if not more, productive working remotely.

Remote work, whether remote-friendly or remote-first, is not for everyone, but I believe we will find it is more and more the accepted, and expected, norm than we thought just a few short months ago.