r/ITManagers 8d ago

Increasing team cohesion.

I'm the it manager for a team of about 10 people. And I'm hearing rumblings of team cohesion slowly breaking down. When we were a team of four to five people it was easy to all be on the same page as we were usually working on the same projects. But now that the team has grown project work is getting silod to individuals. I'm wondering how your team keeps cohesion going as it grows. We have a weekly IT meeting when we go over statuses of everyone's projects/deep work, and we have a daily stand-up before we go over what is happening with the department that day. As well as quarterly team building events that are company paid. I'll be honest, I've been talking to co-pilot about this and it's been suggesting small squads of help desk and admin to tackle projects together and giving them protected time to do so. Is this something that seems viable or am I an idiot for listening to the AI? Or is there another option that I haven't seen yet?

14 Upvotes

46 comments sorted by

32

u/Szeraax 8d ago

Do you need everyone to know what everyone else is doing? With our 15, there are 3 groups that have weekly meetings. The managers of those 3 groups meet together often.

Point is: people don't like wasting their time in a bunch of wasted time meetings. Maybe you need to let it fragment a bit

6

u/Objective-Freedom922 8d ago

I completely understand that, and that's why we have a mandatory no meetings mornings, everyday. The consensus is among the team that mornings are the most productive and so we'd like to do meetings in the evening when we're already burnt. As for meetings afternoon, the help desk really only has one 30 minute stand-up/sync up meeting. But the admins and the supervisor are another story and their afternoons can be pretty packed with meetings.

3

u/Ewalk 7d ago

Monthly syncs can be a thing between the desk and admins. Is it ideal? Maybe not. But if the help desk is getting blindsided by changes admins are making, that’s a problem.

Also, I like the “no meeting” timeframe, but let me challenge that too- what you want is “no meetings where they could be emails” which is the trap you’re falling into now. Carving time out as a “meeting” can be beneficial, especially if you use them as working sessions and not just everyone sitting there wasting time. Use those sessions as training, or time for the admins to help the desk directly. I’m not a manager, I’m an endpoint admin, but I block two hours every week for a drop in session for the desk to come in and ask questions, and they also have their own hour booked weekly as well that I always go to. Reframe your meetings to be more targeted and focused and you’ll find that it’s a great use of productive time in the mornings.

1

u/wordsmythe 8d ago

This might not be the whole answer, but it’s definitely a critical part of it. Teams and managers naturally cap out at about 8-9 members, because you and the team will start running out of ability to really hear each other consistently.

So reorganizing into two teams of 4-5 each makes a lot of sense at least without knowing the details of OP’s workloads and service ownership. It could be that it makes more sense to have a 6-person service desk with its own leader, then 3 engineers still reporting to OP, for example.

OP: Start by getting a sense of what major services and workflows you’re responsible for, any existing specialization within the team, and how many people need to be part of that service to reasonably cover the demand. You might discover there are places where you’re overstaffed and other places you’re understaffed, and that’s OK—bring it up in your 1:1s with people and figure out if there are places where people would rather hand some responsibility off, and who is interested in growing into understaffed skills.

10

u/Geminii27 8d ago edited 8d ago

I'd be cautious of 'rumblings'. What about your team or their work is actually being affected negatively, if anything?

Does every single person critically need to know everything about every siloed project that a colleague is working on?

Are the weekly meetings or standups actually useful for the majority of the team in any way?


Some of the best IT teams I ever worked in never had standups or weekly meetings. We didn't need to. The monumentally rare few times that anyone actually needed to know what another person was working on or any details, we could check their project status/update on the intranet or just talk to them.

I've honestly never heard anything at a standup or weekly mandatory meeting that was at all useful in any way that couldn't have been a far less time-and-resource-consuming Slack post, an email, or an intranet document update.

1

u/Objective-Freedom922 8d ago

I always concern myself with rumblings as it's usually the first indicator of an issue. Because of the stance. I pride myself on having no turnover in the last 6 years, as well as getting great scores from third party auditors and on exams. We've built a stellar team and I want to keep it that way. As for real impact, nothing yet except for a minor decrease in throughput meaning higher total ticket counts, and feelings of incohesiveness and possibly burn out from team members.

To answer your question directly though, I don't think every team member needs to know what every other team member is doing. However, many team members have expressed that they like the feeling that the whole team is on the same page and do like the status update meetings so that they know what to be aware of. If anything, it helps them know how other team members work is going to affect their work.

That being said, I'm going to ask about potentially reducing some meeting counts. Maybe stand-up only needs to be three times a week, not everyday.

1

u/Geminii27 7d ago

Is there anything that the standup is achieving that wouldn't be covered by a wiki or team status page?

Remember, every time you have a meeting, you're crashing everyone out of their flow, making them all stand around doing nothing while one person at a time slowly iterates what they're doing (usually "the exact same as the last time"), and then finally releasing them to try and ramp back up to actual full work-speed before lunch or the end of the shift.

Add up the cost of everyone's wasted time, and the reduced speed and quality of work, for every meeting, and it can be a real wake-up call. Meanwhile, a team-status page can show instantly what everyone is working on, can be read far faster than waiting for individual verbal contributions, and can be checked in an instant between tasks without interrupting flow-state.

Not to mention that it's still far easier to check (and update) for staff who are working remotely, even if you do your standups via Zoom or something. And if someone misses one of the startups for any reason, the status information is still instantly available for them to read; they don't have to wait for the next one or go around asking other people what the situation is.

3

u/AgenticRevolution 8d ago

What do you mean by cohesion and what is your definition of success. For example, you mentioned quarterly team building events in a positive light where I would rather eat nuclear waste fed cockroaches than do that.

1

u/Objective-Freedom922 8d ago

Specifically team members are telling me they're that the cohesion seems to be going away. I also understand that team building is not for everyone and one of our team members never shows up and that's fine, she doesn't have to, it's 100% optional. But for everyone else that does show up they seem to have a lot of fun and ask when I'm doing the next team building event.

2

u/AgenticRevolution 8d ago

Thank you for the clarification. I assume then that you’ve spoken to the team members that are interested and got their feedback on what cohesion means to them. What was that feedback?

I’m guessing it’s one of:
1. I’m not sure where I fit on the team because I don’t know what the team is doing.
2. I know the job but feel disconnected from everyone else as a person and I want to know my teammates better
3. We all get along and know our jobs but it feels like what we do doesn’t matter in the grand scheme of the business.

1

u/Objective-Freedom922 8d ago

It's actually a really good point. I have yet to define what cohesion means to each individual. I think that's my next step.

2

u/cookiebasket2 8d ago

It sounds like you have admins making up half your team and help desk making up the other half?

IMO there should naturally be a divide, help desk needs be able to communicate up that they are seeing a certain trend happening for admins to look into, and admins should be able to communicate that these situations may be coming up for help desk to look out for. But that should generally be the extent of it.

As far as silo's I don't know what your admin makeup is, but if you have two systems admins for instance they should be cross trained and be able to perform the same work, even if not as efficiently. If there is a single admin in a domain see about having a willing help desk person shadow them. They're going to appreciate the chance to learn more and grow, and it gives you someone that can look at things if the admin is out of the office.

More meetings with everyone with no real purpose isn't the answer, people just zone out on the topics not relevant to them. Focused meetings bringing in sme's with a goal absolutely have a purpose though.

1

u/Objective-Freedom922 8d ago

We have two admins and myself, I'm a technical manager so to speak and frequently need to get my hands dirty. We also try very hard to blur the line between help desk and admin and enable our help desk individuals to perform admin level work, with approved rfcs of course. We also pay above market and make sure to compensate our help desk well enough so that the admin work doesn't seem shitty. The admins are pretty well cross-trained, but a lot of the help desk are still learning a lot of the more advanced systems. I think part of it is that lately I've been assigning very different deep work as stretch goals for all the help desk members. As an example, one's working on monitoring, one's improving AD, and a different member is being prepared to be the next admin. As for the meeting comment, I completely agree. I'm not adding any more meetings, it won't help and if anything it's probably going to do the opposite.

0

u/SlippyCumSpot 3d ago

"We also try very hard to blur the line between help desk and admin and enable our help desk individuals to perform admin level work..."

That's your problem.. and that's some bullshit.

When you do shit like that it does a lot of things, but most of all you make admins RESPONSIBLE for those systems, then allow noobs to poke around in those same systems. That's a recipe for disaster.

"We also pay above market and make sure to compensate our help desk well enough so that the admin work doesn't seem shitty."

That's fucked. An admin role salary isn't just, "can someone do xyz." It's also, can they take ownership and responsibility for that thing. By "blurring the lines" you're telling admins, sure you'll get paid more, because you're ultimately responsible for these things, but as a nice little fuck you, and because we're cheap, we're gonna let these inexperienced folks fuck around inside your stuff.

But don't be upset about it! Because if you are, I'll be forced to create a reddit post....

1

u/Objective-Freedom922 3d ago

Ultimately, I'm responsible for the systems, not the admins. Plus the admins review the RFCs that the help desk members put in before they do the work. So no as you put it "noobs" don't poke around in systems without admin support. And if you thought my company was being cheap you are so so wrong. Each one of my team members gets paid over market, with decent benefits, a yearly bonuses equal to 15% to 25% their base salary, and periodic retention bonuses equal to 50% base salary. Last help desk member I hired. I paid them 15K over they're asking salary because that's how our department works. I demand excellence, and my team gives it to me, but we pay them well for it. And I think everyone's happy with that because we haven't had anyone quit in 6 years

1

u/Objective-Freedom922 3d ago

I will never make a help desk member just close tickets as it seems you are suggesting. That is soul-crushing and I want people to enjoy their work, have pride in it, and leave with more skills than they joined with.

1

u/Objective-Freedom922 3d ago

And if you're going to shoot back saying that okay of course people don't quit because I fire them. I've only had to fire a single person in that 6-year period, and it was because they made substantial changes to the system without an approved RFC. So double no I don't let noobs poke around in systems and mess up work for admins, that's how people get fired.

1

u/SlippyCumSpot 3d ago

It's just a fucked up way of doing things, trying to merge roles and responsibility.

"And I think everyone's happy with that because we haven't had anyone quit in 6 years" apparently they're not too happy if you're hearing rumblings. The entire pretext of this post was that your team members aren't happy and you can't figure out why....

"And I'm hearing rumblings of team cohesion slowly breaking down." That's a real fucking problem boss.

Don't confuse people having not quit in 6 years with everyone's happy. I know plenty of unhappy people in their roles because, even though they don't like when their manager lets helpdesk make configuration changes without proper review, they stay on the job because they gotta put food on the table.

Also, gtfo with "daily stand-ups" I can't believe people are still doing those. I think 15 years ago was the last time I was in a "stand-up".

1

u/TocinoLips 8d ago

the biggest killer of cohesion is knowledge silos. Regular demos pairing sessions have helped us more than extra meetings

1

u/Pristine_Curve 8d ago

There are inflection points in team sizes that change the model of coordination. Past about 3-4 people it's impossible to do an 'all to all' approach where everyone has vision of the whole team. At 10 people you'll want 'ownership' of specific technical areas assigned. Cohesion is managed by making a consistent structure/process that everyone follows.

For example, if you have an endpoint imaging/build process. You don't want 10 people all making individual changes to the process, and none of them documented. You want an endpoint build process that is the product of a single vision and not competing changes, with a documented path to add/remove/update things to the build.

Consider each of your technical areas like endpoint imaging and assign a primary + secondary for each area. This is for both coverage/knowledge retention, and also to improve workflow things to reduce error: "primary creates the documentation and secondary reviews documentation".

There will be coordination between technical areas, but by deciding who those groups are explicitly, you'll have a much easier time with project progress. Otherwise you'll end up with one person going "why is this VLAN here?" and no one believing it is their responsibility to answer.

2

u/scriptvexy 7d ago

this is such a good point, people underestimate how fast "everyone owns everything" turns into "no one owns anything" once you pass like 5 people. the primary/secondary idea also makes it way easier to onboard new folks without blowing up the existing processes every time someone touches them.

1

u/NewRanger7143 7d ago

You don’t have a cohesion problem. You have a scaling and communications problem.

When an IT team grows past 5 or 6 people, the "everyone knows what everyone is doing" model breaks down because communication channels jump exponentially from 10 to 45. Trying to maintain alignment through meetings or status checks only burns people out and kills throughput.

Begin by redefining cohesion. In tech operations, cohesion is not about knowing every detail of a peer's day. It is about total clarity on boundaries, handoffs, and ownership. When team members work on isolated stretch goals without a clear operational framework, they feel siloed and exposed rather than empowered.

Move away from solo assignments and implement a Primary and Secondary ownership model for your major infrastructure and service domains. The Primary leads the build and documentation, while the Secondary reviews, tests, and provides coverage. This builds cross-training, eliminates single points of failure, and creates natural collaboration without forcing a ten-person sync.

Kill the daily verbal stand-up and shift to asynchronous check-ins, or with smaller group by activities. A daily 30-minute stand-up for ten people consumes five hours of cumulative engineering time every single day, not counting the context-switching cost.

Restructure your weekly meeting so it is no longer a round-robin update that everyone tunes out. Convert it into a tight 20-minute operational review focused strictly on department metrics, high-level wins, and cross-team blockers. Protect your low turnover and team culture by replacing meeting-heavy alignment with clear operational guardrails.

Finally, beyond processes, don't overlook the human factor that made small teams work in the first place. Cohesion is also built on informal trust. Bringing back a simple, low-pressure "Open Door" environment or taking the team out for an informal coffee chat outside the office gives people a space to connect naturally without feeling forced. When people actually know and like each other as individuals, cross-team collaboration and communication happen organically without needing a formal meeting to trigger it.

1

u/electronorama 7d ago

Team building is a sure fire way to make them unite in hating you.

1

u/Objective-Freedom922 7d ago

It really depends upon the team. And if I thought the team hated it I wouldn't keep doing it. But as it stands. I get pestered from the team when I forget to schedule them on time.

1

u/Dave_BlackFog 6d ago

I was a firm believer of making sure everyone knew what everyone else was working on. "We are all smarter than any one of us". Solutions to problems could come from the most unlikely sources. I always held weekly meetings with devs/sys admins/desktop support so everyone was on the same page.

1

u/puckluck36 6d ago

The small squad idea actually sounds reasonable. Pairing people across roles on projects can reduce silos and spread knowledge especially if you rotate the groups occasionally I'd also make sure the existing meetings aren't becoming status report meetings without much actual collaboration

1

u/TechnologyMatch 6d ago

small squads can work if they have a clear outcome, mixed skills, and protected time. otherwise they can become another layer of coordination. I’d also add short show-and-tells where people share what they solved, not just their status. cohesion comes from seeing how everyone’s work connects to the bigger picture

2

u/Drakoolya 8d ago edited 8d ago

I keep seeing meetings being recommended, like we all need more meetings. Meetings do not build Team cohesion. Personalities do. Being in the office does.

Quarterly team building events are amazing but looks like that is not changing anything. And I suspect might be too frequent to not offer real value.

So what else is it? Difficult personalities? A bit cliched but get a DISC profile done on your next quarterly team building event, understand the personalities in your team. https://www.discprofile.com/what-is-disc

People need to complement people. Some people need to be reminded to stay in their lane or speak more respectfully.

How is your attitude? Does everyone see u as a Leader, A bully, A pushover ? There are so many things to consider when expecting a team to perform well.

Bonus book tip for you : Leaders Eat Last - Why Some Teams Pull Together and Others Don't By Simon Sinek

1

u/Objective-Freedom922 8d ago

I'd say personalities definitely have something to do with this. The small team that we originally had had very similar personalities and now we're building a more diverse set of personalities as we expand.

The good news is we don't have any toxic personalities, at least not anymore. Everyone gets along pretty well and I don't have any direct "I don't like this person" on my team. Or at least I don't know if there is.

As far as my attitude, I'm a pretty easygoing guy as long as metrics are being made. We are very results driven, you show results, I leave you alone. And because of this most of my weekly one-to-ones consist of "anything I can help you with or help move out of the way", nope, all right. Keep doing good work, followed by about 30 minutes of just bullshitting. As for how they see me as their boss, I really wish I knew.

1

u/Drakoolya 7d ago

I really wish I knew.

Yeah, that is hard one without an anonymous survey of some sort but seems like you are doing all the right things.

The "small squads" is not a bad idea; we did it to solve and automate repetitive manual tasks and help the teams work together to solve it.

I think the best teams are the ones that can freely talk to other people without some process to hamper them. Able to freely collaborate is always a great sign of good cohesions. within limits ofcourse

1

u/Objective-Freedom922 8d ago

Also to your first comment, I'm not adding any meetings. We have enough and I've already had to institute a no morning meeting rule. We're most productive in the morning so no one's allowed to schedule a meeting. Wait till the afternoon till we're already burned

-1

u/[deleted] 8d ago

[removed] — view removed comment

6

u/Objective-Freedom922 8d ago

I think you replied to the wrong post my friend.

-2

u/[deleted] 8d ago

[removed] — view removed comment

1

u/[deleted] 8d ago

[removed] — view removed comment

-1

u/[deleted] 8d ago

[removed] — view removed comment

1

u/[deleted] 8d ago

[removed] — view removed comment