It’s a huge challenge retaining and growing an engineering team.
You need to take care of hiring, figure out how to retain developers as long as possible in the team and also figure out the work process and making sure the new developer managers are ready to take responsibility for their teams.
In pursuit of uncovering good practices, we started a blog post series, featuring cool tech companies.
Our intention wasn’t to find the ultimate silver bullet for every kind of organizational problems but to provide small case studies you can learn from.
This case study is about a fast growing medium-sized tech company called Alpha.
Alpha is a product management and user insights platform, helping enterprises and big companies make data-driven product decisions more quickly.
We had an exciting chat with Haggai Weiser, VP of Engineering at Alpha and we transformed the interview into this blog post.
Currently, we have 45 people at Alpha. Our engineering team is managed to stay small with 12 people: 5 engineers, a VP of engineering and 6 product managers. That means we have a 1:1 engineer to product manager ratio since we take products very seriously.
So far, we build everything in-house with this small engineering team, but this year, we’re planning to double the team.
The optimal size for a developer team is around 6-7 people, but in some cases, I would even go smaller and opt for 5-6 engineers and maybe one QA person.
As we start to scale up, we will break things into specific team leads and groups.
Hiring is always a challenge when you’re a young startup. Even when you've validated the product to your clients, team and investors, the next challenge is to showcase that enthusiasm to the community to yield a steady stream of potential candidates.
Hiring tools like Hired and Vettery help to get candidates in the door, but it's easy to get outbid by large companies and more established startups.
What we found to work is focusing on emphasizing and promoting Alpha's culture and mission at every possible venue. Attending and hosting events, publishing articles about culture and best practices or even just sharing successful use cases about Alpha.
Since engineers want to work on a product they can believe in, in essence, every article written by the marketing team explaining and demonstrating Alpha is also another plug for the engineering team.
A strongly motivated team is one that feels accountable with each other and with the company.
Setting clear team objectives at a regular cadence helps a team rally behind a measurable outcome. But in truth, I find most successful developers are already motivated internally.
Engineers love to build and ship products, and they take pride in doing so in the most efficient way possible. But they can quickly lose motivation when they are blocked. The manager's job is to empower them, but then just as quickly to get out of their way.
In practice, this means building a culture of knowledge sharing, rapid iteration, and individual accountability. 1-on-1s are a catch-all to help the manager learn and proactively address any needs the developer may have before they escalate.
Likewise, code reviews, retrospectives, lunch-and-learns, and other events are useful tools designed to help developers share knowledge and establish best practices, but they are ultimately meaningless without a culture to back them up.
Sprint planning fits such a cultural paradigm by setting individual objectives to empower developers with the ultimate responsibility in decision making and accountability for deliverables. In such an environment, the developer works with product and other stakeholders to solve the problem instead of deferring to (or getting blocked by) them for a solution.
We push a culture of experimentation, and we run A LOT of experiments.
Our expectation is the following: everything we build is probably wrong. So, we consider them small experiments that could be killed any time, and my team is comfortable with that.
- Okay, building something for 3 months and killing it would be painful.
This is why for running experiments, we have a really short sprint cycles (weekly sprints).
Our engineering team is not dictated by product. The engineering directs product in conjunction with product managers. The product managers are the subject experts, they know qualitative and quantitative testing back and forth. And engineering relies on information from the product managers to build a product. This building process is driven by engineering.
Objectives are high-level; sprints are weekly.
The whole company has yearly objectives, and these are broken down into quarterly objectives.
I work closely with the CEO and other stakeholders to establish quarterly objectives and then break them down to monthly goals. From this, I work with the product and engineering teams to come up with weekly sprint goals. The process works best when we figure these things out together.
We also use VS code because it has a screen-sharing feature and some collaborative coding features. I literally edit the same file with another developer, no matter where they are, which is especially important if you are a fully remote team.
1. Hiring developers: A lot of people have a hard time hiring people smarter than them. Don’t be afraid to bring in people who will do your job better than you. That said, you still want to make sure you hire someone who will work well in the team.
2. Letting go of micromanaging: If your objectives, standards for acceptance and success are clear, there is no need for micromanaging.
If your developers can answer...
...then you have a green light for giving engineers space.
It’s a misconception that engineers are just here to execute. It’s a misuse of their talent; they’re very capable of solving solutions in product and in other things as well.
Empowering them to do that, stepping back a little bit, and seeing what comes back will shock you.
3. Communication in a remote environment. We’re going there but haven’t figured out how to make things work. I think the solutions going to be around minimal process but you have to set a minimal number of meetings and stick with that.
Interested in managing remote teams? Read more in an interview with Buffer VP of Engineering.
If the solution is wrong, be comfortable killing it early, and don’t worry about engineers getting frustrated about it. Killing early is healthy, and establishing that culture as early on as possible in the organization is really useful.
The most powerful way to convince developers to join your team is to have a wonderful company culture and a product they can believe in. Handling hiring challenge is just the beginning. Once you have talents on board, you need to make sure they stay as long as possible in the team.
Retention is all about having a good culture, keeping your developers motivated by skipping micromanaging, making sure every developer can contribute to the project in a meaningful way and having 1-on-1s to address issues before they escalate.