How this Fast-growing Tech Company Manages Developers

It’s a huge challenge keeping 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.

Enter Haggai.

About the organizational structure of Alpha

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.

What are your plans for scaling up your engineering 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.

What hiring methods work the best for you and how are you planning to double the engineering team?

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.

Learn about Asana's recruitment process from this interview! [Podcast + Blog post]

How do you motivate your developers?

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.

Learn about the renowned engineering culture of Monzo! [Podcast + Blog post]

How is your engineering team managed?

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.

How are decisions made/goals set?

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.

What tools do you use for team communication and project management?

Internal team communication takes place on Slack. For project management, we used to use Trello but recently moved to Jira because Trello wasn’t sophisticated enough.

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.

What are the biggest challenges in team management? What have you done to overcome these challenges?

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...

What problem are we solving?
Who do you solve it for?
How do you know if it’s solved?

...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.

Any good advice to fellow tech leaders regarding team management?

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.

Conclusion

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.