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 promoting

What we value in colleagues:

  1. impact. can understand where the market and tech is going to, how we can use it to deliver value to users/clients, and delivers on it.
  2. focus. can focus on a small number of things without feeling left out. focuses on work topics instead of org and process details. drama-free.
  3. clear. can talk and write in clear way.

When interviewing

Building teams

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


We split our calendar into 4 windows:

Quarterly: Plan and Eval

Quarterly we:

Plan: Deciding what to do next

We plan on the last month of the quarter. In this Problem Finding tasks, there are many possible good plans, and infinite bad plans. It’s important that the teams know that and works hard to build the best possible next quarter.

Eval - Understanding how we’re doing

Monthly: Deep-dive

About once per month we

Weekly: Status

Once per week, we keep people in the loop:

Daily: Execution and Impact

Executing the plan involves Problem Solving and Implementation:

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

  1. Empower teams: by design, teams must self-organize to make decisions, internally & autonomously.
  2. Responsibility: Responsibility is easy to assign. Functions already prescribe responsibilities:
    • Example: Engineers code, and are responsible for bugs in the code.
    • Example: Sales agents are responsible for sales.
    • Example: Product Managers are responsible for documentation and 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 real impact. It’s easier to just feel and measure who has the authority, and then make it official as the organization scales.
    • Example 1: The authority over a particular feature will depend on that feature and the team. Our Demo culture (above) prescribes that sometimes, it will be a designer, other times an engineer, yet other times a Product Manager.
    • Example 2: In our 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, strongly some times; but in the end, it’s their call.


This is what is currently working for us. It’s not perfect, but it feels real. :)