Principles & Practices

guiding beliefs and concrete actions

Principles

I think it's important to establish a set of shared beliefs to act as guideposts for the team's decisions. These principles will evolve as the company matures. Here is the full set of principles I instill in my organization:

Faster is better.

We feel that speed wins. Speed when hiring new colleagues, speed in the user experience, speed/effectiveness in our dev process.

Simpler is better.

We follow the age-old adage to Keep it Stupid Simple (KISS) and avoid unnecesary complexity.

Change is good.

We’re not always gonna get it right. The market, our customers, and our people WILL change over time. This principle says to expect it, embrace it, and adapt. Roll with the punches.

We are vocal, helpful, dependable, and kind.

We default to trust, and we show empathy and compassion with customers, partners, and each other. The closer we are, the better work we do. A happy and healthy team does the best work.

Ah, you thought you'd be clever and bypass the blur in the inspector, eh? Until then...

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

Please consider buying a license key instead.

Ah, you thought you'd be clever and bypass the blur in the inspector, eh? Until then...

Please consider buying a license key instead.

Ah, you thought you'd be clever and bypass the blur in the inspector, eh? Until then...

Please consider buying a license key instead.

Practices

To take on my responsibilities as an engineering manager and leader, I instill practices and develop/evolve them over time. These are the actions, ceremonies, procedures, and processes we use to keep our Machine running.

build for a magic moment

A magic moment is a brief flash of unexpected joy when using a software product. This phrase comes from one of Arthur C. Clarke's three laws, which says that 'any sufficiently advanced technology is indistinguishable from magic'. I seek to build software which wows the user, making them wonder how we did it.

work backwards

Start with the end in mind. I use this approach for product, people, and process. For product efforts, I work backwards from the desired end user experience, employing the technologies that get us there. For people, I work backwards from personal life goals to identify the steps worth taking on one's career path. For crafting processes, I work backwards from the experience we desire when we're actually following the process.

exercise / nutrition / sleep

I'm a firm believer that daily exercise, solid nutrition, and a good night's sleep amplify performance. Better energy, attitude, and focus are superpowers when you're leading a team.

code with the team

Although it's a debate that borders on the near-religious, I believe that engineering managers and leaders should contribute to the codebase IF they have the personal bandwidth. In the early days (Founding Stage), I expect to be a core contributor to the product.

#focus (One Big Thing)

I prefer this practice as a lightweight, asynchronous alternative to a team standup meeting. Each person on the team sends one message at the start of their workday into a shared groupchat channel (our channel is called #focus). The message describes the One Big Thing they intend to focus on today, the one thing they hope to accomplish. This approach forces clarity in personal prioritization ('what's the one key thing I need to do?') and drives alignment across the team ('I can see what everyone is focused on').

hack night

Hack Night is the (totally optional) weekly practice of setting aside a few hours to focus on your personal passion projects. I’ve seen colleagues use it to work on open source projects, to write books, to compose music, and to learn new skills, technologies, and tools. It was through this regular practice that my co-founders and I built the software at the core of our first company.

Since we’re an all-remote company, we gather virtually via group chat and hack on our individual projects of choice, sharing what we’re working on, sometimes giving demos, and frequently seeking feedback. If there are other colleagues living in the same city, it’s common to gather in-person for hack night in a mutually-convenient coffee shop or bar.

meetings: presentations and debates

Meetings are important constructs to keep people aligned, but I'm vehemently opposed to wasting time and boring the team, so we adopt an async-first approach:

- PRESENTATIONS: These are passive meetings. If we JUST need to share infomation broadly, we do so asynchronously (via email or group chat), and let the team read/absorb it when they can. If 'this meeting should have been an email', make it an email.
- DEBATES: These are active meetings, for when there is something we need to discuss, debate, and determine as a group. These are synchronous efforts done via video chat.

We lean heavily on this approach of sharing information broadly via async channels, then having a 'debate' to answer challenges/questions in response. No questions or concerns? No meeting.

rocks, pebbles, and sand

This is a mental model for prioritizing tasks and managing time wherein I imagine our available time as the space inside a jar. To fill that space, we add the Big Rocks (highest-impact efforts) first, then round out the contents with Pebbles (lower-impact features, technical debt) and Sand (small, nagging quick-fix issues). Our stakeholders -- customers, partners, and internal peers -- rarely take note of the medium- and low-impact capabilities and fixes we deliver, but they remember and value the high-impact Big Rocks we ship.

At the end of our available time, we tout (demo/broadcast/market/share) the Rocks, empty the jar, and repeat.

shared understanding

This practice represents a faster, lighter-weight alternative to complete documentation; we use it most commonly to define product features. Instead of spending time to write down in a document how everything should look and function, we meet to draw coarse, low-fidelity pictures, discuss, and debate. We raise concerns and ask questions until we all have clarity on what the others are imagining and why. When we're all on the same page, we've gained a 'shared understanding'; at this point, we will frequently document the key takeaways by capturing issues in our issue tracker.

demo showcase

This practice is a quick weekly demonstration of the notable wins from the dev team. If an engineer doesn't have something substantial to show, don't worry; there's always next week. I love this practice as a frequent, recurring way to celebrate small product victories; it's inspiring and motivating to see perpetual progress.

1-on-1s / Life Path

I believe that sharing meaningful 1-on-1 meetings (aka 1:1s) with each of my direct reports is one of the most important things I can do as an engineering leader; it's a key effort meant to retain and grow every person on the team. I take a more holistic approach than most, seeking to understand their goals in life (not just in this job), and then helping them take steps on that Life Path while in my employ.

Logistically, I like to schedule 45-minute meetings every 2 weeks. If we need to skip one every once in a while, that's fine. Two in a row? Nope; it's critical to connect at least once a month to continue building rapport and a trusting relationship.

I never use a 1:1 as a tactical project status check; instead, I start every 1:1 with 'What's on your mind?' and we go from there. We discuss the top things occupying/demanding your attention (professional or personal, no matter), and I do my best to help you navigate them. Then, if I have constructive feedback to deliver to you, I give it. If you have feedback for me, I seek it.

As we talk, I capture notes in a mutually-editable evergreen doc.

evergreen docs

An evergreen doc is, quite simply, a single shared document that gets reused over time. The document URL stays consistent, but the content evolves with each use. I like to add a new timestamped block at the top of the document each time I use it, pushing down older content. This keeps the most recent information quickly-accessible at the top while also allowing for easy perusal of historical notes.

Example evergreen docs: one for my 1-on-1 notes with Sam, and another for a guild meeting agenda.

picking technologies

In the absence of any other guidance, I believe that the best tech stack to pick is the one we already know because it gets us off the ground and building faster.

However, tools and tech move quickly, so it's important to stay on top of advances so we don't rebuild the wheel. With an idea of the product we're pursuing, I consider 3 notable factors:

- TECHNICAL FIT: does it do the job for the product we want to build?
- SUPPORTABILITY FIT: bleeding edge and possibly buggy? old and possibly unmaintained?
- TALENT FIT: are engineers excited to work with this tech?

If I'm unsure of which tech to pick, I'll use the one that maximizes future flexibility.

ship early and often

I highly value the frequency of our code deploys as an indicator of dev team effectiveness. Every deploy indicates some amount of delivered value, either a feature or a fix or both, so I encourage the team to ship early and often.

Our velocity as a team does not matter if the software we build is not getting out into a production environment, available to our customers and prospects. Commits to the main line of our code repo(s) will not automatically trigger a deploy (too easy to deploy a mistake in a recent commit), but I will give every engineer the necessary tooling (like a one-line script) to trigger a deploy to production.

compensation: personal top of market

Popularized by Netflix and documented in 'No Rules Rules', this practice pays software developers the most that they can be paid within their field, or very close. Since each dev is paid so highly:

- I expect exemplary performance; merely adequate performance will earn a severance package
- there will be no yearly or spot bonuses, as they're already paid top dollar

This practice, while expensive, results in a tight, highly-talented team. It also sidesteps the painful cognitive weight associated with traditional yearly performance reviews and bonus calculations.