Useful links I’ve collected and my short takeaways. Find more detail in the linked articles.

Customer Support

Please, go away

If customer retention matters at all, invest in quality support that’s easy to get. Making it hard to get useful help shows your customers that you don’t care about their pain and encourages them to go elsewhere.

First, de-escalate

The beginning of your interaction with your customer sets the tone. Make things easy, welcoming, and affirming to quickly establish trust and pave a smooth road forward.

Yes == No

Many unreasonable-seeming customer requests aren’t intended that way - the illusion of transparency means the requester may be legitimately unaware of why it’s not reasonable. As long as there’s benefit of the doubt, don’t treat this as an adversarial interaction - treat it as a collaborative one. Explain why it’s unreasonable and bring the requester into your world.

Tiered Customer Support is Dead (And Why That’s Good for Business)

Support teams should be highly collaborative rather than siloed off (especially by tier). This leads to better experiences for the customer and for Support, as well as better education and sense of community for Support.

Survey questions

Customer surveys seem easy and low-cost, but if they don’t respect customers' time and don’t lead to follow-up action they often cost more in good will than they gain you in insight.

(This is also true of employee surveys, by the way.)

5 essential tips for customer care people dealing with technical queries

The normalization of Twitter as a customer support channel has resulted in many customer interactions happening in public. Take these exchanges seriously and move any nontrivial ones to DMs as soon as possible.

See also these tips for support via Twitter.

Service Support

My Philosophy on Alerting

Work hard to avoid noise in alerting systems. Pages should be urgent and actionable. Non-urgent alerts should go into a ticketing-like workflow.

Help Your Fellow Developers with Well-Worded Error Messages

Error messages should include suggested solutions.

So You’ve Been Paged: A Guide to Incident Response (For Those Who Hate Being Paged)

A useful generalized framework for how to respond when paged out. The core is a loop of “Communicate -> Learn -> Act.”

Incident updates, interruptions and the 30 minute window

During outages or other incidents, get in the habit of keeping the incident manager informed at least once every 30 minutes. Incident managers should interrupt and ask for status only if 30 minutes passes without an update.

“This should never happen. If it does, call the developers."

To reduce the need to escalate from support/ops to developers, create runbooks describing how to resolve the urgent alerts the service can trigger. Any time the runbook is insufficient to resolve an issue, escalate to dev and improve the runbook with whatever would have prevented that escalation.

User Experience

7 Practical Tips for Better Microcopy

Simple rules with examples for ways to improve “microcopy” - small bits of text in UIs like feedback messages and calls to action.


In defence of the technical interview

Coding tests can be good, so long as they are objective, quick, allow use of real editors (no whiteboards), and have the interviewer investing just as much time as the candidate.

Some bonus thoughts on designing these tests.

A Humility Training Exercise for Technical Interviewers

To reduce bias, interviewers should go through what candidates go through. One strategy is to do role-play interviews, and you can encourage honest feedback from the “interviewer” by having the “candidate” deliberately provide poor answers to some questions and not say which.

40 Favorite Interview Questions from Some of the Sharpest Folks We Know

A list of motivation-type conversation-starter questions and what people get out of them. I don’t like all of them, but there’s some good inspiration here.

Diversity isn’t only skin deep: Accommodating autistic and neurodiverse people

Interview processes (and workplaces) are often unintentionally hostile to neurodiversity, blocking you off from people who could be great additions to your team. With a little effort and flexibility, some simple accommodations can go a long way to fixing this.


The (Real) 11 Reasons I Don’t Hire You

There are many reasons to reject a candidate that have nothing to do with the candidate not being “good” enough.

Heroes and Juniors: Increasing Engineering Team Velocity

When scaling up, it’s good to hire junior as well as senior employees. This improves organizational velocity and improves growth opportunities for everyone involved.

Preventing the bozo explosion

Another useful heuristic: only hire people you’d want to work for.

Focus on building 10x teams, not on hiring 10x developers

People don’t work in isolation, so don’t optimize for hiring the people who are best in isolation. Optimize for people who will improve the team.

How to build up a data team (everything I ever learned about recruiting)

A number of useful thoughts on recruiting and whom to hire. My favorite rule of thumb is that when considering a senior person, if all the interviewers are impressed you should hire but if they’re on the fence you shouldn’t, while interviewers on the fence about a junior candidate’s skills should consider how excited the candidate is.


How To Use Your Unfair Advantage To Create an Unforgettable First Day For New Hires

Jump-start new hires' connections to their teams by doing something special and personalized for them on their first day. This is probably even more important for remote/distributed teams.


‘Give Away Your Legos’ and Other Commandments for Scaling Startups

“[A]t a scaling company, giving away responsibility . . . is the only way to move on to building bigger and better things.”

The second half of the article is also an interesting look at the typical growing pains companies go through at each level of scale and tips for dealing with them.

Why Big Teams Suck: Seven (Plus or Minus Two) Is the Magical Number Once Again

Teams as individual work units should generally be kept below seven or so members. Larger teams are likely to be harder to coordinate and have reduced empathy.

Independence, autonomy, and too many small teams

Coordination overhead between teams is not reduced by having smaller teams; it’s reduced by having teams with more autonomy - teams whose mission/metrics map directly to a customer goal and who can thus generate business value independently of other teams.

Decision Making

Daniel Kahneman’s Strategy for How Your Firm Can Think Smarter

When choosing between alternatives, a little bit of quantification goes a long way. Come up with five or six dimensions on which to rate each option. Only after doing this, come up with the overall rating.

The Remarkable Advantage of Abundant Thinking

You can be in “scarcity” mode, feeling powerless and just reactively trying to survive, or in “abundance” mode, feeling in control and proactively finding ways to thrive. Scarcity mode is a trap - it drains your energy and prevents you from seeing and taking advantage of opportunities. While it can be triggered by very real pressures, ultimately it’s a choice. Take the effort to step back, discard assumptions, and see your situation fresh.

Turning paradoxes into problems

There are sets of constraints that simply can’t be simultaneously satisfied; you need to remove at least one of the constraints to turn it into a problem that can be solved. Drop low-value goals to make high-value ones achievable.

Favourite Diff

Avoid learned helplessness. When something is causing you headaches and you find yourself complaining about its unavoidability, take a step back and consider whether it might actually be fixable.

Why This Opportunity Solution Tree is Changing the Way Product Teams Work

When working on complex, poorly-structured problems (like “what feature should we build next”) you can avoid a lot of traps by using a strategy such as an opportunity solution tree to carefully frame the goals and options. This can be very helpful for prioritization, for justifying decisions, and for ensuring you’re managing by outcomes and not just outputs.

No Kings: How Do You Make Good Decisions Efficiently in a Flat Organization?

Seek “rough consensus”: “If there is a good enough solution X, don’t ask people what they think about it. Instead, ask everyone if they can live with it and if not, why.”

Project Management

Understanding critical path

To speed things up, prioritize based not on shininess or even impact but on what blocks success in a way that can’t be parallelized.

What is a Feature Factory?

Bad things happen when a product team measures by outputs instead of outcomes.


Do It Now

Keep a to-do list, but if you’re about to add something to it that you could reasonably do now in a couple of minutes, just do it now instead.


Highlights from “The Checklist Manifesto” by Atul Gawande

Efficient, clear, easy-to-follow checklists that remind of critical steps are incredibly valuable tools to prevent costly and destructive errors.

How I Almost Destroyed a £50 million War Plane and The Normalisation of Deviance

A process that isn’t followed is no better than no process. The normalization of deviance must be actively fought - any WTFs should be flagged and dealt with, and if a process isn’t being followed that should be dug in on and the process updated as appropriate.

The Null Process

Failing to define a process results in unspoken expectations, encourages bias, and sets people up to fail. It’s better to have light-weight processes (especially checklists and automation) which are defined collaboratively and allowed to evolve as things change.

To Get People to Change, Make Change Easy

Make it easy to do the right thing and hard or impossible to do the wrong thing.

The Process Myth

Explicit process is increasingly important as an organization scales, but when adding it be sure to write down the why and how the process encodes your values. This can head off Chesterton’s fence problems and make it more likely that good process will survive and bad process will change or die. (You can take this even further and write down explicit, measurable outcomes that mean it’s time to change the process.)

There Are No Bugs, Just TODOs

I don’t agree with every single detail of this, but it’s a great example of how to frame an issue workflow process. Key takeaways include: every issue needs a clear owner, there must be a single ordered queue, and most metadata (including state beyond “todo”, “doing”, and “done”) should be viewed with extreme suspicion.


Asynchronous Communication: The Real Reason Remote Workers Are More Productive

While some synchronous communication is needed, a lot of improvements come from structuring your work and communication to be as asynchronous as possible.

BLUF: The Military Standard That Can Make Your Writing More Powerful

Put your main point first and make it clear.

Don’t be spooky

Provide context so that people don’t assume the worst.

How to ask good questions

When you’re seeking information from a coworker, the best thing you can do is ask a question that’s easy to answer.


When naming things, don’t get cute. Clarity is far more important than cleverness.

How I Slack

Some tips on getting the most out of a busy and crowded Slack server. For me, the most valuable things are showing only unread/starred channels and using the CMD/Ctrl-K Quick Switcher.


Radical Candor - The Surprising Secret to Being a Good Boss

Feedback needs to come from a place of caring personally but must challenge directly. Indirectness can’t help someone improve and uncaring feedback won’t make them want to. From a foundation of caring and trust, you can have the hard conversation early and keep it constructive.

23 Tools to Make Your Feedback Meaningful

Feedback needs to be carefully framed as constructive, supportive, and about the work rather than the person. It also requires a psychologically-safe environment where people are comfortable speaking up.

When your coworker does great work, tell their manager

When a coworker does good work - especially work that’s usually underappreciated - make sure their boss knows what they did and the impact it had. (But get permission from the coworker just in case!)


Maker’s Schedule, Manager’s Schedule

Meetings are often scheduled by people whose work can easily be carved up into small chunks (such as managers), so it’s important to remember how disruptive they can be for people whose work requires extended engagement (such as software developers). Where possible, lean on solutions like designated office hours and meeting-free days, and make use of asynchronous forms of communication and knowledge-sharing instead of interruptive meetings.

How to Run a Meeting

Meetings need both agendas and referees to keep them useful.

Gossip, Rumors, and Lies

Regular staff meetings should discuss relevant metrics, team-sourced agenda items, and questions or issues shared by the team. The summary of the meeting should be shared publicly.


How to Rands

I need to make my own version of this document, but it’s a good starting point for a manual on working with me since I agree with a lot of Rands' views.

The Update, The Vent, and The Disaster

Have 1:1 meetings for at least 30 minutes at the same time each week. It’s for discussing meaty topics, not a status report. (See also this post on similar ideas from the perspective of the direct report.)

Regardless of seniority, every good manager will:

Serve their team and their people.

How to Create a Great Team Culture (and Why It Matters)

It’s up to leaders to mold their team’s culture. Healthy cultures require safety, connection, and shared purpose.

5 Reasons Your Top Employee Isn’t Happy

While I reject the implication that high performers are necessarily jerks, the listed reasons are solid: high-performing employees like consistent priorities, a focus on outcomes that doesn’t play favorites or reward mediocrity, and being able to work hard on the things they are good at.

Discovering the hypocrisy gap in reliability the hard way

If leadership doesn’t actually act on the problems they say they care about, the problems won’t get solved - and any others who do try to act on them may be seen as the problem instead.

Bad-News Boxes

By default, incentives will align to create “success theater,” burying bad news and preventing problems from getting solved. To prevent this, leaders need to create easy and safe avenues for criticism and feedback.

It’s not the bottom, it’s the foundation

It’s difficult but worthwhile to make sure culture and values flow throughout the entirety of an organization. It requires a long-term commitment to communication, fostering trust, hiring and firing for attitude rather than trainable skills, and consistently equipping and rewarding people for doing the right thing.

Bringing out the best in your game dev team

To bring out people’s best, specify the end goal and not the means to achieve it. Set goals that are challenging, clear, and meaningful.

How do managers get stuck?

Managers (or senior ICs) should improve their team’s effectiveness both internally (through delegation, training, process improvements, and prioritization) and to other parts of the org (through strong communication and relationships as well as taking appropriate opportunities to create value outside of established roles).


Developers mentoring other developers: practices I’ve seen work well

Informal mentorship happens all the time, and there’s often limited formal mentorship in the form of onboarding. Having longer-term formal mentorship that’s taken seriously by both parties and encouraged and rewarded by the organization is more rare but can be extremely helpful.


Give people a chance to solve their own problems before you jump in. If you solve everything right away, they won’t build up the needed tools and strategies to handle things without you.

You Screwed Up: The Value of Errors in Game Tutorials

When training, let people make errors and make it clear they are an expected, normal, and healthy part of the learning process.