Office Hours #1 - ICs and Managers

Different perspective in defining roles to maximize the potential of each staff

Content

This is the first entry in my new series (Office Hours) where I explore recurring topics that I’ve gathered through one on one and group discussions with engineers at Xendit and in the industry. Disclaimer, the ideas presented in this series are unavoidably heavily biased towards my own and Xendit’s experience and thus may not be applicable to all companies and circumstances. My hope in sharing is to promote discourse and the expansion of perspectives.

Intro

One of the most frequent questions that I get when having discussions with engineers is the difference between managers and ICs. Having gone through the transition myself and now managing senior ICs and senior managers, I’ve arrived at what I believe is the core distinction between the two.

Whenever discussions on the distinction between roles pop up, there seems to be a rush to define what each role DOES. This makes sense because this is the most visible part of a role and is easy to observe on a day to day basis. The simplest formulation of this and the default assumption that I hear is that managers “manage people” and ICs “write code”. While this is not incorrect on average, it creates a barrier for an organization to achieve the full potential of each of its staff because much of the important and difficult work falls between functional lines.

According to the RACI framework, the model presented above focuses on the R’s (responsibilities) but in practice, many responsibilities need to be shared. An example is the design stage, in which you want to gather the perspectives of many stakeholders to ensure that all functional and non-functional requirements and tradeoffs are considered when changes are inexpensive to make.

What I find more useful is to focus on the A’s (accountabilities). A very crude but expressive way to communicate this is in the idea of “one throat to choke”. I like Amazon’s terminology of a “single threaded owner” much better. At Xendit, we define the accountability of the manager as identifying, communicating, selling, staffing, and ultimately delivering value for the customer. ICs are held accountable for the quality and timeliness of their solutions. This doesn’t mean that ICs won’t participate in requirements gathering and design nor that managers won’t get involved in software architecture and testing. We’re all inevitably connected in the value chain for the customer. However, the distinction is useful when it comes to making the final decision to avoid deadlock. In this framework, managers have the final decision when it comes to which customer problems are important to solve and ICs have the final decision for which solution is best suited to the problem and which technical tradeoffs (e.g. cloud vs bare metal vs VMs) to make.

At the end of the day, there is no perfect framework for dividing work for maximum effectiveness, especially in a fast growing startup. At Xendit, we believe in empowering individuals and increasing the number of high quality autonomous decisions. Additionally, we believe that all of our frameworks ultimately exist to promote our customers’ success. When we find a framework that works reasonably well, we continue to test it until it breaks. What you will find in this series is our continuous process of reinvention as the needs of our customers and markets evolve.