> This becomes very problematic when hypergrowth companies are desperate to recruit so they start hiring friends of current employees via referral. When you hire groups of people who have a history together, they tend to stick together in the new org and resist integrating into the company culture. They want to isolate themselves and operate like they did a few years back at a previous company. You end up with a lot of pockets of people trying to operate as independent teams with their own work culture.

I have seen this at a company I've worked at that experienced rapid growth. The strategy they employed was Split and Absorb: first they substantially increased the size of middle management such that the manager-to-IC ratio was something like 2:1. Next each manager was given the ability to Absorb, and they had a lot of time available to them for hiring and onboarding due to the fact that they were managing maybe 3 people each.

In practice I saw this start to fail almost immediately for multiple reasons. First, there began to be a cultural divide between the people who were hired organically (who were typically at the bottom of the ladder) and middle management (who were typically friends from previous jobs). There were communication breakdowns as more management discussions were being done in private channels between friends instead of with the teams. Lastly it was hard for people at the bottom to bring up concerns; even if every IC on a team agreed a problem needed to be solved, there were only 2 of you, but your manager would discuss it with their 10 friends and that made it hard for the people at the bottom to have their perspective heard in an equal light.

> It takes some work to break up those cliques and fold them back in.

How do you actually do this? Who at a company should be taking these steps?

In theory I'm not exactly sure where it went wrong. If you're going huge amounts of time without any applicants then you can't avoid bringing in referrals, and management might even prefer for their friends to be brought into management roles due to alignment in values and culture. For the clique problem, I'm not entirely sure what an organization can do to avoid that. It's unrealistic in my opinion to assume referrals will always stay objective about everything that involves their friends, and if management has this problem then who are the Watchmen who will address that problem?

I'm not a religious person, but the phrase "the devil makes work for idle hands" seems to apply. If you give teams extra time, less than desirable behavior ensues.

> It's too easy to misjudge who's accomplishing what if your only input is observing who speaks up the most in meetings, who's the most talkative in Slack, or who spends the most time putting together presentations.

Also if the team is split over timezones and management are only in one of those zones. I've seen members of a remote team get none of the praise nor promotion while a loud person in the right office makes it their business to sell their own brand, and gets promoted continually. I've seen that person get promoted into management, and completely fail to grow the careers of their team members to the point where those team members just leave. From the perspective of higher ups, none of this information makes it out of the team event horizon.

> It's too easy to misjudge who's accomplishing what if your only input is observing who speaks up the most in meetings, who's the most talkative in Slack, or who spends the most time putting together presentations.

I would assume that it is the direct manager of the team that makes that decision or at the very least provides input.

And if you are managing the team and don't know who is accomplishing what, then you are in a whole lot more trouble than just a problem of choosing wrong strategy of splitting the team.

Two friends and I just got hired together at a new company. We’re in the same geo while the rest of the team is remote, and the bulk of the company is not in the us. You’re second paragraph is very true! If I’m new and notice an odd workflow I would normally just adjust, but now I can go into our slack group and commiserate with my friends.

It doesn’t help that most of the company is Polish and their culture comes off as very rude to Americans :)

> It doesn’t help that most of the company is Polish and their culture comes off as very rude to Americans :)

I've always worked with Americans, and they struck me as very sensitive, whereas we tend to be much more direct. I adapted, and then I worked with Canadians, to whom my American style was seen as boorishly coarse.

Am American, can confirm. Would much rather work with the Polish, Indian, and Russian contractors I've worked with than our domestic snowflakes.

> It's too easy to misjudge who's accomplishing what if your only input is observing who speaks up the most in meetings, who's the most talkative in Slack, or who spends the most time putting together presentations. Visibility metrics don't always correlate well to actual productivity.

Interesting. As a visible person, I see the opposite of this.

I'm currently in an IC-ish role. In this role, I am the one who speaks most in meetings, most talkative in company chat compared with the rest of my team (they rarely write anything, weeks can go by), and spend more time putting together documentation and reports (even when the whole team is asked to in theory, it seems to fall on me).

This makes me the most visible, but it's having an undesirable effect for me:

I'm highly productive in the sense that I've closed several longstanding issues that were considered hard to solve and lingered for years, and will continue to do that with all major issues in the project. I'm confident it's the right approach, because of the project's history and some consistently missing or broken functionality, that if I didn't do this, the product would be an endless tarpit of not-quite-working enough for end users to actually choose it.

But my way of doing this produces fewer PRs than the rest of my team, noticably so. As a review put it, "their productivity is measured more in quality than quantity". That's because I think hard about what the actual strategic goals are, figure out solutions to problems everyone else seems to consistently skip over even when they are long-term showstoppers, and actually put together a working solution.

Some of these are just clever bugfixes in poorly understood areas. But in other areas you could say I'm re-architecting and developing new techniques, figuring out parts that work well together and how. But I'm definitely not the parochial "architecture astronaught": My hands are dirty with plenty of coding, and to be honest I'm not sure there is another way. In my experience some techniques used have to be demonstrated in working code before people will recognise that they work or that they provide an advantage, e.g. in significant algorithmic complexity, or changing something from taking days to a few minutes, or reducing a terabyte of storage to a hundred gigabytes. Talking about it isn't enough and short write-ups don't convince either. A thorough writeup would be a lot of work itself (eg. like an academic paper is a lot of work), and would be considered a waste of time by others I think, and probably ignored as acedemic papers tend to be anyway. It should be done after, rather than before, a working implementation.

Some things, you can spend weeks talking about and nobody seems to pick up the real point. Or you can ship a surprisingly short PR that makes something work that didn't before, and it's a breakthrough. And management might see it as a mere bugfix, or they might recognise why it took time and is valuable.

It doesn't help that we are all in different timezones; it's fully remote, and the team operates in a very atomised way, hardly talking except in management meetings. I hope to change this eventually but for now I need to work on shipping technical solutions to major areas that I don't think will be solved without me doing so.

I'd love to be do this more collaboratively. But at least for now, my teammates don't seem to have the relevant knowledge and understanding to help effectively with the parts I'm working on, and one doesn't seem to want to be helpful anyway. And, how to say this - they very rarely communicate except to comment on PRs and in management-led meetings. One set up this obstacle a month after I joined: "You can't expect a new person to know what needs doing on a project" (that means me), they want tasks from "people who have worked for years with the project", which makes collaborating in the same areas a real time sink with respect to progress.

So back to the point of gauging who's actually doing the work:

I'm highly productive in one sense: I'm making transformative changes that will help the company and its product achieve their stated goals, and I'd go a little further in this instance and say I don't think they would achieve it without someone on the team taking my approach. That's why I'm doing it. I'm definitely conscientious and working hard. The changes are visible: The effects can be seen and enjoyed as well as making the product more effective.

But in another sense, I'm gauged as not particularly productive for two reasons: I'm most visible (because I talk in meetings, etc.), and I ship fewer PRs than others on the team.

My teammates ship something more often. It's good that they do, as to be honest one of them often appears not to understand the context of the component they are working on (from basic questions in management meetings), but gives a good story of working hard and shipping something. Their work isn't wasted, it will eventually be used, but someone will still have to develop it further to use it.

It's interesting to see that by me being more visible in explaining what I'm working on and why, there ends up being more attention on basic metrics of my output in management meetings. More time is spent by management asking why I haven't produced X and Y, and that I "need" to ship PRs more often (I'm struggling to figure out how to do this effectively given what I'm working on, though). In the same meetings when my teammates also haven't shipped anything, this doesn't seem to get much attention. I imagine this is almost entirely due to my talks setting high expectations, and the management's idea of what they are looking to see.

Politically I think I'd be more secure just staying quiet, and churning out more basic bugfixes and minor features, knowing that the project is kind of doomed due to key unsolved technical issues, instead of dealing with those issues and explaining how the solutions work.

So who "doing the work"? I think it depends on what you decide productive means. I think it's valid to decide that I'm not productive from a certain point of view, but it's also valid to decide that I'm highly productive from another point of view. My own take on it is I'm doing the right thing for the company and the project, specifically in terms of management's stated goals for the project, but that it's not well understood or particularly visible to others at this point in the trajectory which means I'm taking a personal risk doing so. (I don't think it's much of a project risk (except for bus factor). And if our team wasn't so atomised, or if we had similar knowledge and understanding, there wouldn't be the bus factor either, but we have what we have and changing it will have to wait.)

I feel this. It is hard to be a quality-first person because the same kinds of coworkers and situations that create those thorny issues can’t recognize good solutions. Even a manager who is like you has to rely on your word and that can be hard to do proactively over long periods of time.

A frank conversation and/or a job search might be in order.

Sounds like you need a champion in management snd preferably skip-level buy-in as well.

I get the sense you and I would work very well together