How To Build A Rockstar Engineering Team At Your Startup

It starts with hiring

This was never an individual journey. The success of your company is a reflection of the total value of your team. Often, the hiring process is not adequately prioritized and moreover, outsourced to external recruiters and yours might not be the priority cause they likely already have enough clients to cater to. I'm sure you understand how important it is to hire great people from the beginning. Use your personal network of friends and colleagues, and take the time out to scout strategically through professional networking sites like Linkedin, to find good engineers who will contribute to your company’s success.

Setup sprints

Teams that ship without a process, often end up stressed out, chaotic and unsuccessful. Embrace a light process, called the sprint that will help your team ship to production every two weeks. It starts with deciding on what to build. The features are organized into two lists, all the features you want to implement, and a few of those features you will implement in this sprint. Before you begin, make sure the team agrees with the prioritization of features. Then you start the sprint with the top few features. It is critical that you do not add new features in the middle of the sprint. By making changes in the middle of the sprint, you are throwing off the timeline, and stressing out your team. Also, keep two lists of bugs. Before you start each sprint, re-prioritize all the bugs, and move the ones that need to be fixed into the list for that sprint. Also, try not to release into production on Friday, or in the evening. Things often tend to break and then you might end up stuck in the office all night or ruin your weekend. And to make sure you are adding new features to a good foundation, always fix the bugs first before coding new features. The last part of the sprint is testing. The last few days of each sprint will feel like a spiral. You test, identify bugs and then fix it. You should find fewer bugs as you come closer to the release. Towards the end, it's worth it for everyone to focus on certain features or bugs together. This way you go on to the next problem faster after squashing down a bug.

Prioritize

When everything is important, nothing gets done. Always prioritize and stack rank features and bugs. When talking about priorities, use a simple and clear system that everyone can adapt. If you find a bug in production, which impacts your company, then push a fix into production and pause the release. This situation should be rare. If this is happening a lot, then you're not doing a proper job testing or fixing bugs. While spiraling towards release, revisit your process. Re-rank and re-assign priorities as you review your lists of bugs and features. It is entirely okay to change priorities between sprints, just make sure that doesn't happen in between sprints.

Pair program and run unit tests

Pair programming and testing are some of the best methods from the agile methodology to help build high-quality software. Pair programming is pairing two engineers to work together. One types the code and the second watches closely. It might seem like a waste of time, but especially for critical pieces of your system, it is an effective way to code. Pair programming increases the quality of the code and a good way to get the team to bond. Unit testing is another strategy to ensure quality code. It can be hard to write and maintain a body of tests for your code, but it is necessary, and it pays off. Make sure you run a set of tests for critical pieces of your software. And run a second set of tests which exposes the bugs you find. First write a test that exposes it, whenever you find a bug, and then fix the code. This way you can be sure that your test will catch it if the bug returns.

You do not have to reinvent the wheel

Too startups go overboard with their infrastructure by building their own world-class scaling and rebuilding libraries. It doesn't make sense to write them in-house when there are enough great open source libraries. Be it .NET, JavaScript, PHP, Ruby or Python, there are enough libraries that can help you out there. It's a waste of your time to rewrite existing libraries, and you are not likely to do it better.

Code refactoring

Although we don’t see the rust here, software does decay over time. The way to deal with this is to refactor, or proactively clean your code constantly. Every two months, schedule an improvement or cleaning sprint. Instead of focusing on business features, in this sprint, the team must focus on writing tests, cleaning up the code, and making it better.

Culture

Startups seem to thrive on chaos. However, a chaotic approach to building software just doesn’t work. It's a lot like trying to sprint through a marathon. You can’t do it. Writing software is an intellectually intense and highly creative activity and requires a specific cadence or a fresh brain and clarity if you will. Software engineering can either be incredibly stressful or incredibly rewarding. The first step to creating a productive and happy engineering team is having clear priorities and setting up sprints.

Set the tone

When you're building a company, you want to inspire people to work for you. It’s not enough to sell them on the mission of the company. You undermine your team when you refuse to let your engineers be a part of the non-technical decision-making. Our software teams aren't overgrown kids who only understand how to fiddle with code. Expect your developing team to show up for your business. And understand that respect doesn't mean pampering, don’t treat them like the stars of the show. Give them clear, achievable goals and hold them accountable. Most good programmers want to work in a place that inspires them to achieve. Too many of us try to solve that by throwing a “hard technical problem” at them, but a great way to help them grow is by challenging them to partner with ones who have different perspectives.  Engineers have more to give than just their technical chops. But teach them to respect that the non-technical sides of the business have equally valuable perspectives and skills.

 And lastly, if you can’t pay top of the market, you will have to rely on a balance of finding young talent and giving programmers different reasons to want to work for your firm. That to most of us means giving them a voice beyond the entirely technical, and challenging them to understand and see perspectives beyond engineering.