4 ms·

Could it be that the engineers need changes in order to deliver on a product they’re working on? Being on an infra or platform team is always going to involve

by pm90 6y ago

Could it be that the engineers need changes in order to deliver on a product they’re working on? Being on an infra or platform team is always going to involve receiving a lot of demands from engineers, since you become the bottleneck preventing them from adding/modifying the overall system. Genuinely curious to hear how engineers act entitled.

tayo42 6y ago
There's a couple things that make someone come off as entitled. Like someone comes to me with a solution to a problem they don't understand but still demands I implement their solution. Someone wrote a whole doc about how we don't test enough and need to test more, like were unaware of it. I wrote the same thing my self before that, though were just understaffed so things fall to side. Why go in to the interaction with the assumption we don't know what were doing? When I get to back to work, I have someone opening a ticket telling me how to run the service. They're wrong on their assessment, so their solution is wrong. Ive told them yet they still insist and don't want to help with the debugging. Or its the attitude that my time isn't worth as much as theirs or others. I'm on the receiving end of everyone's fire. Any team's fire can be twisted to suddenly be the most important thing for the company. Your problem gets put in a queue. And lets be honest, most people are full of shit with how important their problem is. Like this article said, I have my own projects, with cross team and company wide implications if it doesn't get done on time or done well. A recent scenario, someone asked for help, I told them Ill get to it soon, just not now, apparently that wasn't fast enough (we have defined sla's for responses) Mangers got involved, fine, I dropped everything to figure out their issue, it was a cross team thing, I pulled in other teams to debug too. I was getting pressure for updates for a few days, then silence. I asked for a follow up, i got a response the plans changed, not important anymore. They couldn't be bothered to even tell me? Some team started using our service in a way we didn't intend. (Revolving around persisting state and data, I don't want to give to much away about what i do, just trust I'm right here) So they complain, "whys the data gone?". The answer, because we never guaranteed that? And we have what we do guarantee published. So now this team is demanding special treatment, they can't fix it now, but they promise in the future to. Guess what happened? Were still special casing their ridiculous situation. There's little things people do, generally revolving around unrealistic expectations. Asking for off hours help with test/staging/dev/"whatever phrase you use" environments. Asking for multiple updates a day. Meetings that can be emails. > Being on an infra or platform team is always going to involve receiving a lot of demands from engineers, since you become the bottleneck preventing them from adding/modifying the overall system. Of course this is the case. There's ways to interact with people though, like ordering at a restaurant "Give me the food already, I'm hungry! Is it ready?", that just pisses people off. Have empathy and assume the best intentions until you have a reason not to. There's teams that are pleasant to work with, and co workers that are nice and friendly, there's also teams and names I cringe when I see them show up. That's my off the top of my head examples and part of the rant I tried to avoid.
- Aeolun 6y ago
  Huh, that sounds exactly like product engineers interfacing with business :P
  - tayo42 6y ago
    Yeah we need more empathy all around. Really we should all just admit no ones calling in life is to make their ceo and share holders more money and just take it easy at work and stop torturing ourselves and others for meaningless shit
- narwally 6y ago
  Sounds like in your third scenario you possibly should have given that team an EOL date on support for their special use case from the beginning. If it was an open source platform deprecating support for a feature they use, then they'd make the time to implement a fix. But since you're part of the same org they're able to indefinitely delay when they have to do additional work, but at the cost of your team constantly having a slightly higher workload.

by pm90 6y ago

tayo42 6y ago

There's a couple things that make someone come off as entitled. Like someone comes to me with a solution to a problem they don't understand but still demands I implement their solution. Someone wrote a whole doc about how we don't test enough and need to test more, like were unaware of it. I wrote the same thing my self before that, though were just understaffed so things fall to side. Why go in to the interaction with the assumption we don't know what were doing? When I get to back to work, I have someone opening a ticket telling me how to run the service. They're wrong on their assessment, so their solution is wrong. Ive told them yet they still insist and don't want to help with the debugging. Or its the attitude that my time isn't worth as much as theirs or others. I'm on the receiving end of everyone's fire. Any team's fire can be twisted to suddenly be the most important thing for the company. Your problem gets put in a queue. And lets be honest, most people are full of shit with how important their problem is. Like this article said, I have my own projects, with cross team and company wide implications if it doesn't get done on time or done well. A recent scenario, someone asked for help, I told them Ill get to it soon, just not now, apparently that wasn't fast enough (we have defined sla's for responses) Mangers got involved, fine, I dropped everything to figure out their issue, it was a cross team thing, I pulled in other teams to debug too. I was getting pressure for updates for a few days, then silence. I asked for a follow up, i got a response the plans changed, not important anymore. They couldn't be bothered to even tell me? Some team started using our service in a way we didn't intend. (Revolving around persisting state and data, I don't want to give to much away about what i do, just trust I'm right here) So they complain, "whys the data gone?". The answer, because we never guaranteed that? And we have what we do guarantee published. So now this team is demanding special treatment, they can't fix it now, but they promise in the future to. Guess what happened? Were still special casing their ridiculous situation. There's little things people do, generally revolving around unrealistic expectations. Asking for off hours help with test/staging/dev/"whatever phrase you use" environments. Asking for multiple updates a day. Meetings that can be emails. > Being on an infra or platform team is always going to involve receiving a lot of demands from engineers, since you become the bottleneck preventing them from adding/modifying the overall system. Of course this is the case. There's ways to interact with people though, like ordering at a restaurant "Give me the food already, I'm hungry! Is it ready?", that just pisses people off. Have empathy and assume the best intentions until you have a reason not to. There's teams that are pleasant to work with, and co workers that are nice and friendly, there's also teams and names I cringe when I see them show up. That's my off the top of my head examples and part of the rant I tried to avoid.

Aeolun 6y ago
Huh, that sounds exactly like product engineers interfacing with business :P
- tayo42 6y ago
  Yeah we need more empathy all around. Really we should all just admit no ones calling in life is to make their ceo and share holders more money and just take it easy at work and stop torturing ourselves and others for meaningless shit
narwally 6y ago
Sounds like in your third scenario you possibly should have given that team an EOL date on support for their special use case from the beginning. If it was an open source platform deprecating support for a feature they use, then they'd make the time to implement a fix. But since you're part of the same org they're able to indefinitely delay when they have to do additional work, but at the cost of your team constantly having a slightly higher workload.