3: Team setup

The following is a guide I follow when setting up teams. It's a permanent work in progress.

Hiring and feedback

The mindset I look for in people is "I will make an impact!".

  • hire people that can solve what others can't. They should have unique pro skills.
  • hire people that love challenges and who are courageous.
  • Hire for a great time together: avoid people that make meetings painful (interviews are meetings).
  • avoid people who talk or write in a confusing way.

Daily Work

Daily work should be lean and purposeful:

  • Be autonomous: Deliver value by autonomously completing work that impresses colleagues, users and clients. Deliver when it's done, not when it's almost done. Nobody cares about "almost".
  • Show initiative: avoid adding another brain to a mob. Adopt critical, orphan, projects.
  • Focus: Doing too many things at once means nothing will ever be perfect. Keep your WIP=1.
  • Ship small: Make deliveries as small as you can.

Interacting with others

Team work should be ... also lean and purposeful:

  • Get a calendar: time for your stuff. 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.

Building teams

Once your company is 10+ you should think about teams.

  • Keep teams small: Max 10 people, 5-6 is my ideal.
  • 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-3 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 are shared between 2 teams. One of these positions (PO,PD,EM) may lead.


  • At a global level, there's a list with all projects per team.
    • Prioritize them. Get each team to agree on the order of things, and everyone else to buy-in (bottoms-up or top-down).
    • Add impact-oriented status: to-do, in-progress, delivered.
    • You don't have to communicate deadlines, size estimations, or complex status... In my experience, they're a waste of time.
  • At the micro level, let the teams organize however they want
    • They can use Boards, spreadsheets, notepads. I like GOTChA charts for large projects. If teams want to do estimations within projects, let them do it.

Planning and evaluation

There's 2 key parts in planning cycle: before the quarter is over and when the next quarter starts.

  1. Deciding what to do next
    • Each quarter we reorganize list of projects per team. We do it on the last month of the quarter.
      • 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.
      • To me, the key is how you write the challenges. It's an art to be super clear on the problem without prescribing a technical solution.
      • Teams agree on priorities. Product Managers have a key role in this task, as it's their responsibility to make sure there's a prioritization.
      • CEO gives one pass with comments.
    • We also assess how the product is standing in terms of benefits for the user.
      • We send a survey for all the team so that they comment on each team's absolute value delivery. The CEO does a final write-up of each team's performance.
    • Finalization meeting
      • On one meeting with Product + Business, team leaders (usually Product Managers) present their roadmap plans.
      • We spend a significant time making sure there's common understanding of challenge formulation.
      • we pick up our cohort model and try to do simple forward projections. Everyone on the meeting (product + growth) submits their own model. The point is that team members understand the relationship between actions and numbers.
  2. Understand how we are doing
    • After a quarter is over, we check how we did in terms of product:
      • did each team advance in terms of features, that is, relatively to the priorities list? This is done in a survey for all the team, and the CEO (me) does a final write-up of each team's performance. Points, sizes, speed measures are not considered (pointless).
    • 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.

  1. 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.
  2. 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.
  3. 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: In my teams, the authority over the final spec of a project may lie with a Designer, a Product Manager or an Engineer - even if the responsibility of the team arriving at a final spec is the Product Manager's responsibility.
    • Example: 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.