I became an engineering leader accidentally. I now realize that this taught me the single most important thing about leadership. Effective leadership is all about humility. I do know that there is no way to talk about humility and still seem humble. But, for me, leadership has really never been about the titles — the titles were part of the accident.
How Leadership Happened To Me
For many of my early years in Silicon Valley, I was an engineer, usually in small companies of my own making. That all changed when Google bought Writely and then decided I fit the role of an engineering director fairly quickly, with little history doing manager-type things. Presto! I had skipped over the usual first levels of management, where I thought you were supposed to essentially learn how to be a manager, and landed in senior management. I don’t necessarily recommend this; it was terrifying (I still remember the first time one of my teams turned to me and said “well, you’re the director now, what do we do about it?”). It also meant that I thought about leadership differently than those who join the ranks of senior management through the usual channels.
After working as an Engineering Director at Google for a few years, I was promoted to Senior Director. Again, this was sort of a ta-da! moment. It was fast — so I asked my boss why? In many ways, I still saw myself as a programmer, so I was having trouble finding the value in anything other than lines of code flowing from my own hands, which was exactly 0 at the time. Basically, I wasn’t writing code; I didn’t feel like I was doing anything. Why was I valuable? His response wasn’t terribly reassuring at the time: “I don’t know what you’re doing precisely, but I do know that things are getting better and people are becoming more effective, so I don’t care. Do more of it.” The title didn’t matter to me and it didn’t matter to him either. Leadership isn’t about the title, and really, it isn’t even about you.
Of course, Google wasn’t being completely random: I had “led” most of my startups — at least as the thought leader — and at Google in those first 9 months, I had successfully built a team, adopted a second team in a second city, started a new project, “interfaced” with other execs and leaders, and launched the first version of Google Docs.
Because leadership always felt like an accident for me, I remained focused on adding value and being effective. So, instead of doing the usual “empire building” and grabbing project after project so I could look big enough to become a VP (this kind of thing is pretty common in big companies), I was always happy to give away responsibilities. That went for my peers or my team, as long as they wanted and could handle the job.
I guess that’s something like delegation by default. And while delegation seems like an obvious leadership value to cite, I’ve learned how incredibly powerful it can be if done right. I quickly realized that each time I asked my team to take something on, it made them stronger, and it freed me up to take on something new. And every time I gave something to a peer who was better suited to it, it made that person more effective. In both cases, it made people trust me more. Trust, of course, leads to a more open culture in turn. On the other hand, not delegating can be very toxic — if you don’t trust that your team is capable, they actually become less capable, and then you no longer have the opportunity to trust them. Very quickly you are in over your head, with a stressed leader (you), an unhappy team, and all manner of problems and distractions.
The Guy Who Taught Me To Be Quiet
Engineering discussions are often heated affairs, and in a larger corporate environment, there’s a real temptation to insist that your voice is heard and your intelligence noted. So people talk over each other and interrupt without thinking. This tendency is especially destructive if you’re the leader talking over your team. It’s not about you.
After a few years at Google, I noticed something interesting. One of my colleagues who was extremely intelligent always seemed to take up the least amount of space in any room. He would typically sit in the back of heated engineering discussions quietly taking notes, not straining to make his mark or arguing; he mostly just listened. Others must have noticed his demeanor as well, and at the end of the meetings, people would often ask what he thought. And every time, in a quiet, measured voice, he’d patiently lay out a more useful thought than anything included in the preceding 55 minutes. Over time, he became very influential in the company, and I don’t think I ever once saw him raise his voice or interrupt someone.
This showed me the power of quiet in leadership — it’s not about how loud you can be. It’s tempting to be overly active as a leader and tell everyone what to do — you’re a leader after all! But, actually, good leaders listen, let conversations evolve and develop, and provide measured advice only when needed.
While I am now the head of an entire engineering organization, I think of myself as the least important person in the room. My job is to help my team get things done. Even though I have more experience than many of my engineers, I don’t know the engineering problems we’re working on as well as they do. If I let my title dictate my leadership style, I’d soon be telling everyone what to do, and that would be a huge mistake. I’m much more effective when I remember what I learned from all the accidents that got me here: leading an engineering organization is not about the title, and it’s not about me — it’s about humility (even if it doesn’t sound humble to say so).