- not building enough trust early on with their reports that when a problem comes up, the information they get is biased as they are seen as part of leadership/management and not the team
- applying pressure in the wrong direction (ie; if the team is moving slow because of stress or fear, making things more stressful will not speed things up)
- trying too hard to be friends with all their reports, rather than figuring out the appropriate boundaries on a person to person basis
- relaying anonymous information around in an effort to "protect people" and thus making themselves the go-between between all members on a team rather than encouraging people to work things out themselves
- for ICs that then became mgrs, staying way too focused on the in the weeds details and not on the bigger picture or people details, up to an including still spending too much time coding or trying to do PR reviews that carry too much weight
--
I would actually go so far as to say that the best "IC turned managers" I've had have been about at par with the most mediocre "good people mgrs that didn't come through coding for that role", and the people in that role that excelled at it (a motley crew of former stage managers, teachers, guidance counselors, project managers, etc)
> not building enough trust early on with their reports that when a problem comes up, the information they get is biased as they are seen as part of leadership/management and not the team
Could you elaborate on ways to build trust early on? I'm curious and intrigued. Do you have any ideas / systems that you follow to build trust with different kinds of people?
> I would actually go so far as to say that the best "IC turned managers" I've had have been about at par with the most mediocre "good people mgrs that didn't come through coding for that role", and the people in that role that excelled at it (a motley crew of former stage managers, teachers, guidance counselors, project managers, etc)
Just to make sure this parsed correctly: non-technical, but good at people, engineering managers >> ICs that became technical engineering managers?
I’m 50/50 on this assessment. Best managers I have worked with are IC turned managers that have real good empathy for their team members.
They know how people worked (how to intrinsically motivate them, keep an eye on moral, really good listeners, power of being in the zone) and at the same time understanding how tech works (where will things likely fall apart, an eye for unknown unknowns, value of good tests, power of primitives, focus on minimizing scope and saying no to things).
It comes down to “wow! This person understands how software is built, that it’s expensive and an iterative endeavor. That I am a human being with feelings, ambitions and passions that will make mistakes along the way”
sorry, sometimes my fingers and my brain aren't in sync.
yes in my experience the best IC turned managers are about on par with a mediocre manager that is really good at managing, and didn't come up as a coder, and the best managers I've had have all been from other backgrounds.
No doubt there are great coders-turned-managers out there, but it often seems like the "people skills" are just assumed to be easy to acquire, when actually they take a pretty complicated mix of talent and experience for that sort of thing as well
- not acknowledging obvious elephants in the room
- not building enough trust early on with their reports that when a problem comes up, the information they get is biased as they are seen as part of leadership/management and not the team
- applying pressure in the wrong direction (ie; if the team is moving slow because of stress or fear, making things more stressful will not speed things up)
- trying too hard to be friends with all their reports, rather than figuring out the appropriate boundaries on a person to person basis
- relaying anonymous information around in an effort to "protect people" and thus making themselves the go-between between all members on a team rather than encouraging people to work things out themselves
- for ICs that then became mgrs, staying way too focused on the in the weeds details and not on the bigger picture or people details, up to an including still spending too much time coding or trying to do PR reviews that carry too much weight
--
I would actually go so far as to say that the best "IC turned managers" I've had have been about at par with the most mediocre "good people mgrs that didn't come through coding for that role", and the people in that role that excelled at it (a motley crew of former stage managers, teachers, guidance counselors, project managers, etc)