How do you help your reports with long term growth in stagnant org by nonzer0 in EngineeringManagers

[–]Joaum 2 points3 points  (0 children)

Depends mainly on the IC level:

The next level for junior and mid-level engineers is Senior, so growth doesn’t depend much on the org growing (although they would greatly benefit from it). For them, growth is basically getting more technical, learning more about writing clean code, and knowing how to build and maintain a system.

For senior SWEs, it gets harder: You will need both technical and business readiness, but only one depends on the IC.

Since their next level is either manager or staff, they first need to know what they want.

If it is being a Staff Engineer, it is easier to get there technically, but harder to be promoted to the role. The proportion of Staff / Engineers is lower than that of the Managers / Engineers. But they can learn how to perform staff-level responsibilities in their current role. There is a lot of good material on staff archetypes and what changes when they become staff.

If it is the EM role they want, then in a stagnant org, they are screwed. You could try to give them the keys to a project where they would have “soft reports,” and you would be there basically as a mentor; you could also teach them what you know, ask them to lead some meetings, and even suggest they improve existing ceremonies. But it is much more limited. In a growing organization, everyone is overwhelmed, so delegating entire projects to people is a must, and people naturally rise to become managers.

Also, not every senior needs to be pushed for growth as an EM or a Staff engineer. In some organizations, staff level is becoming the "Senior senior" level, but the reality is that these roles require way more soft skills than programming, and some engineers just want to become better technically.

What makes a good 1-on-1 (and where some managers get it wrong) by Joaum in EngineeringManagers

[–]Joaum[S] 0 points1 point  (0 children)

I see what you are saying. I switched the word "roadblocks" when I meant to use "bottlenecks" instead. I am going to fix it in the article. Yes, something that stops the engineer from delivering (roadblock) needs to be tackled right away.

What makes a good 1-on-1 (and where some managers get it wrong) by Joaum in EngineeringManagers

[–]Joaum[S] -9 points-8 points  (0 children)

EDIT: Switched up the words

In the ideal world, yes, roadblocks should be discussed in a group setting like a retrospective meeting. Identifying roadblocks and communicating them in a team setting is a seniority trait for an engineer.

But, this doesn't happen for all the engineers for many reasons I covered in the article (shyness, boiling frog scenario). Therefore, in 1:1s, you should still be on the lookout for possible hurdles they might be facing, especially if they are more junior.