portotype.com

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

• ask candidates about the future of the tools and processes of your industry, and what opportunities that future opens for delivering impact to users.
• 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.
• expose candidates to some challenge you’ve tackled or plan to tackle, and see how they run with it.

Building teams

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

• Keep teams small, max 10 people.
• Give teams a limitless purpose, like “make the easiest spreadsheet editing experience”.
• Assign Leaders and expect responsibility: for tech teams: Product Owner, Product Designer and Engineering Manager.

Interactions

We split our calendar into 4 windows:

• daily: advance the business.
• weekly: keep people in the loop.
• monthly: management deep-dive.
• quarterly: plan and evaluate.

Quarterly: Plan and Eval

Quarterly we:

• plan the next quarter and maybe the following one.
• review the past quarter performance and do promotions.
• do a board session with investors.

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.

• Strategy: Marketing and Product leaders present a overall company goal: what are the use cases to focus on; how many users we should acquire, retain etc, what are the biggest barriers.
• Feedback: Team leaders gather feedback from users, their teams and overall team.
• Plans: Product Managers organize feedback into a list of challenges (projects). We place enourmous focus on Challenge descriptions to be clear on the problem without prescribing a technical solution.
  • Challenge: the name of the challenge, no frills.
  • Company goals: how will this impact our high-level company metrics - e.g. increase activation rates?
  • Challenge Objectives: how will we know you’ve solved this challenge - a certain technical metric will go up? by how much? We will witness X users doing Y?
  • Approach: is there something defined already? will we start with a Proof of Concept? a design? a spec? we
• Prioritization: Team leaders agree on priorities, and Product Managers organize meetings to agree on it.
• Approve: Teams present plans to management and CEO/Founders. Teams create proposal, managers (inc CEO) can say no and give feedback, then loop.

Eval - Understanding how we’re doing

• After a quarter is over, we check how we did in terms of plans: 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.
• We then look at individual feedback and say if we support or not promotions.

Monthly: Deep-dive

About once per month we

• have a leadership meeting where we review the status of goals, key changes in teams’ projects, ask business questions and deepdive any topic.
• conduct 1on1s with our managers/ reports.
• do an all-hands meeting where we review our status.
• send an investor update.

Weekly: Status

Once per week, we keep people in the loop:

• every team (leaders) creates a simple status report, shared via doc (what we’re doing, what we completed, main notes). This should take max 30min.
• we send news to our users inside the app, as feature announcements.
• we send news to our users in social channels (twitter, linkedin).
• we send an internal HR email with hires, leavers and other updates.
• we have a “show & tell” where anyone or any team can show-off cool stuff.

Daily: Execution and Impact

Executing the plan involves 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), closed.
  • 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, we 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 focus only on delivered impact, not features, which makes it harder to demand deadlines.
• When executing, we follow a Test and Demo philosophy:
  • Each team executes the Challenges (problems) of the Quarter.
  • 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.

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.

Adaptation

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