I was always very focused on speed and productivity, but mostly from my point of view. Developing features fast and with quality is still one of my favorite problems to solve. But now that I’m more of a manager, I have to deal with new insights. How can I balance developers that are so fast that they slow the team down?

Usually developers frown on processes. They want to be left alone working on their tasks and concentrated. And indeed that’s the best use of their time. The problems arise when we have several developer threads working in parallel and we need to sync them. So a new favorite problem to solve is how to make developers productive individually while potentiating the team and the overall output of the team. But for that… I need processes.

While reading Atomic Habits I stumbled on a phrase that got me thinking on my goals as a team leader: “Suffering is the source of progress.”

I’ve worked on several projects where the suffering was seen as usual. It was so usual that the developers didn’t even question it at all. I still see it happening to this day even on healthy teams and projects. There’s this thing that happens that causes suffering somehow, but we’re all so used to it that we just take it as is without questioning.

When we need to make decisions we may schedule a meeting, or start some POC or just lead by example. We’ll need to properly explain our idea, present pros and cons and communicate it well to all interested parties. A process we’ve been using for this is to create a decision log document.

This is similar in concept to a RFC but the semantics are different. While on a RFC the focus is on how we’re doing something and specific details, the decision log is all about presenting ideas and reach an outcome.

As a line manager one of my responsibilities is to level up developers. This is something very challenging that I started to like a lot. I have a primary goal on my 1on1s: how can I level up this person? How can I follow the work that is being done and give good, candid, actionable feedback? How can we know that in fact we’re improving?

This starts by trying to understand what my mentees value and where do they see themselves. I try to do that is by asking:

Imagine that you are 10x more better. What does that look like?

Once upon a time I had a manager that spent the first two weeks of his then new job going through Excel sheets and meetings with the CEO. I had no idea what was going on, none of us in his team had. He was the first to arrive at the office, said good morning to the rest of us as we walked in, had coffee and some informal chats with us about how things were going and for those two weeks that was pretty much it. There was no bossing around or implementing “disruptive” (please do air quotes while reading for full effect) procedures. At some point we were wondering if he was going to do any actual work at all… ever!