From engineer to manager

In 2015, I co-founded a company with my friend. Until then I had been working as an individual contributor. Though I had been a technical lead to many projects, I hadn’t managed teams. Over the past 7+ years I have learned a great deal on project and people management. My experience has taught me the most than the books and articles I have read. In this series, I would like to summarize what has worked for me with the hope that it would be helpful for someone following similar trajectory. If you have any feedback, please leave in comments.

Project and people management

As a manager, you are managing two things: projects and people. They both require different sets of skills. 

For the most part, managing projects can be learnt from reading books. But managing people is a different skill and it cannot be learnt from books alone. It requires a lot of interacting with people. It requires listening and understanding people’s needs so that you can help them succeed. Usually these needs are driven by an instinct of self preservation. If you choose to ignore these needs, you are doomed to fail as a manager and you will end up with an unproductive and unhappy team.

Project management

Task is the basic unit of project management. Though it may sound trivial, I didn't have this clarity at the start.

Tasks have priorities. Most of my spectacular failures have been around misplaced priorities. There may be a task to build a cool feature using the latest and greatest GraphQL database with micro services. There may be another task which is a boring bug fix that is blocking a customer. Your developer may be excited and start working on the cool task, while there is a waiting or disgruntled customer. It is my responsibility to prioritize the task and to help the team see why a task is important.

When I am going through the list of tasks, I ask only one question: have I assigned the right priority to the task? I follow a guideline that the tasks that are blocking a customer from getting something done demand immediate attention. Those are the ones assigned highest priority.

Depending on the priority, tasks are committed. Every committed task has deadline. 

How specific the deadline should be? You can say a task will be done by 3:30 PM tomorrow. In my experience, this is usually a bad idea. I follow this rule of thumb: if the task will take less than a week of effort, I specify the deadline in days. Else I specify the deadline in weeks. For instance a task that will take three weeks, don’t specify the dead line as Wednesday 4:00 PM of the third week. I say the deadline is third week. It could happen any time during the third week. Why is this important? I have observed that teams generally have high morale when they commit to a deadline and hit it.

Tasks also have dependencies. To keep track of dependencies, every project management system provides some means. For instance, JIRA has “Blocked By” field where you can specify dependent tasks.

Illusion of infinite time

A critical mistake that I kept repeating was saying yes to every task and allowing tasks to be re-prioritized arbitrarily. At the end of the week, I will find myself very frustrated and most of what was planned at the beginning of the week was pushed to the next week. This frustration was contagious. My team also will feel frustrated. When I say yes to everything, I am living under the illusion of infinite time. 

Once a set of tasks are committed, your team’s flow should not be disturbed unless there is a valid reason. I use the same guideline here: is there a customer blocked by some broken functionality? Then it makes sense to stop working on a committed task and unblock the customer. A customer being blocked is different from customer asking for a feature. When a customer is asking for a feature, you can negotiate when it will be delivered. Your doesn’t need to drop everything and start working on the feature.

Bottlenecks

The most valuable skill I developed was to identify people and process bottlenecks. You may not even recognize there is a bottleneck in your team that is preventing from scaling. I developed a simple test for identifying people bottlenecks.

Every time when someone says only X can do a task, X is a bottleneck.

The test is simple and effective. Let me explain. As a manger in a planning meeting, if you find yourself repeating statements like “DNS change can only be done by Joe”, or “bootstrapping a new server can only be done by Kathy”, you know that Joe and Kathy are bottlenecks. Over a period of time, you will find that they will accumulate a set of tasks that can only be done by them. Soon they will be overloaded and worst case burnt out. 

There a few techniques you can use to address people bottlenecks. If you have to do a task twice, automate right from first time. I have seen people giving an excuse that they will automate next time as they are under time pressure. Guess what, next time to automate never comes. And you will find the person doing the same task manually next time as well. If you are under time pressure, let the person do it manually and then automate. If you don’t have time pressure, automate first.

If the task cannot be automated, due to whatever be the limitation, convert the task into a easy to follow set of steps with an associated check list. Documenting the steps will also bring to light what is involved in the task and ask yourself the question why it cannot be automated. Documenting the steps also lets someone else in the team to pick up the task the next time.

Process bottlenecks can be identified only when you have listed down steps involved in a process.

Art of asking questions

The best way to encourage your team to participate in a conversation is to ask open questions. If you ask “Isn’t Redis the right back end for this task?”, your developer might say “yes” and go and go and use it.

Instead if you ask them an open question like “What do you think is the right back end for this task?”, you will hear a totally different answer. They may tell you about a few back ends they have used in the past, what are the pros/cons of each of them, what they read in the Hacker News about this latest back end, etc. You can let your team member be a hero who came up with the right back end. When people feel that they came up with an idea, they have a strong sense of ownership and feel more accountable. If you see any issues with the solution being proposed, you can ask a follow up question that will guide them to come up with the right solution. 

Who knows they may propose Redis itself. Except this time they will feel like a hero for coming up with that answer and feel totally committed to it. 

Summary

I can summarize my learning as:

  1. Being a manager involves project and people management.
  2. Don’t fall victim to illusion of infinite time. Learn to say no.
  3. Learn to prioritize. Every task is created with a priority.
  4. To scale, identify and fix people and process bottlenecks.
  5. Ask open ended questions.


Comments

Post a Comment

Popular posts from this blog

Gotchas with DBCP

I had to make use of DB connection pool in one of the applications that I was implementing. Since I am new to Java, everyone in the team was suggesting why don't you make use of Commons DBCP. Being a fan of reuse, I decided to make use of DBCP and started reading about the parameters that are exposed so that I can customize DBCP to fit my needs. While reading through the available configuration parameters , I was thinking, "I don't need to check the connection to be bad on every borrow or return. It is sufficient if I check for being bad only when the connection is sitting idle in the pool." So I set the testWhileIdle to be true and set the validationQuery to be "SELECT 1 FROM DUAL". I was thinking that the configuration that I had was the optimal for the situation in hand. But one thing I overlooked was, the default value for the testOnBorrow is true. So the moment you set the validationQuery to be any non-null value, every connection you borrow from the po
Read more

A note on Java's Calendar set() method

Remember that the Calendar's internal fields include year, month, date, hour, minutes, seconds, milliseconds and time zone. Whenever you are calling a set() method with multiple fields, like set(year, month, date), it will not affect the rest of the fields. Remember that there is no set() method with multiple fields available to set the milliseconds. If you would like to set the milliseconds, you must use set(Calendar.MILLISECOND, value). Likewise, if you are planning to set all the fields, its a good idea to reset all the fields using clear() method. This will clear milliseconds as well. Most of the times, millisecond field may not be of interest to you. But if you are going to use the UTC milliseconds, by calling getTimeInMillis(), then make sure you set the right values for milliseconds as well.
Read more

The mysterious ORA-03111 error

Recently one of the applications that I developed started throwing exceptions, that had the following message: SQL state [72000]; error code [1013]; ORA-03111: break received on communication channel When I googled around, I couldn't come across anything useful. Sadly enough most of the sites just showed the documentation for that error, without any explanation from anyone experiencing that issues. So here you go, with the best possible explanation that I could come up with. My application sets two things on the connection that is throwing this exception: It sets the fetchSize to be 2500 rows It sets the query timeout to be 10 seconds The database server and the application are separated over a long latency network (actually there is a NetEm box that emulates the long latency between these two boxes) which has a latency characteristic of 50+/-5 milliseconds. This is the whole setup. It is important to understand how the timeout is handled by the Oracle client (in my case JDBC clien
Read more