Have you ping ponged between being an individual contributor and being an engineering manager?

If so, what did you learn?

Comments

[Alvaro Montoro]

Yes. I became an engineering manager at one company, then went back to being an IC at a different company. It was an interesting experience, as a manager had to deal more with the "human factor" of development and work and I really liked that. I will do it again in the future.

[Randall]

I'd say yes, though I've never officially been a "manager", I've had to do a lot of people management as "lead engineer" on teams that do not have a "manager" (and "manager" is sort of a dirty word where I work now - we don't have them, not officially anyway).

I've done performance reviews, led the standups, retros, made all the Jira tickets and epics, etc. While doing a lot of the coding too 😅Basically being "leader engineer" here means "lead engineer and also manager".

One thing I think I've learned is how to listen. Especially when people want to vent. People need someone they feel is safe to vent to. Then they need some help seeing the bright side. Sometimes, my natural instinct is to commiserate and say "oh yeah dude I totally hate xyz too, what a load of crud", but I don't think that's what they need to hear, they need some help seeing the positives, and looking beyond the immediate challenges.

I guess you could say: only complain upwards. I complain to my mentor, but I never complain to the people whom I mentor (even when I want to), that's not what they need from me!

[Jess Lee]

Complaining upwards is a great piece of advice!

and "manager" is sort of a dirty word where I work now - we don't have them, not officially anyway

Are you working at an org with a flat structure then? How is that?

[Randall]

It's pretty flat. Technically we have titles but they're a little meaningless.

I think somewhat of a hierarchy has emerged anyway with three layers:

1. The people who are purely individual contributors. They're often entry level, or they just choose to avoid responsibilities beyond writing code (which is a fine choice to make, as far as I'm concerned). These people usually have "software engineer" as their title.
2. The people who are willing/able to mentor people, lead projects, possibly put in long hours (at least sometimes). I'm in there somewhere. These people often bounce around between IC and leadership roles. They usually have titles including "lead engineer", "director of engineering", "CTO" (technically that's my title, but it makes zero sense, so sometimes I prefer to say I'm a "lead engineer". We have several "CTO"s).
3. The people who are mainly leaders and spend most of their time on leading teams and architecting large initiatives. They have the same titles as the people in rung 2 so you can't tell who they are at a glance, but you would quickly see that they command a lot of respect and trust, including from the executive team.

It can be a little chaotic, but I've also enjoyed that I can easily move around and do different things without bureaucracy and switching my job title. I wouldn't want to be a leader all the time, it's tough. I stay hidden in my code hole until duty calls and some project needs a lead engineer. Even when I'm in IC mode though I still do one-on-ones with people I used to manage, lots of code reviews, and there are often some quasi-management tasks that pop up here and there.

[Jess Lee]

Very interesting, thank you for sharing. What would you say the biggest pain point or thing to watch out for with that structure is?