Office Hours #2 — You are Not Your Hat
Maximizing your value by unconditioning from thinking primarily in terms of title
This is the second installment of the weekly Office Hours series, where I explore common questions raised in discussions with engineers within and outside of Xendit.
When you look across Linkedin these days, you can expect to stumble across a variety of different role and title names. Most of them are pretty mundane (software engineer, technical lead, engineering manager). Sometimes you can also find some more arcane sounding titles (staff engineer II, software architect, etc).
The advantage of having these titles is that they convey a general sense of career advancement. It’s generally understood that a viable career track for more senior engineers is to move into designing software architectures instead of being hands on for every feature build. The disadvantage of using titles this way is that it boxes engineers into narrow job descriptions that do not always align with the needs of the business nor the desired growth of the individual. They imply a relatively linear career trajectory with increasing specialization.
At Xendit, we try to spend a lot of time unconditioning engineers from thinking primarily in terms of title. The analogy we have for roles and titles are hats. In the same way that you can put hats on and take them off, we believe that you can assume different roles as the need and interest arises. For example, most days I will wear the CTO hat when I’m working on aligning engineering strategy with business goals. However, there are days when I take that hat off and put my Founder hat on when I’m coaching early stage startups on how to approach early product market fit and go to market. Other days, I put on a software architect hat when I’m deep diving into a hairy business problem which requires an exploration of the domain and services which support that product. Finally, I put on a product manager hat when I interview customers and try to discover their needs and organize the requirements in a way that is intelligible for engineers.
This approach allows for a nuanced approach to problem solving, allowing for the appropriate goals and context to be considered when designing solutions. More than anything though, this keeps things interesting. I firmly believe in the phrase “variety is the spice of life”. Practically, it doesn’t mean that you need to be switching hats every day or even every week. Those that enjoy software architecture and who are competent to execute in that role may find themselves spending a disproportionate amount of time wearing that hat and honing those skills. What this framework allows for is for that same engineer, when he/she decides that they have reached the limit of what they want to achieve in a given role to smoothly transition into other hats which bring value to the business.
This limit may be different for each individual. Some want to achieve a certain level of mastery (e.g. a difficult re-architecture of a core service), others want to explore and want to be more of a generalist, and yet others may find that many of their problems are coming from outside their specialization and want to get ahead of those problems. In practice, there is no one right answer that fits everyone. Every individual should consider the scope and complexity of the problems they care to be able to solve or the magnitude of value they want to be able to deliver, and would be proud to say that they were able to. Then, looking carefully to see whether that would require putting on a new hat or whether existing hats would work.
When I started my career, I always had the goal of putting a CTO title on my Linkedin profile. For me, it represented a sense of prestige and accomplishment. I’m incredibly grateful for the opportunity to have served as an early stage and growth stage CTO. What I’ve learned is that life goes on after you achieve your initial goals. I’ve learned that (after a certain point) careers stop becoming linear and are more driven by what skills add the most value to customers and your own experience. What I value most these days is the flexibility in being able to put on the appropriate hat for any given problem and being able to hone my skills in areas that I care about.
