Time Management for Engineering Managers
When we first founded our company (Xendit S15), there wasn’t a need for the founders to manage anyone but ourselves. Given how small we were, there were times when I felt that we were almost telepathic; able to communicate our intent with minimal words and instantly switch context to solve problems together. Fast forward to 2021, with Xendit serving thousands of merchants across Southeast Asia and employing hundreds of talented individuals, the need for effective and empathetic managers has never been more clear.
My journey in first becoming an engineering manager and later managing through other managers has not been the smoothest journey. My hope in sharing my experience is that you (the reader) will be able to avoid some of the pain I’ve experienced, especially in scaling yourself as a manager.
I believe that at core of being an effective manager, one who is able to scale as their companies, teams, and responsibilities grow lies crucially in how they approach time management. Managers don’t get more than 24 hours in a day even as the demands of their customers and teams grow.
There is a quote which goes “time is money”. In my experience, it’s closer to “time is like money”. There are some similar properties between time and money, most importantly of which is the idea of compounding interest. This idea definitely isn’t new, and I’ve shamelessly borrowed it from Rory Vaden who explains it better than I can in his Ted Talk. The thesis that he makes is that it is possible to multiply the amount of available time by investing in activities that reduce the amount of future time an individual needs to spend on the same task. An example of this can be automating a task to manually generate a report which takes 3 hours a month. If that automation takes 6 hours to complete, and reduces the time it takes to generate that report from 3 hours to 1 hour, then that time investment will break even at month 3, and starts paying back 2 hours/month in each subsequent month. A relatively contrived example, but hopefully enough to get the point across.
Rory focuses on 3 key areas to invest in current time that has the potential to gain future time. I will explain each of them below in the context of scaling as an engineering manager:
- Reduction
- Delegation
- Automation
Reduction
Reduction is asking the question, “Do I really have to do this task?” and if the answer is yes, asking again “Do I really have to do this task RIGHT NOW?”
The simplest way to gain future time is to reclaim the time that was going to spend on the next task. This concept was extremely counterintuitive to me early on as a manager, as I had come from a software engineering background where my default mode was to try to ship as many features and stories as I could handle (partly because I enjoyed it).
I quickly learned the hard way that this approach wouldn’t work as a manager because the demands of customers and the team quickly outpaced what I could personally focus on each day.
But even though I knew that the approach wouldn’t work, it wouldn’t be until later that I realized that taking the short term pain of saying “no” and disappointing someone upfront (often myself) was important precisely because it allowed me to reinvest that time saved into much higher yield time vehicles.
Reduction in Practice
I take reduction very seriously because it’s very clear at this point that the rate of growth of the organization eclipses my very human limitations. Allowing my tasks to grow linearly with the organization would result in disaster for myself and for the organization which is bottlenecked by me. To this end, I’ve redesigned the way I approach my to-do list.
This CLI does two very useful things to help me reduce my tasks:
- Forces me to assess whether any task that I’m planning to work on is important enough to add to the list before it’s added.
- Based on the answers to the impact and urgency score, it will automatically sort tasks in my list based on a modifiable heuristic, meaning I will only be able to see my most important task at a time. My goal every day is not to finish every task on my list, but rather to tackle only the most important ones.
Delegation
Delegation is actively asking the question “who will take over this responsibility from me in the future?” before embarking on a particular task. Delegation is, on average, a better time investment than simply reducing. Delegation in its best-case scenario can be an exponential rate of return if the delegates are able to successfully find others to delegate to.
However, delegation is not without its risks. In its worst case, delegation can result in a net loss of time if delegates need to be micromanaged in order to be effective.
Delegation in Practice
My approach to delegation can be partly seen from the CLI example above. Before I allow myself to add a task to my list, I ask for a hypothesis on who could be a candidate for future delegation. Effective delegation is a function of effective hiring and grooming, both of which are immense subjects.
For an engineering manager just starting off, my advice is to view delegation as an investment in future growth rather than purely a means to offload undesirable tasks or increase short-term human capacity (e.g. to service operations).
In practice, there will be situations in which hands are needed on board just to keep the team from sinking. Past that stage, delegation is at its best when the initial group that was personally groomed is able to replicate that process within their own teams.
At Xendit, we spend a significant amount of time in training our employees to take on lead and management roles, with the expectation that they do the same within their teams.
Automation
Automation is actively asking the question “can a piece of software partially or fully replace a human in performing this task?” Automation is, on average, the highest rate of return on time investments of the 3 mentioned above.
Software is increasingly easier to scale horizontally in the cloud and does not need to sleep in the same way that humans do, making the upper bound on returns extremely high.
As long as the fixed upfront cost of development and variable maintenance costs are lower than the amount of human time saved, then automation will typically yield a positive return.
Automation in Practice
As a software engineer by education and by training, automation holds a close and dear place to my heart. However, my experience in automation as a manager is significantly different than as a software engineer. The key differences and corresponding pitfalls that I’ve observed are:
- On average, less clarity and definition on who the customer is and requirements. This has the potential to lead to greater variance in under or over-engineered solutions.
- On average, less dedicated engineering capacity to focus solely on building and supporting in-house solutions (most are working on product/customer-facing builds). This has the potential to be an issue if managers are not leveraging a good mix of general-purpose solutions (e.g. JIRA automation, Github automation, Zapier, Google Sheets, etc) and approach every automation project as a separate build.
Based on these differences, my first advice is to spend some amount of rigor in defining and validating requirements and design with the customer (e.g. the human whose effort you are looking to substitute), especially if it’s not a fully automated solution. Secondly, try to build a minimum viable product with general-purpose solutions before committing valuable engineering resources to the build.
Time management is an important part of how engineering managers can scale themselves to meet ever-increasing demands from customers and the companies they operate in.
In my experience, effective time management lies in balancing the short-term demands for your attention with the long-term process of creating more time for yourself and your organization.
That time may be created from time saved today in not working on a task (Reduction), from another person who can partially or fully take over a responsibility (Delegation), or from a piece of software (Automation). Ultimately, finding this balance is often more art than science, and depends on the specific companies and problems that you are tackling.
I wish to leave the reader with one idea to consider: Stop wishing you had more time, and start taking the necessary steps today to ensure that you do in the future.
