It may not be instinctual to link director Christopher Nolan and Looker founder Lloyd Tabb, but the two might view the world through a shared lens. A serial entrepreneur, Tabb has assembled development teams for his startups by classifying engineers by their superhero personas, rather than by standard roles. As Nolan created a reality that hinges on the counterbalance of heroes and antiheroes in The Dark Knight Trilogy, so does Tabb with his engineering team.

Tabb became enchanted by computers at an early age because he couldn’t figure out how they worked. It took him years to understand them on the level of microprocessors and flip-flop circuits, but once it clicked, he was off to the races. He became a database architect and language designer at Borland, a Principal Engineer at Netscape and the CTO of LiveOps, to name a few of his posts. Currently, he’s the founder and CTO of data platform startup Looker, where he designed and built a new way to think about data. Looker is on pace to end this year with over 500 of the most data-centric customers, including Etsy, Sony and Twilio.

After computers, the equally fascinating phenomena for Tabb are those who command them: engineers. As one himself, studying them is both an introspective and instructive endeavor. In this interview, Tabb outlines the four superpowers which you must have on your engineering team and shares how to best recognize and channel their powers. Also, he describes the profile of the engineering leader, who must corral but not constrain these heroes. Tabb’s take on star programmers and dev team dynamics will inform how you’ll work with your technical talent.

Parsing Powers from Prowess

In the quest to bring on excellent engineers, most startups slip into equating specific roles with inherent ability and motivation. “Front end. Back end. HTML. Javascript. Python. Don’t get me wrong — it’s important to check the box on specific development concentrations and languages, but don’t forget these are capabilities, not necessarily innate drive,” says Tabb. “Throughout the years, I’ve met candidates that have over- and under-estimated their abilities, but their answer to one simple question has never steered me wrong to date. I ask them: Tell me something that happened at work in the last year that made it a truly great day.”

Tabb’s question achieves two goals. Like most case-based interview questions, it prompts an answer that shows rather than tells, allowing the interviewer to draw her own conclusions. But more importantly, it separates their powers from their prowess. “Technologies change. Startups come and go. For the long-term success of both the engineer and me, I’m interested in what fuels the person, more than their last achievement. Then you can start to see where the love of work is coming from and the very depth of what inspires them.”

Over the years, Tabb has started to see patterns in the responses to these questions, creating categories of engineers who have joined his team. For some, the answer has been solving a hard problem that was intractable. For others it was, getting to demo a product they built. Some candidates’ days were made when a customer viewed the world differently after using something they created. “Having hired some of the candidates who I’ve interviewed I can say that what truly inspires you at work rarely changes. It’s part of your identity and the way you like to work,” says Tabb. “That’s the root of superheroism and what makes you powerful.”

AQUAMAN

Aquaman’s superpower is diving deeply. This engineer is driven by solving big problems. He may not write any code for weeks on end, but will continue to dive through layers of the API to find and tackle a challenge. This superhero is nimble and acrobatic enough to penetrate operating system, database and controller layers to dig for a bug. His rare ability is being able to understands the code of each of these levels well enough to know what’s happening.

“Early on, we had a bug in Looker in the SSL layer because we’re built on top of JRuby [Ruby on the Java VM]. Our Aquaman spent a month hunting the bug through JRuby, and then throughout the Java VM and down into the SSL networking layer,” says Tabb. “If I didn’t have that guy who could hold his breath and had the stamina to dive to the bottom and get that SSL bug, we’d be in trouble. Looker would freeze occasionally because of it, and we wouldn’t stay in business long with that happening. He persisted, found the bug and fixed it.”

Stated conversely, the kryptonite for Aquamen is working on standard websites, such as building basic functionality for an ecommerce site. They want a challenge. “They’re not about UI or UX, and could care less about how it looks or how the user perceives the product. They’re about how it works in a very deep way,” says Tabb. “At Looker, we’re a distributed application. We’ve written our own web server. We need an adept, expert diver to navigate those waters.”

Aquaman in Summary

• Inspired by: Deep problems. By how software fundamentally works — and where it doesn’t.

• Strengths: Really good at solving very hard problems; fluent in all layers of the API.

• Behavior: Has a singular focus and incredible stamina; might not write any code for weeks.

• How to manage: Emphasize mission not metrics; don’t measure by number of deadlines met or sprints finished.

• Misuse: This hero needs deep problems. If the ocean is shallow, it’s not a good fit.

• Failure mode: He doesn’t come up for air and drowns. Make sure he’s got freedom to move and oxygen (resources) to sustain his dive.

Engineering superheroes have distinct abilities, but they all share a weakness: the misuse of their powers.

THE FLASH

The Flash’s superpower is speed. Of all the engineers, the Flash knows it’s the demo that inspires. She lives for the thrill of people seeing her work in action. “Look at what I made” is her battle cry and her best moments are when she can say it. While others discuss what can or can’t be done, the Flash zooms away, makes a prototype and is the first to demo. It may not be perfect, but it functions. That’s because she firmly believes that making something to play with is the best way to get a feel of its potential and understand it better.

“As the name suggests, The Flash is interested in what’s fast. She can sit down, start coding and get it knocked out pretty quick. Ultimately, she helps steer the boat by actually getting out there in front and demoing,” says Tabb. “The Flashes who I work with hear a problem in the afternoon and demo a solution in the morning. They are overnight achievers and they have a big toolbox. I’ve known Flashes that work in Tcl — where a line of code is parsed only once — because it’s so fast. Or in Perl, for real-time programming. Whatever takes fewer strokes.”

Of her engineering counterparts, Flashes are the tip of the spear. “They may be sharp. They may be blunt. But they will be first,” says Tabb. “That means that there’s likely a team of people who will clean up after them. They are inspired — and messy — cooks.”

The Flash In Summary

• Inspired by: Speed and exposure. Getting software to end users. They’re less driven by how it works and much more concerned with what it is.

• Strengths: Really good at cranking work out quickly and reading other people’s code.

• Behavior: Practices incredible speed to share work; produces code with each breath.

• How to manage: Let them lead the charge and quickly test code. Create structure or environments where you can minimize the mess.

• Misuse: This hero needs to be on the vanguard. Don’t hold them back with procedures.

• Failure mode: The dev team can get frustrated with the Flash’s code and not want to work with her. If unaddressed, it can create enough unease that messy code outweighs her pioneering discoveries.

The Flash starts on the foundation of a house while others mock up a blueprint. With an architect’s mind but a contractor’s instinct, this engineer builds to show vision.

THE PRIEST

The Priest’s superpower is righteousness. The Priest is the engineer who is inspired by order and code quality. He fundamentally views an API as a legal contract, which anticipates user behavior and codifies a user’s interaction with software. He sees the world built from rule-based exchanges of requests sent and responses given through software. A great Priest cleans up messy code and makes a contract understandable to all, an act which not only inspires him but also reaffirms his sense of order.

“While the Flash is interested in what a program does, the Priest is really in love with the act of programming to a higher degree. He honors pull requests and code reviews, which both refine his sense of order and make code more understandable to more people,” says Tabb. “While this collaboration may seem to put process over progress, it can also speed things up because his code is less likely to have bugs from the beginning than that of the Flash or other engineers.”

Every programmer is inspired by the order of things, but there’s a level of orthodoxy that is not just practical, but academic in nature. The Priest embodies a sacred commitment to order. “However, this dedication can tip into stubbornness, especially for a Priest who is frequently right. That’s when this superhero turns into a villain called The Zealot. This anti-hero can wreak havoc on a team with his unwillingness to yield on certain frameworks. We once had a Priest-turned-Zealot, whose damage required us to rewrite all his code. It was disastrous.”

Lastly, Priests gone awry can also become Bakers, who like APIs to an extreme degree and turn to them too frequently. “The Baker builds APIs on top of APIs, like unnecessary layers of a cake,” says Tabb. “Unlike the Zealot, the Baker is not driven by ego and being right, but by the use of one tool for every problem. With hammer in hand, everything looks like a nail.”

The Priest in Summary

• Inspired by: Responsiveness. By making it easy to ask the software to do something.

• Strengths: Fantastic at abstraction and very skilled at building beautiful APIs.

• Behavior: Has a singular focus and incredible intellect; can get ornery sometimes and refuse to work on specific code.

• How to manage: Let them process and prioritize through structure. Give them cross-functional opportunities to work and verify their system with other engineers.

• Misuse: Don’t give them the prototyping or quick turnaround projects (best suited for the Flash).

• Failure mode: Bad Priests become villains. They are two main types: Zealots and Bakers. The first becomes fanatical about frameworks because of ego, while the second uses APIs as the answer to everything because it’s his only tool.

THE SPIELBERG

The Spielberg’s superpower is telepathy. With technology, that happens when the software communicates without words. “Some of the best engineers of this profile type who come to mind studied film. They’re inspired by its form of storytelling and bring that discipline to development,” says Tabb. “When they look at a screen, it communicates to them in a variety of places. For example, they’d look at Google Docs and see the Share button as a composite of its attributes. It has a lock, which means it can be opened and shared. It’s blue and in bold to attract attention and interaction, while other buttons like ‘bold’ and ‘italics’ are smaller and grey because they are old conventions. These engineers are inspired by those nuances.”

The Spielberg likes to make software, but only when it communicates well and if it works just the way you’d expect it to from a usability standpoint. Each component must say the right thing, either explicitly or tacitly. “I remember when a Spielberg came in to help us on our IDE (integrated development environment). Early on, it was very rough. But in a short period of time — he was a Flash Spielberg — he made it so much more intuitive and fluid,” says Tabb. “There’s a distinct understanding of visual language versus computer language. I think in film, it’s foreshadowing and non-direct communication. It’s a signalling communication.”

The Spielberg in Summary

• Inspired by: Tacit communication. Clean, simple user interfaces and design aesthetic.

• Strengths: Masterful at knowing the purpose of the software — and what users want from it.

• Behavior: Continually draws attention back to the user and to the software’s purpose. Grows uncomfortable when the user interface is substandard.

• How to manage: Pair with the product team. Be very careful when you hire, so you don’t have to fire. Given strong aesthetic beliefs, you’ll need to respect their opinion. If you don’t, it’s over.

• Misuse: Give creative latitude. Don’t keep them on a constrained, narrow problem set.

• Failure mode: They tend to overreach with their strong design capabilities and ability to intuit others’ behaviors. They can become overbearing and overstep boundaries with rest of team. To avoid this, balance the rest of the team’s feedback with their input.

The Spielberg facilitates the exploration — not explanation — of software. It’s not about popping up to ask users to share. It’s a suggestive robin blue button with a lock on it.

The Paladin and the Art of Engineering Management

There must be a leader of this cast of powerful engineering superheroes. It’s the engineering manager who must command but not restrict these talented developers. “There are some common traits of really good engineering managers. I’ve known several of them and they’re really rare,” says Tabb. “They’re almost all paladins. Historically, paladins are the premier warriors of Charlemagne’s court, but for those familiar with World of Warcraft, they are both warriors and healers. The most important trait of an engineering manager is that she must be able to heal her team.”

Tabb makes this parallel, because of how different — and more appealing — the programming world is for many engineers compared to the business side of a startup. “The ability to heal any injuries that occur from the interface between the business side and the software side of a startup is the job of the engineering manager. As a Paladin, she keeps the team healed and protects the powers of her engineers,” says Tabb. “It’s also about bravery in the face of authority. Someone is always telling engineering what it should do. If it’s not welcome, Paladins absorb the heat, shrug it off and shield the team from the pressure so they can perform.”

Aside from healing, a Paladin must keep order among her heroes, given their distinct powers and often counteractive ways of operating. This requires recognizing their powers, not misusing their abilities and having them work well together. “Here’s a quick cheat sheet for your primary heroes: Aquaman flies solo so is generally easy to manage in a hands-off way, though you must check-in to make sure he has interesting problems to solve and remembers to comes up for air,” says Tabb. “The Priest and Flash are the hardest two heroes to get together and make appreciate the other. The important thing is to acknowledge their strengths publicly until they start to respect them in each other privately.”

What It All Means

Tabb’s superhero classification is a way to recognize the unique faculty of your exceptional engineers, and, in doing so, create the optimal environment for them to flex their powers. Ironically, Tabb had challenges characterizing himself. At different junctures, he commented that he was an Aquaman to a degree, but had a little Flash in him, too. He knew that Priests have a hard time with him and that he was sure he wasn’t a Spielberg. But in deeply knowing how to propel and protect all of these hero archetypes, he revealed himself as a Paladin.

“Listen, we all want to feel valued. What it comes to is this: our engineers do tremendous work. They’re superheroes. On a regular basis, people deliver work that changes the future of our company. It happens all the time. That’s where the future comes from and the engineers need to feel that,” says Tabb. “The Priest says, ‘Our future becomes better because our software is built so well that it will last forever.’ The Flash says, ‘I see a vision of the future in what the software might be. We see a glimpse, get inspired and do that.’ The Spielberg says, ‘The future is when users understand what we do because the software is so intuitive. It communicates.’ The beautiful truth — which the Paladin knows all along — is that they’re all correct.”