Really good question, thank you. I look forward to hearing more answers.
For me, it was working as an investment analyst - sorry, I'm going to redact the company name to protect my identity. I've held roles at a few firms, but one stood out:
A lot of that would be difficult to replicate by individuals, since it was heavily dependent on the company's CEO and senior team being ultra-focused on actually achieving outperformance and not symbolic busywork, but potentially relevant to start-up founders.
A couple of things stand out to me about the groups I was in thaalt worked better vs the ones that didnt work as well.
1 - meeting regularity. Its hard to seperate cause and effect, but groups that 'have a meeting on mondays' are way less effective than groups that 'have a meeting when there is a need to have a meeting'. The second type of group average slightly fewer meetings, but they are so much more effective. People go in knowing 'Eric found such and such a problem this morning, which means we possibly need to change the plan somehow, hence this after lunch meeting. The meeting ends when a descision on how to proceed is reached.' Instead of ' this meeting is because it is 10am on monday and it ends when everyone runs out of things to say.'
2 - People 'closer to the ground' making the final descisions. The person who is going through the data by hand, should have the final say in what analysis method to use. The person writing the code for processing the data has final say on the statistical method the code will do. If you dont have this system all kinds of dumb problems come up. The PhD student has a sense from having read all the data that the analysis is going wrong somehow, but instead of just changing method they start trying to come up with some kind of actual argument for why the method feels off, then trying to book a meeting to attempt to justify changing methods. Its slow, its bad, people are much better at seeing that something isnt working than explaining why. Doubly so, when they have already decided in their heart that the right course is to change methods, and so the meeting is asking permision to switch, not advice on whether to switch. I watched someone struggle with a simulation tool that didnt work for nearly 2 years, going back and fourth with their boss trying to get permision to try a different software package, and being repeatedly told 'but, that software always worked for me in the past'. Dumb situation. After 6 months they are no lomger trying to make it work, but trying to produce proof that it doesnt work so they can use the other software. Making them do that for another 18 months was bad management, but the manager should never have been in charge of that desicion in the first place. Obviously if you constrain people more, they are less effective.
I think all the effective tips and tricks are the downstream of the team, and especially the leadership of it, being radically focused on execution of a very clear goal. It sounds obvious and hard to vary, but there are different levels to which teams follow this meta-rule and from my experience, it's what makes or breaks the team effectiveness. Many mid and micro rules are too contextual to generalize, some are well-known and sound like truisms (because they are correct) but here's a couple of uncommon advices from my experience, all connected to "being radically focused on execution of a very clear goal" meta advice:
Execution slows down when accountability is collective - When everyone owns something, no one owns it. In the teams I'm leading, every micro and macro initiative has a singular owner. It is a contact person having the biggest context about the topic, a person responsible for moving the needle and figuring out what's the next step. It rarely means they have to complete and maintain the solution end to end but they are responsible for progressing it. This makes people feel personally accountable, give them a sense of pride and build their leadership skills.
Nobody seems to have answered yet, and this post has been on the front page for a while. This is unfortunate! I really expected at least someone to have a decent story of organizational adequacy, given that AI safety research has been---in my experience---far better organized than anything else I've been involved with.
On a micro-level, the organization of a LASR labs project vs my PhD:
LASR:
PhD:
The LASR labs team I was on was clearly a far more effective team than the research lab I'm in.
Process documentation is notoriously bad, and people are heavily disposed to working well=invisible.
I could probably talk about ways that business consultants were impressed with mistakes we didn't make at mealsquares, but we still made some big ones, and we never got big.
When I see people add a lot of value to organizations, very often it’s in the form of importing a way of doing things that worked well from some other organization that they have been involved with.
This process knowledge can take all kinds of forms, from "this is how to efficiently run a meeting, with an agenda, so everyone knows what the meeting is about and we don't waste time on extraneous maybe-tangents" to "we absolutely need to be constantly getting rapid feedback from our users" to "we need a CRM" to "exactly one person should be in charge of this project, and they must be full time", to "this is how to clarify your organizational goals and set KPIs". Often there will be some tacit knowledge component that is hard to convey without having seen the system in action.
When you’ve seen a class of problem handled really well at one org, it stands out very starkly when a different organization is struggling with that class of problem. It's very natural to adapt what you've seen work in the past to this new context.
And beyond isolated process improvements, some teams are just much more effective at whatever they're trying to do than most organizations. The way they do things overall coheres into a highly effective machine. They know how to work together to do amazing work.
In retrospect, I wish I had prioritized seeking out and trying to join highly effective teams, to collect reference experiences of groups of people working together effectively and achieving exceptional performance. I think those reference experiences would help me, today, in trying to make the organizations I work with succeed at their ambitious goals, even when those goals differ substantially from those of the orgs I'm modeling.
As a second best to that kind of direct, personal, experience, I would love to hear anecdotes about impressively effective teams that you all have first hand experience with and what it was that made them special.
I don't care what the team was doing together. An research group, a sales team, a film crew, a political campaign, a broadway production, or a startup, are all interesting, if they were exceptional at what they were doing.