Building a great software engineering team takes more than finding the best developers. Engineering leaders must also ensure their team’s work aligns with the goals of the business and that they keep one eye on the future so that they’re ready to scale — and tackle the challenges that rapid growth creates.
Leading by example helps accomplish some of these goals, but it’s not enough. Tech leaders must also be intentional. They must take ownership of the interview process, team development and the core values that guide their work. Here’s how five Seattle tech leaders tackle the challenge.
Adam Loving's ideal software team is both flexible and diverse. According to the Pioneer Square Labs' principal engineer, these values lead to the creation of more robust code and enhance problem-solving ability, which is especially important to teams that are in high-growth mode.
What are the most important factors to consider when building a great software engineering team?
Finding well-rounded developers who are comfortable experimenting. Hiring experienced or specialized engineers will lead to fast near-term progress, but it could limit your options down the road. Junior engineers are more likely to grow with the needs of your business but will need mentorship and more time to reach full effectiveness.
Also, do you want each member of your team to be able to touch all parts of the code, or do you want them to have clear application boundaries and defined interfaces between their different subsystems? In some cases, the architecture may call for multiple experts. In other cases, all the engineers may be able to work on the full stack. Having a more flexible team is better for overall code robustness.
For most roles, I prefer candidates with a computer science degree. A grasp of data structures and algorithm fundamentals is far more important than expertise in a particular technology. When it comes to personal and professional backgrounds, ideally your team will be as diverse as possible, if not technologically, then in their business or cultural backgrounds. In a startup, it’s critical to see problems from as many angles as possible.
Having a more flexible team is better for overall code robustness.’’
What challenges have you faced as you’ve scaled your software engineering team, and how did you overcome them?
Software complexity increases and requirements change as businesses grow. The engineers who helped us get off the ground didn’t always have the skills to take the software to the next level. It was often necessary to add more senior engineers, bring on those with different specialties or split into separate teams. Otherwise, engineers may need to skill up in a new area.
This is where transparency early on pays off. If the engineer has visibility into the business, is customer-centric and is good with team communication, then she will be more likely to turn her skills toward learning a new expertise.
Senior Software Engineer Gary Manfredi told us that prioritization and alignment has completely changed the way his team at Navigating Cancer works, both internally and with other departments.
Obviously, defining priorities and getting everyone on the same page is easier said than done. But Manfredi has advice for other engineering managers looking to overhaul their current practices: Get back to the fundamentals.
What are the most important factors to consider when building a great software engineering team?
Building a great team begins at the top. Impeccability regarding commitments, candor, good planning, clear decision-making, urgency and empowered delegation are all part of our self-development as individuals and are required for good leadership. Aligning with the company is also key. If a manager is not fired up and motivated by the company and their place in it, then they should revise their outlook or find a new company. Engagement is contagious.
When it comes to interviewing, don’t default to whiteboard coding tests. If your company is in the business of shipping whiteboard code, then great. Test for that skill. Otherwise, provide the candidate the integrated development environment of their choice and test real coding skills. You risk missing a good candidate who may freeze up or not code well on whiteboards. That said, we’ll test whiteboarding for a few things, including concept diagraming, architecture and unified modeling language.
When it comes to interviewing, don’t default to whiteboard coding tests.’’
What challenges have you faced as you’ve scaled your software engineering team, and how did you overcome them?
I’ve had the challenge of owning a team that was struggling because of tap-on-shoulder request processes, bad tooling, missed timelines and poor morale. Simply adding more people would not have fixed the issues to allow us to scale. My focus was to take the team back to fundamentals. We got our Scrum process down with the right ceremony and transparency. This took some time, better technical planning and the support of an awesome project manager, as well as replacing an engineer who wasn’t invested. It also required coaching the product team on how to pace their inflows and clear requirements.
But it paid off. Velocity, engagement, quality, employee retention and morale went way up. And the product team became happier as development became a well-oiled machine. Practicing and perfecting development fundamentals is the basis to do it.
As oxymoronic as it might sound, as an engineering leader, you want to avoid doing as many of the things that got you your job as possible. According to Derek Taylor, senior software engineering manager at DoubleDown Interactive, this means coding and really getting into the weeds. Taylor told us how minimizing such tasks is key to creating an engineering team that is primed for sustained growth.
What are the most important factors to consider when building a great software engineering team?
I assume that developers can identify good engineers and determine what specialties they’re looking for. Finding the right teammates is more difficult.
Decide on what kind of culture you want for your engineering organization. List the attributes that define it. Make goals for the first year. Score your candidates against that criteria. This does not mean all candidates should match a single template. You should have a healthy mix of people who will work well together and communicate with each other. Look for future leaders. You’ll need them. It’s easier to grow them now than to hire them later.
Avoid doing what got you your job.’’
What challenges have you faced as you’ve scaled your software engineering team, and how did you overcome them?
Growing quickly is relatively simple. Growing well is difficult! You won’t scale well if you are still trying to code, strategize with upper management, plan with your peers in other disciplines and manage engineers. So find new leaders, and be clear about expectations. Give managers the appropriate amount of people for a team and then stop managing that team. Manage your managers or they will not become powerful.
Avoid doing what got you your job. Minimize coding and don’t micromanage. You will steal vital experience from engineers and managers and you will miss critical strategic details. Knowledge silos develop naturally when you start a team. Actively work to break them down and spread out the expertise.
Crossed-wires are just as useless among engineering teams as they are behind television screens. At Tango Card, Seattle Engineering Manager Russell Dodds encourages a culture of self-direction while also emphasizing team deliverables to ensure each developer has clear priorities based on a solid foundation of support.
What are the most important factors to consider when building a great software engineering team?
I love working with teams that move fast, understand the customer or business impact of what they are working on, believe in the products they are building and deliver value as a unit. To allow the team to move fast while still delivering the right features, you have to remove friction from the development and release processes. Transparency from management and the non-engineering business side of the house about how solutions affect customers is also critical in empowering engineers.
Continuous integration and delivery is also important, as well as cloud-based infrastructure. A strong culture of code reviews, team-over-individual deliverables and self-direction will allow developers to ask the right questions, own the results and build the best solutions. To make this work, we are always striving for the right balance of senior engineers and junior engineers. We want to maintain a strong engineering foundation while continuously injecting new ideas and technologies.
Undocumented tribal knowledge is prevalent in most small teams.’’
What challenges have you faced as you’ve scaled your software engineering team, and how did you overcome them?
Undocumented tribal knowledge is prevalent in most small teams. Once the team reaches a certain size, that lack of documented information can negatively impact productivity, be a roadblock to onboarding new engineers and lead to bugs and the poor integration of existing features. Even as our overall team has grown, we have continued to use Agile and Scrum groups of between four to six members that focus on products. This has allowed teams to remain efficient, productive and retain a sense of ownership.
But it does cause issues when features cross groups. Either the team without expertise adds features to an unfamiliar product or they are blocked on the product team's ability to deliver the requested feature. To counteract these drawbacks, we encourage all engineers to code review commits across teams, have bi-weekly demo sessions to understand what other teams are working on and commingle to increase cross-functional knowledge.
As a technical leader, it’s your job to lay the groundwork for your team’s initial success while casting one eye on the horizon. The Dreambox Learning engineering team strives to stay ahead of potential problems that come with scaling.
According to Lorenzo Pasqualis, VP of engineering, they do this using Agile techniques like the Scrum of Scrums to organize cross-team dependencies that inevitably slow coders down.
What are the most important factors to consider when building a great software engineering team?
Building high-performing engineering teams is a non-negotiable skill for engineering leaders. It is the difference between successful and failing technology companies. It all starts with hiring well and without compromise. Once you’ve hired great people, you need to give them direction by defining reality in the form of clear expectations and business strategies. Once you’ve defined reality, you need to respect your people by giving them your full trust and getting out of their way.
Finally, you need to keep a close eye on your team’s culture. Seed it with coherent and consistent guiding principles and give it space to grow organically. However, you can't stop paying attention. Team culture, like a garden, tends to evolve in surprising ways. Sometimes, you have to adjust it by tweaking your guiding principles or introducing new ones when necessary.
Seed your culture with coherent and consistent guiding principles and give it space to grow organically.’’
What challenges have you faced as you've scaled your software engineering team, and how did you overcome them?
As a company grows, software engineering teams need to evolve in concert with new and changing realities. Some people and groups are naturally good at adapting, while others are not. Leaders need to be able to identify new nascent bottlenecks and take appropriate actions to ensure uninterrupted high-performance.
For example, I’ve found that there is a significant inflection point when engineering teams go from working on projects that have no dependencies to working on more complex projects that do. In my experience, you must deliberately tackle that complexity by introducing some form of dependency management. We solved the problem with the introduction of a scaled Agile technique, the Scrum of Scrums, to organize cross-team dependencies. We also created the role of engineering owner, who is a leader responsible for coordinating the technical aspects of a particular stream of work with inter-team dependencies.
