WTF Just Happened at Khan Academy

TLDR: we have a new team called “WTF” focused on what might be termed meta-engineering: expertise in the practices, tools, and culture of a modern-day software team.

Matthew Rothenberg
5 min readFeb 2, 2016

When I first came to Khan Academy last year, I discovered one of the healthiest engineering cultures of any software team I’d ever seen. Just ask the handy Slack Bot:

Khan Academy’s Culture Cow Slack bot dispenses wisdom.

Most importantly, core to KA’s dev culture is the notion that “anyone can fix anything.”

In such an environment, starting an entirely new functional team within the engineering organization to focus inward might seem strange—Our engineering culture and practices were already pretty darn good. However, we asked ourselves: What if pretty-darn good wasn’t good enough? What if our goal was to make Khan Academy the absolute best place in the world to be a software developer? What would we do then?

So WTF is it then?

WTF is focused on how to build software as a team — everything from process management, to tooling, to making sure engineering best practices are well defined yet evolving, to improving how engineers & designers interface with the rest of the company.

Members of this team are software engineers who work on the same project list and teams as everyone else. We felt it was critically important to not create a separate service organization, and since KA already has a culture where any developer is allowed (and expected) to implement these sort of changes, people jump between different types of projects all the time.

Rather, just like some engineers choose to focus on front-end or mobile or infrastructure as their primary area of expertise (while still working across the stack as needed), we wanted to recognize another growing functional area of focus. One might call it “meta-engineering” — expertise in the practices, tools, and culture of a modern-day software team.

So while members of the team work on all sorts of projects, they are expected to use their time embedded in those projects to develop this expertise: troubleshoot process, introduce and trial new ways of working, and develop best practices. The commitment from management to someone on this team is to explicitly help provide mentorship and career development opportunities along those lines.

The Hardest Problem in Computer Science is Naming Things

In defining this team, we were still having a particularly difficult time with one particular aspect — seemingly the most basic part: WTF to call it.

Many organizations have a “Internal Tools” team, but we knew that wasn’t right for us. Internal tools typically means “building things used internally outside of the core product,” whereas we want to be focused on “how the team that building the core product works.” (Also, at far too many organizations, this unfortunately becomes the unoffical “dump all the unglamorous projects no one wants to touch here” department, and we certainly want to avoid that stigma.)

Twitter has the notion of “Engineering Effectiveness,” which sounded closer on paper, and certainly more broadly defined. But I was stuck with a few fundamental differences with the way it was discussed and some of our aims:

  • We care just as much about developer happiness as we do organizational effectiveness.
  • We want to address cultural issues, not just technical ones.
  • Don’t become the Department of Saying No™. One of the key guidelines we established early on in thinking about this was “it must enable and push us to say yes to more.”

In terms of prior art, the spirit we want to embody is most closely aligned with Ernie Miller’s concept of “Humane Development,” which focused on taking a holistic and human-centric approach to software development.

But what do you call a functional team around pushing those concepts forward?

When discussing what we wanted this team to be, a particular anecdote kept coming up about the process by which “suboptimal” things rarely get fixed (as told by Julia Evans to Dan Luu):

new person joins
new person: WTF WTF WTF WTF WTF
old hands: yeah we know we’re concerned about it
new person: WTF WTF wTF wtf wtf w…
new person gets used to it
new person #2 joins
new person #2: WTF WTF WTF WTF
new person: yeah we know. we’re concerned about it.

At one point, in exasperation, I said “why not just call it WTF?” as a joke, and it kinda stuck. We quickly came up with something that fit that acronym (“Workflow Task Force,” I believe, but that varies based on who you’re talking to at the moment), but the reality is the name was simply meant to invoke the spirit of this anecdote.

Things I should have learned from classic Simpsons episodes: “His name isn’t important!”

…But yeah, there is actually a box on the org chart now that literally says WTF on it. Whoops. My bad. Maybe we’ll change it later. Maybe not. But it seems to be working for now!

The primary point of writing this post was to share our efforts in thinking towards this, so that we can begin to engage in public dialog with others in the industry about their experiences. If your organization is working on something similar, I’d love to talk.

Some early goals

Focus on the holistic experience of the developer, not just tools. The experience of being a productive and happy software developer on a team is defined by much more than the tools one uses. (As an example, the first few initiatives WTF team members have been working on have ranged from scaling how we track bug reports to containerization of our dev environment to encouraging diversity through our hiring practices.)

Enable thoughtful change. We never want to be too comfortable, or become complacent with the current state of things. On the other hand, we value thoughtful approaches to problems, and are extremely skeptical of the stereotypical Silicon Valley “disrupt all the things for the sake of disruption!” approach. Focus on thoughtful solutions to benefit the entire team (including those who haven’t joined yet), and go beyond existing best practices when possible. In short, build the industry we want to work in.

Learn from remote work. Khan Academy currently has dozens of full-time remote engineers (while not a majority, a significant percentage of our small and growing team) whose needs can be better supported — but more importantly, our increasing focus on remote work is teaching all of us a ton about more effective and healthier ways for us all to work.

The Obligatory “Yeah, We’re Hiring”

Well, if I’m going to make this post public I’d be remiss not to mention this as well. So uhm, in my unofficial wording: We value people who are skilled yet humble, as excited to teach as they are to learn, and believe in the promise of technology to make the world a better place for more than just a small set of privileged individuals. (Also: we may be a non-profit, but we compensate fairly.)

If you think this might be you and you are particularly interested in WTF, please reach out to me directly.

--

--

Matthew Rothenberg

Artist + hacker. Made @emojitracker & other internet detritus. Past lives: @flickr, @bitly, @polaroid, @khanacademy.