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:

• Great clarity on the mission, which was investment outperformance. 
• Extensive efforts to measure and track investment performance. (I want to say we started with an advantage, because investment performance is quantifiable in a way that lots of desirable outputs are not, but even within the investment industry, the level of focus on goal is very variable. One company I worked for was so bad that my team literally never had a discussion about our investment performance even though it should be the number one mission-critical item.)
• Thinking systematically about incentive structures. There was an investment team (including me), incentivised to focus on investment performance. We were not incentivised to focus on general company profitability, client satisfaction metrics, or other genuinely important stuff. We had a job, we were incentivised to do that job. There were other people incentivised to focus on various other things and make sure other jobs got done. (Importantly relevant: these jobs were separable. My team wasn't picking up the phone to clients, so we didn't need to have incentives about that. The actual client-relations team weren't picking the investment portfolio. Etc.)
• Sensible design of the work environment. It was an open-plan office, but we had our own floor away from distractions like people yelling into phones all day. 
• Limited number of meetings, clear purpose for each meeting we had.
• Hiring by the team doing the job. Ten years on, I literally can't remember if we had a separate HR function. I think we just had an admin team for payroll and stuff. But the somewhat limited hiring (maybe 1 person per year on an 8-ish person team) was done by the team, who knew what technical competence looked like and who could detect bullshit.

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:

• Guardrail the conversation at the risk of being perceived as rude - this is one of the valuable implicit lessons I learned  from my lead and mentor at the time who is now a CEO of quite big company - People are just people and every once in a while they dive too deep into technical details, answer the wrong question or the one that's loosely related to it, try to plan too far ahead, spend too much time on debating extreme edge cases with non-severe outcomes, jump into implementation without understanding the big picture. These and other rabit holes can really hijack the conversation and disrupt meetings without anyone even noticing. What I think is more common though, people notice but are too polite to call out the crap when they see it.  Just say it, interrupt even mid-sentence, propose to discuss it at a different time if necessary and propose what to focus on instead. I can imagine this advice has some limitations, e.g. you're in some strictly hierarchical setting or people in the team have egos to protect but I can guarantee that in most cases people just admit they derailed from the objective and move forward, regardless of their position or title. In one of my teams I was quite anxious doing that at the beginning but soon it was normalized and other people started doing it as well.

• 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.