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!”.

When interviewing

Daily Work

Daily work should be lean and purposeful.

Interacting with others

Team work should be … also lean and purposeful:

Building teams

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

Planning and Execution

There’s 2 key parts in our planning cycle

  1. 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.
  2. 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.
  3. 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:

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 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.