How To Run A Project
Lessons from contracting
One of the amazing things about contracting is that you get to see inside many different organizations and management styles. I have found that every new team I work with has a technique or system worth learning from.
Over time you gather a broad toolkit and an intuition about the types of structures that best suit a certain group of people.
I have gathered my favorite systems and frameworks for organizing a team around a project, normally focused around a piece of software or journalism.
Teams are almost always changing, and the systems that worked at the beginning of a project or team might not work when other variables change. Staying nimble, and deeply aware of the ✨vibes✨ is crucial to creating a good shared collaborative space, virtual or physical, and making dope work.
- Lessons from contracting
- Cooking metaphors
- Core principles
- Non-technical systems / mechanisms
- Technical systems / mechanisms
Table of contents
Cooking metaphors
Make sure you have all of your ingredients
You can't make a good dish without all the ingredients. It is important to have a clear understanding of what you need before you can start.
It is important to understand the limitations of the project, and what you are able to do with the resources that you have. Be hopeful, but realistic.
Mise en place
Mise en place is a French term for "everything in its place". It is the set up of a recipe or meal before starting to cook. This is one of the most important parts of cooking, and can be thought of as "step zero".
It is a good idea to spend time gathering everything before beginning to cook. If you have to stop in the middle of cooking to go and find a utensil or ingredient, or if you have to improvise, you are much more likely to make a mistake in the heat of the moment or forget something important.
It is not merely having the right ingredients on hand, but having the onions correctly chopped to the right size and your dressing mixed in a bottle ready to be poured, so you don’t have to think about it while you are executing.
Let it simmer
Simmering is a process of cooking stews and soups at a low heat for a long time. It is important to not rush this process and to let it cook slowly and let flavors build. Simmering is a good metaphor for the beginning processes of a collaboration. It is important to allow time for ideas to simmer and to be considered.
People need time to reflect and to come back to an idea later. In the same way that you need to be patient during the simmering process, you need to be patient when waiting for people to respond to an idea or prototype.
Measure twice and cut once
This is a simple carpentry rule, but applies to a lot of things. This is a good rule to keep in mind when shaping a project. It is a good idea to label, and plan, and organize, and think before taking action.
It is important to do the research, to establish a clear goal, and to have a solid understanding of the structure and plan before starting work.
Core principles
Non-hierarchy
When making decisions with a team, it is important to give everyone an equal voice. The best way to do this is to facilitate the conversation using a non-hierarchical structure. This means that everyone is on the same level and can share their ideas without feeling like they are being judged by someone with more authority.
Lack of hierarchy can sometimes be code for “invisible hierarchy” – and this almost always needs to be actively worked against. Groups of humans fall into patterns of hierarchy based on perceived expertise, extroversion, loudness, seniority, or race and gender. These need to be noticed and corrected with generosity and patience.
Chain of Command
The chain of command is the structure of authority within an organization. It is important to have a clear chain of command so that everyone knows who to go to with questions or problems.
Even without hierarchy, there are areas of responsibility and chain of command in decision making. When working quickly it is useful to delineate someone whose responsibilities are to make game-time decisions which, due to constraints, cannot be discussed at length.
This requires a lot of trust with your teammates, and the ability to swallow disagreements in service of the project and the deadline. This is possible if people know there are systems in place to responsibly have those disagreements later, especially if they are core to the outlook of the project or the team as a whole.
First Person In
In the military or SWAT teams there is the concept of the “first man in”. This is the person who enters the room first, and the rest of the unit follows. The “first man” in is the most vulnerable position with the most information, and the rest of the unit is there to support them. In a project, it is important to have someone who is willing to take the lead, and to be the first person in. This is a non-hierarchical decision made tactically in the moment based on the circumstances the team is presented with.
Clear Roles and Responsibilities
It is important to have clear roles and responsibilities so that everyone knows what they are supposed to be doing. Having clear roles and responsibilities makes it easier to hold people accountable and for people to independently push the project forward.
In a commercial kitchen, chefs are responsible for a specific part of a meal: meat, sauce, vegetables and have autonomy within their specialty to accomplish the shared task when making an incredible meal with the kitchen as a whole.
Good vibes
It is important to create a good vibe around a project. This means that everyone is comfortable with each other, and that they feel like they can trust each other. Good vibes are important because they make it easier to collaborate and make decisions. If people are not comfortable with each other, they are less likely to share their ideas.
A team that is laughing together tend to work well together. Professionalism and humor are not mutually exclusive. Every team is different and have different ways of finding joy in their work. But it is important to spot and intentionally cultivate that joy anywhere it happens organically.
Great teams play dope jams on their sound system all day, with a rotating playlist anyone can access or change.
Consensus
Consensus means that everyone agrees on something. When making decisions with a team, it is important to reach consensus. This means that everyone agrees on the decision, and that they are all comfortable with it. Consensus is important because it makes it easier to implement a decision, and it keeps the team from falling into potential pitfalls, even if seen by a single person.
In a consensus system, any individual can veto any decision the group makes. The entire group must agree on a path of action. This dynamic exists in other non-consensus working structures, even if not explicitly spoken.
Non-technical systems / mechanisms
User stories
User stories are a way of describing the functionality of a system from the perspective of the user. User stories are written in the following format:
"As a type of user, I want goal so that reason."
For example, "As a customer, I want to be able to search for products so that I can find a toothbrush to buy."
They are complete, actionable, and accomplishable units of work and output. User stories, either individually or in groups, turn into specific features in a product.
Product backlog
A product backlog is a list of all the features that need to be implemented in a system. The product backlog is organized into priority order, with the most important features at the top. User stories can be used to create a product backlog.
Sprints
A sprint is a period during which a team works on a set of features from the product backlog. Sprints are usually 2-4 weeks long, but can be much shorter, especially for a “research sprint”.
At the beginning of a sprint, the team decides which features, tasks, and user stories they are going to work on. The team then works on these features until the end of the sprint.
At the end of the sprint, the team demos the features that they have completed, and the product backlog is updated with any new features that need to be implemented.
Stand ups
Stand ups are a quick check-in that follow the format “yesterday I worked on X, today I am working on Y, I am blocked by A, B, and C” and then sometimes someone else will say “Oh, I can help you unblock C!”
This can be done quickly and provides a good way to keep everyone up to date on what everyone else is doing. Stand ups can be done in person or over Slack at a regular time daily or weekly.
Build your way out of problems
If you are having difficulty with a problem, try to build your way out of it. This means that you should build the smallest prototype of the idea that you are working on. This prototype does not need to be perfect, but it should be enough to demonstrate the concept.
Building a prototype can help you to understand the problem better, and it can also help you interrogate the framing and limitations from different angles.
Once you have a prototype, you can show it to other people and get their feedback. This feedback can help you to improve your prototype or create a new one, and the cycle continues.
Technical systems / mechanisms
Kanban
Kanban is a framework for managing software development projects. Kanban is based on the idea of continuous delivery, and it uses a Kanban board to visualize the work that needs to be done. This makes it easy to see all the work a team faces and who is responsible for what.
GitHub: Issues and Pull Requests
Every bug, feature, style update, and change should be first created as an issue and then fixed with a focused Pull Request that closes it. This is not always possible, but it is what we should strive for. This allows all of the decision making to happen in one place and for the code review to happen with the context of all of the discussion.
Code review
Code review is the process of reviewing code before it is merged into the main codebase. Code review is important because it allows people to give feedback on code, and it helps to find bugs.
A disciplined team will have at least two eyes on every line of code pushed to production.
This requires a level of trust and expectation-setting around code review.
My philosophy is to approve any Pull Request that accomplishes the task and doesn’t break anything or interfere with other active PRs.
If there are things that I might do differently, I try to write the code I am asking to be implemented, which may require opening a fresh PR with a new approach.
Documentation
Documentation is important because it helps people understand how a system works. Documentation should be written in a clear and concise manner, and it should be easy to find and change.
Documentation can take many different forms, such as comments in code, README files, wiki pages, and blog posts. It should be as eas for anyone to add to documentation, no matter where it lives.
Working in the open as much as possible
Working in the open means that the work that you are doing is available for anyone to see via blog posts, livestreams, social media, and talks. Working in the open is important because it allows people to give feedback on your work, and it allows people to build from your work and create unexpected amazing things.
It encourages good habits, such as writing clear and concise documentation, using descriptive names for things, and not taking shortcuts.
Working in the open is not always possible for various reasons, but it is something to strive for when possible as it is always rewarding.
Mob Programming
Mob programming is a software development technique in which the two or more people work on the same thing, at the same time, in the same place. One person often “drives” but anyone can jump in at any time. Real-time collaborative software like VSCode LiveShare, Figma, and Google Docs help this process tremendously.
Mob programming is a good way to share knowledge, and it helps to find bugs. A lot of bug-free work can be produced quickly, especially if everyone finds a lane to push things forward together.
This might look like one person processing data, another person visualizing it, another person reading documentation, and another picking colors, for example. Everyone is encouraged to participate, offer suggestions, and “touch” the project.
Speaking your thought process out loud to a colleague not only clarifies the information, but organizes it in your head. When the problem is re-stated to the group, sometimes the solution is obvious.