getting stuff done
leadership principles and learnings from my experiences working in a variety of teams
Over the last few years, I’ve had the experience of working on a wide variety of teams focusing on several disciplines including dance, venture capital, event planning, software engineering, and more. Even across dramatically different domains, I’ve found that effective execution in all kinds of teams is attainable for everyone by applying the same set of leadership and operational principles. This post attempts to distill my learning surrounding leadership and teamwork into a core set of ideas.
Before jumping into my principles and learnings, I want to start by explaining how I evaluate effective execution. There are two main things I look at:
Outcomes - I know, fairly obvious. The key point I want to make here is that outcomes encompass both team goals and individual expectations/desires (sometimes which go unspoken). I view the experience of being on the team as just as important (if not more important) than the attainment of the desired team goals. Granted, they generally go hand in hand (team success typically makes the experience of being on the team better), but I had a distinct experience that proves this isn’t always the case. During my sophomore year of college, I led my dance team to the national competition (through a combination of insane luck and grit), but I don’t view my leadership that year as effective. The process was riddled with fear, doubt, and anxiety, and I largely don’t maintain relationships with anyone on that team anymore, which feels odd considering what we achieved together and the amount of time we spent together. Given the way I led and the team norms I played a part in establishing, this outcome isn’t altogether surprising. Only through maturing and developing in my leadership have I learned to not tunnel vision on team outcomes and successes at the cost of the experience of working together.
Efficient use of resources - The ideal goal is to allocate the right amount of time, effort, and people for the outcome that you desire. I think time is a resource that few people talk about. For example, I think it’s less important to arrive at the “perfect” decision or arrive at the “perfect” outcome than it is to spend the correct amount of time on something that sustains team momentum and prevents other priorities from being derailed. You’ll probably find that you need less of these resources than you think; the most effective leadership can create an outcome greater than the sum of its parts.
A lot of this probably feels self-evident. And it generally is! I think most people intuitively know how high-performing teams operate. The difficulty comes in not only recognizing when your team is slipping or having the self-awareness to see when you’re off, but also knowing what to do to correct it. Those things come with experience and intuition.
A lot of this is also reflective of my broader leadership style. My default mode of operation is to move fast, break things, fail, and learn faster. I’m not afraid to make mistakes in the name of experimentation, speed, and innovation, and this attitude brings out the best in me and my teams. This attitude bleeds into every one of the ideas I’ve laid out.
Let’s get into it.
Execution
This section is about general principles I have for actually doing the work.
1. Define criteria for success
Misalignment of expectations is the cause of an unbelievable amount of time wastage and frustration. There are two parts to this:
Alignment on team criteria for success - Every piece of work that a team does has to have a purpose in driving towards a desired outcome. I’ve found that teams operate best when it’s very clear what that outcome is and how each piece of work is moving toward that outcome. It helps each individual know how to course correct on their own because they are fully clear on what that target is.
Alignment on individual criteria for success - Every individual should know exactly what the expectations are for the work they’re doing and how it’s supposed to look / function. There are few situations more frustrating than when an individual thinks they’ve done things correctly, but their work isn’t in line with what their leader expected or had in mind, causing lots of time spent on rework. It’s annoying for everyone involved.
Software engineering is a good example. Good, mature organizations have very strict and structured processes for how they add code and features to their products, and every engineer typically has a clear understanding of the work they need to produce for their code to get incorporated. It’s been fun watching PrizePicks mature as an organization; when I joined and was one of just a handful of engineers contributing to our codebase, there were not many checks and processes that had to occur. Now, we have a much more structured and diligent process, and every engineer knows what to do. For the most part.
I’ve also seen this done well at PrizePicks in our use of experiment documentation. To run a successful experiment, there are many things you have to get right - communication with relevant stakeholders, adding in the relevant analytics you need to study, technically setting up the experiment in the correct way, and so on. We’ve done a great job of ensuring that we do the work to set up the experiment the correct way so that we’re not stuck with bad data and useless experiment results later. Everyone is very clear and aligned on what needs to be done to pull off a good experiment.
There are also several times I’ve experienced this being done poorly. One good example is my leadership with Legends. When onboarding the team, I hadn’t communicated to them that feedback exchange and written updates and documentation were expectations of everyone on board. Now, it’s really difficult to get consistent feedback from board members. The responsibility is mine; it was never established as a core expectation. Another time that I could have improved was during my time as a captain of my dance team. I was often frustrated when we weren’t making as much progress between practices as I thought we should’ve been; I implored everyone to put some time outside of practice to improve, but it seemed like everyone was constantly forgetting what they had worked on. I could’ve done a better job of explaining exactly what I expected people to do between practices to smoothen out the process and minimize frustration.
2. Plan work before projects start
Projects go much more smoothly when everyone involved has a really clear understanding of exactly what the project is going to consist of and what their role entails. This is because it’s extremely hard to adjust the scope after the project has already started. People build expectations and create routines based on what is initially communicated, and it’s hard to get people to change on the fly once you’re already underway.
For the planning to be useful, it needs to consist of project bounds (what’s included and not included in the scope, how much effort are we going to put into it, etc.) and ownership (what groups of people are involved, who are the relevant stakeholders, who are the key decision-makers, etc.)
For this to be done effectively, it’s easiest if leaders have a good domain understanding so that they can be as precise and accurate in creating a good plan. Sadly, this is rarely the case. The best leaders will still be transparent and aware enough to communicate to the team where their blind spots are and where the unknowns lie in their plan so that the team can effectively problem-solve together.
I’ve experienced this with Legends firsthand. When I onboarded the team, my goal was to get people started on projects immediately so that they could get comfortable working together and so that we could build some momentum as a team. I hoped that once we had built momentum, we’d be able to assess our bandwidth and tackle more ambitious projects. We never really got to the second part; as soon as we started, even though we had many conversations about things that we wanted to do, it was impossible to prioritize those other things over the work that was already underway, no matter how much additional bandwidth we had. I would love to go back and commit to things that I thought were attainable before diving into the work.
3. Have a single decision maker
Leadership groups are a bad idea for many reasons:
They’re subject to group decision-making biases - when 3+ people have to come to a consensus on a decision, so many group decision-making biases come into play including groupthink, silent majority, etc. No matter how communicative your group is, it’s impossible to avoid these dynamics, and they often not only lead to bad decisions being made but also create resentment within the leadership group.
They kill speed - if you asked a board to approve funding or reject funding for a new nuclear power plant, a new bike shed, and snacks for the office, the discussion over the power plant would take 1% of the time, the discussion of a bike shed would take 10% of the time, and the discussion about office snacks would take the rest even though the nuclear power plant discussion is the most significant. This is because when discussing things as a group, the discussion topics that take the most time are the ones that are most trivial and least complex because those are the things that everyone can chime in on. Just because something can be discussed doesn’t mean it should.
They kill innovation - if you asked a group of friends to pick 2 flavors of ice cream to have as a group and 1 kind of pizza, they’d pick chocolate and vanilla ice cream and cheese pizza. Decisions with several people involved typically end up in the most bland option. To try something new and unique, you have to align as a team to experiment, which runs counter to the idea of an experiment to begin with. In effect, leadership groups typically end up acting as boring, risk-averse managers.
They allow people to hide from accountability - people and organizations grow when there’s ownership and accountability taken over decisions. When groups of people have to take accountability, it’s very hard to identify where the mistake happened and how to learn and grow. It also can create resentment when individual people are allowed to hide their mistakes and not take ownership over something because a group of people was involved.
To avoid this, when any kind of decision has to be made, I will always advocate for one person to have the final say. It has some dangers of its own, but as I mentioned above, I’m an action-oriented guy; I’d much rather move and take action than go through the process of reaching a group consensus. Organizations that prioritize consensus over action are rarely innovative and typically spend a whole lot of time doing a whole lot of nothing.
4. Avoid planning hell
One of my biggest pet peeves is when groups spend more time discussing something than actually doing it. It drives me insane. There is no sense in spending an indefinite amount of time trying to create the perfect plan. The only thing that’s ever certain is that things will not go according to plan. The best way to plan is to identify the knowns and the unknowns and then create a strategy to handle the unknowns (collect data, do scenario planning, etc.)
If the unknowns are still too large to create a plan and take action, then just run a small experiment. You need some way to collect at least some data that will help guide you, and the experiment will give you at least a little more information to help you decide whether or not the project is worth pursuing.
There is zero value in discussing the same information over and over again with the hope that a perfect plan will appear.
One thing that we’ve done well at PrizePicks to build momentum on our experimentation roadmap is using an Impact, Confidence, and Ease matrix. We rate all of our ideas along those attributes, multiply the scores, and get to work on the ones that have the highest total. It avoids planning paralysis and gets us moving.
Another success story is with the development of the Legends App, which we just launched this year. One option would have been to survey the community to gauge the need for an app, collect data about which features to prioritize, and work with a different group to generate potential wireframes for the app. We chose a different route; we were convinced an app would add value to the community, so we just got to work building a minimum viable product with basic features and a basic wireframe, and we published it. 4 weeks later, we’re at 2k+ downloads, far surpassing our expectations. All because we just got moving.
5. Constantly self-assess
The only way to improve your ability to execute is to constantly self-assess and learn. No leader or team is ever perfect, but the best teams can get closer and closer by habitually self-assessing and course-correcting. Some of my favorite ways to do so are:
Decision logs - Every time you make a decision, write down both the decision rationale as well as your hypothesis for the reason the decision will fail if it does. Once you’re at an outcome point when you can reassess, look back on your decision rationale and identify your blind spots, what you missed, and how you’d improve your decision-making process going forward. Building a habit of doing this will build your intuition and supercharge your pace of learning and growing.
Retrospectives - Make it a habit (whether it’s biweekly, monthly, quarterly, etc.) to revisit your current team processes and norms and how aligned they are to the team’s desired outcomes. You never want to reach an inflection point where you’re forced to make changes as a result of something bad happening. Scheduling recurring retrospectives will help you stay on course and be proactive about any issues that may arise.
1:1s - I think 1:1s are essential for leaders to stay connected with everyone on their team. As a leader, I believe you have a great responsibility towards your team, and one of the ways you show that is by taking time for everyone individually to build trust, exchange feedback, and develop a relationship. I prefer more frequent 1:1s (both as a leader and as an individual team member) to ensure I’m connected. The frequency depends on the situation. At PrizePicks, I have biweekly 1:1s with my manager, and that’s been a great cadence. At Legends, I’ve had them about once every 2 months with my teammates. I wouldn’t be opposed to having more frequent 1:1s, but this generally has been a good cadence.
6. Be very intentional when adding people to your team
It’s a lot of effort adding people to a team:
Onboarding - during the onboarding process, new team members are essentially taking away resources from the full team because they require time from existing team members for knowledge transfer and training.
Additional communication requirement - adding another person adds another node to a communication matrix that leaders have to manage. Regardless of how individually talented the new team member is, every new member increases the proportion of overall team time spent communicating and decreases the overall team time spent working. You just have to make sure that their impact and value exceed the amount of additional communication / managerial overhead they’ll require.
Risk to team culture - if your current team is in a great rhythm and has a great culture, every additional team member becomes a slight risk; you don’t know how the culture will change and how long it’ll take to get back into rhythm. While most great team cultures should be able to survive personnel changes and team member additions, there are also many stories of team cultures getting destroyed as a team expands. The internet is littered with many startups having this story. Scaling is hard.
You obviously need team members for a team to function. My general principle is just to keep teams smaller if you can.
With Legends, I’ve felt the challenges of having a larger team. Each committee is roughly 3-4 people, so a meeting including just 2 committees and leadership would require 10+ people. It’s not only a pain to schedule, but it’s impossible to facilitate. This has caused cross-committee collaboration to be very difficult this year.
Communication
This section is about general principles around sharing information.
1. Communicate visibly
Every team member and leader should be in the habit of communicating frequently with one another and in highly visible channels.
It saves time - if you’re proactive and forthcoming in sharing information, people don’t have to spend time chasing you for answers. It also gives people something to reference.
It builds a culture of collaboration - teams that communicate openly and visibly are typically more high-powered because everyone will have a higher contextual knowledge of the business and their teammates. This supercharges team alignment and ensures everyone is marching in lockstep.
The best communication is honest and open. It’s healthy to share bad news, blockers, delays, etc. It’s always better to be proactive in sharing this information because it not only builds trust, but it gives your teammates time to react.
2. Be transparent
While there’s something to be said about not overloading people with information, I operate on the principle of sharing everything unless it’s confidential as opposed to only sharing information that people need to know for what they’re working on. I think it’s a good habit; you’ll get feedback from a wider variety of stakeholders, and even if the information won’t directly help with work, it’ll build loyalty, trust, and overall domain knowledge.
3. Build a culture of documentation
Documentation is essential for many reasons:
Prevents information from being siloed - there’s a huge risk of information loss whenever there are things that only certain people know. If they happen to leave, that’s a disaster. Additionally, those people will continuously get bombarded with questions preventing them from actually focusing on their own work. I’ve experienced this at PrizePicks; I’m the subject matter expert on our experimentation platform, and I often get questions from new engineers asking to get onboarded onto the platform. It’s been a constant agenda item of mine to build better documentation and overcommunicate with the team.
Helps audit processes and decisions - when things are written down, it is much easier to identify oversights and opportunities for improvement. Even the process of writing documentation alone often makes the next steps clear.
Empowers teammates - onboarding people onto a team is a lengthy process, especially when the team has been operating for some time. Effective documentation speeds up this process substantially, helping them quickly become contributing members. Additionally, documentation is helpful for people already on the team who are looking for further context or information on certain topics. They’re empowered to get themselves up to speed instead of being dependent on someone else to take time and educate them.
Culture
This section refers to the traits and mindsets of both individuals on the team and the team overall.
1. Give me solutions, not problems
Very few things make my blood boil more than people who only point out problems with decisions, approaches, processes, etc. without offering solutions. There are always problems with everything; nothing is ever perfect. Fixating on the problems is not only discouraging but it limits creative problem-solving. This is especially true during brainstorming sessions; when people are offering unpolished ideas, the worst thing that you can do is criticize or point out problems because it disincentivizes people from sharing and it shifts the tone of the conversation to a creative and innovative one to a critical and evaluative one. There’s a time and place for that, but it’s typically reserved for retrospectives and planning.
Regardless, on every team that I build, I want a team of people who will pair every problem they identify with a solution.
2. Have a bias for action
If you’ve read up to this point, this is self-evident from everything I’ve already said. If I’m on a team, I’m on it to do things, experiment, and learn. I want my team to include others who feel the same way; who don’t let fear of imperfection or failure deter them from trying something new.
3. Be intentional about meetings
Meetings are sacred; especially now, during a remote-heavy culture, we have less face-to-face time with the people that we work with, so I view the little synchronous time that we do get as sacred. It plays such an important role in building a good team dynamic. Here are two principles I abide by for meetings:
Do the prep work - every meeting should have an agenda and some pre-work for the meeting facilitators. Everyone should be clear on why they’re hopping on call and what the purpose of the meeting is. This way, you ensure that you’re respecting people’s time and building great energy during the time that you share.
Slash unnecessary meetings - if there are meetings simply centered on information sharing, I will advocate for slashing them. It’s so frustrating when you hop off a call with the feeling that you didn’t need to be on call for this; it kills energy in a team. The goal should be to minimize this feeling as much as possible. Even if it’s more convenient to have a standing call to talk things out, I will always prefer opting for better documentation and asynchronous communication even if it takes a little more time. It’s more impactful and sets a better basis for collaboration.
4. Team norms are what you do, not what you say
It’s easy to hammer a set of principles you strive to hit, but there’s a difference between your aspiration and where you are. Team norms are built based on the behaviors that are permitted in teams and the actions that are repeatedly done. It takes a lot of self-awareness to be able to construct an accurate set of team norms that reflect the way that your current team operates.
Even though it’s hard, it’s really important to do this! Just like you have retrospectives with your actual work processes, it’s crucial to have culture retrospectives to ensure that you’re building the environment that you want to build. This has been the greatest area of growth that I’ve seen across pretty much every organization that I’ve worked in.
5. It’s not that deep
Just like everything else in life, nothing you do while working on projects is ever that deep. My favorite teams to work on are teams where people recognize that nothing is personal and can balance focus and intensity with playfulness and joy, not taking themselves too seriously. This is something I strive hard to cultivate in every team I’m on.
There you have it; my core set of leadership principles I strive to apply across every domain that I work in. While it’s very reflective of who I am as a person and as a leader, I have no doubts that years down the line, I’ll have a different set of principles as I continue to grow and mature. I’m very excited to see the changes.
I hope you found this valuable! I’d love to hear principles that stood out to you, things that resonated with you, and especially things that you disagree with. My experience is limited and my blind spots are large.