in Projects, Programming, Technology

Building a great software engineering team

Building a great software engineering team for a tech startup requires finding well-rounded players that are comfortable experimenting.

Experience vs Potential

Are you hiring for experience, or potential? Hiring experienced engineers will likely lead to faster near-term progress, but may limit your optionality down the road. Junior engineers are more likely to grow with the needs of your business, but will require mentorship and may take longer to reach full effectiveness.

Deep expertise with a particular framework, architecture pattern, platform, or language will definitely mean your team progresses faster. Also, strong opinions on technology choices can be a good thing. However, that same bias may mean an engineer may not want to pivot to another technology later. Their experience will also make them more expensive.

A junior team on the other hand, can grow with your business. Their learning will be tied to what the business needs. However, you should budget for their learning curve, and dedicate time to mentoring their growth. 

For most roles, I prefer candidates with a computer science degree. In my opinion, grasp of data structures and algorithm fundamentals is far more important than whatever technology is in fashion this month. So, I look for an engineer with a strong grasp of the fundamentals, a desire to learn new things, and a well-rounded background. Ideally, they will have had exposure to different business models and work environments (consulting, freelancers, large and small companies, software and non-software businesses).

Diversity vs. Sameness

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 define 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. A more flexible team is better for the overall robustness of the code and of course pager duty.

When it comes to personal and professional backgrounds, ideally your team will be as diverse as possible. If not in technology background, then in business and cultural background. In a startup it is critical to see problems from as many angles as possible.

Transparency & Communication

One of the best leadership practices is clear communication and transparency about what is happening with the business. Engineers are smart people, and they will want to understand what customers need, why the business needs the features they are completing, and of course how the business is doing.

Some companies document salary levels and list the skills expected at each level. All engineers are compensated within specific narrow bands. This is a form of transparency because it simplifies negotiation. It also removes unnecessary frustration from wondering whether the engineer next to you is making more money simply because they are a better negotiator.

Transparency should go both ways, and a good engineer will recognize this and enjoy it. Engineers should expect to commit their code daily, participate in a friendly code review culture, and ship often. It will take some work on the part of the engineer to clearly communicate to the business side what they’re working on and the difficulties entailed (how long it’s going to take).

Matt & Raj – SingleFile.io

Challenges

As your business grows and requirements change, the engineers that helped get you off the ground may not have the skills to take the software to the next level. If the engineer has potential and wants to learn, hiring in more senior members as mentors is necessary. 

Similarly, skilled engineers with technical depth in an area may need to skill up in a new area. This is where transparency early on pays off. If the engineer has bought in to the potential of the business, likes her team, and has helped build the culture – she will be more likely to turn her skills to learning a new expertise.

Software teams must always be customer centric. It’s a huge waste if a team spends months (or even days) writing code that the company doesn’t need. For me, customer-centric design and agile development is the solution to this problem (and many others). Issues such as dealing with the complexity of code debt, platform choices, and team alignment are made easier by focusing on the customer. Nowhere than in a startup is it clearer that customer issues come first. Software solutions are only valuable in the service of those problems.

Header image: The nextstep.carreers team.

Write a Comment

Comment