Short stroll on the Manager's Path
There was a short period of time — for about two and a half years or so — in my career history I was an engineering manager. At one point, I had 11 full-stack engineers reporting under me. It was a short stint, I switched back to an individual contributor role as soon as I had the opportunity to do so.
I decided to switch back because I feel that I don’t have what it takes for the role. However, my short period of time being an engineering manager, had been an eye-opening experience. It is good to step into the other side and experience it for yourself.
Here are some learnings from my time as Engineering Manager, most of them are advices from my mentors during that time — other software engineering managers that I look up to.
You can’t fix people, but you can improve processes, infrastructure, and toolings.
One of my mentors had told me this casually, I wish I had known this sooner. It is not your job to change individual team members’ personalities, habits, or intrinsic qualities. It is not your job to motivate your team members individually. Instead, you should aim to create an environment where people are more likely to thrive by improving processes, infrastructure, and tooling. Establish a team process that fosters peer-to-peer recognition, which helps maintain morale and motivates team members.
You can’t fix people — human beings are complex creatures. We typically are resistant to change, unless we want to change ourselves. To micromanage the team up to the point of forcing a certain behaviour often leads to frustration, resentment, or disengagement. “Fixing” people is not practical (and not ethical if you think about it).
Improve processes, infrastructure, and tooling instead. What many companies refer to as ‘culture’ is, in my view, just ‘standard procedures’, what I refer to as processes here. Calling it ‘culture’ just makes it sound more hip and less corporate-ish.
When we encounter these problems with the team; struggling to meet deadlines, bad quality and error-prone code gets into production, slow feedback loop in the development environment. These are all symptoms of having an inefficient process in place.
When the team that I managed back then constantly struggled to meet deadlines, I made the mistake of trying to fix the problem by shifting them around, adding more engineers to work on a more immediate and important task. They had to context switch most of the time. For software engineers, context switching is costly; it creates cognitive overhead and fatigue. The quality of work suffers as the result.
That was my knee-jerk reaction to the problem at hand. What I should have done was to take a step back and evaluate the team planing process. There was no clear planning process or task prioritisation framework. There are many methodologies when it comes to prioritisation frameworks, don’t be too academic about it, just identify the impact and value of each task and how it aligns with the set goals.
Similarly, for problems where bad quality and error-prone code gets into production often, perhaps we should look into the CI/CD process or the testing procedures.
But then again, wouldn’t plenty of processes slow the team down? There are probably procedures and processes already in place, but nobody cares and bypasses them anyway. Oftentimes, software engineers perceive these processes as bureaucratic red tape that hinders their ability to ship code.
“Make the right thing the easy thing” was the title to a popular talk given a few years ago (look it up). When you reduce friction for doing the right thing, people will do the right thing by default. I am confident that most folks hired are not stupid or cruel, probably just a bit lazy or are under the pressure of needing to deliver on time. Nobody will go out of their way just to do the wrong thing, unless the person has nefarious reasons. Even if that is the case, there are processes and guardrails to avoid this.
To get people on the same page, you literally have to create that page, and get them to be on it.
One of the things that an engineering manager has to do is to get alignment with other teams or with other part of the company. You need to make sure that your team is moving in the right direction, the same direction other teams are moving towards. The direction should be to whatever target the company as a whole has set for themselves. Alignment ensures that efforts are focused, resources are used efficiently, and goals are achieved with minimal friction or misunderstanding. You need others to be on the same page with you.
To get people to be on the same page with you, you need to literally create that ‘page’ and get people on it. Create a Google Doc, or Confluence Wiki, or a Notion page, or any document sharing platform that your organization uses. Share it with others that you want to get alignment with. Give them permission to comment on the doc. This will get the ball rolling. Once all comments are addressed and needed changes have been made to the doc, you have a written document of the things that you and others agreed to, the things that we are aligned with. You can next start the engineering spec, or product spec, or whatever document required to move it forward, but at least you already have a source to refer to.
Most of the time, meetings are more of a formality ritual and less of a discussion place. Actual discussions happened before the meeting, better when it is asynchronous. You may need a face-to-face interaction, do that when needed, and update that document page with whatever that were decided, and have the other party confirm to what you have written down. Written down confirmations are better than verbal confirmations.
Misalignment happens because different teams or individuals have their interpretation of what needs to be done. Clarity reduces misalignment. Having a clearly written down shared ‘page’ (the doc), you eliminate room for conflicting assumptions.
This shared understanding creates the feeling of ownership among the people involved, since they feel that they have participated, even if it is just reading and confirming the doc. People are more likely to commit to the plan.
Don’t just say No, work on how we can get to Yes.
When I was a junior, I used to have managers who boldly say no to requests from other teams. At that time, I thought he was doing his job, he was shielding the team from excess work. I thought he was on our side. Later on, I realise that he was just being difficult. The team got a bad rap from the other teams. We were a team that is perceived to be a team that is difficult to work with.
When I became an engineering manager myself, I realise that engineering managers actually have two teams. One team is the team that the engineering manager manages, the other team is the group of other engineering managers peers together with non-engineering peers (product managers or from the business unit).
To start with “No” to a request — that you know it can’t be done — shuts down innovation and creative thinking. Instead, you should explore the constraints, trade-offs, and find other potential paths forward (no matter how crazy it may seem) to achieve the desired outcome.
The leaders who ask for really hard, and at times almost impossible deliverables, they don’t have the same information on the ground as you do. Simply responding with a short “no” does not improve their understanding of the overall situation. They still don’t have the clear picture.
You add value to the conversation by giving all the possible ways of moving forward with the request. Explore all the creative and crazy ways to get to yes. This opens up the discussion, and often time it will lead to a different request than the original impossible ask that they have given. A more reasonable request that makes it possible to say yes to.
Every so often, the right answer is actually “No”, but at least it is a collective “No”. It is not a choice one person is making. Everybody knows why it is a “No”.
Don’t mistake what I am saying here as to blindly saying “yes” to everything. This is more about having a problem-solver and creative thinker mindset person who adds value, rather than a gatekeeper who focuses solely on limitations.
Closing thoughts
Take this advice with a grain of salt. My experience as an engineering manager was a short one. My experience is limited, and I don’t think I was a great engineering manager at that time. These are a few lessons from my experiences, combined with my observations of other great engineering managers I’ve worked with.
