At what point is the fight against information silos too much?
Posted by ShroomSensei@reddit | ExperiencedDevs | View on Reddit | 23 comments
Currently dealing with what feels like the tipping point of a fight against information silos. My team is about 7 engineers with 2 seniors and the rest junior to mid level. We are working on so many things at once right now it is starting to feel impossible to really grok/understand anything that has any level of complexity. For context we have around 2 full projects that honestly each could have their own full on teams. About 50 repositories make up these projects with \~35 of them being independent microservices and the rest shared libraries. I am leading 2 epics this quarter one of them being a large/critical refactor and I am just suffering through context switching hell. I cannot give either of these projects the time and care they need.
All of the work around that surrounds the epics I'd be fine with (designing, jira admin, docs, coding, testing, etc), but its also people on other work that try pulling me in for help so "everyone has awareness" and "no information silos". It's not just other feature delivery either but everything from maintenance/support, production releases, and design work. I see the same thing happening with other team members, they keep getting dragged everywhere and it really makes it hard to confidently get stuff done every sprint. No one seems to be as vocal about the pain of context switching as I have been but I think that's because it has been shut down by our PM each time it's brought up. I have confirmed with others this same sentiment so I know I am not alone.
Asking to create more distinct "teams" or "responsibilities" within our group is always shut down with "if we silo this work / domain / feature those people will be solely responsible for it, do you want to be the only one ever on call for this?" and I completely understand that sentiment but I think we are really reaching a breaking point. We are having more defects come through and more stories roll than ever before for half a year now when, say 1 year ago, we were spotless. We are also know starting to fail our production releases which is an extremely big deal in my company, these get reported high up the chain people have gotten fired for this stuff. All of this has management keeping us under a microscope because of low trust since we've been performing so bad lately. I am to the point where I would be pretty comfortable being the only person responsible for a given subset of our services if it meant I didn't get dragged everywhere else. Or even just leaving to a worse team as long as I am not under a microscope and context switching all the time.
I've found my own ways to manage this, but it's really starting to take a toll. I hate having to constantly up amount of effort for shallow work just because it's going to take extra time to understand the context and get stuff up and running. I want to actually sink my teeth into complex topics, really understand what's going on, and build something I can be proud of not something that just meets the poorly written acceptance criteria. My teammates also just seem to not be able to manage this stuff nearly as well hence the rolling stories constantly.
Anyone else gone through this before or seen the tipping point?
and yes I'm already looking at other jobs
freeformz@reddit
~50 repositories for 2 projects is lunacy.
yeahnoproblemitsfine@reddit
This is very easy for me to say, but you just need to start saying no to stuff.
I had success in the past with a "team charter". What we do, why we do it. What we won't do.
ShroomSensei@reddit (OP)
Like I said, I have found my own ways to manage it, and saying no and standing my ground is a part of that. That's just another thing my team members struggle with though.
I don't think undefined mission is the problem. It's very clear what we're doing and why we're doing it. How we're doing it I think is the problem and one reason for how we are doing it is to avoid silo'd information.
gorrepati@reddit
Can you tell us where you work so we can avoid this workplace 😛
codescapes@reddit
Silos are ultimately necessary and fine. There's a reason all developers at a company aren't just in one team with completely shared responsibility. It reaches a point where for practical reasons you have to split and allocate work / knowledge to different groups of people.
Frankly it sounds like your management just don't want to hide the engineers or you know, manage.
Away_Echo5870@reddit
That’s my assessment too, op is just overloaded and trying to involve less stakeholders seems like a way to reduce the load. If it works, there will just be more load added because fundamentally the issue seems to be that the company wants to push them to their limits of “productivity” to operate cheaply.
They need to hire more staff or reduce scope. That theres only 2 seniors and the OP is one of them with 4 yoe on his flair is another red flag. My team by comparison has only seniors and we’re given plenty of time to focus on work, good management is a choice. I would suggest just leaving, but the market is shit right now after what 15k devs looking for work from the Microsoft layoffs alone.
temp1211241@reddit
Well there’s one problem. If you’re doing this these should be small enough they’re rarely revisited, change isolated so parts that interact with them can change without touching them, and well documented since you’ll ideally ignore them for years.
These should be handled sequentially and not in parallel with any delay reviewed at least monthly to update the timeline.
This work is important. Based on your start it’s maybe actually more important than the epics.
Set aside pairing days. You could even partner up with one person a week and spend two days pairing on one project then swap to pairing on the other. Rotate pairs sprinkle or weekly.
Scheduling it will reduce random context switching that comes from it being unorganized.
Presenting a problem often works better when it’s presented with a solution. Once you start doing this you’ll be surprised how willing PMs and EMs are to go along with it. Plus it’s a great way to get promotions.
Stability work will mater here. Hot spot analysis and test coverage focused on maintaining contracts/expected output are probably good pairing projects when the getting up to speed. Take notes when not driving, ask questions to validate them, the throw them in readmes, wikis, or confluence since there’s clearly a reference material issue.
Puggravy@reddit
Why not mono-repos? It makes it hurt a LOT less being able to run tests, lint, commit code and pr with just a couple steps rather than once for every single repository. I tend not to favor having mono-repo frameworks handle CICD, but that's also an option if you're so inclined.
TurbulentSocks@reddit
Why do you have so many repositories and micro services for two projects and under ten engineers?
gosuexac@reddit
Are these repositories just different parts of their monorepo, or are they entirely separate git directories?
ShroomSensei@reddit (OP)
entirely separate
mvpmvh@reddit
The wording suggests not a monorepo
ShroomSensei@reddit (OP)
An architecture decision made early on for how we'd split up business logic and limit blast radius of failures. No one knew years ago that it would explode to what it is now.
TurbulentSocks@reddit
How much of that is a cause of those solos? I understand well the issues of context switching and too much going on, but that's seven or eight projects, not two. But we've a couple of repos at most, not literally dozens.
LeadingPokemon@reddit
So you have 7 engineers and 50 Git repos? Holy shit… that’s not a good ratio…
Turbulent-Week1136@reddit
You need data and slides that you can present to the people above you so that they understand the business impact. That's the only way they will understand, otherwise it will just keep on getting worse.
ShroomSensei@reddit (OP)
Yeah I could probably make some correlation between defects / cycle time / and toil to when the 2nd project was introduced and really added to apart of our efforts.
onefutui2e@reddit
It sounds like you have some sort of ticketing system to track work. That's a great start. If you're holding sprints, that gives you a few data points to work with:
You should be able to put together a narrative around how unplanned work is tanking your team's velocity. From there, you can start suggesting solutions. When you do, be sure to highlight how you'll know it's working, what your timeline is, etc.
It's an incredibly thankless task, but as someone who did something similar to help my team, the force multiplication effect is massive. And seeing my team's morale and output improve was a huge satisfaction for me.
Turbulent-Week1136@reddit
Yes. Stuff like that is the only language that managers understand. Once you email it out and present it, it's there forever and if things go to shit, then the people that ignored it will be held responsible.
Just make sure you don't just present the problems, but present solutions and how it can help. No one likes a complainer, so providing suggestions at the same time you point out the problems makes you look very valuable.
bulbishNYC@reddit
Why do you need sprints? Sprint is for when whole team works on one experiment /goal together. You are just working on a laundry list, why not work without an artificial deadline or try so hard looking into the crystal ball?
ShroomSensei@reddit (OP)
While I don't personally like sprints / scrum it is what is here and that's not going to change.
Significant_Mouse_25@reddit
It’s always a spectrum and like any spectrum the point you want to be on it is dependent on current circumstances. And those change over time of course.
Right now the argument should be made that nothing is getting done because of the attempt to avoid siloing. Moving towards the silo end of the spectrum would increase productivity and generate a foundational set of expertise. Then in the future these people can be leveraged to KT to the rest I’d the teams and share more of the work. But that needs to happen very deliberately.
Then there’s the question of why they are so against it. Are they concerned about single points of failure? Attrition taking away expertise that isn’t replicated? Are they trying to keep you fungible so when the work is lower they can more safely lay you off? Are they accepting of the trade offs for doing it this way? If they are then you should just take care of yourself. Set the expectation that it’s going to take far longer and start estimating efforts with extra sandbagging. Tell the team to do the same. Ensure everyone knows the strategy chosen, implications, and trade offs.
ShroomSensei@reddit (OP)
I think this is what is most needed right now. Out of the 7 engineers only the tech lead and myself understand just about everything going on which puts a huge strain on us both. Other members have been on the product for over a year and some even 2 years now but still greatly struggle, but I think if they were focused it would allow them to take actual charge of something and be confident in it.
As far as why they are so against it I think it's because of past situations they have been in. They've been on teams that was just a death march of operations and keeping the lights on. They've been solely responsible for products with large support queues and don't want it to happen to us. I understand their sentiment but like you said it is a spectrum. Our support queues are fairly small but have been growing due to all the defects and maintenance popping up.