Manager guide

Hi there! I’m excited to be working with you. This is meant to give you a rough introduction to me—how I think, what I value, what works for me and what doesn’t.

What success looks like

I want us to ship valuable software, quickly, sustainably, and at high quality. I want the teams I work with to be known for getting things done, not through heroics or long hours, but by consistently delivering work that matters. I want the people on those teams to grow in their craft and take pride in what they build. I want us to succeed, for the companies we work for to succeed, and for the work to matter.

That’s the idea. Everything else in this document is in service of it.

About me

I’m @bguthrie on Bluesky, GitHub, and LinkedIn. I prefer to be in a physical office most days; I like being around people and find that certain things move faster when you’re in close proximity to folks. I have a partner with a similarly demanding job and two small children. My pronouns are he/him.

I think of myself as a software generalist: I have preferences about tech and process but my job is primarily to deliver value. I have been, at various points in my career and in no particular order, professionally employed as a founder, consultant, EM, frontend engineer, backend engineer, VPE, data engineer, mobile engineer, devops engineer, QA engineer, and, at my very first IT job, a tech support guy. Some of it has worked and some hasn’t. I’m happy to share stories.

Working with me

My usual policy is half-hour 1:1s every week with my direct reports and every 2-4 weeks for my skip-levels. In cases where I need to build alignment I prefer short high-frequency meetings over infrequent longer ones. I iterate on meeting cadence and structure and would appreciate feedback on mine.

I keep my calendar open and block out work time if I have to. Please treat any open time on it as bookable. I’m comfortable with comms in either Slack or email. If you need me to do or remember something, I prefer email; if it’s a quick question or a conversation I prefer Slack.

Approach

Speed matters

I believe it is possible to move fast, and that fast matters. Speed isn’t about effort or hours worked; it’s about lead time, the wall-clock time between when someone asks for something and when they get it. Every feature is a bet; more swings means more hits.

Moving slowly is often a choice. Everyone involved has decided that speed is a subordinate requirement to talking to all the right people, writing all the right documents, and ticking all the right boxes. Sometimes that’s necessary; sometimes it isn’t.

I expect intentionality and a bias to action when it matters. I need you to work out how clear blockers by escalating, to tap someone on the shoulder instead of waiting on a code review, to choose a direction when the path is clear. For me personally, grinding is neither necessary nor sufficient for moving fast; the fastest teams I’ve worked with were not the ones pulling all-nighters.

Teams compound talent

I like to work with people who are, or who aspire to become, extremely skilled software practitioners in their own right, but I’ve never worked with a professional I admired who didn’t benefit greatly from the wisdom and skill of the people around them. Great individuals get better when they’re surrounded by other great individuals working toward shared goals.

The wrong kind of process and collaboration saps everyone’s energy, draining morale and momentum. A great team, with the right setup, compounds everyone’s impact. A team that shares context, reviews each other’s work, and distributes knowledge will generally outperform a collection of brilliant individuals working in silos, and they’ll be more resilient when someone gets sick, leaves, or makes a mistake.

I have a very particular view of the responsibility of management: a manager’s job is fundamentally to ensure that the work matters, and they are the lens through which the organization understands it. The work must be (1) worthwhile, thoughtfully chosen, and well-executed in itself; it must be (2) valuable, in a visible and real way, to the business and the broader organization; and it should be (3) meaningful to the individuals involved from a career and growth standpoint.

Good managers do this by providing clarity on direction, setting guardrails for decision-making, focusing on execution and delivery, understanding and communicating impact, creating feedback loops and, in the absence of consensus, making decisions.

I strive to ensure each team has:

a way to understand, visualize, and prioritize work;
the right feedback loops, so they know if they’re getting it right;
a process or a system of work that leads to good engineering outcomes;
a process for iteration, self-management, and blocker clearing;
and a low-ceremony way to communicate their challenges and wins to me and other stakeholders.

Systems and process

I like (but do not mandate) eXtreme Programming, which tends to optimize for technical excellence and team performance. XP is not Scrum; it’s explicitly anti-bureaucracy and focused on engineering practices like continuous integration, test-driven development, and pair programming. I mention it because its values—communication, simplicity, feedback, courage, and mutual respect—are ones I hold.

A bad system will beat a good person every time; poor systems often overwhelm the talents of the individuals working inside them. I try to believe that everyone walks into work into morning wanting to do a good job, but that can’t build great teams by sitting on top of individuals and whacking them until they conform. You do it by building momentum, trust, and the right feedback loops.

The secret sauce of software development—the philosophical origin of most advancements in thinking over the last 20 years—is incremental change, tight feedback loops, shared knowledge, and mutual respect.

Principles

Users and product over tech. Don’t build systems for their own sake; solve real problems. The people who use the software we build are the reason we get to do what we do; growing businesses make for fun and rewarding career opportunities. Most of our time and mental energy as software practitioners should be focused on adding value, not experimenting with tech.
Time-to-value over efficiency. An efficient process isn’t better if it doesn’t lead to better outcomes. An inefficient process focused on the right business outcomes and optimized for user value is faster and more effective most of the time.
Responsiveness to change over sticking to a plan. I encourage my teams to form robust short-term plans and loosely directional long-term ones and build the feedback loops necessary to figure out if they’re working. As new priorities emerge, the ability to change direction rapidly is a major advantage—embrace it! But there’s a difference between a pivot and a U-turn.
Compounding talent over individual heroics. Individuals matter, a lot! But overreliance on key individuals is fragile and can amplify the impact of bad decisions. Teams that share knowledge and collaborate effectively multiply each other’s strengths.

Expectations

People

I expect communication, simplicity, feedback, courage, and mutual respect. These are the values espoused by Extreme Programming, and regardless of what you think about that particular ball of wax, I think they’re pretty good ones.
I expect you to work as part of a team. Your primary delivery responsibility is to your team, and your goals should be aligned with the team’s goals. You own work as a team; you introspect and adjust as a team; you succeed or fail as a team.
I expect you to adhere to, and work to change, the policies the team sets. Examples include the way your team approaches remote work, standups, and core hours. Some of these policies may depend on the organization, but often they’re changeable, and you have the right and obligation to change them.
I expect you to bias towards incremental user-visible change. Giant leaps in software emerge from lots of small steps, with plenty of healthy self-correction along the way. A changeable codebase (or product, or process, or architecture) is better than a perfect one.
I expect you to act with imperfect information. Having autonomy to make decisions means operating in an environment with ambiguity. This is a cost we pay for speed and ownership, not a virtue in itself. Seek clarity when you can, but don’t let uncertainty become an excuse for inaction.
I expect you to invest in yourself and your community. You own your career and I want and need you to continue to focus on your own learning and growth. I’m overjoyed to enable you in this and provide what support and coaching I can, but it’s not solely your manager’s job.
I expect you to hit meaningful deadlines. When a deadline matters—to customers, to the business, to a launch—and your team has done its honest best to plan for it, I expect you to hit it. Scope is almost always negotiable; communicate early if you need to cut. That said, I don’t think it’s useful to fix both scope and timeline, and I won’t penalize you for missing arbitrary dates.
I expect you to bias towards high-quality engineering practices. More below.

Software

We’re all on a learning journey, all the time, and we won’t always agree on individual practices; I’ve been wrong in some of my choices in the past. That said, I have certain engineering practice expectations that I hold for my teams. I’m happy to discuss any or all of these at length. I believe they are generally applicable across platforms and languages.

I expect you to take quality seriously and approach it with rigor. Quality here is defined expansively: the structure, readability, and testability of the code; the operations of the system; the observability of all its constituent pieces; the developer experience and feedback loops; and the design of the user experience. Ignoring any of these will hurt team safety, and severely hamper most teams’ ability to move fast and ship great software.
I expect you to do the simplest thing that could possibly work, starting from a concrete need and working backwards, and to iterate from there. I like Kent Beck’s formulation of the Unix Way (“make it work, make it right, make it fast”, in that order) and his rules of simple design, and Henrik Kniberg’s Testable/Usable/Lovable.
I expect you to build, test, deploy, and operate the systems you create by monitoring them and going on-call for them. This ideally creates a virtuous feedback loop: an engineer on call for their own systems will tend to build them in a way that holds up in production, and write code they can debug easily if they get woken up. I like the Charity Majors definition of “observability”.
I expect you to merge or push to main (trunk) once or more a day. Trunk-based development is a strong predictor of good software outcomes. If that’s not possible in our environment then I’d love to work together to explore if it can become possible. I will be your advocate for prioritizing technical work to achieve this goal.
I expect you to ship often and refactor often. It is better to ship something imperfect and iterate in the open than to polish in private. You do not need to ask permission to refactor. I expect you to understand the Martin Fowler definition of the term “refactoring”.
I expect you to collaborate at least some of the time to prevent silos, to grow and learn from your peers, and to clear blockers. I’ve worked on teams that successfully adopted collective code ownership and full-time pair programming; I don’t think it’s necessary or practical to expect every team to do so, but doing so taught me the value of working together.
I expect the rules to change during a crisis. I have different expectations for emergency situations: command-and-control and clarity of communication become paramount, with a particular focus on rapid mitigation of the issue at hand.

What I Won’t Do

I won’t (generally) erect an individual backlog, or a one-person team, for you and your particular skillset. You are part of a collective that exists to solve a shared problem. I will help reorient your team’s understanding of the problem around your skillset when it’s a critical differentiator.
I (generally) won’t review your code or estimate on your behalf unless I’m acting as a member of the delivery team or you ask me explicitly for my take. I have some strongly-held technical opinions, but as a manager, I won’t always have a deep grasp of the particulars of the problem you’re working on. I would be happy to give you feedback on your code or pair with you if you ask me to do so. (My Ward Number is 2.)
I won’t let you off the hook for the simple stuff. Show up on time. Be present and committed, prepared and honest. Communicate with others. Honor your users. Be kind to your teammates. Take this work seriously.

Books, Talks & Articles

I recommend each of these for the way they may alter how you approach software work. Depending on role and seniority, I may ask you to familiarize yourself with some of them depending on context. I’d appreciate feedback and recommendations.

For Current or Aspiring Managers

I think a lot about management practice, which I interpret here holistically as inclusive of the management craft itself as well as process and product thinking. Being a manager is hard, and will challenge you eventually; read up.

The Goal, Eliyahu Goldratt (book) — How to think about optimizing complex systems. The Phoenix Project and The Unicorn Project are modern adaptations for the software industry, but this is the original.
Accelerate, Nicole Forsgren, Jez Humble & Gene Kim (book) — The few engineering KPIs we can point to with any confidence.
Extreme Programming Explained, Kent Beck (book) — A bit dated now, but the best early Agile software process guide.
High-Output Management, Andy Grove (book) — An interesting and useful way to think about what a manager is and does. A useful work to pair and contrast with…
The Manager’s Path, Camille Fournier (book) — You may not agree with either of these books, but they present contrasting pictures of what management is and should be—one more old-school, the other people-forward—and it’s useful to familiarize yourself with the debate.
The Lean Startup, Eric Ries (book) — A cliché classic that’s still worth a read.
The Art of Action, Stephen Bungay (book) — An interesting way to think about cascading objectives down, though it’s a bit too martial for my tastes.
The Tyranny of the Plan, Mary Poppendieck (talk) — A classic Lean treatise on how to think about process, delivered by a master software practitioner but using the Empire State Building as a case study.
Team Topologies, Matthew Skelton & Manuel Pais (book) — A practical framework for organizing teams around flow of work. Not everyone adopts it but it’s a useful framework that’s had significant impact on thei ndustry.

For Independent Contributors

These are specifically chosen with mid-level ICs in mind; I strongly suggest that you read all of these by the time you’ve hit a “Senior IC” title.

The Pragmatic Programmer, David Thomas & Andrew Hunt (book) — Dated in specifics but the mental models (“tracer bullets,” “broken windows,” “DRY”) remain useful shorthand.
Continuous Delivery, Jez Humble & David Farley (book) — The foundational text for trunk-based development, deployment pipelines, and the practices that Accelerate later validated with data.
Designing Data-Intensive Applications, Martin Kleppmann (book) — The modern systems book. Comprehensive coverage of the tradeoffs in distributed data systems, from storage engines to stream processing.
Working Effectively With Legacy Code, Michael Feathers (book) — The canonical guide to making untested code testable. Essential reading for anyone working on systems that weren’t built with testing in mind.
My Philosophy on Alerting, Rob Ewaschuk (essay) — A great single-article guide to helping your team navigate the thin line between over- and under-alerting, and SRE work more generally.

For Architectural Thinkers

Every IC must be an architect eventually, not just the ones with “architect” in their job title, but not everyone will need to understand the craft at the start of their career. Many of these become more useful and relevant as you grow, and overlap in significant ways with the management items above.

Choose Boring Technology, Dan McKinley (essay) — This has changed my thinking dramatically, but harder than it looks to use it to guide decisionmaking.
Building Evolutionary Architectures, Neal Ford, Rebecca Parsons & Patrick Kua (book) — How to design systems that can change over time without requiring big-bang rewrites. Introduces fitness functions as a way to protect architectural qualities. Offsets and challenges big-design-up-front (BDUF) thinking.
Enterprise Integration Patterns, Gregor Hohpe & Bobby Woolf (book) — The canonical catalog of messaging patterns. Dense but essential reference for anyone building distributed systems that communicate asynchronously.
Stevey’s Google Platforms Rant, Steve Yegge (essay) — An important document on how different kinds of companies optimize, even though his analysis of Google’s woes is arguably incorrect.
Release It!, Michael Nygard (book) — A classic book on patterns for building robust distributed systems. Good war stories, too.
Your Server as a Function, Marius Eriksen (paper) — I find thinking about RPC this way very appealing (except for the Scala) and it fundamentally changed my approach to writing backend code.

For Software Philosophers

Simple Made Easy, Rich Hickey (talk) — Justifiably a classic, but I’ve found it difficult to put into practice reliably, as Hickey’s definition (correct, in my view) never truly took root, and because local simplicity doesn’t guarantee systemic simplicity.
Refactoring, Martin Fowler (book) — A lot of people treat this as a dropdown menu in their IDE rather than a way to approach code, but it’s best understood as the latter, and the entire thing is worth a read. Full disclosure: I am a reviewer on the second edition.
Fowler’s Bliki, Martin Fowler (blog) — I could have a whole section just with articles from the bliki. Many important concepts in software engineering have a canonical writeup on his site.
Inventing On Principle, Bret Victor (talk) — A visionary talk on the relationship between creators and their tools, and how immediate feedback transforms creative work.
A Philosophy Of Software Design, John Ousterhout (book) — A concise, opinionated guide to managing complexity. Complements “Simple Made Easy” with more concrete, actionable guidance.

For Historians Only

These talks and articles are interesting for the way they’ve affected how the industry thinks about software, but are unlikely to be relevant in your day-to-day work. If you’re the sort of person who enjoys reading primary sources on software history, this section is for you.

The Rise of Worse is Better, Richard P. Gabriel (essay) — A provocative argument about why simple, “worse” designs often outcompete correct, complex ones. The tension it describes remains unresolved.
The Little Schemer, Daniel P. Friedman & Matthias Felleisen (book) — A Socratic introduction to recursion and computational thinking. Whimsical but rigorous.
The Cathedral and the Bazaar, Eric S. Raymond (essay) — The foundational text on open-source development methodology. Some ideas have aged better than others.
Lambda: The Ultimate Imperative, Guy Steele & Gerald Sussman (paper) — One of a series of papers demonstrating that lambda calculus can express any control structure. Dense but foundational.
The Law of Leaky Abstractions, Joel Spolsky (essay) — The idea that all non-trivial abstractions leak is now conventional wisdom, but this is where it was articulated.
Folklore, Andy Hertzfeld et al — A collection of wonderful stories about the development of the original Macintosh, including firsthand accounts of Steve Jobs as a leader. My favorite, still entertaining and relevant today, is Round Rects are Everywhere!.

If you’ve made it to the bottom of this essay and you work for me, point out a round rect the next time we chat. I’ll buy you lunch.