Radoslav Stankov: Perspectives From The Bulgarian Who Leads Product Hunt’s Remote Engineering Team
Every week hundreds of developers, entrepreneurs, and creators launch their new products on Product Hunt. With several million visits per month, the platform, acquired by AngelList in 2016, has become one of the go-to-sites for technology lovers. It’s the place where early adopters can discover and talk about everything from emerging enterprise software tools through productivity apps to cool web projects.
But did you know that the head of Product Hunt’s distributed engineering team is a Bulgarian living in no other city but Sofia? His name is Radoslav Stankov and we figured it’s about time the tech community in Bulgaria gets to hear his story and insights on remote work, IT processes, and software development in general.
Trending Topics: How did you end up at Product Hunt?
Radoslav Stankov: Well, I was one of the company’s first employees after the first funding round. Andreas Klinger, Product Hunt’s head of engineering at the time, was looking for someone to help him set up the programming team as well as the platform infrastructure. We previously worked together at another startup, LOOKK, so he reached out to me with the initial idea for a six-month collaboration… five years later I am still here.
What is like to be a part of a team that’s distributed across three continents and seven time zones?
Product Hunt has been a fully remote company since day one – at the beginning, our founder Ryan Hoover and Andreas didn’t meet in person for months. In my opinion, remote work is the future of work, especially for software engineers. I like being a part of a distributed workforce – during my entire career that started back in 2002, I have worked in a traditional office environment for less than two years and a half.
I think one of the biggest benefits of remote work is that people develop the habit to communicate more effectively than if they were in the same place. You just need to have rigorous processes and make sure everyone’s responsibilities are clear. Remote work produces the best results when you have a product to iterate over but if you seek to make an important strategic decision, then face-to-face interaction is definitely better.
How do you decide what new features to implement in Product Hunt?
We work quarter-for-quarter, using the Objectives and Key Results framework (OKR). At the end of each quarter, we sit down and decide what are our goals and priorities for the next quarter, what metrics we want to increase, what do we hope to learn over the upcoming period, and what features we need for all this to happen. We plan very carefully – if the execution takes longer than three months, it means that something has gone wrong. There are scheduled exceptions. For example, for YourStack, a new product we develop, we allocated one year of development time.
Can you tell us more about YourStack?
It’s currently in beta, you can go check it out at yourstack.com. The project started as an idea for a new Product Hunt feature. We wanted to add a button that says “I use this.” However, when we started thinking about scope and functionality, we realized that’s something so big that it would make more sense if we create a separate product under a separate brand.
Building YourStack is a different experience. When we release a new feature on Product Hunt, we can count on the large pool of existing users to give us feedback. That’s not the case with YourStack. It’s like we went back in time to the early days of Product Hunt.
What do you like doing outside of the (remote) office?
For the most part, I just try to relax. I love listening to audiobooks. Besides that, I organize dev events like React.NotAConf and the React.Sofia meetup.
Any programming books you would recommend?
Yeah, three titles come to mind. First, we have “The Pragmatic Programmer”. It teaches you what being a programmer means and how to develop a proper mindset for the job. Another good one is “Refactoring”. After all, as programmers, we spend most of our time improving and cleaning existing code rather than building products from scratch. The final one I’d go for is “The Phoenix Project”, a novel that explains IT operations and processes in a light and easy-to-read manner. It’s actually written by the guys who pioneered the DevOps movement.
What advice would you give to young software engineers, the ones at the very beginning of their programming careers?
Try to get a deeper understanding of how things work. A good software engineer should know their languages, frameworks, and technologies very well. But a great software engineer needs to also understand the business side and the real-life context in which a given product exists.
