Flat. It’s an organizational meme in rapidly growing teams in Silicon Valley, and it contains a couple of noble ideas. Simply put, a flat organization is one with as little hierarchy as possible to encourage the individual voice. What’s not to love?
The first challenge to the flat organizational mantra is the inevitable arrival of leads or managers tasked with organizing different aspects of the team. The flat religion’s answer to this development is rebranding of the role: the lead or manager is no different from the individual. It’s not a promotion, there is no raise; it’s just a different gig. There is no difference between those responsible for building the product and those responsible for building the people.
I love this. I love this because it’s the beginning of solving a core career problem in teams of engineers: How do we grow? As I wrote in my book Being Geek (O’Reilly, 2010), the curse of Silicon Valley is that great engineers are often promoted to leadership for their hard work. While many succeed in this role, an equal part fails because the skills required to lead are vastly different than the ones required to be an engineer. The curse is that we’re often placing our most valuable engineers in a role where they’re predisposed to fail.
Think of it like this: there’s a large population of immensely talented engineers that should not be leaders. There is no amount of training that would make up for the talent we’d extinguish by teaching them how to write annual reviews.
But everyone wants to grow.
Unfortunately, in many companies the only perceived growth path is via management. Yes, there are job grades and cleverly phrased job descriptions that confusingly define the various states of engineering experience and growth, but these are a joke. These are a distraction packaged as a solution to the fact that we don’t have a good idea how to systematically grow engineers outside the traditional management hierarchy.
No Ticker-Tape Parade
A solution begins with rebranding, by introducing the idea that managers and engineers are hierarchically no different. Keep the pay the same; don’t throw a ticker-tape parade when a new leader is minted. They are peers. I support this religion because a flat organization is one where power, accountability, and responsibility are equally distributed. But I do not yet understand how this idea scales.
Even with leads and managers who have the best of intentions, the moment they become responsible for folks—the moment everyone realizes they (figuratively) sign the checks—the relationship changes. I can’t yell at you because you sign the checks. This core change of perception isn’t just based on compensation, it’s based on a change of ownership and responsibility, and it’s the beginning of all sorts of potential cultural turmoil that’s worthy of an entire additional chapter.
We need leads and managers as a means of scaling responsibility and communication, but we need to dispel the idea that their roles are also the exclusive owners of decision-making.
As a solution, I offer the DNA meeting.
Five Kinds of Win
DNA stands for design ’n’ architecture. At its core, DNA is just a meeting. It’s a collection of bright engineers from across the team or the company sitting in a room tasked with a specific purpose. As the name DNA suggests, these engineers are responsible for deep analysis regarding decisions and directions core to the product. You probably already informally hold this type of meeting when faced with a big technical or design challenge. You gather together an informed set of eyeballs to vet the challenge. DNA makes the informal formal and it has five kinds of win:
It shines a light brightly. While the more eyeballs you get on any decision the better, the DNA meeting is scheduled when something technical is going down. Something big. Something of magnitude. It’s not a bet-the-company decision, but it might be a bet-the-group —or the division—decision. If we fail at this, the consequences are extreme. This is why when a DNA meeting is going down, you . . .
Bring respectable firepower. I’ll talk more about the construction of the DNA team in a bit, but I want you to think of the three best engineers around you. I’m not talking just about those with ability, but also the folks who go out of their way to teach—the engineers who not only know what they’re talking about, but have the ability to explain their thinking. They shine a bright light on the idea by making the complex painfully obvious. The DNA team is not only the set of engineers who are the best candidates to vet the big idea, but those who have ability to talk about how to make it better, can constructively criticize, and are distinctly drama- and politics-free.
It has teeth. You can gather all the talented engineers you want, but what will make the meeting useful and memorable are two threats. First, the rule for all attendees in a DNA meeting is, If you don’t contribute, you won’t be invited back. A DNA meeting is not a regular meeting; it is an active and healthy debate about a bet big enough that we’re gathering our bright minds to make sure we don’t fuck it up. If you’re in the room, it’s because we believe you have something to add, and if you don’t, we’ll correct our misperception.
Second, it needs to be culturally understood that if you don’t bring your A game to the DNA meeting, the team is authorized to mentally kick the shit out of you. The end result of a healthy DNA meeting will have members of the receiving team sitting with their heads squarely planted on their desks, whispering, “Oh shit, I can’t believe we didn’t think of that.”
The DNA meeting is not cruel. It is a living, breathing example of a team of engineers who put the value of design and technical excellence above all else. They don’t rule by mandate; they influence by being great at what they do. At a prior gig, the threat of a DNA meeting pushed us to prepare in extraordinary ways. Our goal was to predict every single question that might be asked and have every answer in our back pocket. Winning in the meeting was silence.
DNA has absolutely nothing to do with management (and everything to do with leadership). Pure managers are not considered for the team, because DNA is about cultivating technical leadership . A DNA meeting is a staff meeting of the influential engineers who don’t want direct reports, but want to lead. They want to make decisions critical to the technology. If managers have anything to do with DNA, the meeting will become about the managers, not the technical leaders.
DNA is achievable and aspirational. Inclusion on the DNA team doesn’t come from a popularity contest. It is the result of a well-defined journey that any interested engineer can embark upon. At the prior gig, you needed a combination of tenure and experience, shipped products, and visible technical contributions to the team. Some measures will be subjective, but the end result is that when someone arrives on the DNA team, everyone will agree that they belong there. It’s not a club; it’s an honor. DNA recognizes that the team members we want are examples of folks who live and breathe technical experience, who are selfless, and who contribute exceptional value to the company. DNA exists as an acknowledgment that a team is led not just by the folks who build the people, but also by people who build the product.
Flat Is a State of Mind
I didn’t come up with the idea of DNA. It was a former boss at Apple who suggested the idea long before I arrived on the team. Since then I’ve adapted the idea twice, and each adaption has yielded different results. In the current gig, we split DNA into different tracks: UX DNA and system DNA .
You build a DNA meeting to suit your culture. You build a DNA meeting so your technical leaders have a platform where their ideas are heard, debated, and acted on. You build a DNA meeting to remind the team that all forms of leadership matter.