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.
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.
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
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.
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.
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!