Scaling Your Team and Product

Scaling Your Team and Product: Leadership Stories from Product Hunt - Interview with Radoslav Stankov (Head of Engineering, Product Hunt)

Leadership stories from huge companies are highly instructive and interesting.

However, you don’t need to look at the biggest companies to find great takeaways.

Laying the groundwork and scaling up a smaller company and its product is no walk in the park either.

In this post, we bring you leadership stories from Product Hunt with Radoslav Stankov, Head of Engineering. He’s been carefully building the product, the engineering team and his own leadership skills over the years, and shares some of his stories.

Listen to the full interview in episode 2 of the Level-up Engineering Stories podcast hosted by Karolina Toth.

This blog post covers:

• The evolution of Product Hunt's structure
• Going from individual contributor to Head of Engineering
• Evaluating yourself as a leader
• The effect of the pandemic on remote work
• Leadership challenges in product development
• Biggest takeaway in product development

About Radoslav Stankov

Radoslav is from Bulgaria, and he started his career in tech around the age of 15. He’s been at it for over 20 years, and he's currently Head of Engineering at Product Hunt.

Before the pandemic, he used to do public speaking and organize conferences in Bulgaria. Recently, he’s been giving talks online.

How has the structure of Product Hunt evolved?

Contractors to full-time engineers

Early on, the engineering part of Product Hunt was built on contractors. As we grew and the product proved to be viable, we started to hire full-time software engineers. My main focus currently is building a layer of engineering managers and splitting the work between the teams.

Single-player mode to teamwork

We used to call the way we worked single-player mode. We handed a feature to one engineer, and only that one person worked on it.

We’ve developed this into a collaborative single-player mode. As you grow, you have to move from individuals to cross-functional teams. My current challenge is to keep the good parts of single-player mode, but update it to serve our current needs.

We doubled our size during the pandemic and went from 20 to around 40 people. We also have contractors in DevOps and QA.

How have you made the transition from engineering to management?

It’s been a gradual process for me. Early on, we didn’t have engineering managers; it was just Andreas Klinger, the CTO.

I was helping my teammates and mentoring developers, as a senior engineer does. When I went from engineer to manager, I struggled with figuring out what my role should be as Head of Engineering.

Understanding the role of management

I needed to realize that management is a separate career from software engineering. Not everybody needs to become an engineering manager; you can remain an individual contributor and have the same impact.

Early on, time management was difficult, as reducing the time I spent writing code hurt on the technical side, and I had to balance that with learning about management. Here’s what I’ve been doing to make myself a better manager:

• Reading a lot about management.
• Discussing my challenges with others in similar positions.
• Creating a circle of friends to discuss management issues with.

I’m still in the process of learning the handles.

From management to leadership

Currently, I’m moving away from working directly with engineers and starting to focus more on working with a team of engineering managers. There are significant differences between leading vs. managing.

I trust my team, so I don’t want to keep tabs on them. Getting the amount of freedom I give my teams has always been tough to nail for me. You want to set standards, but it’s not obvious how much you need to stick to them or when they may stop working.

You need different skills in management, so make sure to improve yourself every day.

How do you evaluate your progress as an engineering leader?

Build an autonomous team

It’s my goal as a leader to build self-managed teams, and to make my presence unnecessary, just like in a DAO.

The company has seen phases of hypergrowth, which keeps me busy and forces me to move the frontline work lower on my priority list. When this happens, I try to delegate some of my work. I look at my list of tasks and ask myself why I’m the only person who can make this decision, and how I may change that.

Manager journal

I have a technique that I call my manager journal. I write a log of everything that happens every week.

This includes the general things, like what I was doing or what core events happened to our system. I also use it to keep track of what I’m worried about that week. For example, there might have been an outage, or an argument in my team, or some of my points didn’t go through.

For example, my concern right now is the design system we’re building. My main concern was balancing its flexibility with performance. I write these in my journal every week and check back every month to track how my concerns have changed and to see whether they’d been resolved.

Keep it to myself

I also write a personal journal for myself, but my major journal is still too personal to share. I try to be as honest as I can when writing it, so the thoughts in it are too raw. They’re meant only for me.

Sometimes I overreact in a situation, and the journal gives me a better perspective. Sometimes I think I did something and it was a huge success, but looking back on it a week later, I realize it isn’t such a big deal.

I use the journal to share some of my concerns, either if I have a solution, or if I need help from a team or from leadership, but I don’t directly share the journal. There is a lot of raw information that comes to me; I put a big chunk of it into the journal, and I don’t want to overwhelm people with it.

Keep it simple

For some reason, I write my journal in English, even though it’s not my first language.

I’ve been changing the format, but the point is to write your thoughts, no matter the format. I used to write a blog, but most recently, I created a note on my desktop called weekly journal, and I write in it every day as a cold storage. I tend not to use any fancy software; I keep it in a simple text file.

The point is to move the information out of my head and into a document that I can look at and manipulate. Recognizing the problem is the first step towards a solution, and this helps me recognize problems.

I sit down every Sunday for about 30 minutes to plan my next workweek. I read through the journal, consider my goals for the week and plan what I need to do.

I use these tricks to keep myself in check.

How do you make a fully remote organization work?

Managing remote teams used to be easier before the pandemic. COVID made everyone stressed. It made it difficult to optimize everyone’s work environments, because their families are there as well, and it complicates things. Everyone faced these issues.

In-person meetups stopped happening, and I’d like them to start back up. We used to hold meetups two-three times a year in Bulgaria, and often up to five people from my team attended them. These were great opportunities to meet in person and get to know each other.

Autonomy

We use a concept we call single-player mode to provide autonomy for our engineers. We want to empower everybody to be able to execute without depending on others. I consider dependency the worst thing on both the people and the technology side.

For example, we hire full-stack engineers because I don’t want to force front-end and back-end developers to have to sync up continuously. One person can execute alone, and their engineering manager has to enable this by providing standards, tools, and guidance.

You need an organizational decision making process where autonomous employees are empowered to make decisions on their own.

Communication

You need the ability to write to your colleagues as clearly as you write code. Software engineers aim to write concise code, but when you look at comments in the code or the code reviews, you often see long comments that aren’t formatted well. They often don’t put the same effort into writing clear comments as they put into writing clean code.

Example from Product Hunt

I’ve found that communication styles differ between nations.

Engineers in the US prefer to start with the problem, go straight to the solution, and then go through the thought process that leads to the solution. The thought process comes last, because if they don’t agree with the solution, they don’t bother reading the rest.

People from Central Europe work the other way around. They want to see the thought process, and the solution itself is less important for them. A leader needs to balance these preferences.

Accountability

I prefer not to measure the time spent with work. In a remote environment, I think it’s better to measure the output of each engineer. It’s difficult because engineers are often blocked by other engineers or designers.

In order to get accountability from people, you have to give them a clear line where they can execute from the beginning to the end with a clear goal. Set clear expectations for them, and make sure they know who to reach out to if they have any issue. Not hitting a deadline is okay, but you need to understand why it happened.

Story from Product Hunt

At some point, an engineer on my team told me that he couldn’t hit a deadline, because it was too much to build in such a short time. I went through his tasks with him, and we realized that half of the features he was supposed to build were useless.

We adjusted his tasks accordingly, and he ended up delivering early.

What challenges are you facing at developing the product?

We used to have scaling issues before we switched to our latest architecture. By now, we seem to have fixed this, and we’re doing well on the technical side.

Updating the algorithms

The biggest challenges currently are on the product side.

Product Hunt has a simple mental model for users. We have a daily feed for products and people vote for the best ones. We have a ranking algorithm that sums up the main features.

Our challenge is constantly fine-tuning the processes that prevent users from gaming our system. They try to game it because a successful launch at Product Hunt is important for them; they often depend on it. We keep updating it to stop them from misusing our system.

We have to be careful when changing the core parts of our system, like the homepage. Product Hunt isn't just ours; it’s the communities’ as well, so it has to work consistently.

I’m proud of stories like when a kid from India launched an app, and it became the top product, beating Google Travel. The whole company is aware of the need to make the system fair for the smaller players, while we need to avoid breaking it. We can’t release a major experimental update to our system and stop the same kid with the same app from getting traction on Product Hunt.

We need to evolve the product, but we have to be careful when making these decisions. This balance has been the challenge for us recently.

Making product decisions

There are two main areas we’re working on all the time:

1. Improving our product for different users.
2. Improving our processes, systems and structure.

We’re currently focusing on the latter.

Our new CEO, Ashley, arrived earlier this year, and she started by asking what the biggest blockers are for the company. The point was to see if we could fix background issues and improve the product in the process. We made sure to get everything that might improve the work we do in engineering.

We’re experimenting and changing things from the bottom up.

What is your biggest takeaway in product development?

Ship early

Shipping early doesn’t mean shipping a product that doesn’t work. The idea is to understand the core that makes your product unique and to ship that in the best possible shape. You can roll out the rest of the features later.

For example, we launched YourStack with little functionality; it was pretty much a wireframe. We manually changed databases rather than using panels. We were using no code solutions just to get it up and running, because we needed to understand what the product was.

If your product is all about tech, for example, you’re building a database engine, you can’t use no-code solutions. Still, focus on the core features, and ship a sensible MVP.