portotype.com

Teams

The following is how I’d setup a new team.

Hiring and promoting

What I value in colleagues:

1. impact. delivers more clients (selling, marketing) and better clients (product, retention, virality, upsells). is autonomous in big and small decisions, knows where the market and tech is going to, understands quality and users, and merges that to deliver value to users/clients.
2. focus. can focus on a small number of things. doesn’t need to be a part of every project at first. focuses on work topics instead of org and process details. drama-free.

Interview example.

When interviewing you try to award 2-1-0, per question, and then as a total. 2 means the person impressed you, checked all ticks without help, and is a natural leader. 1 means the person is ok, has experience/ motivation and can add value with a bit of help. 0 means the persom will require lots of management, explanation, will be a distraction. - Step 1: What is future of the this industry? - talks about other tools in depth. - knows existing use cases, pains and solutions. - knows the future of tools and what tech enables. - Step 2: What are we doing in this company? - knows company and product well. - actually tested it. - has questions and suggestions. - Step 3: What are the the challenges your expect in your function? - the issues they identify are the ones you do too. - Step 4: What is your experience in that? - has relevant experience, can talk about it, identifies real aspects (company, team size, their role in team) - Step 5: What would you do in this challenge (problem solving). - solves the actual problem with tools (code, sells) - explains clearly what is happening. - Step 6: How do you piss off people? - identifies real flaws that are actionable- - avoids common place (i'm a perfectionist).

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. each team should be full stack as much as possible.

Interactions

We split our calendar into 4 windows:

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

Quarterly: Plan and Eval

Quarterly we:

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

Note: Plan could possibly be done monthly.

Plan the next quarter

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: Managers organize feedback into a list of challenges (projects). We focus on making Challenge descriptions 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.

review the past quarter performance and do promotions.

• After a quarter is over, we check how we did in terms of plans: did we deliver a lot of user/ client impact?
• We then look at individual feedback and say if we support or not promotions.
• Evals are 0-1-2. 0: not acceptable. 1: acceptable. 2: amazing. Outstanding is something at least 2x more than what everyone thought was good.

Monthly: Deep-dive

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:

• we have a deep dive meeting to see what happened the previous week.
• we have a “show & tell” where anyone or any team can show-off cool stuff.
• every team (leaders) shares a simple status report - what Challenges we’re doing next, what we completed. this is asynchronous.
• we send news to our users inside the app, as feature announcements, and social media.
• we send an internal HR email with hires, leavers and other updates.

Daily: Execution and Impact

Executing the plan involves Problem Solving and Implementation.

• Teams organize themselves, pick their tools and sub process.
• No need to do deadlines, you iterate on who delivers more.
• Intense Demo philosophy:
  • team pick Challenges of the Quarter.
  • Challenges can be started in multiple ways:
    • PoC: Proofs of Concept are for projects with big uncertainty. Start on a v0 of the value to deliver to the user. Do it with engineering, team of 1-2 people, no waterfalls with design etc.
    • Spikes: To solve a technical question and to test different technologies.
    • Design: Starting with Designs is ideal when there’s low engineering uncertainty and complex user journeys. Like a sharing flow.
    • Specification: Best to deliver on detailed business requirements and vertical context like how to process payment.
    • Just start coding: Relevant for bugs and other predictive and small activities.
  • When the team makes sufficient progress, they Demo to manager; Give feedback, check what’s next.

Responsibility and Authority

Team decisions are tricky. Everyone is responsible for the success of a company.

1. Empower teams: by design, teams self-organize to make decisions, internally & autonomously.
2. Responsibility: Responsibility is easy to assign by Functions:
   • Example: Engineers code, and are responsible for bugs in the code.
   • Example: Product Managers are responsible for documentation and prioritization, but that can be done by technical contributors too.
   • Example: Sales agents are responsible for sales.
3. Authority: Authority is hard to establish. Ideally, “the best idea wins”, but that’s frequently code for “endless discussion of what best means”. We look out for people who can deliver value in an autonomous way, and give them authority.

Adaptation

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