Wednesday, September 15, 2010
Leadership by Influence
Leadership is an interesting skill; here are a few thoughts I've had recently at Google.
Skills are honed by practice, but leadership is a daunting skill to try before you have your confidence. Some skills you build up little by little, and often you can learn about them before you try them. But leading is one of those skills that you need to learn by doing and then thinking. It can be intimidating to try, like public speaking. But that's the pattern to follow: try leading a little bit at a time, and growing.
Finding opportunities to improve leadership is also different than many skills. Learning how to program? Start writing some code. Learning how to lead? You need some people to (possibly) follow, and an appropriate time and place. That's a good segue into some of my experiences.
At Emergent I spent the last few years as a software architect. My role was varied, but essentially was influencing the direction of our product and business. I did that by understanding technical issues, building compelling explanations, and influencing the decisions of others. Those others ranged from software engineers on our product, managers and executives, and external game teams considering tech. The key point is that I had no authority or decision power myself, even over our own engineers.
My situation was different than some of my peers. A few of us rose into senior positions at the same time. Some of my friends ended up as technical leads over groups of engineers. While they didn't have "personnel management" responsibilities, they did have direct technical management. Teams collaborated on the work that they did, but generally speaking these technical leads defined tasks onto their team members. If they needed to they could specifically direct a given engineer. I contrasted this against my role, with no reports and only the ability to influence engineers.
Gathering information from groups was novel as well. The technical leads' smaller groups met regularly and shared information. Spanning the engineering department I couldn't gather information directly from all engineers. I relied on meeting notes, speaking with team leads, and most importantly individuals coming to me for relevant topics. Some engineers did this voluntarily , "Vince, I've got an idea to bounce off you." Other's work I wouldn't have heard about unless I stopped by and asked them about it.
Moving back in time, I recall developing a game during my undergraduate degree. We had some initial meetings with dozens of interested students. A smaller group moved forward to create a game. But, being entirely volunteer work there was no certainty that anything would get done. In the end, only a couple of us made much progress, and we were left with many good intentions of others, but no work done.
And that brings me back to Google, where the internal engineering structure is decidedly bottom up. Engineers self organize, recognize issues, and address them. Leadership at Google is more similar to my experience as a software architect at Emergent than the tech leads there. Engineers aren't assigned tasks, they generate them or adopt them. The top down influence comes in two parts: influential direction, and team allocations. The technical influence is something anyone at Google can, and is expected, to do. And that's what motivated me to write out these thoughts.
This is also my first time contributing to open source projects. And I can see they follow similar patterns. There is decentralized control, and often no specific hierarchy of technical authority. Rather, the community relies on those individuals who've proven the kind of influential leadership I've described here.
So, what's your takeaway, dear reader? How about a few answers to questions I asked myself in the past:
How does one gather more influence?
By recognizing when something needs doing, making compelling explanations for why and how, and showing others how it can be done by doing it. By doing so you build respect as someone who will make things better and solve problems.
How do you get an opportunity to try leading?
Everything you do is an opportunity, and you have to grow by taking small steps. It is rare that you'll be given the responsibility without first having demonstrated that you can lead. Don't wait for someone to decide that you can try leading. Just offer your contributions and thoughts, lead by doing, and be sensitive to what the group needs.
And, a final thought. At Emergent, we frequently used the phrase, "Managing engineers is like herding cats." The statement has a changed meaning for me now. If you manage engineers by herding them, you'll be as frustrated as if you were herding cats. But, all the cats will run to tasty food. Perhaps that's why Google invests so much in it's cafes ;)
Subscribe to:
Post Comments (Atom)
I notice this difference at Google as well from my previous experience in games. My take away though isn't that the Google way is different but that making webapps is different than making games.
ReplyDeleteWebapps = release often, update, iterate.
Games = release perfect, move on to next game.
Webapps = release when you're ready
Games = release on the date we promised the retailers it would be on their shelves 6 months ago
Webapps = 95% engineers
Games = 50% artists, 20% designers, 20% engineers
Webapps = almost no assets
Games = crazy amounts of expensive to create assets.
Webapps = more de-centralized (add the features you personally care about, we'll eventually get them all in since we have unlimited time)
Games = Director's vision (add the features the director has decided must be in in his specified priority since there's a time and budget limit)
I'm sure there are others. My point is, I'm not sure any of the decentralized control things and self direction that is possible on many projects at Google fit in the other contexts. Specifically, making games which is vastly different than making webapps and also making libraries/engines/tools for paying customers.