When I started at the company I currently work for, we had about 60 individuals in the department. That's including management, QA, Developers, etc. When someone new joined the company, it was pretty easy to at least know who they were and what role they filled. Often we got to know them pretty well within a few weeks of them starting.
Since then, the company has grown. We've added new roles, adopted the Scaled Agile Framework, and grown our existing teams. Now we're just north of 100 individuals in the department. When someone new starts, those outside the team they join might not know whether they're developers or quality assurance or product owner or scrum master for a few weeks at least. It seems to be harder to get to know our coworkers now.
This seeming decline in cohesion and communication has been on my mind a bit recently. I've read a few things about it and there seems to be some really cool things that other companies do to help combat this. So, I'm curious, how do you maintain team and department cohesion as you scale? What have you seen work? Do you think it's important to have cohesion outside of individual teams?
Top comments (5)
We are currently pretty small, so I don't know for sure how we will do, but I can tell you how we are approaching it.
We're not putting off developing practices that we could put off at our current size
That means we have an employee handbook even though we don't really need one. That means we have explicit policies we don't need right now. We have explicit team activities that we plan for even though at our size we could do it in a more ad hoc way.
We try to make time for company-wide presentations even though our that seems a little overly-formal at our size. We are building habits for the future.
It can be hard to stop and breathe when you're currently trying to get things done and get over the current hump, but plan for the success-case of growth (if that's the success case) and don't let it catch you off guard.
Good thoughts. Thank you for sharing. That's great to hear you're doing that. I interviewed at a small company that was putting off some best practices (whether they realized it or not). I could see where they were at and the inevitable issues they'd have to face if they didn't change. Even though they didn't need some things now, they'd be better equipped by doing some of those things now rather than waiting until they needed them.
I think one thing that's really disrupted us (mainly in good ways) is adopting the Scaled Agile Framework. It's helped a lot in certain ways but we're still trying to figure out a few things such as department cohesion and communication. Even with that major change, I feel like the solutions are likely very simple.
I'd say we're also "putting off some best practices", it's a tug-of-war between the right solution and the good enough solution. But planning for growth without slowing down the current process is the name of the game.
It helps when you have diversity of thought among leadership, but that they are willing to get along and hear each other out. Jess and I are constantly debating management practices. I'm usually on the "more freedom/more random creativity" and she's usually on the "more process" side of things, but we engage the debate and always keep an eye towards the future.
We also have a few abstract models we look up to. We love a lot of Stack Overflow's mantras and try to establish a healthy remote-first culture, even as our whole team is currently based in New York City. We also try to read a lot of the same books to get guidance. How Google Works gave us a lot of ideas that we think apply well now as well as in the future. It's important to also discuss the parts you don't agree with, because these books always have an element of narrative fallacy or hero-worship in them.
Conversations like this help too. I'm definitely going to check out Scaled Agile Framework.
Totally agree on selectively putting off some best practices. I think every company needs to do that no matter the size or market they're in. That's good to hear you have a good culture where things can be debated and challenged and that you're able to reach consensus. That's not always easy. Open cultures like that can be hard to find. And thanks for the book recommendation. I'll have to check that out.
Conversations like this definitely help. I also enjoy receiving the Software Lead Weekly newsletter and discussing it with my coworkers. There's been a lot of good stuff in there such as this one on communication at scale. A medium like dev.to is also a great place to hear from others in the industry and get a glimpse into other environments.
Whenever someone new joins our division, we get a mass email with the person's name, role in their team and some baseline info (moved from Arizona, loves Hockey, has 2 kids). Since we're supposed to do inter-team communication through our ticketing system, I tend to not meet people face-to-face unless they pick up my ticket or we're assigned to the same project. I like it.