Every individual has strengths and weaknesses; it’s easy as a hiring manager to hire people who display similar strengths as yourself. That’s because these strengths are easier to identify since you have experience and interest in said area and more confidence in your evaluation. However, people like you may also have similar blindspots. These blindspots, amplified on a group of people, will become much more detrimental. As a manager, I would want to reduce the number of weak areas on my team.
Technical strength is often regarded as the measurement of seniority of a software engineer. I’m not going to diminish the importance of technical strength. Engineers are hired to create software that solves real life problems; having the ability to write maintainable and reliable code is a must. In addition to technical depth, I would like to offer a more well-rounded perspective to assessing the strengths of software engineers and how that applies to building a team.
I’m always seen as the weakest engineer on the team. My technical strength is weak in comparison, but I enjoy actively working with others and dabbling into product design. What can I do to improve my technical chops when I don’t see myself spending all of my free time reading about compilers or operating systems?
Throughout my experience as an engineer and in managing teams, I’ve heard this concern come up numerous times; it’s especially common with female engineers. Folks in the industry have all seen the typical “senior engineer” persona: An individual who has deep expertise in one or more technical areas. This individual has seen scale at companies like Google or Facebook, or actively follows tech blogs and reads highscalability.com for fun. (side note: Highly recommended if you do enjoy learning about scalable architecture) Engineers whose interests do not align with the traditional deep-tech persona are often regarded as “junior” members or even “under performers” of the team.
There are many types of strong engineers. One needs more than just deep technical knowledge to build solutions that meet the needs of different types of end-users.
Just some examples:
- Collaborating and Communicating effectively is extremely important for a team to stay aligned internally and externally.
- Understanding trade-offs between optimizing for the present day vs building towards the future so the team doesn't fall into the trap of becoming stagnant or building something intangible.
- Empathizing with user needs in order to provide input to the product roadmap and build a product that people actually want.
I want to share some stories that taught me the importance of building well-rounded teams.
One of my internal teams supports product teams by providing a shared platform with reusable, customizable components. While the technical standard for building this platform to both be scalable and reliable is incredibly high--numerous complementary “soft” skills are equally important in order for our team to properly understand and meet the needs of our customers. When I first joined this platform team, I noticed the team had a number of strong, passionate engineers, but the team had a lot of issues with delivering results and communicating with customers. You can have a talented engineering team build something technically amazing, but if it doesn't work for your customers then it was time wasted. I helped the group clean up our processes and hired individuals with complementary perspectives and skill-sets to round out our collective capacity. Today, we have a strong, healthy working relationship with the rest of Square.
Does the team need engineers to tackle deep technical problems, engineers who have an interest in product, or engineers who build team culture?
I once hired a woman who came from a team that had a reputation for their high engineering standards. She was not the fastest programmer, so it caused her to struggle with imposter syndrome and lack of self confidence. It didn’t help that she was constantly reminded of her weakness because everyone else had either many more years of development experience, or a stronger interest in deeply understanding technical subjects.
What they overlooked were her strengths - she had a natural intuition for product and very strong empathy and team-building skills. I brought her onto our platform team because the current team already had several with strong engineering experience; most of them came from infrastructure teams and we lacked people with a better understanding of how to ship products that solve concrete problems and drive for execution.
Even though she was considered a “junior engineer” on her previous team, she joined our team and she immediately upleveled the team and positively impacted our deliverables. She helped the team gain a better understanding of how to match and prioritize what we’re building with the actual problems users felt while the other engineers on the team helped her practice and refine her technical skills. As a team, we became much stronger in our ability to deliver impactful results.
Do you want the team to focus on the present or the future?
I am personally very forward looking. I enjoy thinking about long-term strategies and forming a vision. This is what the example team lacked originally. They were unintentionally designated as an “SRE team” to keep a highly critical, but poorly understood platform afloat. The legacy architecture was never designed to scale.
I hired a couple of individuals that were forward-looking like myself to help us create a realistic vision for what a future platform could look like. We got buy in from the internal team as well as the company to make this vision a reality. I would love to say it was smooth sailing from there, but it was definitely not that simple. There were still countless present-day needs we had to meet while trying to steer the ship toward the future.
Some of the engineers are extremely passionate about digging into legacy code and creating patterns to simplify and improve the current state. Other engineers required separation from the current day baggage in order to design an ideal vision to strive for. These two groups frequently hit tensions in determining our priorities.
What we learned is the importance of both perspectives and learning how to compromise. If we only focused on the present day, we would become a fully reactive team with a platform that doesn’t scale; we would need to linearly increase headcount to simply keep up with company growth. On the other hand, if we only focused on the future vision, we would have failed as a team to meet the needs of customers today and no longer have a platform to build a future version for. We recognized and rewarded the strengths of both types of engineers and compromised with each other to cover our blindspots so as a team, so we can make sure all bases are covered.
Does your team collaborate frequently with others or does it need to stay focused and iterate quickly?
There are two different types of senior engineers. There are senior engineers who enjoy working with other senior engineers, and there are senior engineers who enjoy leading and mentoring others.
On my example platform team, junior engineers frequently needed help from others to complete tasks. Unfortunately, instead of teaching others the reason behind decisions or principles behind their design decisions, the senior engineers simply took over the tasks and completed them quickly to save time. This resulted in all work including onboarding becoming an independent activity for individuals to figure out in isolation. This led to the team being filled with engineers who are very independent, but weaker in collaborating with others. Of course there were improvements from a management standpoint that could help, but this was a situation where we needed senior engineers who enjoy teaching those around them. In this situation, I hired another experienced engineer who taught not only the junior engineers on how to create great code, but also demonstrated what effective mentorship and communication looks like.
As a shared platform, we require our internal engineers to mentor product engineers to learn and use the shared components we provide. Lacking these collaborative skills greatly hurt the team. The reasons for building components slower but more generally were not properly explained to the product teams, so product engineers always thought of the internal team as a blocking function and disliked working on the platform. Had we not corrected these misconceptions and improved working relationships, the team would have failed and lost all of our customers.
Be thoughtful and deliberate
There’s no right or wrong answer to building a team. Ultimately, only you know what your team needs and how to achieve your team’s goals. There are circumstances where you do need to build a team of like-minded individuals with similar strengths to accomplish a particular goal -- ie bringing a product to market as fast as possible in a startup setting. My advice is only to consider broadening your perspective; decide what type of team you’re building and for what purpose.
When coaches build sports teams, they won’t build a team filled with only star players. That’s because every star player will want the spotlight: either they’ll hog the ball or wait for the ball to be passed to them for that perfect shot. A team filled with star players won’t win the game. You need players who are fantastic dribbler, players who play amazing defense, and players who complement your star player.
Software engineering teams are the same. There are multiple types of high-performing software engineers. Technical excellence is important, but not the end-all, be-all. For building sustainable, long-term high-functioning organizations--only when the internal teams are well-structured, well-rounded, and brought together thoughtfully can the products your team builds meet the needs of a diverse and inclusive customer base.