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 ;)
