Rendered at 22:30:13 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
Aurornis 3 hours ago [-]
This is a strange read. The intro buries all of the important information about where the team came from and pretends like a headless team appeared out of nowhere and he was in charge of the team:
> All of a sudden, in the slides there were a new team.
> I had a new team that nobody asked me for my input, nor informed me before that decision was made. It just appeared out of nowhere.
I had to read into the middle to discover the key information that the team reported to another product leader:
> The first odd decision was that the team didn’t report to any of the tribe leaders. They reported directly to our product business vertical product leader.
Was this really "his" team? Or did someone else put together a team and assign them to work with his teams, which offended his sense of empire-building and control?
There is a lot of writing and diagrams in this blog post, but throughout the post he talks about everything except how he tried to work with this other leader. It's all just complaints and washing his hands of the problems.
I agree that the way this team was introduced wasn't optimal (if we can trust the narrator), but the way this person handled everything afterward feels like office politics to the max: I didn't create this team, so I will relentless identify problems with it and make no attempt to address them until they're destroyed. I feel sorry for the people hired into this position who got caught in this EM's crosshairs while they were just trying to do their job.
mitjam 1 hours ago [-]
Yes and the org models look funny, too - a platform team for one other team, a second team bolted on that’s then merged back into the one team, but still a separate platform team. In one sentence it was mentioned that the distributed architecture created many of the problems in the first place. I think the system architecture followed the org chart in this case.
farazbabar 6 hours ago [-]
This team does not report to me, I will ensure their demise and make sure their work is never adapted by anyone within my sphere of control. It is easy to justify such behavior behind snazzy terms but I have seen this so many times that it isn't funny. Sometimes leadership may make a decision you may not agree with or even understand but focusing on why it happened, what you can do to align yourself and how you can help product, customer and business succeed are more important than your walled garden of carefully controlled conway conventions. It is right there in your own terminology of tribes, how very tribal.
belval 5 hours ago [-]
What exactly should the author have done differently? It's part of the leadership roles to understand the power structures within your organization. Reading between the lines, a new team was thrusted onto an arguably functioning sub-org to address concerns that they had not themselves raised. Then the expectation was for that sub-org to take a hit on their KPIs to onboard to the new teams platform.
It's not "tribal" to refuse to do something that is misaligned with all your explicit incentives. Otherwise we'd have to pay lip service to every internal tooling team just because they exist. It's the leadership team's job to keep pushing if they strongly believe the sub-org leader is acting in bad faith.
Aurornis 3 hours ago [-]
> What exactly should the author have done differently?
Work with the other engineering manager.
This person was angry about the team's appearance, but the other engineering manager who assembled the team is barely a side note in the document.
The way you deal with these situations is by working with the other managers involved and propose better solutions.
This is a weird blog post because it's supposedly from someone in a high up engineering manager position, but it's written with a political awareness that I'd expect from someone who had never managed before or who was a first-time manager without good mentorship.
watwut 1 hours ago [-]
They had better solution and used it. You cant "work with" people who are not working with you in the first place.
This was not a cooperative situation. Trying to cooperate in this situation will make you walked all over and also will make you the one to be blamed when it fails.
lostdog 4 hours ago [-]
The best managers I've seen would turn this situation into a headcount request.
The problem is leadership has priorities 1-5. Your team works on 1-3, but the PM keeps getting hassled about 4 and 5, so they look for levers to get them to happen.
In this situation, the PM scrounged up headcount from elsewhere, but if you present the option of adding headcount to the existing team, then you create a more harmonious option of getting these lower priorities accomplished.
Of course, this guy was taken fully by surprise by the suggestion. It's much harder to present a better option after the fact, and I agree that letting leadership feel the consequences of its decisions is a reasonable thing to do in this case.
stephbook 1 hours ago [-]
This is full of red flags. "Mysterious new team nobody told me about", "I don't focus on why I wasn't included in the meeting", "the problem is they don't report to me."
This definitely reads like someone up top – with the obvious power of creating teams – circumvented the author, and for good reason.
Your peers' and bosses' motives shouldn't come as a surprise, nor remain mysterious for months!
sdevonoes 24 minutes ago [-]
These are the worst kind of engineering managers. Arrogants, god-complex, always serving the company instead of serving the employees
cbbb 4 hours ago [-]
The CX team was created to facilitate the creation of a centralized dashboard to help support staff resolve customer issues quickly.
The manager decided there wasn't enough alignment (no "human connections"), and therefore each team should build an individual dashboard, then later (how much later?) realized the teams did not have the skills/motivation to do so.
The justification for why the manager steered the project in a completely new direction might be missing context. Unless I'm reading this wrong, their devs just needed to expose some APIs and they could get back to their work, no longer on call for handling support requests.
I'm left a bit confused why the original plan wouldn't have worked.
stephbook 1 hours ago [-]
It had the feeling the author made his backend guys develop "product teams dashboards", which they lacked the skill to implement.
Even though that's not what leadership wanted and they tasked the CX team with the dashboards (..for good reason?)
I was definitely confused the whole article and have had to guess at the author's intention. I hope the communication was clearer during working hours..
misiek08 36 minutes ago [-]
So good to read one single sentence. After the team wasn't delivering (it's separate discussion why and who was at fault) - it was disassembled and issues were still being resolved.
So much better than big corps leaving people as-is and then making hardcore reductions seen as bad...
ben8bit 5 hours ago [-]
Am I missing something - what's with the "tribe" terminology?
EDIT: Just like Agile, it's poorly implemented at most companies and can lead to a ton of fighting due to multiple reporting arrows coming off employees.
andyjohnson0 3 hours ago [-]
I once interviewed with a company that organised their people into four "tribes". The company culture was pretty odd, and I fortunately managed to bomb the in-person interview. Now I know where they got the idea from.
ben8bit 3 hours ago [-]
Yea, it's a very odd way of referring to people you work with.
ben8bit 4 hours ago [-]
Thanks!
layer8 3 hours ago [-]
What surprises me most is hiring a full three FTEs for the purpose of creating an internal dashboard.
> The dashboard wasn’t that complex: View information, perform some API calls. Replicate what we were doing in the DB and API manually but in a web page.
stronglikedan 5 hours ago [-]
Funny, I was just involved in the opposite of this, where the PM proposed a new "E2E" team (coincidentally also called the CX team) that reported to someone outside the "tribe", and the proposal was shot down by leadership. I really didn't give it much thought since, but after reading this I want to find out why they shot it down.
munchbunny 3 hours ago [-]
"E2E teams" are difficult because your success depends on specialized teams to not screw you over - and not just in terms of politics, but it can happen just from them protecting their codebases and trying to focus on delivering under the pressure they're getting from their management, independently of the "E2E team's" goals.
If you think about the people in your team who command the respect and trust to be able to get past all of that wariness of team outsiders, it's usually a really small number of people, and usually they are veterans who've been around for long enough to have built those relationships.
> All of a sudden, in the slides there were a new team.
> I had a new team that nobody asked me for my input, nor informed me before that decision was made. It just appeared out of nowhere.
I had to read into the middle to discover the key information that the team reported to another product leader:
> The first odd decision was that the team didn’t report to any of the tribe leaders. They reported directly to our product business vertical product leader.
Was this really "his" team? Or did someone else put together a team and assign them to work with his teams, which offended his sense of empire-building and control?
There is a lot of writing and diagrams in this blog post, but throughout the post he talks about everything except how he tried to work with this other leader. It's all just complaints and washing his hands of the problems.
I agree that the way this team was introduced wasn't optimal (if we can trust the narrator), but the way this person handled everything afterward feels like office politics to the max: I didn't create this team, so I will relentless identify problems with it and make no attempt to address them until they're destroyed. I feel sorry for the people hired into this position who got caught in this EM's crosshairs while they were just trying to do their job.
It's not "tribal" to refuse to do something that is misaligned with all your explicit incentives. Otherwise we'd have to pay lip service to every internal tooling team just because they exist. It's the leadership team's job to keep pushing if they strongly believe the sub-org leader is acting in bad faith.
Work with the other engineering manager.
This person was angry about the team's appearance, but the other engineering manager who assembled the team is barely a side note in the document.
The way you deal with these situations is by working with the other managers involved and propose better solutions.
This is a weird blog post because it's supposedly from someone in a high up engineering manager position, but it's written with a political awareness that I'd expect from someone who had never managed before or who was a first-time manager without good mentorship.
This was not a cooperative situation. Trying to cooperate in this situation will make you walked all over and also will make you the one to be blamed when it fails.
The problem is leadership has priorities 1-5. Your team works on 1-3, but the PM keeps getting hassled about 4 and 5, so they look for levers to get them to happen.
In this situation, the PM scrounged up headcount from elsewhere, but if you present the option of adding headcount to the existing team, then you create a more harmonious option of getting these lower priorities accomplished.
Of course, this guy was taken fully by surprise by the suggestion. It's much harder to present a better option after the fact, and I agree that letting leadership feel the consequences of its decisions is a reasonable thing to do in this case.
This definitely reads like someone up top – with the obvious power of creating teams – circumvented the author, and for good reason. Your peers' and bosses' motives shouldn't come as a surprise, nor remain mysterious for months!
The manager decided there wasn't enough alignment (no "human connections"), and therefore each team should build an individual dashboard, then later (how much later?) realized the teams did not have the skills/motivation to do so.
The justification for why the manager steered the project in a completely new direction might be missing context. Unless I'm reading this wrong, their devs just needed to expose some APIs and they could get back to their work, no longer on call for handling support requests.
I'm left a bit confused why the original plan wouldn't have worked.
Even though that's not what leadership wanted and they tasked the CX team with the dashboards (..for good reason?)
I was definitely confused the whole article and have had to guess at the author's intention. I hope the communication was clearer during working hours..
EDIT: Just like Agile, it's poorly implemented at most companies and can lead to a ton of fighting due to multiple reporting arrows coming off employees.
> The dashboard wasn’t that complex: View information, perform some API calls. Replicate what we were doing in the DB and API manually but in a web page.
If you think about the people in your team who command the respect and trust to be able to get past all of that wariness of team outsiders, it's usually a really small number of people, and usually they are veterans who've been around for long enough to have built those relationships.