Now that I’ve been asked several times, there’s finally an answer about this site’s theme. It’s free! Freshly extracted for your re/use, you can file issues, contribute fixes, or grab the base stylesheet and source files from Github, where they’re available under the ISC license.

Ask, ask, and ask again. You’ll receive!

Teamwork depends on communication. Alignment, autonomy, and accountability—the building blocks of happy, productive teams—won’t happen without it. Nor will useful feedback, or personnel conversations that are anything more than downright uncomfortable. Small surprise, then, that Kim Scott’s Radical Candor measures managers by their ability to share timely, direct criticism, and devotes its bulk to helping them deliver.

The first rule of Radical Candor is to “care personally.” Readers won’t need Scott’s background as a manager at Google, and later training managers at Apple University, to recognize the importance of personal relationships. In an era that idolizes superhuman individuals, it’s all too easy to lose track of the different situations and motivations represented within group. Get to know them. Build trust.

The second rule, “challenge directly,” demands frank, frequent feedback. To deliver it without being obnoxious, managers must lean on the existing trust and caring within their team, but—where that trust exists—direct challenges help the team exchange criticism and find the right path. Solicit feedback. Offer it in turn. And celebrate the challenges and sense of agency that result.

At its heart, Radical Candor is a guidebook to the happy path between “ruinous empathy” (the domain of the too-nice boss, uncomfortable correcting mistakes or giving honest feedback until it’s too late), “obnoxious aggression” (candor without caring), and “manipulative insincerity” (which lacks both communication and caring). At its end lies an environment where managers care and their teams are comfortable challenging them.

None of these are radical ideas, but Radical Candor packages them up with excellent prose and memorable examples. Even for those of us working outside blue-chip tech companies, the reminder to develop relationships–and to leverage their results–are well worth a quick read.

We ship some pretty crazy things when we think that customers aren’t watching. You’ve seen them: the mysterious scripts underpinning critical systems, or the Craigslist-chic GUI that gives the support team its superpowers. Take off the shackles of usability, security, and future support, and just see what we can build.

The results lend themselves to a fun little game that I like to call “spot the root cause.” The rules are simple: when you encounter an internal tool, ask yourself “why?” When you finally track down an answer–likely an internal-only interface buried a bit deeper down the platform–ask “why” again. Keep unraveling the thread until you arrive at the original, distant-past decision marked “for internal use only”. Well done! You’ve spotted the root cause.

Three Little Costs

If we know where the journey ends, why embark in the first place?

Internal-only has its allure. When we stop building with customers in mind, we can cut corners and develop at a breakneck pace. But “quick and dirty” has a nasty habit of auto-correcting to “unusable, maintenance-deferred.” Only later do we recognize the unexpected costs that a cavalier approach to quality tends to incur.

The first we notice is time. Even hacky programs take time to write and debug, let alone (perish the thought) to maintain. Next come their users, ticking away the minutes frustrated by quirky interfaces and the complete absence of documentation. For developers and customers alike, time spent wrestling against arcane tools means less time delighting customers, shipping world-changing products, or watching the kids grow up at home.

The second cost is reuse. Internal tools don’t break customers, and–in the best case–the internal ecosystem can be a valuable incubator for new technology. It’s important, however, to recognize the distinction between a tool used internally and one built for internal use. Is the tool maturing with an eye to eventual generalization? If not, it will eventually need to be thrown out and rewritten.

But the biggest cost of building for internal use are the opportunities that get shut out. Every tool is a potential product. It addresses a problem shared by at least one of the other seven billion warm bodies heating the atmosphere. Sharing isn’t just a nice thing to do: it’s also potentially lucrative (in social capital, if not revenue). Few of us are going to follow Tiny Speck and drop everything to follow an internal tool, but neither should we ignore opportunities our own needs uncover.

A Little Respect

Foregoing internal tools doesn’t mean a blank check to prototype in production. It’s simply the recognition that everything has a customer. We don’t have to be fanatics about it (it works for Amazon, of course, but then most of us aren’t Amazon) to reap the fruits of a little self-respect. We wouldn’t sell a lousy tool to our customers, so why inflict it on ourselves?

The next time you win a game of “spot the root cause”, take a good hard look at the problem unraveled before you. Could someone else’s open-source tool obviate it? Or could this be the start of a solution to someone else’s problem? I bet it could.

Let’s make it official. Here are some nice, shiny digital stickers ready for the sticking on your (proudly) open-source tool. Use them anywhere!