- Explicitly define the [[values]], vision, and desired [[culture]] of your team.
- Define the vision to promote loosely coupled, tightly aligned teams. Then, define the strategy with [[Writing Team Key Results|great key results]].
- When coming up with a long-term vision is important to stay abstract.
- Stick to defining components and keep concepts generic (cache, [[databases]], algorithm, …). Show how the components interact.
- Define boundaries and limitations of each component.
- Work in the open and [[Documentation|document]] everything. Transparency increases understanding and reduces synchronization challenges. Emulate Open Source projects and [[Remote Jobs|remote companies]].
- Write weekly updates and share them in a common place.
- What is shipping (e.g. what is on the near horizon).
- Why is it important / what is now possible as a result / why should people care?
- How are things progressing. Any blockers?
- To make everyone more productive and happy: Make feedback loops fast. Some best practices / sensible defaults:
- Tested, automated process for new development environments.
- Automated preview environments.
- Automated code formatting.
- Templates for new projects and components.
- Mechanisms for creating test data.
- Invest in thoughtful logging.
- Create a [[Company Handbooks|handbook]] to store your [[Company Knowledge Management|company knowledge]]. Document:
- [[Processes]]. Status updates, [[Design Docs]], on-boarding docs/scripts, [[Checklist]], …
- Decisions. Context and rationale can be documented in a durable location.
- Each team should keep a changelog. The company too. ^473cb4
- Aim to confirm and log decisions to move them forward. Everything must have an URL.
- Show your work. Capture who made what decision and when, along with a detailed, but concise description of why and how that decision was made.
- Consistent changelogs also communicate new features, the value they get from your product, and your commitment to improving it.
- [[Meetings]] agendas and conclusions.
- Responsibilities. Things that aren’t your fault can still be your responsibility. If something is everyone’s job, it’s no one’s job.
- Defaults. Each thing should have a place by default, docs, issues, …
- Aim to be a completely autonomous team. Everyone should feel empower to make decisions. Those who are responsible for something must have the means and context to effect it. You build it, you run it! **The company strategy guides the team, it doesn’t tell it what to do.
- Run Automated Check-ins to share things explicitly. What are people working on, what are they planning to work on next, …
- The right way to promote people is to give them meaningful and clear goals for the organization and promote them if they hit the goals.
- If you don’t promote and communicate your work, no one else will.
- Lack of ownership is the root of all evil.
- Write postmortems after large changes. This will create [[Feedback Loops]] to guide learning about what happened and how it can be avoided next time. It’ll also help calibrate for the previous decisions.
- Do lightweight self reviews . Worst case scenario, they help you update your resume.
- Make time to pay technical debt. [[Systems]] evolve organically over time and might get stuck on a local maximum. Alternative abstractions/designs might be better to continue progressing! There are two kinds of tech debt:
- Things you haven’t built yet.
- Things you shouldn’t have built that way.
- Accidental complexity is a sum of all the shortcuts you have taken. Complexity attracts more complexity and compounds in a non-linear way. Every shortcut you take is an invitation to more shortcuts elsewhere.
- When the context changes a lot, you can use the blue tape technique to notice what is wrong with it:
- Notice everything that feels off.
- Make a list of everything that feels off, no matter how big or small.
- Wait a bit, like a month, but address everything.
- This translates to ideas to review, tools to try, docs you want to write up, …
- Culture should incentive people to fix things outside their area. Encourage submitting Pull Requests that might be rejected.
- Teams need slack to absorb and adapt when unexpected things come up and to prioritize the development of force multipliers (tooling and automation).
- Focus on business outcomes, not on technologies.
- When you start from a shared understanding – that you’re all doing your best you can – you can foster a compassionate working environment.
- Everyone on your team should assume that everyone else on the team is doing their best work, given their circumstances.
- Trust people with freedom. Add [[Processes]] where you need to replace some level of trust.
- Share as much context as you can.
- Times change, trends change, cultures change. Make it explicit.
- Spend time at work thinking strategically. E.g: Think about the approach you will take to address the company’s needs over the medium to long term.
- How to drive change in a team: find people who agree on the problem, start small, experiment, scale, repeat. Making big change is hard. Keeping things simple is hard.
- On the other hand, beware of changing too many things. You don’t feel the pain of things you’re not doing!
- Scale organizational efforts across a portfolio of synergistic products.
- Don’t replace prototypes with roadmaps. Encourage prototyping to learn and build confidence with different parts of your software stack.
- Ask people “when do you think you’ll get this done”, write it down and then follow up at that time. That makes teams more effective.
- Every document must have a specific goal written at the top of it.
- When building something:
- Question everything.
- Remove more than you add.
- Optimize what works.
- Shorten iteration cycles. Boyd’s Law of Iteration: speed of iteration beats quality of iteration.
- [[Automation|Automate]] and keep standards.
- Keep great global [[coordination]] and incentive local experimentation.
- Being able to run small and compounding experiments (on the product or company [[processes]] and systems) is important. Work smaller.
- Some experiments won’t work. But oftentimes it feels like it wont work when in fact you just haven’t stuck with it long enough for it to bear fruit. This is hard enough for solo experiments. For group experiments, where not just one but many people must all try a thing at once and get good at it, all it takes is a little defection to spiral into a mass exodus.
- The group with the most power determine the system that reflect and reinforce their own way of thinking. Aim for inclusion. Diversity is being invited to the party. Inclusion is being asked to dance and help organizing the party.
- Brainstorm for questions first (explore). Then find the answers (exploit).
- Strive for constructive conflict. Get people to[[Asking Questions|ask questions]]. Engage in passionate, unfiltered debate about what you need to do to succeed.
- Encourage to fail. Failing is good if the team [[Learning|learns]] from it!
- Encourage effectiveness. Find ways to free up your time.
- Communication is a central part of working in teams. Prefer [[Asynchronous Communications]], use common [[Communication|communications]] techniques and be friendly. Trust and efficient communication has a big impact on team effectiveness.
- Have a primary [[Communication]] channel.
- Use long-form [[Writing]], rather than [[Meetings]], speaking, and chatting. Speaking only helps who’s in the room, [[Writing]] helps everyone.
- Finish projects before starting more.
- Prioritize things that will compound on shipping faster.
- Constantly prioritize. Communicating with the team to make sure everyone understands the what and the why of the priorities, especially in times of change, and is aligned with clarity to move forward.
- Assign as few possible to a project. Should have an owner and a stakeholder.
- Software quality is more the result of a system designed to produce quality, and not so much the result of individual performance.
- This implies system with tests, easy development environments, CI/CD, documentation, culture, …
- Optimizing for short term speed is dangerous if you don’t allow some slack to pick up things that will make you faster in the long run.
- If you want to optimize for speed, you need an experimentation platform to track the impact of changes. Teams need to learn how to disagree and commit.
- Look for a way to decouple things as much as possible and don’t aim for perfection. Aim for eventual convergence.
- Beware of potential things that might harm your team.
- When proposing a change, add context to why is important and how it’ll impact people.
- Standards make it easy for new team members to onboard and enhance efficiency in the long run (removes micro-decisions).
- Learned helplessness can happen in a team. Two of the main reasons of this normalization of deviance:
- The team needs to follow processes that have either been externally imposed, or internally imposed but no-one remembers exactly why.
- The sheer scale and/or complexity of how things work. There is truly no-one who understands the emergent behavior of the [[Systems|system]].
- E.g: Slow boiling frog situations where existing tools have become ineffective but no one noticed.
- Act as if you might leave on short notice. Document your knowledge, long-term plans, meetings, train people around you, empower other people, delegate and keep learning!
- Write everything in plain text and in a shared place so is not lost.
- You have to put in more effort to make something appear effortless. Effortless, elegant performances are often the result of a large volume of effortful. Praise this instead of complex solutions.
- Invisible work will happen. If you’re doing it, make an effort to share and get credit for it. Build a narrative (story) for your work. Arm your manager and fight recency bias keeping track of all the things you’ve done.
- As a manager, give problems to solve, not solutions. Make sure the team knows what they’re working toward and that it has the resources needed to complete the work.
- Most software or processes should be opinionated. In increases [[Coordination|collaboration]]. Flexible processes lets everyone invent their own workflows, which eventually creates chaos as teams scale.
- As teams scale, traditional approaches to decision making force a tradeoff between transparency and efficiency.
- The easiest way to ensure everyone can understand the how and why of a decision is to adopt systems that, through their daily operation, ensure such context is automatically and readily available to those who might want it (and explicitly not only those who presently need it).
- Run 1:1s (one-on-ones). A recurring meeting with no set agenda between a manager and one of their reports. Don’t make it a status update (these should be async). Chat about anything bothering you, career growth or type work that is interesting for you. End it with actionable next steps.
- Say no a lot, up front. Distractions are anything that doesn’t help you keep your existing features running, or deliver your top priority faster. Finishing work is more important than starting it.
- As a new team member:
- Ask questions without judging. Never ever be negative about the stuff they created. It was done for a reason.
- Beware of Normalization of Deviance.
- When meeting/emailing interesting people ask if they know anyone else you can meet with. Try to expand your network with successful folks in the area/space!
- Keep a private work log. It’ll make easier for everyone to advocate what you did.
- Don’t sabotage the team!
- Nobody gets credit for fixing problems that never happened. People get credit for shipping things. Figure out how to reward and recognize people for preventing problems.
- The same practices that make great [[Large Language Models]] promts also make great practices with humans:
- Give clear instructions.
- Share relevant background info.
- Break big problems into chunks.
- Give them time to think.
- Point them to helpful tools.
- Test their work systematically.
- Make small, achievable changes rather than large risky leaps. Each step should be within the “adjacent possible” - what can be realistically accomplished.
- Prefer combining proven components in new ways over building everything from scratch.
- The overall goal is for a team to be as close to its own startup as possible, with only a handful of centralized processes.
- Never be more than six people.
- Have Accountable Person responsible for its performance - whoever is most appropriate depending on what the team is working on. This does not mean the most senior person on the team.
- Must have (1) a customer (internal or external), (2) a mission and (3) [[metrics]].
- There may be certain functions where at your current stage that don’t need a team yet.
- Each team runs its own processes. This must be done transparently.
- The team has the final call in which of its features get into production, with no need for external QA/control.
- In your first two weeks, your focus should be on understanding the business, getting to know your peers, validating expectations, and getting yourself organized so that you’re able to apply what you’ll learn in future weeks.
- There’s a real danger in thinking that what made you successful in the past will make you successful now.
- Read all the things.
- The team you’ll be working on will probably have some kind of normalized deviance. Try to understand why everything is as it is before doing any recommendations. Don’t come in with “the answers”.
- Record first impressions / friction log as you go. Beginner’s mind has real value!
- Build great relationships so you can be supported in decisions to get some early wins.
- One of the most valuable things you can do during onboarding is update/write documentation and create/update checklist of all the processes. This will help you and your team in the long run.
- Make bite-sized impact, fast.
- Every member of the team knows what they should be working on.
- Every member of the team knows what to do if they finish a task, or get blocked.
- Every member of the team has had a meaningful career conversation within the last six months.
- Every member of the team receives timely, meaningful, actionable performance feedback.
- Work that needs to get done aligns with work that is rewarded by the promotion process.
- Performance reviews never contain surprises.
- Team members are able to express ideas for new projects or changes to the way the team works.
- The team is able to give input on roadmaps and plans.
- The team is staffed adequately and work is evenly distributed.
- The team, overall, has the level of functional expertise required to do the work, and a reasonable number of stretch goals are available.
- Conflicts are resolved in a fair and respectful way.
- Diversity is represented and embraced; a broad spectrum of views are considered. Diversity is not a political slogan. It’s the basis for collective intelligence.
- Progress and set backs are regularly communicated to key stakeholders.
- When collaborative projects are completed, credit is shared among the contributors.
- Management is prediction. In order to run a team well, you need to be able to predict the outcomes of your team actions.