How to deal with a peer who tries to micromanage and push their work onto you?
My team has 1 E5 iOS (me), 1 E5 Android, 1 E4 iOS, 1 E4 Android, and several backend engineers. We also have a few web engineers, but I don't work with them.
I optimize for quality even if it takes more time, while my E4 iOS optimizes for speed (often cutting corners, skimping on testing, neglecting edge cases, etc.). My E5 Android's quality is somewhere in the middle of my E4 iOS's and mine, but he takes a lot longer than me on comparable tasks.
My E5 Android tends to push tasks onto others, with the excuse that he "doesn't have time". For example, our team's manager wanted our mobile engineers to learn the backend, so she specifically assigned a backend task to the E5 Android engineer. However, in a 1:1, the Android engineer asked me to take that backend task "if I have time" -- I had finished my iOS tasks early, so I technically had time, but I was hoping to work on a side project to demonstrate E6 scope. When I mentioned that I didn't have time because I was writing a 1-pager, he asked me to share it with him. Then he said we should focus on finishing our existing projects before starting new ones and added a lot of negative comments to my 1-pager, which made it more difficult for me to get buy-in from other engineers.
My team's EM had told me I could DRI a particular project I was excited about. However, the E5 Android convinced our PM that we should finish existing projects before starting new ones, so they forced me to deprioritize the project I was excited about to work on some boring E4 tasks. My E4 iOS was busy with another project, so he didn't have the bandwidth to take those tasks. However, I was hoping the E4 could take those E4 tasks after he finished his current project.
Do you have an tips on how to navigate this? I get the impression that the E5 Android pushes a lot of tasks onto the E4 Android as well, based on the latter's annoyed look in meetings when it happens.
My team will start our H2 scoping soon. Apparently the E5 Android engineer already set expectations with my team's EM that Android will take a lot longer than iOS for that project that I'll DRI.
![Senior Software Engineer [E5] at Meta company logo](/_next/image/?url=https%3A%2F%2Ffirebasestorage.googleapis.com%2Fv0%2Fb%2Ftech-career-growth.appspot.com%2Fo%2Fcompany_logos%252Fmeta.jpeg%3Falt%3Dmedia%26token%3Da7a5bcc0-e178-4b5b-b71e-09bf6c6aefae&w=48&q=75){kind=small}
![Entry-Level Software Engineer [L3] at Google company logo](/_next/image/?url=https%3A%2F%2Ffirebasestorage.googleapis.com%2Fv0%2Fb%2Ftech-career-growth.appspot.com%2Fo%2Fcompany_logos%252Fgoogle.jpeg%3Falt%3Dmedia%26token%3D780356ef-3efc-4728-9eb4-d909b75bb4a6&w=48&q=75){kind=small}
Discussion
(4 comments)- 2
6 months agoEngineer @ RobinhoodThe behavior of the Android E5 is catching my eye (naturally given how the story is structured), but I don't think their behaviors are necessarily "toxic" given the view presented. My view is that the Android E5 is trying to focus on growing the "direction" axis and they're not able to keep up with driving the team forward while doing core implementation work.
A lot of the intent & behaviors are just speculation, but you need to dig deeper to see the reason why this situation and people are playing out the way it is. I think the path forward is simple: you need to start talking to people. I don't mean like in a project or an ad-hoc meeting setting (as an E5, I assume you already have those behaviors): you need to talk to people 1:1 through recurring 1:1s. This will help you understand the people around you and allow for more nuanced, intimate conversions to grow your view of the world around you. This will also allow for you to extend a helping hand to folks without putting them in a position where they might feel publically shamed.
Proposing projects for the team is only 1 part of growing as a senior engineer: you also need understand the people around you. While the people issues may seem like dysfunction, this is an opportunity to rise above and be the one supporting and carrying the team. Build that understanding your team and learn what they're capable of, what they enjoy doing, how they generally react to certain conversations, and how they generally behave. As this understanding gets stronger, you will better learn how to path around projects by being able to proactively support teammates so that the frequency and the magnitude of these issues is minimized.
Hope this helps!
- 06 months agoSenior Software Engineer [OP]Taro Community
Thanks, Jonathan!
Proposing projects for the team is only 1 part of growing as a senior engineer: you also need understand the people around you. While the people issues may seem like dysfunction, this is an opportunity to rise above and be the one supporting and carrying the team. Build that understanding your team and learn what they're capable of, what they enjoy doing, how they generally react to certain conversations, and how they generally behave. As this understanding gets stronger, you will better learn how to path around projects by being able to proactively support teammates so that the frequency and the magnitude of these issues is minimized.
I have recurring 1:1s with the Android E5. The Android E5 enjoys mobile and is capable of doing Android and iOS (although I've only seen trivial iOS PRs from him). A while ago, he told me that he doesn't enjoy backend and that's why he switched teams -- his last team didn't have much mobile work. At various times, I've heard him say that he either has no backend experience or little backend experience. He generally is quick to push work onto others. In 1:1s, he likes to micromanage me, ask for help, and find ways to push work onto me. I think this is why the EM assigned the backend task to him.
- 0
6 months agoTech Lead @ Robinhood, Meta, Course HeroSo the E5 Android does have a point (you should indeed make sure existing projects are in great shape before creating new ones), but it seems like they're achieving their point in toxic ways.
For the back-end task going to you, there are a couple options:
- Code machine - You take the task and power through it. If you do this repeatedly and end up with a commit count double that of anyone else on the team (while maintaining quality of course), that can be E6 scope (or at least some sort of "Exceeds" rating). I've seen many engineers get to E6 in this way though it is admittedly very intense.
- Delegate through a back-end engineer - If you have good relationships with the back-end engineers on the team (maybe you can mentor an E3/E4 back-end to make them like you and willing to go the extra mile to help you), that's another option. It also shows E6 behavior (working through others by cultivating deep relationships proactively).
As usual, I recommend that you talk to your manager for issues like these as well. If you are both E5 and they move significantly slower than you (and with lower quality), this means that they are under-performing (either that or you are close to E6).
If the E4 iOS's code quality is a big problem, check this out: "I'm having trouble getting code quality feedback to land with an engineer I'm leading - What can I do here?"
- 16 months agoSenior Software Engineer [OP]Taro Community
Thanks, Alex!
Code machine - You take the task and power through it. If you do this repeatedly and end up with a commit count double that of anyone else on the team (while maintaining quality of course), that can be E6 scope (or at least some sort of "Exceeds" rating). I've seen many engineers get to E6 in this way though it is admittedly very intense.
I often get stuck doing glue work (e.g., system design for the entire project, cross-functional alignment, project management, design proposals & discussions, E2E testing, helping/unblocking others, project scoping, etc.), so there's no way I can surpass my E4 iOS's commit count since they just focus on raw code commits and also sacrifice quality.
Delegate through a back-end engineer - If you have good relationships with the back-end engineers on the team (maybe you can mentor an E3/E4 back-end to make them like you and willing to go the extra mile to help you), that's another option. It also shows E6 behavior (working through others by cultivating deep relationships proactively).
Unfortunately all the backend engineers are already allocated to projects and have no bandwidth to take on additional tasks. My team is a bit short-staffed on backend at the moment -- that's another reason why the EM wants the mobile engineers to ramp up on the backend.
As usual, I recommend that you talk to your manager for issues like these as well. If you are both E5 and they move significantly slower than you (and with lower quality), this means that they are under-performing (either that or you are close to E6).
The E5 Android is very good at managing up, so I'm not sure if my manager realizes that they move significantly slower than me. He probably blames the E4 Android engineer for being slow. For example, Android started this project about 1.5 months after iOS, so I had to design the overall project system design, drive alignment and project management with all our partner teams, perform multiple escalations to unblock the project, do the initial E2E testing, etc. I even had to take over the backend for ~4 months because our project lost all our backend engineers at one point. The 2 Android engineers just focused on Android the entire time even though both my E4 iOS and me jumped into the backend to de-risk the project after we completed the iOS tasks. Since iOS already paved the way and de-risked the E2E flow, the Android execution should have been straightforward. Despite this, Android is still troubleshooting their significant metric degradations. iOS ramped to 100% this week and had significant positive impact, helping our team surpass our H1 goals. At this point, the EM would just be happy for the Android metrics to be neutral.
If the E4 iOS's code quality is a big problem, check this out: "I'm having trouble getting code quality feedback to land with an engineer I'm leading - What can I do here?"
Thanks, I think people notice the number of bugs, but it's easy to hide when the api contracts in his area are not clear (e.g., is iOS not behaving correctly or is it a bug in how iOS is getting called?). He had worked with an E6 engineer (who has now switched teams) on those contracts, but they didn't document them. The Android and iOS contracts are also slightly different in his area due to legacy reasons.
