The following is a guide to how we’re setting up teams at Rows, and how i’d set them up in general if I’d start anew.
Hiring and feedback
The mindset I look for in people is “I will make an impact!”.
- hire people who can solve challenges you can’t solve or don’t have time to solve.
- hire those who want to focus, that is, hire people who don’t want to start by owning lot’s of projects.
- Avoid people who talk or write in a long, imprecise or confusing way.
- avoid those who react to feedback in a negative way or with whom sharing feedback is a painful, long process.
- ask candidates about their views on what you are doing, what’s the challenges they expect, and their experience in solving similar things.
- ask them to detail their past impact precisely - what was their role; when did they get involved; what was their contribution; who else was a part of the team.
- ask them about what’s the technical future of the tools and processes of your industry, and what opportunities that opens for delivering impact to users.
Daily work should be lean and purposeful.
- Focus: Keep your WIP=1 as much as possible. Start by solving 1 challenge end-to-end.
- Be autonomous: Deliver value by autonomously completing tasks in a way that impresses users, clients and colleagues. Deliver when it’s done, not when it’s almost done. Nobody cares about “almost”. Leaving finalization to others is very burdensome. If you’re unsure, make multiple options.
- Show critical initiative: avoid adding another brain to a mob. Adopt critical, orphan, projects. Let others tackle other things. If you solve your project, eventually you’ll be called for other things.
- Ship small: Make deliveries as small as you can, and focused on the user impact.
Interacting with others
Team work should be … also lean and purposeful:
- Get a calendar: set time for your stuff and Time for meetings. Try to keep “meeting” days to 1, max 2 per week.
- Collaborate asynchronously: split tasks, work, discuss, merge. Avoid chats and endless synchronization processes and meetings.
Once your company is 10+ you should think about teams.
- Keep teams small: Max 10 people, 5-6 is my ideal per team.
- Split up for work: If your teams have more than 4 people, work in smaller units. Alone or in groups of 2 or 3. A team of 5-10 people can tackle 2 projects simultaneously.
- Give teams a purpose: Each team should have a purpose that is limitless, like “make the best search engine for our product”. Avoid overlapping purposes of different teams.
- Assign leaders and expect responsibility: my teams have up to 3 leaders: Product Owner, Product Designer and Engineering Manager. Some of these people work on 2 teams.
Planning and Execution
There’s 2 key parts in our planning cycle
- Deciding what to do next (Problem Finding)
- Each quarter we validate a list of projects per team. We do it on the last month of the quarter.
- Marketing presents the overall company goals: how many users we want to acquire, activate, convert to paid, how much revenue we will get.
- Team leaders talk to users, Business, designers, engineers, users, etc.
- Product Managers organize feedback into a list of challenges (projects) including features, bugs, improvements, tech debt.
- We place enourmous focus on Challenge descriptions. It’s critical to be clear on the problem without prescribing a technical solution.
- Challenge: the name of the challenge, no frills.
- Why: why you want to solve it - have users asked for it (who, how many), do we need it to fulfill a high-level company metric (e.g. increase activation rates).
- Objectives: how will we know you’ve solved this challenge - a certain technical metric will go up? by how much? the feature will enable users to do X, Y or Z?
- Approach: is there something defined already? will we start with a Proof of Concept? a design? a spec? we
- Teams agree on priorities. Product Managers organize meetings to agree on a prioritization.
- Get it approved. Teams present plans to managers and CEO/Founders. These can agree or object, in a veto system: Team creates proposal, Managers (inc CEO) can say no and give feedback, then loop.
- Executing the plan (Problem Solving and Implementation)
- At a global level, we track the list of all projects per team.
- Teams keep plans prioritized.
- We track an impact-oriented status: to-do, wip (work in progress prior to 1st delivery), wip-delivering (wip after 1st delivery), delivered.
- We don’t communicate deadlines, size estimations, or complex status… In my experience, they’re hard to assess and pointless in a startup.
- At the micro level, let the teams organize themselves however they want
- Teams organize themselves:
- They can use Boards, spreadsheets, notepads. I like GOTChA charts for large projects.
- If teams want to do estimations or commit to deadlines, we let them do it.
- However, I personally focus only on true delivered impact.
- When executing, we follow a Test and Demo philosophy:
- Each team executes Challenges.
- Challenges can be started in multiple ways:
- PoC: Proofs of Concept are great for projects with significant engineering uncertainty. They should focus on a MVP of the value to deliver to the user. They can be done by engineering, without or without design even.
- Spikes: Great to deep-dive on a technical question, to test different technologies.
- Design: Starting with Designs is ideal for projects with low engineering uncertainty and complex/ rich user journeys. User research/ Interviews can make these really shine.
- Specification: Starting with a specification is appropriate when you’re dealing with detailed business requirements and vertical context.
- Just start coding: Relevant for bugs and other predictive and small activities.
- When the team made sufficient progress, they Demo to manager; Demos can be made post releasing something live. Manager checks if Challenge is fulfilled, gives feedback.
- Understanding how we are doing
- After a quarter is over, we check how we did in terms of plans:
- were we able to predict what we were going to do?
- were teams mature (independent)?
- did we deliver a lot of user/ client impact?
- We also do a check on the numbers, and what happened in terms of cohorts and other metrics.
Having a long term strategy is also important:
- Keep it simple: We commit to a strategy which is reviewed once or twice a year. The CEO generates a template, and everyone is encouraged to debate and make additions and edits.
- it’s a great source or challenges.
- the collaboration part is a nice way to make space for intuition, taste & initiative.
Responsibility and Authority
Team decisions are a tricky subject. Ultimately, everyone is responsible for the success of the company. Teams should be self-aware and decide together, that’s always preferred. But as teams and skills grow, you’ll see deciders (authority) popping up here and there. It’s practical and perhaps unavoidable to assign Responsibilities and Authority.
- Empower teams: by design, teams must self-organize to make decisions, internally & autonomously. They should weight users needs and teams views, be them Business, Design or Engineering.
- Responsibility: Responsibility is easy to assign. Functions prescribe some responsibilities.
- Example: Product Managers are responsible for prioritization, so it’s them who have to make sure there are priorities, that they are updated and communicated.
- Authority: Authority on the other hand is hard to establish. Ideally, “the best idea wins”, but that’s frequently code for “endless discussion of what best means”. I hesitate to give authority to functions, because power is not born of a title, but experience. It’s easier to just feel who has the authority, and then make it official (or not).
- Example 1: The authority over a particular feature will depend on that feature and the team. A Demo culture
- Example 2: In my teams, the authority over the final say of a hire lies with Engineering Managers. Not even I, a founder, overrule the EMs decisions. I do give my input, but in the end, they have to manage their teams engineers.