3 ms·

Yes, to an extent, first had my startup where that was extremely easy (people love to suck up to you when you're in charge). Then Google. Google was a nightmar

Yes, to an extent, first had my startup where that was extremely easy (people love to suck up to you when you're in charge). Then Google. Google was a nightmare for sociological reasons not dissimilar to what you describe. Quick anecdote attempting to: - colleague is a server-side engineer, highly sociable and communicative. They transfer to client side work on our team, get about a year experience - new manager comes in but is quiet and absentee due to parental leave, about 6 months of a 9 month launch cycle - manager assumes and communicates I'm de facto lead and should be getting people on the project - colleague sees it more as a competition (residual from new manager coming in and me being de facto lead in between managers). new manager never spelled it out to everyone, so 6 months of hell ensue - got to the point he went to manager's manager to complain regularly, eventually gets cut off and told to stop giving me a hard time because he's describing me helping him - 2 weeks past ship deadline, with 2 weeks of work left, he repeatedly insists in a meeting that our work is in Binary A, but it's in Binary B, I let partner team deal with explaining it to him, I tried to avoid anything approaching conflict - He consistently was a helpful contributor when he sat down and coded, but caused an infernal amount of racket between severe absenteeism and a sense of extreme alarmism when he was present and learning what was going on, because of the gaps like you explain (not knowing what you don't know) - The bitter lesson I took away from all this was more or less that I did the right thing, I got them involved and was polite.and helpful with them, and there was nothing I could do to keep the abusive side of that from happening without causing a situation where it looked like I was uncharitable and failing at my duty to mentor. - Didn't matter or help with my performance review. He kicked up enough noise to indicate smoke, so there must be fire, even if managers manager had enough at that one point. - after launch, i spent the next 6 months carefully building a relationship with the other key team member via everyday things, lunch, cat pictures. That way, my relative formality was obviated, and they began being a good influence (i.e. being blunt with the trouble colleague when they were on another planet, rather than re-enforcing their alarmism)

NicoJuicy 3y ago
Thanks! Many great points. There is a reason behind my original question, since it's related to reflecting over the mentor role in the current situation. And I'm trying to find out if if there, with the current situation, are similarities with past annoyances because of my character. So the following hit right to home, because that's what I'm reflecting about: > What struck me each time is how the things you observe are universally centered around people not behaving the way youd want someone to behave given your estimation of their talent and/or experience. I'd appreciate your thoughts about the mentor role on the following situation. The person I'm mentoring now is a senior with past roles in Amazon, IBM, ... We are working together for 2 months now, but December is traditionally a low activity month because of holidays and a week off by the company. I've had a feature that I was originally going to do solo ( my priority was the deadline and now I'm mentally switching to onboarding the senior the right way). This also means that the user stories were less documented. We have a 7 hour difference in time zone ( he in Canada and I'm from Belgium). I've almost daily asked if there were any issues/unclarities. He also started early sometimes, probably to have more overlap and more help from me. He also worked a Saturday ( for a relatively simple problem that he couldn't fix in 3 days, we did pair programming and I had 2 solutions in 30 minutes). He couldn't solo implement a feature flag, where the "enabled" route took the new endpoint ( swagger generated) and the old route took the old one. I literally had to take the screen over and did it in 5 minutes. Personally, this looked like an easy task. Any advise from the mentor viewpoint? My urge was that this ( and other things) looked like a red flag. I requested feedback internally and it was mentioned to take character/culture differences into account. I'm now trying to compare past experiences to reflect on that feedback. But I have a hard time getting over it that someone with 18 years of experience couldn't do that solo. I was always worried that he would be without work. It's possible that this was viewed as "pushing", while I just tuned in to see if everything was clear and if he had questions. My current guess is that perhaps because of my handling, he tried to adjust his coding to my way of doing/development and it impaired him ? ( that's the only possible explanation I can find). This guess is related to what was mentioned after feedback internally. My actual guess is more in the lines of "beginner expert". And my worry is that our team in theory has an additional senior, while that's not the case. Note: I requested for an additional senior ( full stack) for a while since we can use it. But it seems that the position that was open is not similar to what was fulfilled ( I would say there's even such a big difference that's it's red flag. And i believe it's also my job to signal that). Any advice / reflections would be greatly appreciated.
- psyklic 3y ago
  It sounds to me like you really care about mentees being successful and are investing a lot of time/effort. I believe you can change your outlook a bit into knowing it's moreso on them to flourish. For example, you sound extremely hands-on for a mentor. I would not do all of their coding for them. IMO it's not your job to teach how to use a framework. But instead of assuming they "should" know things, you could assume they are skilled but at different aspects of development. So from this perspective, a mentor might give additional topics to brush up on to be successful in the job. And still be super open to providing internal career advice, helping with company-specific things, etc. It sounds like maybe a lot of what you write here is important for mentee success yet not being communicated. You could probably be more upfront about team expectations, and let them know what a typical dev workload will look like. Hiring is tough, and some people are not able to perform as well as expected. That can be frustrating, but it's not your fault. You may want to clarify how the company evaluates new hires so you know the process.
  - refulgentis 3y ago
    Wanted to put in a plug for this comment: it's honestly stunningly rare and a real credit to you to think about it carefully in these terms.
  - NicoJuicy 3y ago
    Thanks. A lot of this is similar to what I encountered/observed, to the point where I thought to check the hiring process too. > For example, you sound extremely hands-on for a mentor. I would not do all of their coding for them. Well. I guide them through keywords to look up, so they can find more info about their current issue and then ask them to come back when they need to know more or still have further issues ( I do want to see they put in some effort in finding the issue first, depending on the issue ofc). The problem is after some back and forth. If it takes a relatively long time, I sometimes do the coding for them ( a lot less the last years) and I still think it's a difficult balance. Once you fix their problem with pair programming, I tend to get into an akward situation, where it's expected to do that more from their side, which I don't want to do. To the point of the actual request of : "can you take over my screen" or "can you do it for me". Fyi, that's an example of the current senior situation. I hit the "can you do it for me" feedback loop really fast this time.

NicoJuicy 3y ago

Thanks! Many great points. There is a reason behind my original question, since it's related to reflecting over the mentor role in the current situation. And I'm trying to find out if if there, with the current situation, are similarities with past annoyances because of my character. So the following hit right to home, because that's what I'm reflecting about: > What struck me each time is how the things you observe are universally centered around people not behaving the way youd want someone to behave given your estimation of their talent and/or experience. I'd appreciate your thoughts about the mentor role on the following situation. The person I'm mentoring now is a senior with past roles in Amazon, IBM, ... We are working together for 2 months now, but December is traditionally a low activity month because of holidays and a week off by the company. I've had a feature that I was originally going to do solo ( my priority was the deadline and now I'm mentally switching to onboarding the senior the right way). This also means that the user stories were less documented. We have a 7 hour difference in time zone ( he in Canada and I'm from Belgium). I've almost daily asked if there were any issues/unclarities. He also started early sometimes, probably to have more overlap and more help from me. He also worked a Saturday ( for a relatively simple problem that he couldn't fix in 3 days, we did pair programming and I had 2 solutions in 30 minutes). He couldn't solo implement a feature flag, where the "enabled" route took the new endpoint ( swagger generated) and the old route took the old one. I literally had to take the screen over and did it in 5 minutes. Personally, this looked like an easy task. Any advise from the mentor viewpoint? My urge was that this ( and other things) looked like a red flag. I requested feedback internally and it was mentioned to take character/culture differences into account. I'm now trying to compare past experiences to reflect on that feedback. But I have a hard time getting over it that someone with 18 years of experience couldn't do that solo. I was always worried that he would be without work. It's possible that this was viewed as "pushing", while I just tuned in to see if everything was clear and if he had questions. My current guess is that perhaps because of my handling, he tried to adjust his coding to my way of doing/development and it impaired him ? ( that's the only possible explanation I can find). This guess is related to what was mentioned after feedback internally. My actual guess is more in the lines of "beginner expert". And my worry is that our team in theory has an additional senior, while that's not the case. Note: I requested for an additional senior ( full stack) for a while since we can use it. But it seems that the position that was open is not similar to what was fulfilled ( I would say there's even such a big difference that's it's red flag. And i believe it's also my job to signal that). Any advice / reflections would be greatly appreciated.

psyklic 3y ago
It sounds to me like you really care about mentees being successful and are investing a lot of time/effort. I believe you can change your outlook a bit into knowing it's moreso on them to flourish. For example, you sound extremely hands-on for a mentor. I would not do all of their coding for them. IMO it's not your job to teach how to use a framework. But instead of assuming they "should" know things, you could assume they are skilled but at different aspects of development. So from this perspective, a mentor might give additional topics to brush up on to be successful in the job. And still be super open to providing internal career advice, helping with company-specific things, etc. It sounds like maybe a lot of what you write here is important for mentee success yet not being communicated. You could probably be more upfront about team expectations, and let them know what a typical dev workload will look like. Hiring is tough, and some people are not able to perform as well as expected. That can be frustrating, but it's not your fault. You may want to clarify how the company evaluates new hires so you know the process.
- refulgentis 3y ago
  Wanted to put in a plug for this comment: it's honestly stunningly rare and a real credit to you to think about it carefully in these terms.
- NicoJuicy 3y ago
  Thanks. A lot of this is similar to what I encountered/observed, to the point where I thought to check the hiring process too. > For example, you sound extremely hands-on for a mentor. I would not do all of their coding for them. Well. I guide them through keywords to look up, so they can find more info about their current issue and then ask them to come back when they need to know more or still have further issues ( I do want to see they put in some effort in finding the issue first, depending on the issue ofc). The problem is after some back and forth. If it takes a relatively long time, I sometimes do the coding for them ( a lot less the last years) and I still think it's a difficult balance. Once you fix their problem with pair programming, I tend to get into an akward situation, where it's expected to do that more from their side, which I don't want to do. To the point of the actual request of : "can you take over my screen" or "can you do it for me". Fyi, that's an example of the current senior situation. I hit the "can you do it for me" feedback loop really fast this time.