Manager Stories

Published at February 27, 2026, 16:09 GMT+0
An image illustrating the two people in pilot and copilot seats. Credit to my wife, who drew this for me.
An image illustrating the two people in pilot and copilot seats. Credit to my wife, who drew this for me.

Table of Contents

Hey there! I hope you are doing well. This post is a somewhat indirect continuation from the previous post, Lead Software Engineer: Year One. I didn’t follow the “Year X” convention because it feels pretty weird if there are some “year skips” (like from Year One skipping to Year Three), and who knows if in the future I’ll lose track and suddenly it’s “Year Ten”. Look at me, worrying about things that haven’t happened yet… oh well.

In any case, this post contains stories that I experienced in the past 2 years. Just when I thought I had seen it all in my first year of being a manager, life kept bamboozling me with the most unexpected things. So, yeah, here goes!

The many kinds of direct (and indirect) reports

I have collaborated with a lot of people within my team in the past 3 years (including my first year). Based on those experiences, I would say these are 2 aspects that you should expect to face when you want to (or are “forced to”) be a manager:

  1. Capability aspect: This is the “hard skills”. Example: how well someone solves a problem and communicates with others.
  2. Motivation aspect: This is the “drive”. Example: how hard someone tries to grow personally and professionally.

Let’s try mapping these 2 skills into a quadrant with 2 axes, the X-axis is Motivation and the Y-axis is Capability.

A quadrant depicting what we need to provide to each type of person.
A quadrant depicting what we need to provide to each type of person.

Based on the quadrant above, we have 4 “states” of a person. Of course, this is simplified, and there are more “layers” to it. Also, keep in mind, there are probably many reasons why the person is the way they are (and understanding those reasons is often the hardest part).

  1. Low capability, low motivation: not the easiest people to manage (unfortunately). You usually need a lot of micromanagement and support here. The latter, especially, so you can see how you can help their situation. If the situation doesn’t improve, it may be best to raise it to the Human Resources team before it gets out of hand and becomes a lose-lose situation.
  2. Low capability, high motivation: they are the people who have the “potential”. They may start slow, but they pick up the pace as they become more comfortable, more confident to tackle more challenging tasks, and ultimately grow. That is why we have to give them opportunities and support. Although, there is also a spectrum—some have aspirations but don’t follow through on them.
  3. High capability, low motivation: sometimes the most frustrating people to work with. They have the skills to work on a task in a good manner, but they don’t have the drive to do so, so we usually end up having to micromanage. You may want to discuss with them ways to improve their morale, one of the options is to give them room to express themselves. However, sometimes they can’t keep their expression within the boundaries that we define (e.g., having very drastic opinions and no middle grounds).
  4. High capability, high motivation: the best people to work with. They can break down tasks, they can own an initiative, and they take ownership of outcomes. They make your life easier. Shower them with opportunities and freedom of expression so they can keep actualizing themselves.

Now, as mentioned above, of course, there are other layers, such as the “middle grounds”. They have both good capability and motivation. They aren’t the brightest stars, but they get the tasks done and have good autonomy.

All that said, it’s important to note that I used the “states” term, because it’s all dynamic. You might be highly capable and motivated at one point, but then you can be very unmotivated due to certain reasons. Someone who starts off as not capable and unmotivated may end up being the most capable and motivated person in the team.

Visibility

It is pretty straightforward when everyone that you manage is in the same team, you know every context that they are in. However, when some of them are outside of your team (e.g., in a matrix organization where you manage people who are embedded in other teams), you lose visibility.

You may still see their pull requests, but how about the process? You will never see how they communicate because each of them may have their own chat channels and their own workflows. You’ll have to rely on the stakeholders on that team (e.g., Product Manager or the Lead in that team), who may have a different perspective or only share partial feedback. Optionally, you may ask yourself to be invited to their Slack channel, but then you’ll risk being labeled “control freak”, it’s a bit awkward situation.

In these kinds of cases, what we can do is to let go of our control and see how the person contributed in cross-team or public spaces. Do they write documents? How do they communicate in public chat channels? These kinds of things are good opportunities for you to observe and measure their state.

Also, if possible, I think it’s a good idea to always encourage those reporting to you to communicate in public chat channels (instead of in direct messages or private channels). That way, not only can you get visibility, but also your managers. Hence, at some point, if you want to provide proof of their activity, it’s easier to access.

Balancing between managerial and individual contributor

When my role was still around “pure” Individual Contributor (IC), life was… maybe easier? I had fewer meetings, I didn’t have the responsibility to help others grow… although as peers, I was still able to help do the same by setting up examples: write documentations, communicate clearly, be proactive, and so on. But it was out of my own desire, not an obligation.

Now that my role is more of a manager, my responsibility shifted from “doing” to “coordinating”, ensuring that everything is heading in the right direction. This requires knowledge of what other teams are doing: what are the behaviors of the services they maintain, and what are the third-party services that they use, to name a few.

I have to also make sure the team morale is okay… which can be done in probably many ways. One of the things that I do is ensure everyone has a safe space to communicate. Sometimes people are afraid to communicate because they feel afraid of making mistakes. I try to counter this by openly making and admitting mistakes myself (hopefully not too often).

Lastly, I have to make sure that the highest performers get recognized and are regularly “challenged”. It won’t work if those highly capable people are only given “peanut” tasks. They will be bored before you know it. But, be mindful. We don’t want to burn people out, we have to balance the chills and the challenges.

But wait, did you think I don’t do IC-specific tasks anymore? HA, wrong! I still have to do them, for better or worse. But yeah, it is what it is. Looking from another perspective, it kinda emphasizes more the importance of context switching. Back then, I really liked when I could “tunnel vision” the entire day working on a task; now that is a luxury.

Caring more about numbers

This is probably the area that I have the fewest stories about.

I used to care so little about numbers. My focus was just build, build, build. If the feature worked and was used by other people, I would be happy. Feature being delivered? Cool, let’s continue doing other features. However, it was very qualitative. There was no “data-oriented” way to check how the products were being used.

So, I tried to improve my knowledge around data/log retrieval, Google Analytics, spreadsheets, and all other kinds of products that could drive decisions through data. At some point, I discovered that an onboarding feature that was up for almost 6 months didn’t really click with most customers, as proven by low usage and conversion rates.

I’m still far from being able to use Google Analytics to track funnels and behaviors effectively, but I think it’s a good skill set to have so we can help drive decisions that actually matter, so we don’t implement something “just because”.

Closing words

Well, that’s all, folks! I’m not going to sugarcoat it by saying something around “it’s been rewarding” and so on (like what AI agent suggested me to); I’m just going to say it has given me unique challenges so far and I’d say the experience is quite invaluable to my growth, be it professionally or personally.

Hopefully this is useful, and see you on the next post!

Edit this post