Navigating the tech stack of engineering management

As a new engineering manager, I struggled to have high bandwidth conversations with skilled¹¹ It was tempting to use experienced instead of skilled. However, as the great Jay Shirley puts it, experience does not equal to skill. managers. They speak extremely succinctly with high information density. I understood every single word they spoke, yet I was not able to make sense of their phrases, let alone sentences or ideas. I fanatically took notes which hardly resonated with me, only for imposter syndrome to kick in.

Imagine you were newly introduced to the amazing world of programming, where you were confused yet fascinated by the differences between i++ and ++i. You walked up to a senior engineer, and they told you to create a Single Page App using React as frontend and node.js as backend. The app would feature isomorphic server-side rendering to accelerate page loading, and it would sport hyper performance thanks to minimal DOM updates with immutable Redux state. You should look into GraphQL rather than REST for RPC. By the way, don’t forget to use yarn to manage npm packages. How would you feel at that point?

Now you would understand my anxiety, confusion, stress and depression as a new engineering manager.

Over time, after many rounds of trial and error, I slowly came to understanding of those abstract ideas. But it was not until recently that I realized there is also a tech stack of engineering management. To be able to put those ideas into practice, I need to view the problem space of engineering management similar to the one of software engineering. I will learn to navigate the stack, moving up to design and moving down to execute.

In software engineering, I learned to write code - a few lines of boilerplate to begin with. And then came variables, loops, functions, classes, modules, and programs. Design patterns, micro services, and distributed systems were next. It was all about abstraction. Those ideas helped me design large, complex systems. However, I would happily write the good old print statement every time I started a new program.

I did not build the skills overnight. I picked up a Windows GUI via MFC book in the early 2000s, which was my introduction to C++. I got terribly confused by the usage of &. I was so frustrated about pointers versus references that I gave up on the language and resorted to BASIC. Not having the foundation sorted out really cost me. I was unable to move up the stack. I could not think at the next level. All I cared about was whether to use & or * on the next line. I waited years before making the leap to read The C++ Programming Language, bridging the gap to allow me move one level up the stack. That was such a refreshing moment. I wish I had done it earlier.

The same applies to engineering management, except that I am an absolute rookie. I don’t understand visions, policies, strategies, nor how they connect to my day-to-day work. However, there is one thing I do know: I need to make an intentional effort to level up my abstract thinking. I need the ability to roam freely on the tech stack of engineering management. That realization made my experience of engineering management such an incredible journey.

Here we go.