The best leaders set the direction to follow, know when to delegate and communicate effectively.
Real leaders use management skills to guide their people to the right destination.
A key aspect of software engineering that I can't get enough of is collaboration to get anything meaningful done.
Of course, solo enterprises exist and can thrive, but don't mistake these lone developers as singular magicians: they are leveraging the work of dozens, if not hundreds of other engineers, to accomplish their individual goals.
While there are successful solo developers and projects, a big team is likely powering the software you use daily. For example, Facebook, Amazon, Netflix, and Google employ thousands of engineers, organized as many different teams. Discussing how to organize large engineering groups is a complex topic that we'll perhaps wade into in the future, but today's focus is on the teamwork itself.
Growing up, I participated in many, many different sporting activities. Born in Grenoble, France (a valley in the Alps), it all started with skiing. When I was six and moved to California, I gave tennis a try. Then I got into karate, which I stayed with for several years, making it one step away from a black belt. Then I started fencing in middle school, yet another individual sport. A fun side note about that is that the Stanford Fencing Club I was at was also where Steve Jobs' son fenced. Reed is a couple of years older than I am, though, and I remember him beating me 99% of the time; he was just stronger than I was back then!
Around middle school, though, I started playing more team sports and joined my middle school basketball team in 8th grade. While I loved playing in games, we never won. It was a short, 10-game season, and my team went 1-9; the single win was the only game I missed. That never got to me, though, because I had so much fun in practice every day with my teammates. My friend Will Dickens was on that team, and he then pulled me into another sport he played when basketball wasn't in season: water polo.
The rest is history as I joined my high school's junior varsity water polo team the following year. By my sophomore year, I was not only starting on the varsity team but playing the entire game without subbing out. It's in water polo that I was able to experience what a championship team looks and feels like, which is something I've taken with me ever since.
Leadership is a term thrown around a lot in software engineering as a critical trait that engineers need to develop to advance in their careers. When I first came into the field, this was a bit surprising since I thought you just needed to code, code, code! However, the reality is that building software at scale takes teamwork, and the best teams have great leaders.
Leadership isn't just about being the most senior or most intelligent person on a team. Leadership is about caring for the whole team and keeping it accountable to their shared goals. These goals separate championship teams from others; I've been on many teams that don't care to be great -- fun is the only goal. While that is a great goal, there came the point where I wanted more: I wanted to win. However, in a team sport, one person's desire to win is not enough. The whole team needs to buy-in. How do you get a team to buy in? Leadership.
I've always been on the younger side for my school grade, which meant that in the summer between my junior and senior year of high school, I was still eligible to play in 16&under tournaments for water polo. Stanford, the club I played at when my high school wasn't in season, has a solid program. That summer, we fielded a very strong team to compete in the Junior Olympics, a nationwide tournament with several hundred teams vying for qualification in a 64-team tournament. As a 16-year-old, 2 months away from turning 17, I was 6'4'', which was my team's average height. Our tallest was 6'7'', and he could literally fly; he was one of the fastest swimmers in Northern California. Our center was also 6'4'', but probably had 50-60 pounds on me, AND was left-handed. I was the starting center defender on that team, and boy, were we good for our age group.
I don't know that I was a great leader of that team, though, as all these other guys intimidated me, and I remember the nerves of playing in these big games where we were expected to win the whole tournament. We came in as the #2 seed and showed it the first few games. As we approached the later rounds, games got more challenging, but we kept winning and made it to the finals. There, we played the #1 seed who had also made it all the way through, and they kicked our ass. We lost 12-3, and I will never forget the handful of crucial moments that decisively turned the game in their favor. As disappointing as that loss was, I can't complain about a 2nd place finish in a massive, nationwide tournament!
After that Junior Olympic heartbreak, I was ready and excited to get back to my high school team, with whom I was far more comfortable around, but I had my work cut out for me. I was the only returning starter from the previous year's team, and only 3 of the 9 players that played meaningful minutes the year before were returning (1 of those being me). Needless to say, we did not play very well the first game that season (which, fun aside, was against Tom Brady's high school), and I remember sitting in our team room after the game with my coach and crying because I had been yelling at my teammates all game to figure their shit out, and it hadn't been working. I will never forget his words that day: "Ben, this is not the same team as last year, help them help you." He was 100% right, and I immediately changed my approach and have never looked back.
When doing hard things, people get stretched to their limits. This is by design and desired, stretching leads to growth. In these situations, emotions tend to run hot because all of one's energy goes into the task at hand. That's where a leader is needed to ensure that any heating up that occurs doesn't boil over, causing damage to the person or the team.
While counter-intuitive, that means that as a leader, I often am trying to lighten the mood and help others around me relax when they are stressed. This felt counter-intuitive to me at first because I pictured a leader being the one to push, push, push for results and progress. On a great team, though, that push is just not necessary: every individual on a great team is self-motivated to be there; they wouldn't be on that team otherwise. So it's not about getting others to do what you want or need; it's about getting others to do what they do best without you getting in their way or them getting into other people's way.
All of that said, great teams have great leaders. Notice the plurality there because that is not a mistake. Leadership is not a title that a single person can hold, even if there's only 1 captain on your sports team or 1 manager for your team at work. Instead, great teams have several leaders, who complement each other, such that whatever the situation, one of them will be able to help bring the rest of the team along for the ride. Building great teams, then, requires finding leaders to complement those already on the team.
As has been hopefully made clear, software engineering is no different from a team sport: it takes a team, and teams need leaders. The bigger the group, the more leaders it needs. Software engineering has a fantastic feature that team sports don't: there are no roster limits! While a water polo team is capped at 15 or an NFL team capped at 53, software engineering teams have no size constraints other than the need to keep it all functioning. As just mentioned, though, there is still a need for leadership somewhat proportional to the size of the team, which means that big software engineering organizations need lots of leaders. Not only that, though, but most of the big software engineering companies are still very much growing and therefore have growing needs for leaders -- they can't get enough!
While many decry the way big tech companies approach their workforces and how they hire/fire/compensate, the logic from the business perspective is relatively straightforward, even if distasteful. Hire as many capable software engineers as possible, of which there are MANY more junior developers than experienced leaders, and push them. Set them up to be challenged and learn and grow to meet those challenges. The best get promoted, and voila, leaders formed from within the organization. Of course, leaders can be hired in, but this is far rarer (and potentially more expensive). The distasteful part is when companies don't care about those who can't meet these challenges and burn out.
At least in my experience at LinkedIn so far, I feel like there's a nice balance found within this messy setup. We keep a high hiring bar to help weed out those that are likely to burn out under the pressure of the job. Of course, arguments can be made that the hiring process needs work, which I don't disagree with, but that'll be for another time. The hiring bar reduces the number of folks coming in. It is combined with an aggressive stance towards self-development, where there are immense resources at everyone's disposal to learn and develop themselves. To some degree, though, no hiring process can tell if someone can be a great leader; only time doing the job can do that. But when surrounded by experienced leaders who are already there, the available role modeling helps increase the likelihood of success.
All that to say, I'm very grateful for the leadership opportunities I've had in my life thus far, and especially for those given to me by LinkedIn. It takes trust to hand the reins over to someone else, and I both trust my coworkers and leaders and feel trusted in the roles I've been able to play. This is one of the most fulfilling parts of my job because it acts as a reminder that I'm on a great path and that others trust in my path too.
Great teams require three core things, then:
A shared goal
As simple as it sounds, getting these to line up perfectly is quite challenging, which is why leadership is such an important skill to develop.
Benjamin is a passionate software engineer with a strong technical background, with ambitions to deliver a delightful experience to as many users as possible. He previously interned at Google, Apple and LinkedIn. He built his first PC at 15, and has recently upgraded to iOS/crypto-currency experiments. Benjamin holds a bachelor's degree in computer science from UCLA and is completing a master’s degree in Software Engineering at Harvard University.