Good team dynamics

Published

April 5, 2023

I’ve worked with dozens of teams now, and I wanted to share some patterns I’ve noticed. These are things worth emulating. They’re first-principles worth strengthening inside your team. Expect a pt 2 “bad team dynamics” at some point.

Push decision making downwards: this has become a common management sentiment, but it’s one of those platitudes that I don’t think is actually implemented well. Pushing decision making downwards still requires:

Regularly pushing information upwards: this may take the form of an exec review meeting or product council (like we did one place I worked). This keeps everyone informed and most importantly let’s people with big titles feel like they influenced the decision and have all the same information as you so they can come to the same decision you did.
Seek more clarity, more detail: whether it’s execs above you or ICs next to or below you, anyone should feel comfortable asking for more information or more clarity on how you made the decision you made. As long as this isn’t hostile and as long as folks don’t disagree with the data you showed (eg: “I think you talked to the wrong customers”) then this is productive.
They must be problems: starting work without pulling forward the problem you’re trying to solve leads to futile execution or “feature factory” strategy. Aligning on the problem to solve is typically the most agreeable common ground you’ll ever find when making a decision.

Data informed: there are probably industries where you must entirely be data-driven and completely abandon your sense of inductive reasoning, but I haven’t found them yet. Data-driven teams often use data and SQL as a cudgel for sensible context. Good data practices include:

Different types of metrics: picking the wrong metric to measure success is almost as bad as picking the wrong thing to build or work on. Different types of metrics serve different purposes and most people, even executives, will look at not hitting your metrics as failure rather than an indicator of progress.
North star metrics: this is a hot topic, and folks like John Cutler have written a lot about it, so all I’ll add is that North Star Metrics should have a very short feedback loop so they can inform the day to day motivations and focus of your team. A bad North star metric is overly reactive or lags by weeks or months. If you do work towards your NSM, you should see its effects in less than a week. Ideally 2 to 4 days.
Business KPIs: these often should not be north star metrics. KPIs could include “sales pipeline generated” or “platform SLA”. These are difficult NSMs because they take weeks or months (or, ugh, quarters) to see effects. These are important to track but they shouldn’t be your success criteria. Rather, frame KPIs as guiding policy for making a decision. Rather than “add $1m to sales pipeline by shipping X feature” say something like “ship X so that so we can support the sales team’s efforts to build pipeline”. Eventually, you should retro on whether this initiative had the intended effect.
Key Results (OKR land): key results are useful for bridging the gap between realtime North Star Metrics and long-term evergreen Business KPIs. Ideally, set a key result to fundamentally change something about your team, achieve it, and never revisit it again. Let’s say you’re building a new business line, set a key result like “Add X new customers at Y spend by Z date” this is a SMART goal and may feel like a KPI but it isn’t long lived.
One last note, you should have a NSM, KPIs, and some Key Results per big body of work your team undertakes. This shouldn’t feel like a chore but rather a framework for reliably making the case for your work. If you find yourself spending a lot of time arguing about the best metric that’s fantastic. Often metrics are a great way of “working backwards” and driving alignment. Beware the singular metric to orient your team—often these are honeypots for org disfunction.

Heads down work: disclaimer, I’ve never hired an executive, but I’ve watched enough of them come and go to pick up on good/bad behaviors. Oh, this also absolutely applies to everyone else—not just execs. I think most types of emotional labor (eg: white collar jobs, desk jobs, etc) require a lot of heads down work. Collaboration is great, but heads down work resists entropy and the focus and quality that flows from it is gold.

How’s your head? An early indicator of poor work performance is too little individual work-product and heads down work. This depends on the role and could mean writing docs, shipping code, designing UI, summarizing data/research, etc. At every level of the org, demand individuals contribute their own work-product—somehow.
Meetings! We’ve accepted that too many roles’ success are defined by their ability to attend meetings and politick. This is a symptom of org dysfunction and individual inefficiency. While meetings are certainly important, they should be in service of heads down work.
Flow state: if you’ve been brainwashed by meetings and zoom calls, you may find it difficult to remember what heads down work feels like. When was the last time you entered flow state at work? How regularly do you enter flow state? Chances are when you enter flow state at work you’re producing highly valuable work. This might literally be the output of docs and charts, but it also might look like you going deeper to understand or learn about a problem.

Being document driven: decisions should be written down. Teams should review artifacts of high information density to inform their observations and decisions. Humans, especially groups of them, easily forget and and documents provide inertia to reduce fickle decision making.

Thoughtfully prioritize: it’s very difficult to accurately prioritize (or scope) work without details on the stuff you’re trying to prioritize. For the people in the back, it’s very difficult to accurately prioritize (or scope) work without details on the stuff you’re trying to prioritize. Documents provide a full view of the decision, context, impact, and the why which are all vital for good decision making. I’m not going to provide a prioritization framework here other than to say—if you’re not writing it down you can’t prioritize it.
Keep it brief: humans have short attention spans and you should assume you have a more sophisticated understanding of your document than everyone else (especially stakeholders). If you assume this, then the mountain of detail that’s in your head is too much for most people. Documents that are one to two pages are best and if you really need more link out to additional docs (or have an appendix section).
Thoughts on deck: decks, powerpoints, presentations are good. They help you build a narrative and can help non-technical folks follow your train of thought more easily. Using decks is okay as long as you strike the right balance of information density. Too little information and you’re hand wavy; too much information and you’re just back to a doc but with bad page breaks. Always, have copious presenter notes and link out to supporting docs.

Matrix Reloaded: The last element of good teams is they build a sixth sense for what reacting too quickly and too slowly looks like. This varies greatly on team, industry, and market dynamics, so there isn’t a clean rule. But some thoughts include:

Don’t react so slowly you avoid talking about obvious issues: add the “sunk cost fallacy” to this bucket. If you’re armed with the right metrics, you should be able to see in 3 months or less if you’re heading in the right direction. Change takes time so don’t expect metrics or outcomes to move overnight. Conversely, don’t wait too long to see numbers move.
Don’t react so quickly you never give it a chance: it’s good to discuss threats and risks to projects but don’t assume they’ll come to fruition. If you give this FUD too much voice, you can kill the momentum of a project and not even give it a chance. Sometimes the things that shouldn’t exist are the most impactful and that takes grinding thru FUD.
Get to market quickly: a lot of these issues are fixed by quickly getting to market (to users, to stakeholders) with your solution. Once an idea is outside your brain and in the real world you suddenly opened to people’s real thoughts on what you’re building. It’s tough for customers or stakeholders to object to something that doesn’t exit. It’s easy to object to things in the abstract.
Reload: inevitably you’ll make a good decision that will be paired with a bad outcome or make a bad decision and see a bad outcome. The best thing you can do is GOTO Step #1.

Hardcore mode: think back on decisions you’ve made recently. Are any of them bad decisions that had a good outcome? This is the anti-pattern that’s most dangerous. If orgs pattern recognize bad decisions with luck, you build structural weakness that won’t help you get through tough times.

Wow that was a lot! Thanks for listening. I’m available for feedback or consulting at [email protected].