November 20, 2021
I wish write down things I’ve learned by being a manager in a systematic way, so that it can be used to guide my future development and execution.
I learned that I dont like to do things like organizing Team Socials, or organizing meetings, I am not sure if anyone enjoy such activities, but I certainly dont.
I dont like to spend most of my time fighting complexity with pre-existing software system that I have little context of, it sometimes feel unproductive and pointless, it is not glorious, and I dont take pride doing those work, plus its very taxing and stressful.
I really enjoy doing system design work, and here system isnt limited to software system, but also organization system, I particularly enjoy the exercise of forming a theory/hypothesis and test it out quickly.
I failed to build a good relationship with a PM, I think it boils down to my refusal to deal with that person, which in a way is saying I am super flexible and sometimes be a bit stubborn, presumably because I think I have choices.
I am also not doing a good enough job to push back strongly, and can sometimes create false image of agreement, although I dont feel this problem when interacting with most people, I am definitely not able to do it well with certain people, this suggests I need the right environment with the right people to perform well.
I am good at overriding decision and call for halt on projects, 2 of my biggest mistakes both stem from it, when I delegate, I tend to let delgatee make the call, while I have a gut feeling that’s not the right call, I am always hesitant to make strong intervention. Thinking deeper into this, I think it mostly comes from my desire to rely on working experience over my 10-feet-pole away view. This can work against me occasionally, especially when dealing with less-experienced subordinate. I am not sure if I need to change here, if I were to, I will need to figure out a way to identify when to override with high precision.
Another failure was my incorrect commitment to an effort that goes nowhere, on my defense, I didnt have enough information to understand where we are going but was still required to do something with it. But I really should have done it better by collaborating better with the team, or to be more risk-averse and dont work on platform-ish improvement. I prefer to not treat this as area of improvement but instead try to get into places that this isnt a big concern, ie. get more autonomy, have enough structure and vision in place so that I can actually plan for future.
Another major weak area I had was delegation, on hindsight, I made quite a few bad mistakes on not delegating more aggresively, there are a few reasons of it:
I think only reason 3 is valid, and 1 and 2 are poor solution, for 1, instead I should let the team share the burden, feel the pain, and then motivate us to fix the underlying issue, really we are underpower and forced to own way too many things. For reason 2, I should let them learn.
Another issue I had was that I dont know how to delegate when it comes complex issue like project management, there are too many moving parts and I dont always know what to delegate and when to intervene. The best case is to fully delegate and ask delegatee to be accountable for outcome, but not everyone is capable of doing this, maybe I should just not delegate.
On hindsight, a better model would be to keep a trail of the most complex issue a person had handled, and then based on that determine the task to be delegated.
I am also not very good at complaining, there are a few important issues that I’ve raised but I didnt communicate its importance enough, I think there’s also a part where I dont want to be too negative, but I think the final outcome is much worse.
I also failed at distributing the right amount of focus across multiple projects at the same time, I should have delegate stuff that I already know how to do, and spend most of my effort on what I dont know how to do. I think on the project I dont feel and thus not acting like an owner. This insight is important because it might happen in the future on my subordinate too.
I think I am good at designing software system with flexibility in mind, as I tend to care alot on interface and conceptual clarity, but this isnt necessarily the top priority for the business. I need to learn when to apply this.
I am also quite good at process improvement, I’ve either made or help with a few improvement in the company, I think my approach is mostly emotional driven, I pay a lot of attention to my emotional reaction, if there’s something that does not feel right, I tend to look deeper and analyse it, this opens opportunity to fix them, but doesnt guarantee.
I think I am also decent at organizing people to reach certain goal, I know how to reduce effort from people and I know how to identify conflict and bring focus to them, in general I am quite good and summarizing.
I think (or hope) I’ve learned a few things about Management, borrowing from High Output Management, the output of a manager is the total output of her team.
I think a manager is expected to meet 2 objectives in general:
In order to maximize the team’s output, a manager need to:
In order to grow the team over time, a manager need to:
One aspect of keeping the operation smooth is to make sure the team has the right capacity, a manager is responsible for staffing. One important thing here is to have a good model of people, including their skill, knowledge and style of working. Remember people are not fungible, this is more important for complex project.
This is something I still do poorly of, largely being reactive here. I need to develop a way to be more proactive here.
TODO: develop a system to measure capacity
One of manager’s job is to keep the operation running smoothly. Process is a tool you almost cant avoid, by setting up processes, you setup some level of expectations among team members, and provide some level of predictability into everyone’s day to day life.
As a new manager, I think the right way of going with it is to start with little processes, experiment and only add process where needed, preferably with consensus.
I sometimes overlooked a benefit of simple but non-efficient processes, which is the ease of implementation, a process might not be the most efficient one, but if it is alot easier to implement when compared to alternative, it can be quite appealing. One example I have is the way a team deal with Escalation ticket, at the very beginnig I was pretty much against the idea of fix allocation to deal with issue, for example every Friday is bug day, because it ignores a lot of intricacy in real world, like not all bugs are equal, and many bugs take more than 1 day to complete, but I am now changing my view and see it as a legit approach due to its simplicity in implementation. I still think it is not great, but there are cases where it can work great when you dont have enough attention to fix it
As a manager, you’re responsible for the output of the team, its your responsibility to understand and/or determine the most important objectives for the team, one needs to manage multiple dimensions of it.
IMO, a tech company (or any company that I want to work with) should pursue 2 traits:
A manager is also generally expected to help with subordinate’s growth, there are a few parts of it
In general, it is better for a manager to actually know how, so that one can help improve your subordinate’s skills and knowledge by mentoring. There are situation where this isnt the case, in such cases I’ve tried to learn the domain and failed miserably, I think the right thing to do is to trust the expert and manage by listening and delegation, focus on the outcome and let the expert to figure the how.
Part of managing people is really to manage their expectations ,and to communicate your expectations of them to them, and stick to it. Be clear what is rewarded and what is being punished for, be consistent, and this will help people to grow or maintain at a level you need them to.
I think a key about being a good manager is to understand your reportee to a good enough level. That includes understanding how they react to complexity, ambiguities and uncertainty. Understand their preferences, communication style and openness, understand their motivation is important and it helps you get the most value out of them.
There are many reasons why trust is important, but personally it is simply an environment I want to be in. From a practical viewpoint, the more complex and ambiguous the works are, the more trust we need within the group so that people support and cover each other when needed. You want a team that people are willing to do extra when needed.
Should a manager focus on keeping on top of technology advancement? How?