patife

Teams

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. delivering impact. we love people who can solve unique challenges that deliver value to our users/clients, especially those we can’t solve on our own.
  2. focus. we avoid people who want to “own” lots of things before they execute a few well enough.
  3. clarity. we avoid people who talk or write in an unclear way.
  4. easy. we want people who can take feedback positively and act on it. people who react defensively to comments and decisions make work painful.
  5. vision. we love people who can search and find the one challenge we should solve, out of the potential 1000s of ideas, improvements and fixes.

When interviewing

Building teams

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

Interactions

Team work should be … also lean and purposeful:

Quarterly: Plan and Eval

Quarterly we:

Plan: Deciding what to do next

Each quarter we validate a list of projects per team. We do it on the last month of the 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

Daily work should be impactful.

Executing the plan

Executing the plan involves Problem Solving and Implementation:

Strategy

Having a long term strategy is 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 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 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 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.

Adaptation

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