I'm Roman Voloboev, remote Full stack Team Lead and Junior Product Manager, Ask Me Anything!

animir profile image Roman Voloboev ・1 min read

I started developing web solutions over 10 years ago. Since that time I have tried many languages on the backend: PHP, Ruby, Python. I use mostly NodeJS and ReactJS for full stack developing these days. Quite usual story, ha.

I've been working as Team Lead in distributed teams for the last 2 years. Helped to build 3 startups from scratch. Still polishing skills related to management and mentoring other developers.

I had also founded small online retail business, it was really amazing experience!

One my open source package rate-limiter-flexible is getting popular. I'm glad, it is useful for community.

My cup of tea is balancing between quality and speed. I enjoy successfully delivered products, especially when it is done out of expectations with some new idea.

I've been trying to combine 10 years engineering experience and business thinking, as it excites me.

My current reading is "Skunk Works" by Ben R. Rich. Glorious story about building new airplanes by group of top-notch engineers from Lockheed company on the tech edge with quite good engineering and product management real life examples.

Ask me anything.

Posted on by:

animir profile

Roman Voloboev


Full Stack developer and open-source lover


Editor guide

Hey Roman,
Curious question, very similar to one below, but as a Team lead working remotely, how do you effectively gain an understanding and know what your team is working on? As this has recently came up in the organization I work in, do you and your team utilise a tool for documenting and collaborating outside of say GitHub/Repository? How effective do you find meetings?

Thanks again! new member of Dev.to :)


Hi @timmythegamer
Thank you for your question! It is quite important for in office worker too.

I usually work with Jira and it's Scrum board. It helps to see the full picture. But it is just data. Sometimes developers may spend time for something not really related to current task or task is not understood/described well. It is good, if there is only one PM or CTO responsible for planning current sprint. I have worked for a startup, where two people could unpredictably add tickets in TODO column. Developer starts doing it and this brakes Team Lead's plan.

This is where Daily meetings come into play. Daily meetings partly solve issues with reassuring, that developer does what is necessary and doesn't go wrong way. But developer still can waste about 1 day and this is may be crucial for current sprint.

Team Lead should work with his team to avoid that. Developers are different as people and as professionals, so there is no silver bullet:

  1. All developers should understand what is the aim of product or at least current sprint. Context helps identify wrong direction even with lack of task description or when task in current sprint by mistake.
    If it is said: "we're working on 2 new reports and bug fixes in user profile during current sprint ", probability of questions raise up, if there is a task "change billing type".

  2. Team Lead should see and notice every developer's characteristic. For example, there are two metrics: 'who trust task description fully' and 'who constantly doubt in task description'. Every worker somewhere in between, of course. I won't go deeper phycology, it may take years :-) Team Lead should notice habits and characteristics of his developers. And when there is really important ticket, that data about developers may help to avoid fails.

  3. There should be a rule, that all requests and tickets should go through Team Lead. Any direct request from the top manager to developer may affect current sprint success.

Even with the best Team Lead, fails are not possible to avoid. Team of seasoned and responsible developers is the best for downgrading number of fails. But, you know what? Such team doesn't need a Team Lead ;-)

Hope, this is useful input.


Thanks heaps for the insight and clarity! the depth of knowledge and information is greatly appreciated as well.

I can relate to your sentiment regarding understanding the developers/employee's reporting into you and which require guidance.

The use of daily meetings in conjunction with the use of a digital Scrum Board for organisation seems to work quite well in your scenario, we are currently challenging the requirement for a daily meeting in how our team operates which is quite interesting.

Great to hear your side of the story and thanks for providing a tonne of context, I'll definitely be frequenting your posts for more insight :)


Please tell us about the remote working experience. You might give some suggestions to people who never worked remote. For example, I never worked as a remote Software Developer.

I wonder about the development process, meetings etc.



From my experience, development process, meetings, mentoring, etc. only can help make process more stable, if applied correctly. Obviously, there should be some process defined, but it is flexible and depends on product, requirements and money. All things are the same as in office. For example, if company hires remote developers to save money with idea, that Agile can bring a good result, it is completely wrong.

Here is a short list of quite common developing process steps: discuss, plan, create task with description, assign task, answer questions, help with details, review code, check all tests are passed, prepare release, smoke test, fix bugs, release. Repeat. It looks like usual waterfall, but it can be covered by Agile/Scrum as well.

Many people ask "Should I try working remotely? What should I do?".
The first step every remote worker should do is realising 2-3 main motivators. Money must not be in this list, as it is by default. HR/Team Lead should try to realise those motivators during interview process and the first months. It is good for in office worker too, but the key for successful remote work.
For example, 3 things which excite and motivate me:

  1. Amaze people with fast and smart solution/idea. I like praise and respect. And I like to achieve that.
  2. I hate and afraid fails. I realise, that it is impossible to avoid them. But still hate fails. And even if I do not like my current task and do not know how to complete it right, I continue with all the power of "the dark side of the Force".
  3. Creative work can carry me away in a good way. It can be software architecture, where many aspects should be considered. It may be road map creation. Or R&D. This is not only related to the first point of this list, but also about enjoying subjective beautiful.

If someone works in office and want to try remote work, he should try assess motivators. Or talk to psychologist, which in many ways better and less time consuming. However, it may be a good exercise for the future Team Lead or Product and Project Manager.

Or just save some money for the next 6 months and try working remotely. There are no obstacles to return back to office.

Hope, I at least partly answered.


Hi Roman thank's for sharing !

Do you have resources to recommend to learn react?


30 Days of React was one of the best for me.
And official react docs are really awesome


What's your advice for aspiring developers that are interested in product management? Is there anything one should learn or focus on to become a pm?

animir profile image Roman Voloboev github logo Ask Me Anything

First of all, read any popular book about Product Management to get your head around the role. If you're excited, try related courses or even better your own small (or big?) project. If it is for you, save some money and try to get a job as Junior PM. Salary will be much less than for developer the first couple of years, but there are a lot of opportunities. And there is a need in a great PM anytime. The same for developers though :)


Oh Skunk Works looks great, any other recommendations?

  1. "Inspired" by Marty Cagan with examples and articles on svpg.com. This book is mostly about software products development.
    The best thing, there are real life documents like product opportunity assessment doc from Netscape.

  2. "The Inmates Are Running the Asylum" by Alan Cooper

These two in my list:

  1. "Thinking, Fast and Slow" by Daniel Kahneman

  2. "Metaphors We Live By" by George Lakoff