The short version: when you move from managing individual contributors (ICs) to managing managers, you aren’t doing the same job at a larger scale. Your job shifts from solving problems yourself to shaping the people, context and shared knowledge that let others solve them well, and to making sure that these, in turn, serve the business goals of your company.

Now let’s break this down.

I might be biased but I tend to think that most other people assume that when a manager is promoted to manage a larger organization they essentially do the same thing, just on a bigger scale. Well, life has shown me that isn’t the case. When I look back at leadership roles I held in the past 20 years I think there are two key components that factor into this fallacy:

  1. It really matters what organizational demographic you manage directly. As a Team Lead my direct reports were only Software Engineers (SWEs), but as a Group Lead that changed to a mixture of Team Leads and Staff Software Engineers. Neither of them has the same set of capabilities and expectations that SWEs have, and there comes a point where you’ll have to work effectively with these new (to you) demographics and make sure they stand up to their role.
  2. As you climb the organization’s hierarchical ladder the issues you deal with as a manager will become more and more general, strategic, long-term and consequential. This follows naturally from being in charge of more people and more budget. You will have more, bigger and newer problems to solve, so you’ll need to work with new people in the organization who have more general functions that had little or no impact on your life until then.

My last role in AppsFlyer was that of R&D Group Lead, in which I managed other managers and senior ICs. In the first few months of my role it was very evident to me that this is a different kind of ride, so I decided to keep track of conclusions/realizations I reach as time goes by, with the goal of giving a short talk to Team Leads in the company on what the transition from TL to GL looks like. I did prepare a talk with all of my ideas but for some reason never got around to giving it to a wide forum, instead giving it only in private sessions. When I left that role to support my wife in a career opportunity granted to her I had the idea of developing the talk into some kind of blog - this blog. Given my experience at AppsFlyer I might touch on more topics related to software engineering or engineering management later, but at first I’d like to focus my attention on the particular point in time when an engineering manager transitions from managing ICs to managing managers.

There’s a lot to unpack here and I do believe that the context really matters in driving certain conclusions, so your mileage might vary. Some dimensions that I see as key in this context are the company’s industry; regulation; company size, maturity and ownership (private/public); your position in the organization; your own experience; your direct manager and direct reports. The list can go on.

There are excellent engineering management resources out there, such as James Stanier’s Become an Effective Software Engineering Manager and Gergely Orosz’s The Pragmatic Engineer. What I haven’t found is one that focuses specifically on the transition from managing ICs to managing managers.

So my plan is this: write a series of posts that will touch mostly on my experience working at AppsFlyer for ~6.5 years.

Why do I plan to use that particular experience? Because I find it to be a very good example due to the company’s size, success, business context and technological context. Also, because that’s the freshest experience in memory. 🙂

Why do I plan to write a series of posts?

  1. A one-topic post is bite-sized and simpler to understand and think about.

  2. It’s a commitment to myself to keep at the keyboard and hash out my ideas on a constant basis.

    I particularly like point (2) because I want to iterate and improve my authoring skill.

Who is this for?

  1. Line managers (=those that manage ICs) looking for a promotion to managing managers.
  2. Managers of managers (=middle managers, but not executives) who are new to their role and would like resources to help them with the transition.
  3. Experienced managers of managers who would like to get another angle on their role and freshen up their skillset.

What’s in it for you? Looking back at previous roles I held I noticed that in most cases I stepped into a new role without having the relevant predecessor leave any handover materials to help me and the organization with the transition. This is a double-edged sword: on one hand you remain mostly unbiased (you probably heard something about your new org) and can enjoy building from scratch; on the other hand organizational knowledge is somewhat lost, which is a real hindrance to the organization’s ability to compound its successes and capabilities over time. This blog is, in a way, the handover document I never got.

What are my credentials? My group was the core of the company’s fundamental product offering that drove a major revenue stream. We handled millions of events per second, on thousands of kubernetes pods, huge databases and kafka clusters, and had an interface and stake in many other R&D groups/premium products. Who’s “we”? About ~35 people in 4 teams and a few talented Staff Software Engineers who reported to me. So you can imagine that this creates a lot of challenges, which in turn lead to discussions and internal reflection.

I hope you’ll enjoy the ride. If you are able to take away just one idea or piece of advice to your own career - I find that as a huge success.

P.S.

References to my previous roles are in past tense because to me they are in the past, although they might still be true for the people who work there today.