What do you do when you notice duplicate workstreams independently solving the same problem?
Posted by brystephor@reddit | ExperiencedDevs | View on Reddit | 20 comments
I am a senior engineer. If you think of each team as a node, then my team is near the center. This makes it natural and easy for me to see what cross functional teams are working on.
I can count 4 problems that are being worked on by 2+ teams independently without knowledge of each other. The problems are in an area tangential and useful to my domain. Think of these as "we want to evaluate the quality of X" or "our backend will be used for thing Y" and is not specific to their team, theyre intended as tools to be used in a horizontal manner across teams.
This is frustrating as the centralized team because now when I want to solve thing X, I have N different options to evaluate. When we do any cross functional effort, multiple stakeholders need to be aligned and taught why we use tool A over tool B, theres a constant amount of infighting happening which degrades support, and lastly its just wasted effort.
I can think of a few options:
-
I do nothing. not my problem, leadership should figure this out.
-
I bring this up to my manager. They'll probably suggest option 1 or something similar to it.
-
Bring it up to my director. The director tends to not like anything labeled as throw away work. Some of it is cross org though so director has little to no influence.
What do you suggest?
note: Upper Leadership (above director) general opinion is that everyone does anything and if it works, keep it, indifferent of complexity or overlap.
dmbergey@reddit
pour myself a drink
ColdPorridge@reddit
This is not unique and happens everywhere. I would go as far as to say this type of internal duplication of work is an inevitable and continuous process, a side effect of any sufficiently large engineering org.
So for what to do… you need to get them in the room together. You might be senior but you can act like a staff. Start the conversations. Find common ground. Probably don’t pick sides but try to mediate the ICs and first line managers to build with awareness of the org.
boring_pants@reddit
It's also not necessarily a bad thing. A single central solution means more synchronization and coordination between teams. It means that team A may not be able to just fix a bug or add a feature in that code without considering compatibility and checking in with other teams.
Sometimes, parallel development is actually a good thing because it frees up each team to make the decisions that make sense for them.
(Of course there are downsides to it as well, but I don't think I need to enumerate those)
Ok_Chemistry_6387@reddit
There are probably a lot of upper level politics at play that seniors/staff/etc are not aware of or have already fought. So be wary of this approach, you may expose old wounds, or down right hostility unfortunately. If there isnt already a formal meetup for staff across org, try organising an informal one. This often helps reduce these kinds of things with out having to play politics.
fangisland@reddit
I agree with this, and one of the simplest / low cost solutions might be to just host a community of practice across X line of expertise. Because a lot of times, you'll have expertise in one specific domain spread across a lot of different teams, so those individuals don't have a place to communicate naturally (this is often the result of cross-functional teams). This is why Spotify advocated for the chapter/squad/guild model. Literally just host a 30m - 1h call that's voluntary, and show people the overlap and how X number of teams are solving the same problem. Doesn't even have to be prescriptive or shaming or anything, just show what's going on. I bet people will start to have light bulbs on their own.
positivelymonkey@reddit
Id stay quiet. You're just going to annoy people.
Firm_Bit@reddit
If I care about it and it’s important I do it better and work the political angles to make sure my version wins.
If not I go work on something that matters and matters to me.
EdelinePenrose@reddit
not knowing the culture, i think option 2 is your best bet. i’d probably write up a document explaining the situation abstractly, show/link the N examples, offer a suite of options for mitigation. approach your manager in a vibe of asking for advice on if and how should we coordinate simplification. let them choose if it’s a problem. i wouldn’t take it upon yourself to resolve unless your manager thinks it’s a problem, or wait until it becomes your problem and therefore your manager’s because productivity drops once your team has to wrangle N solutions for the same thing. or something like that. negotiate, don’t impose.
TheTacoInquisition@reddit
Do the teams know they're duplicating systems?
If not, tell them. If they do, or don't care after you tell them, then talk to your manager AND higher ups about doing a quick (day or two) audit of the various systems and making a central document of systems. Then, where there's duplication, you can point it out and request the director to pick an "officially supported" approach.
Teams can duplicate effort if they want. There are good reasons to do so sometimes. But, if others in the organisation are being asked to use a system, there needs to be a simple way to make a decision, and duplication makes it complicated.
So for example, a team needing an auth system and being told one exists to use should NOT be faced with multiple systems to evaluate. There should be ONE preferred system, and that is the one everyone defaults to. If that team have special considerations and the default doesn't fit but another one DOES, then they can deviate. If enough teams run into that same problem, then the default changes
drnullpointer@reddit
We have a process to fix this at two levels.
At the leadership team level, we regularly go over the projects we are working on and our future plans. This allows us to deconflict our plans and optimize actions before we even expend any work.
At the individual contributor level, we have a weekly architecture meeting where people present design and architecture changes they are planning to introduce. This allows us to disseminate knowledge primarily, but also to have open process to critique the design and solve issues at early stage. It also forces people to be better prepared with regards to documentation and arguments they have and forcing people to think about what they are planning to do is a good thing in my opinion.
Cosmicdev_058@reddit
This happens at every company past a certain size. You're not going to stop it from happening but you can be the person who makes people aware of each other. Just set up a 30 min call between the two teams working on the same thing. You don't need to pick a winner or propose a solution, just get them talking. Half the time they didn't even know the other team existed. That alone saves months of wasted work and it's the kind of thing that gets remembered when promo conversations come up
YK5Djvx2Mh@reddit
Everyone is getting so political. Just act dumb and innocent: "Oh, thats a cool project, I think Mike is working in that too!" or "Oh, you are working on that? I thought was working on that?" Let them decide if they want to work together or compete.
chikamakaleyley@reddit
freakin mike dude
annoying_cyclist@reddit
I default to doing nothing.
Sometimes it is worthwhile to take action because having overlap is really costly. Maybe it's moving the architecture in two mutually incompatible but highly costly ways that impose costs on other teams. Maybe it's a bit enough time investment that the opportunity cost of having two teams working on parallel solutions is risky for the business (you'd hope a manager would catch this, but people's desire to own fancy projects often blinds them to things like this). Those, in my experience, are the exception. In most cases a little bit of overlap isn't too harmful, and starting political battles to address it isn't the best use of my time.
csgirl1997@reddit
I’ve seen some changes like this play out at my org over the course of 5 years.
It does not necessarily always make sense to consolidate duplicate work. My org is currently working on pulling apart a codebase where we attempted to consolidate a lot of shared functionality between teams.
At first it went well, but as our respective teams’ products grew, we began to step on each others’ toes. It became less clear who owned what and who was responsible for issues on the shared platform became a point of contention. Folks hacked around to shoehorn their own features into it.
I also worked on a developer-led infrastructure project that several teams ended up adopting. It solved a common pain point and in theory it was a useful tool. However, we never got enough leadership buy in to actually support it. It kind of spiraled into a sh*tshow quickly when all these teams integrating with it started to discover bugs and there was no one developer 100% allocated to it.
I’ve also seen individuals come up with stellar tooling on their own which the organization comes to rely on, only for it to be left to rot when these folks depart.
Before proposing consolidating some of this logic I would ask yourself a few things: - Is this potential shared component large enough that someone could argue forming a team to maintain it would be a net financial positive versus developers duplicating work - Who would own this shared tooling? Who would be responsible for maintaining it? - Is there a precedent for this sort of thing in your org? Sometimes this sort of thing can work in orgs that have a sort of engineering focus internal open source mentality. It did not work at my org because we are heavily product/feature oriented
editor_of_the_beast@reddit
I go home and punch something
Dimencia@reddit
More options is usually a good thing, and duplicate work does usually end up finding different approaches that are hard to decide which one is better - so it's convenient that you get to see how both of them play out in the real world, and everyone learns something when they eventually see one of them working better than the other (at which point they might swap to that approach). Or, if that never happens, then you just have two distinct approaches, each with different tradeoffs, and each team can pick the one that fits their needs the best. It's win/win either way
Mediocre-Pizza-Guy@reddit
IMHO - this is office politics. The correct answer is going to depend on factors not given.
At most organizations, it will be set up in such a way that you are intended to bring these things to your manager. And mostly, your manager won't care.
Or if they do care, you risk them claiming (or at least receiving) the accolades you might deserve.
Jumping over your manager and talking to the director.... Could be great for you. Especially if the director agrees with you. But also....your manager might get pissed and your director might get pissed.
The director and your manager might be pals. They might have a long work history and all that jazz.
Respectfully, stuff like this usually isn't very hard to see. Two teams doing similar work... That's either...
An embarrassing failure of management
An intentional decision to double the odds of success or whatever MBA tip they heard about. It sounds like senior leadership feels this way.
In either case, by calling it out, you are saying 'Someone in management is doing something stupid.' and leadership wants that something stupid.
For most people, I think your best bet is to focus on whatever dumb shiny thing leadership wants, rather than trying to address actual problems.
No-Economics-8239@reddit
It's a hard problem to solve. And not one you can solve directly. You really need someone at the director level or above to take notice of it. I, personally, would just feed it up the chain if I don't have relationships and political capital with the teams involved. If I do have such relationships, I would still weigh if it seems worth it to try and side channel it and risk stepping on toes.
If you can step in and get cooler heads to prevail, it might be a nice feather in your cap. But at the senior level, you are more likely to make enemies than allies if you try and 'improve' things. Because even if you're right, the truth is no defense if you can't convince others.
originalchronoguy@reddit
You do nothing. You follow the lead of your leadership. I've been in this many times throughout my career; where teams and different leaderships vie for first mover's advantage. There is a lot of politics and machinations above your pay grade you don't know about. And leave it at that.
Some other leadership (on another team) might be on their way out and your leaderships see their siloe as the backup plan B.