A mentor is someone that provides guidance and is an important asset on our journey to be the best version of ourselves. Sometimes we have mentors and we don’t even realise it. But we should be conscious on who are our mentors, how to get the most out of them, find other mentors that cover other areas and also help them improve their own mentorship skills.

I remember when I was at a company and I found myself with several mentors without realising. Due to some circumstances I had monthly 1on1s with my direct manager (okay that’s to be expected) but also with other people with different kind of roles:

I always liked doing deep reviews on pull requests. I’d try to have an ownership mindset. If I approve a pull request, then it’s as if I was the author. I’d need to have full responsibility and would be able to fix or change that code. This approach requires a significant time investment per pull request. And sometimes generated discussions and I always liked to discuss opinions, approaches and iterate on making great code.

But when I started being an engineering manager, I started to be overwhelmed with pull requests to review. I remember a time where I’d start by day having 20 PRs to review, and from different areas (backend, frontend, quality, ops).

I needed to find a way to be effective and be able to add value.

Is assessing performance important? We usually have performance reviews tied up with end of year bonuses and promotions. I tend to focus more on performance towards continuous improvement. If we have a template of what we should accomplish and how to add value and we can see if we’re on track we can adjust and improve.

I believe that performance talk should be held at 1on1s. We should not wait for the end of the year to give feedback and a score. We should have a continuous process for leveling up people.

I really like heated debates. It’s great to discuss different strategies of doing things and struggle until we align on a course of action. A healthy and productive team should have heated debates from time to time. But the main point should not be about being right.

I think a lot on how to make these discussions more productive and how to take the most out of every participant. I’ve been trying to pay attention on how we present our ideas and opinions and how other people react and give feedback.

With growth companies tend to create new ways of work and interact in order to scale. The simple vision of small teams using the some agile methodology simply does not work in growing companies that want to retain talent and keep their engineers motivated. The repetitive work, the fact that small teams don’t have the capability to be responsible for several engineering solutions and the fact that, in a small team, challenges that can be given to a engineer are limited makes growing companies to question the common work methodology and create new approaches to software development.

Pipedrive is one of those companies. Joining the best practices used by the biggest companies and, using this information, appling a major brainstorm, it came out a framework that reimagines the way we produce software development.