Manager to IC Pendulum Redux (a 90 day readout)

Manager to IC Pendulum Redux (a 90 day readout)
(Image by poupoune05)

In February as I wound up my last role as a SecOps Director, the Engineer-Manager pendulum was definitely on my mind, but I wasn't sure which way I'd swing.

Would I choose the IC route like I did in July 2019 or pick up another team?

Even in a tough market, I was fortunate enough to have a choice between a Principal Engineer role and another Director role reporting to a CISO, leading a small team.

I ended up going the IC route again.

The second time hasn't been easy for a of lot of reasons (some obvious, some not so) but at nearly 90 days "on the job" here are some observations about the first time and what I've learned this go around.

Hopefully this is helpful for those folks in leadership roles that are contemplating moving back to an IC either because they want to recharge their hands-on skills--or because technical leadership roles in Security and Engineer are extremely competitive during this downturn.

The "Pendulum" Defined

In 2017, Charity Majors wrote what I consider to be a ground-breaking blog called The Engineer/Manager Pendulum where she defines the problem space:

Being an IC is like reverse-engineering how a company works with very little information. A lot of things seem ridiculous, or pointless or inefficient from the perspective of a leaf node.
Being a manager teaches you how the business works. It also teaches you how people work. You will learn to have uncomfortable conversations. You will learn how to still get good work out of people who are irritated, or resentful, or who hate your guts. You will learn how to resolve conflicts, dear god will you ever learn to resolve conflicts. (Actually you’ll learn to YEARN for conflicts because straightforward conflict is usually better than all the other options.)
You’ll go home exhausted every day and unable to articulate anything you actually did. But you did stuff. You’ll miss the dopamine hit of fixing something or solving something. You’ll miss it desperately.

Two years later (and almost five years ago to this month!) I decided to move from an Platform Engineering VP role in late startup to a Principal Architect on a security team in a financial services company. I'd had enough of meetings (and battles) with Legal and Sales. I was tired of texting with my C-level boss on the weekends about layoffs and which products needed to be axed to maintain the right ratios of R&D spend.

Truth be told, I was really burned out after eight years of increasingly stressful Engineering leadership roles in volatile organizations and technology stacks, in businesses undergoing transition. I'd been through 3 M&As, including two exits. I'd built 2 teams and rebuilt 2 more. I needed to re-charge. I did for a little while, at least.

Mixed Results in 1.0

In hindsight, I'm not sure if it would have made any difference in that I moved from a chaotic organization (most startups are like this regardless of the stage) to a far more stable (and perhaps even stagnant) org. I definitely remember feeling the frustration of the glacial pace of change of the Enterprise--and being really bored a lot of the time. One of the metrics I've thought about since then is "rage-quits per week." How many days a week do you wish you could throw in the towel? One day? Probably fine. Three days a week? Maybe you made the wrong choice.

(This would contribute to me swinging back to an Engineering manager role in under less than six months, where I was much happier, but I'm getting ahead of myself.)

The Enterprise can be a target-rich environment for socio-technical problem solvers, where effective managers have an advantage--and I heard this from my team and how it made a difference for them. The inefficiencies and poor process were frustrating–as was the friction of working on an environment with far more security controls that I'd ever experienced as an engineer. Then, there was the worst IT support for Mac's that I'd ever experienced, to the point that I eventually made me get a Dell laptop when I had the chance for a refresh. This leaves out a broken ticketing system and procurement processes, and, of course, the organizational misalignment and an org chart that was badly in need of refactoring that affects many large Enterprises that leads to cynicism and apathy among engineers that don't quit.

I most certainly felt the "ridiculousness" of being an an IC on the "leaf node" in an organization where I lacked the context (and understanding of the business) that I had (and communicated to my teams) as a Director and VP.

(I took this experience of "being in the dark" and a "lacking context" with me when I returned to management, and it made me a better, more empathetic leader and making damn sure I was emanating business context to those on my team.

I've always believed in over-communication, but the experience of not having that context as an IC in a new company definitely left a strong impression.)

I simply couldn't unsee the fact that most of the problems I (and my engineer peers) faced were socio-technical in nature: shitty processes and tooling they had no control over, poor communication across teams, and staffing issues on teams that resulted in unnecessary conflict and drama.

But there were definitely some good parts.

I had a "maker calendar" free of meetings with lots of distraction-free work during my first 90 days. People left me a alone and I didn't have to work with Legal or Sales teams or fight with Procurement. I got my git and Terraform muscle-memory back and dealt with the complexity of distributed systems an environment when it mattered. I met some great people that have become friends and served as references as I looked for a new role.

I didn't regret the decision. It made me a better leader when I moved back into a manager role in the March of 2020 as COVID was spreading globally and the world shut down and the market slid. It was a weird time for leaders and for companies and I saw a lot of folks step up.

Owner or Advisor?

Whether or not it is the correct view, when I'm not a people leadership role, I see the problem-solution space very differently. I find myself reacting differently to problems and can be far more objective.

It makes a difference whether I have people I am responsible for and feel like I have to support them and fight for them. As an IC, I find myself being far more dispassionate, reflective, and objective than when in a formal leadership role.

I provide diagnoses and solutions, but really it is on the decision maker to make the call and own it. Yes, I try to influence and advocate the way anyone at the Staff Engineer level should. Sure, I build relationships and mentor others, but there is something allows me to be less emotional if I don't have "a team of my own" or the "burden of command."

I've long known that when I have a team I have to "protect" or "defend" (yes, these are symptoms of broken organizations, but most companies are broken) I am far less patient and flexible. It is one thing to have observations of how things ought to be yourself. It is another thing entirely when others are escalating to you and saying, "Matt, please help!"

I'll keep this in mind the next time I return to a people leadership role and we'll see what happens.

The first time around I'm not sure I gave it enough of a chance.

While I was regaining my hands-on skills, I started to advise my peers (and my boss) on "manager stuff." There was a performance problem was that was been plaguing the team. There was a span of control where one manager had far too many reports than they could be effective. I influenced change and it happened. It was a slippery slope, though.

When you move back to an IC role and you have muscles to flex in the org where you can add greater value, it is tempting to use them. You have to be careful about where you apply your experience based on where you want to go--and grow.

And I did flex them. I refactored the hiring process that would yield some strong hires the following year. I called bullshit on an an immature vendor using my Director+ "vendor-management" repertoire gained from leadership roles in product and SaaS companies. They got better.

But in the end, after starting to feel at least partially technically competent again--and having actually learned technical things and touched real systems and written code, I saw that I could make more difference in a leadership role and when the opportunity to lead the team I was part of, I swung back in less than a year.

Returning as an EM for COVID

From 2017 to 2019, I had led a global team of nearly 30 employees and contractors in the U.S. and Romania. That declined through multiple rounds of layoffs, but it was a decent-sized org reporting to both the SVP of Engineering that hired me and a new CPO that joined a year in, after our first round of layoffs in November 2018. It was hard to stay hands-on in this role, besides being very stressful for a lot of other reasons I can't blog about.

But in April 2020, I had a team of only two, which was obviously well-below the desirable size to even be called a team. In some ways, it was comfortable--except that in the early months of the COVID-2019 Pandemic nothing was normal. The stock market was in free fall. We weren't sure of our budget. Would there be layoffs? We weren't sure if we and when we could hire, let alone when my engineers could start. Would they even have laptops or have to deal with the hell of Citrix to Windows 10 workstations with VirtualBox? What would the on-boarding process look like in the team? Would our pro services projects get approved? Would a small startup vendor that provided our core tech survive? It was not dull. In fact it was exhilarating and I'm glad I remained in a large Enterprise despite actively looking for an exit in March 2020, before I returned to a leadership role.

By mid 2020, I had hired two engineers from the outside and picked up two more through an internal consolidation. I picked up two more products. I got involved in Anti-Fraud efforts. I was back in business and the pendulum was fully back.

Then in Q4 2022 the recruiters started calling and I followed the money, ending up at CrowdStrike right after Christmas, which one be one of the two roles I've had where I left in under a year.

Embracing Staff post-Director

Fast forward. In early-2022, I learned the hard way that I actually really liked being a first-level manager. Also, that there only very narrow conditions that I would ever want to be manager of managers again--even thought I'd done that from 2014 to 2019.

Word to the wise, If you are ever interviewing for manager of manager role, make for damn sure you get to interview all your leaders. Otherwise, you won't know what you are walking into. They probably wanted your job. They might have interviewed for your job. You need to know why they didn't get the role. You need to know if you can (or want) to work with them. If you can't (or aren't allowed to do this) beware. I learned that I prefer flat organizations. I do not believe in empire-building. The is is not how a lot of Big Tech works. I liked working with a range of engineers from early career to the Staff and Principal level. This was part of the reason I left CrowdStrike and I took knowledge to my job hunt in Q2 2022 and I did not change my mind in Q4 2023 and Q1 2024 when I looked for an exit from Ping following the merger with ForgeRock.

During my job hunt in Q4 2023 and Q1 2023, I shared many of the same frustrations that others have faced as the tech bubble burst.

Being ghosted. Going through 6-10 rounds of interviews and being rejected, sometimes with helpful feedback, but often with none. Applying for dozens to hundreds of positions and hearing nothing. I also heard "we liked you but you weren't the best candidate." A lot.

During one of my interviews, I realized hanging on to a job I that I hated and working for someone I did not respect was impacting my view of the future. It was toxic. It was not worth the anxiety and stress. That is what savings is for. I should have quit way earlier.

So without having a negotiated offer, I decided to quit so I could clear my head and to really figure out what I wanted to do. I stopped looking. I stopped applying. I needed a break after the most chaotic M&A I've been through in my 25 years in tech, and a half-dozen M&As. The irony is that, at that point I actually started getting more actionable interviews and referrals. I was approached for FedRAMP DevOps role by a headhunter that knew very little about DevOps or FedRAMP.

I replied on a whim. I though I was too senior, but why not? I had nothing to lose. I ended up having a good screen with the leadership team then went down to Northern Virginia for a face to face in the office. Much of it went well and I liked the org, but when I was interviewed by an architect, not only did we butt heads about technical approaches, but I really didn't have enough recent hands-on experience to answer some quite basic questions that I really should have been able to.

It was super frustrating to know that I could have easily done the work but not. This ended up being one of the crucial factors that led me to go back to an IC. That it was time.

"It is all the same:" the reality is that tech leadership is super fuzzy

One of the weird phenomena that I've experienced is seeing lots of senior engineers wanting to be managers, but not knowing exactly sure why.

I know it is really not weird. It is symptom of a lack clearly defined career progression. It is a symptom that roles are not clearly defined in the organization, and perhaps that there is not nearly enough delegation by folks that are "people leaders."

At some point, I remember having a slide where I had a Venn Diagram that included Tech Lead, Architect, and Manager. There is a lot that overlaps. I've found this to be true as I swung back into a Staff role.

As an EM and a Director I used to use Will Larson's book as a discussion point for engineers that wanted more, but were not exactly sure what. I recently started reading Tanya Reilly's, The Staff Engineers Path as much more useful text on what the various types of "beyond senior" engineer roles do.

The funny things is that so much of what she describes are things I did as a manager, director, and even VP. This is reassuring--and should be for anyone that has been a EM/Director who wants to move back into an IC role like I did in April.

At the Staff+ level you must understand the business. I would argue that any engineer that understands "the business" has a leg up on those that don't. At the Staff+ plus it is all about influence. Can you "nudge" folks forward? Can you get humans to think about a problem in a new way? Can you guide others towards owning both the problem and the solution?

This is what Tech Leads should do. Good "people leaders: (regardless of seniority) do this, too. Without getting into the false dichotomy between manager and leader (TLDR: you need both), leading is leading regardless of the title that you have and how much you are paid.

You must be able to work across teams in an organization to achieve results. You need to be strategic. Yes, you must get into the details, but the higher your compensation the more you need to operate at higher levels of abstraction.

You must help create the "shared reality" of what needs to be built, when, and why. You need to be able to communicate with various stakeholders from customers to founders to interns. This is not easy and the context switching can be exhausting.

Whether as a Staff+ (or Director/EM) you must be able to scale yourself. You cannot be the bottleneck in either decisions or actions. This requires maintaining a high degree of "alignment" with everyone you work with. A high level of self-awareness is needed if you are able to pull this off.

Although you'll wear multiple hats, one of them is as technical project lead. This will be true whether you are Staff+ or an EM or Director. You must be able to plan. You must define goals. You must resolve disputes. You must identify and resolve blockers. You must understand and communicate risks.

The TLDR is that much of what you did as a technical leader was and is still relevant if you are in a Staff+ role and once you get your engineering muscle-memory back (and fast enough) you'll be a better engineer. As I was making the decision in March about what I'd do next, a former manager of mine told me this and they were right! I also heard this exact same point from a leader I met up with at RSA about a former Director swung back into a Staff role and reported to them. The fact that they understood the business (and the demands on leadership, and had been in their shoes) allowed them to add much more value than than someone who hadn't been there.

Essential Readings on the Pendulum (and Engineering Leadership)

Questionable Advice: “My boss says we don’t need any engineering managers. Is he right?”
I recently joined a startup to run an engineering org of about 40 engineers. My title is VP Engineering. However, I have been having lots of ongoing conflict with the CEO (a former engineer) around…
Becoming An Engineering Manager Can Make You Better At Life And Relationships
Original title: “Why Should You (Or Anyone) Become An Engineering Manager?” The first piece I ever wrote about engineering management, The Engineer/Manager Pendulum, was written as a lo…
Leadership Safe Words: Know when to say when!
127 days ago seems like a lifetime!
Engineering for the Why
Folks Doing Stuff
The Staff Engineer’s Path
For years, companies have rewarded their most effective engineers with management positions. But treating management as the default path for an engineer with leadership ability doesn’t serve the industry well--or … - Selection from The Staff Engineer’s Path [Book]