merging in material that will be folded in
This commit is contained in:
23
SourceMaterial/people/team-structure/_team_template.md
Normal file
23
SourceMaterial/people/team-structure/_team_template.md
Normal file
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: Team Example
|
||||
sidebar: Handbook
|
||||
showTitle: true
|
||||
hideAnchor: true
|
||||
---
|
||||
|
||||
## People
|
||||
|
||||
- [Jane Doe (Team Lead, Full Stack Engineer)](/handbook/company/team/#jane-doe-software-engineer)
|
||||
- [Max Mustermann (Full Stack Engineer)](/handbook/company/team/#max-mustermann-software-engineer)
|
||||
|
||||
## Mission
|
||||
|
||||
## Responsibilities
|
||||
|
||||
## Customer
|
||||
|
||||
## Output metrics
|
||||
|
||||
## Slack channel
|
||||
|
||||
[#team-example](https://posthog.slack.com/messages/team-example)
|
||||
39
SourceMaterial/people/team-structure/core-experience.md
Normal file
39
SourceMaterial/people/team-structure/core-experience.md
Normal file
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: Team Core Experience
|
||||
sidebar: Handbook
|
||||
showTitle: true
|
||||
hideAnchor: true
|
||||
---
|
||||
|
||||
## People
|
||||
|
||||
- [Eric Duong (Team Lead, Full Stack Engineer)](/handbook/people/team/#eric-duong-software-engineer)
|
||||
- [Paolo D'Amico (Product Manager)](/handbook/people/team#paolo-damico-product-team)
|
||||
- [Buddy Williams, Full Stack Engineer](/handbook/people/team/#buddy-williams-software-engineer)
|
||||
- Sam Winslow, Full Stack Engineer
|
||||
- [Li Yi Yu, Full Stack Engineer]((/handbook/people/team/#li-yi-yu-software-engineer))
|
||||
|
||||
## Mission
|
||||
|
||||
To create the easiest way to discover insights about products and its users
|
||||
|
||||
## Responsibilities
|
||||
|
||||
- Extending feature set as suggested by requests, by our own ideas, and by need for parity with other platforms
|
||||
- Maintaining data quality and clarity
|
||||
- Ensuring performant and clear user experience across all analytics functionality
|
||||
|
||||
|
||||
## Customer
|
||||
|
||||
- Any PostHog user, whether they're an engineer or a product manager, should be able to effectively analyze their product.
|
||||
|
||||
## Output metrics
|
||||
|
||||
- Retention per feature
|
||||
|
||||
[Dashboard](https://app.posthog.com/dashboard/1124)
|
||||
|
||||
## Slack channel
|
||||
|
||||
[#team-core-experience](https://posthog.slack.com/messages/team-core-experience)
|
||||
41
SourceMaterial/people/team-structure/design.md
Normal file
41
SourceMaterial/people/team-structure/design.md
Normal file
@@ -0,0 +1,41 @@
|
||||
---
|
||||
title: Team Design
|
||||
sidebar: Handbook
|
||||
showTitle: true
|
||||
hideAnchor: true
|
||||
---
|
||||
|
||||
## People
|
||||
|
||||
- [Cory Watilo (Team lead, Lead Designer)](/handbook/company/team/#cory-watilo-lead-designer)
|
||||
- [Lottie Coxon, Graphic Design)](/handbook/company/team#lottie-coxon-graphic-designer)
|
||||
- Mike Nicklas, Front End Engineer
|
||||
|
||||
## Mission
|
||||
|
||||
|
||||
|
||||
## Responsibilities
|
||||
|
||||
- Support Small Teams (and contributors) in building better versions of PostHog
|
||||
- Enable customers to build better products (using PostHog)
|
||||
- Communicate to prospective customers the value we provide
|
||||
|
||||
Tangibly, we:
|
||||
|
||||
- Initiate new projects to support the responsibilities above
|
||||
- Support Small Teams in completing their sprint tasks
|
||||
- Iterate based on feedback from customers
|
||||
|
||||
## Customer
|
||||
|
||||
- The other small teams - [here is a guide](handbook/company/working-with-design) on how to best work with the Design team.
|
||||
|
||||
## Output metrics
|
||||
|
||||
- Acquisition
|
||||
- Retention
|
||||
|
||||
## Slack channel
|
||||
|
||||
[#team-design](https://posthog.slack.com/messages/team-design)
|
||||
59
SourceMaterial/people/team-structure/extensibility.md
Normal file
59
SourceMaterial/people/team-structure/extensibility.md
Normal file
@@ -0,0 +1,59 @@
|
||||
---
|
||||
title: Team Extensibility
|
||||
sidebar: Handbook
|
||||
showTitle: true
|
||||
hideAnchor: true
|
||||
---
|
||||
|
||||
## People
|
||||
|
||||
- [Marius Andra (Team lead, Full Stack Engineer)](/handbook/company/team/#marius-andra-software-engineer)
|
||||
- [Michael Matloka (Full Stack Engineer)](/handbook/company/team/#michael-matloka-software-engineer)
|
||||
- [Yakko Majuri (DevRel + Full Stack Engineer)](/handbook/company/team/#yakko-majuri-technical-writer-and-developer)
|
||||
|
||||
## Mission
|
||||
|
||||
Team Extensibility's job is to turn PostHog into a platform that everyone can integrate with.
|
||||
In essence, we enable users to:
|
||||
- get data _into_ PostHog
|
||||
- get data _out of_ PostHog
|
||||
- extend PostHog itself according to their needs
|
||||
|
||||
## Responsibilities
|
||||
|
||||
Team Extensibility is particularly responsible for:
|
||||
- the plugin server
|
||||
- the data ingestion pipeline
|
||||
- PostHog integrations with all sorts of platforms (JS, Go, iOS, Zapier, Segment, etc.)
|
||||
- the user experience of extensibility features in PostHog (e.g. plugins, webhooks)
|
||||
|
||||
## Priorities
|
||||
|
||||
1. Making sure there are no cracks in the walls and that we always keep in mind safety, security, and data
|
||||
integrity of our systems. We code defensively, prefer allowlists to denylists, and so on.
|
||||
2. A fabulous user experience. Connecting things to PostHog either via plugins or integrations
|
||||
should spark joy.
|
||||
|
||||
## Customer
|
||||
|
||||
- Plugin developers, contributors to extensibility
|
||||
- Plugin users (and in extension, all PostHog app users – who we'd love to make use of plugins)
|
||||
- Integration users
|
||||
|
||||
## Output metric
|
||||
|
||||
- Number of plugins installed and/or in active use
|
||||
- Used plugin-seconds on cloud, breakdown by team (for billing)
|
||||
- Number of integrations and their usage
|
||||
|
||||
[Dashboard](https://app.posthog.com/dashboard/1865)
|
||||
|
||||
## Meetings
|
||||
|
||||
- Sync: Monday, 9:00 UTC
|
||||
- Sync: Wednesday, 15:00 UTC
|
||||
- Internal release planning: Friday every other week
|
||||
|
||||
## Slack channel
|
||||
|
||||
[#team-extensibility](https://posthog.slack.com/messages/team-extensibility)
|
||||
62
SourceMaterial/people/team-structure/growth-engineering.md
Normal file
62
SourceMaterial/people/team-structure/growth-engineering.md
Normal file
@@ -0,0 +1,62 @@
|
||||
---
|
||||
title: Team Growth Engineering
|
||||
sidebar: Handbook
|
||||
showTitle: true
|
||||
hideAnchor: true
|
||||
---
|
||||
|
||||
## People
|
||||
|
||||
- [Kunal Pathak (Team lead, Growth Engineer)](/handbook/company/team#kunal-pathak-growth-engineer)
|
||||
|
||||
## Mission
|
||||
|
||||
Generate scalable growth by applying focused efforts of product, data, and engineering to specific areas of our business.
|
||||
|
||||
## Responsibilities
|
||||
|
||||
* Own activation flow
|
||||
* Own revenue flow
|
||||
* Proactively search for (and execute) opportunities to run experiments to improve output metrics anywhere in the business
|
||||
|
||||
## Customer
|
||||
|
||||
Growth engineering works
|
||||
|
||||
## Output metrics
|
||||
|
||||
* Acquisition
|
||||
* Activation
|
||||
* Revenue
|
||||
|
||||
## Principles
|
||||
|
||||
### Solve Problems, not Metrics
|
||||
|
||||
We do not focus on moving a number– we are focused on solving real problems and solving real pain to drive growth. Metrics are used to help inform the work we do, check our assumptions, and measure our progress. However, we believe metric growth is a side effect of great experiences and solving real pain.
|
||||
|
||||
### Find the 80-20
|
||||
|
||||
It is important that we approach problems with pragmatic solutions – focus on finding the 20% that will solve 80% of the pain.
|
||||
|
||||
As a team with a narrow and dynamic focus, it is critical for us to boil down problems to their core and to effect change on those. Future work or progress should be summarized and shared as learnings with the broader team so we can reprioritize when appropriate.
|
||||
|
||||
We are a dynamic team that jumps across many different areas. We believe that it is better to be growing and getting better day by day for the next year than to be stagnant everyday but great in a year.
|
||||
|
||||
### Any Jank is Jank
|
||||
|
||||
We believe in product-led growth. This means that the product experience is always the most important thing to maintain.
|
||||
|
||||
Pragmatism, dynamic ownership, and the 80-20 rule are not reasons to ship poor or broken product experiences.
|
||||
|
||||
Nothing hurts growth more than a bad product.
|
||||
|
||||
### Control the Inputs, Trust the Process
|
||||
|
||||
Great execution beats everything.
|
||||
|
||||
We believe that rapid iteration, compounding our learnings, and following our experiment process will eventually lead to success. We trust that as long as we are making sound decisions and running great analyses, the right things will happen.
|
||||
|
||||
## Slack channel
|
||||
|
||||
[#team-growth-engineering](https://posthog.slack.com/messages/team-growth-engineering)
|
||||
73
SourceMaterial/people/team-structure/infrastructure.md
Normal file
73
SourceMaterial/people/team-structure/infrastructure.md
Normal file
@@ -0,0 +1,73 @@
|
||||
---
|
||||
title: Team Infrastructure & Deployments
|
||||
sidebar: Handbook
|
||||
showTitle: true
|
||||
hideAnchor: true
|
||||
---
|
||||
|
||||
|
||||
|
||||
## People
|
||||
|
||||
- [James Greenhill](/handbook/company/team/#james-greenhill-software-engineer) (Team lead, Data/Infra Engineer)
|
||||
- [Karl-Aksel Puulmann](/handbook/company/team/#karl-aksel-puulmann-software-engineer) (Full Stack Engineer)
|
||||
|
||||
## Mission
|
||||
|
||||
Make using and developing for PostHog as reliable as running water. Wherever you want it.
|
||||
|
||||
## Goals
|
||||
|
||||
- We don't lose events
|
||||
- Data is as up to date as possible
|
||||
- Engineers always be able to ship and build
|
||||
- Fail fast. Fix faster.
|
||||
- Ship anywhere
|
||||
- Stack scales with demand
|
||||
- Support Small Teams (and contributors) in building and debugging Posthog
|
||||
- Be frugal.
|
||||
|
||||
## Responsibilities
|
||||
Concrete things we take responsibility over:
|
||||
|
||||
- [app.posthog.com](app.posthog.com) and its infrastructure
|
||||
- On Prem & Single Tenant deployments
|
||||
- CI/CD - How we deploy
|
||||
- Data infrastructure (Clickhouse, Kafka)
|
||||
- Monitoring and Alerting stack
|
||||
|
||||
## Customer
|
||||
|
||||
- Other Small Teams in making sure they have the tools (databases, queues, etc) and the ability to deploy effortlessly that they need to build
|
||||
- End users (Both cloud and on-prem teams)
|
||||
|
||||
## Output metrics
|
||||
|
||||
### VPC
|
||||
###### Retention
|
||||
- Metric: Retention
|
||||
- Objective: Better than cloud
|
||||
### Cloud
|
||||
###### Data Loss
|
||||
- Metric: Data loss %
|
||||
- Objective: < 0.1%
|
||||
###### Uptime
|
||||
- Metric: Uptime
|
||||
- Objective: > 99.99%
|
||||
###### Speed
|
||||
- Metric: Speed
|
||||
- Objectives
|
||||
- Event ingestion: TBD
|
||||
- Query response: TBD
|
||||
- Overall: We should anticipate increasing demand (either manually or automatically)
|
||||
##### Cost
|
||||
- Metric: Infra Costs
|
||||
- Objective: Our costs should grow at a rate that is sublinear relative to scale
|
||||
### Dev Experience
|
||||
##### Dev Experience NPS (Infra)
|
||||
- Metric: Developer experience (relating to infra) (maybe NPS?)
|
||||
- Objective: TBD (maybe NPS?)
|
||||
|
||||
## Slack channel
|
||||
|
||||
[#team-deployments-and-infrastructure](https://posthog.slack.com/messages/team-deployments-and-infrastructure)
|
||||
36
SourceMaterial/people/team-structure/marketing.md
Normal file
36
SourceMaterial/people/team-structure/marketing.md
Normal file
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: Team Marketing
|
||||
sidebar: Handbook
|
||||
showTitle: true
|
||||
hideAnchor: true
|
||||
---
|
||||
|
||||
## People
|
||||
|
||||
- Mo Shehu, Content Marketer
|
||||
|
||||
## Mission
|
||||
|
||||
Make PostHog a ubiquitous developer tool.
|
||||
|
||||
## Customer
|
||||
|
||||
Innovative technical teams, who care about:
|
||||
|
||||
* a unified product analytics platform
|
||||
* open source
|
||||
* control: hosting, pricing, source, data, privacy and security
|
||||
|
||||
We will expand to non-technical teams when we have achieved technical awareness saturation.
|
||||
|
||||
## Output metrics
|
||||
|
||||
* Acquisition
|
||||
|
||||
## Philosophy
|
||||
|
||||
Be kind, concise and direct.
|
||||
|
||||
## Slack channel
|
||||
|
||||
[#team-marketing](https://posthog.slack.com/messages/team-marketing)
|
||||
45
SourceMaterial/people/team-structure/people.md
Normal file
45
SourceMaterial/people/team-structure/people.md
Normal file
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: Team People
|
||||
sidebar: Handbook
|
||||
showTitle: true
|
||||
hideAnchor: true
|
||||
---
|
||||
|
||||
## People & Culture
|
||||
|
||||
- [Eltje Lange](/handbook/company/team#eltje-lange-people-and-talent)
|
||||
- [Recruitment and Operations Coordinator](https://apply.workable.com/posthog/j/554EC800BE/) (currently hiring!)
|
||||
|
||||
## Mission
|
||||
|
||||
Make PostHog the best place everyone here has ever worked. Our goal is to create a world-class (remote) culture, prioritising impact, autonomy and personal development.
|
||||
|
||||
## Responsibilities
|
||||
|
||||
Our people team works across talent, people operations and culture:
|
||||
|
||||
- We attract, engage and hire top talent from around the world, while ensuring an outstanding candidate and hiring manager experience.
|
||||
- Building a [diverse and inclusive culture](/handbook/company/diversity) is at the heart of everything we do.
|
||||
- We support our team throughout the entire employee lifecycle - from making an offer, to onboarding and career development, to parental leave and eventually parting ways.
|
||||
- We create light-touch initiatives and processes that allow PostHog to act fast (while complying with local legislation) and [iterate](/handbook/company/culture#iteration) continuously.
|
||||
- In the people team, we live and breathe our [culture](/handbook/company/culture) and [values](/handbook/company/values), and constantly work to make PostHog an even better place to work.
|
||||
|
||||
## Customer
|
||||
|
||||
All small teams as well as current, future and past candidates.
|
||||
|
||||
## Output metrics
|
||||
|
||||
Talent:
|
||||
- Hiring progress vs. plan
|
||||
- Time to hire
|
||||
- Percentage of hires from [under-represented groups](/handbook/company/diversity#how-diversity-helps-us)
|
||||
|
||||
People and culture:
|
||||
- Quarterly Team engagement survey
|
||||
- Turnover rate (voluntary and involuntary)
|
||||
|
||||
## Slack channel
|
||||
|
||||
[#people](https://posthog.slack.com/messages/people) - internally public, default for most people discussions
|
||||
[#people_ops](https://posthog.slack.com/messages/people_ops) - internally confidential, for minority of issues, e.g. salaries, candidate offers
|
||||
48
SourceMaterial/people/team-structure/team-structure.md
Normal file
48
SourceMaterial/people/team-structure/team-structure.md
Normal file
@@ -0,0 +1,48 @@
|
||||
---
|
||||
title: Team structure
|
||||
sidebar: Handbook
|
||||
showTitle: true
|
||||
hideAnchor: true
|
||||
---
|
||||
|
||||
We've organised the team into small teams that are multi-disciplinary. [You can read about why we've done it this way.](/handbook/people/team-structure/why-small-teams).
|
||||
|
||||
## Engineering
|
||||
|
||||
- **Core experience**
|
||||
- [Eric Duong (Team Lead, Full Stack Engineer)](/handbook/people/team/#eric-duong-software-engineer)
|
||||
- [Paolo D'Amico (Product Manager)](/handbook/people/team#paolo-damico-product-team)
|
||||
- [Buddy Williams, Full Stack Engineer](/handbook/people/team/#buddy-williams-software-engineer)
|
||||
- Sam Winslow, Full Stack Engineer
|
||||
- [Li Yi Yu, Full Stack Engineer]((/handbook/people/team/#li-yi-yu-software-engineer))
|
||||
|
||||
<br />
|
||||
|
||||
- **[Extensibility](extensibility)**
|
||||
- [Marius Andra (Team lead, Full Stack Engineer)](/handbook/company/team/#marius-andra-software-engineer)
|
||||
- [Michael Matloka (Full Stack Engineer)](/handbook/company/team/#michael-matloka-software-engineer)
|
||||
- [Yakko Majuri (DevRel + Full Stack Engineer)](/handbook/company/team/#yakko-majuri-technical-writer-and-developer)
|
||||
|
||||
<br />
|
||||
|
||||
- **[Infrastructure and Deployments](infrastructure)**
|
||||
- [James Greenhill](/handbook/company/team/#james-greenhill-software-engineer) (Team lead, Data/Infra Engineer)
|
||||
- [Karl-Aksel Puulmann](/handbook/company/team/#karl-aksel-puulmann-software-engineer) (Full Stack Engineer)
|
||||
|
||||
<br />
|
||||
|
||||
- **[Growth engineering](growth-engineering)**
|
||||
- Kunal Pathak (Growth Engineer)
|
||||
|
||||
## [Design](design)
|
||||
|
||||
- Cory Watilo (Team lead, Lead Designer)
|
||||
- Lottie Coxon (Graphic Designer)
|
||||
|
||||
## [Marketing](marketing)
|
||||
|
||||
- Mo Shehu (Content Marketer)
|
||||
|
||||
## [People & Culture](people)
|
||||
|
||||
- [Eltje Lange](/handbook/people/team#eltje-lange-people-and-talent) (People and Talent)
|
||||
110
SourceMaterial/people/team-structure/why-small-teams.md
Normal file
110
SourceMaterial/people/team-structure/why-small-teams.md
Normal file
@@ -0,0 +1,110 @@
|
||||
---
|
||||
title: Why Small Teams
|
||||
sidebar: Handbook
|
||||
showTitle: true
|
||||
hideAnchor: true
|
||||
---
|
||||
|
||||
PostHog is structured for speed, autonomy and innovation.
|
||||
|
||||
Many traditional organizations have big, separate functions. You have a product team, an engineering team, customer support, and so on. This slows things down when you scale because there are more layers of communication and complex approval chains. This stifles innovation - you have to get your boss to talk to someone else's boss to get work done. It also means that people can't really see the impact of their work.
|
||||
|
||||
PostHog started off as a completely flat company with one big goal: to increase the number of successful products in the world.
|
||||
|
||||
As we are getting bigger, we anticipate that it will get harder for people to see the direct impact of their work, which reduces the sense of ownership.
|
||||
|
||||
We have therefore introduced Small Teams. These are designed to each operate like a startup.
|
||||
|
||||
# How it works
|
||||
|
||||
* The overall goal is for a Small Team to be as close to its own startup as possible, with only a handful of centralized processes
|
||||
* A Small Team should never be more than six people
|
||||
* A Small Team has an Accountable Person responsible for its performance - whoever is most appropriate depending on what the team is working on. This does _not_ mean the most senior person on the team.
|
||||
* A Small Team must have (1) a customer (internal or external), (2) a mission and (3) metrics
|
||||
* There may be certain functions where at our current stage we don't need a Small Team yet.
|
||||
* Each Small Team runs its own retrospective + sprint every week. This must be done transparently.
|
||||
* A Small Team has the final call in which of its features get into production, with no need for external QA/control - within our existing release schedule.
|
||||
* A Small Team will, at some stage, be able to create its own pricing (too complex in immediate future to do this, however)
|
||||
* Small teams should document what they build.
|
||||
|
||||
# Small Teams list
|
||||
|
||||
* Core Experience (trends, retention, funnels)
|
||||
* Extensibility (plugins/APIs)
|
||||
* Deployments and Infrastructure (AMI/VPC/PostHog Cloud)
|
||||
|
||||
# Functional teams
|
||||
|
||||
* People & Culture
|
||||
* Marketing (includes website)
|
||||
* Growth Engineering (proactive experiments / activation flow / revenue flow)
|
||||
* Design
|
||||
|
||||
# FAQ
|
||||
|
||||
## Who do Small Teams report to? How does this work with management?
|
||||
|
||||
The Accountable Person has the final say in a given Small Team's decision making - they decide what to build / work on.
|
||||
|
||||
Each person's line manager is their role's functional leader (if possible). For example, engineers, no matter which Small Team they're in, will report to an engineer. It's important to note that management at PostHog is [very minimalist](management) - it's critical that managers don't set tasks for those in Small Teams.
|
||||
|
||||
Think of the Small Team as the company you work for, and your line manager as your coach.
|
||||
|
||||
## Can someone be in multiple Small Teams?
|
||||
|
||||
No. This defeats the purpose of ownership. We should be hiring in both places. Sometimes that'll mean we "overstaff" certain teams, but in reality there will always be further projects we can move people onto if they run out of work. It's better to do this than to be perpetually understaffed and for our product to suffer as a result.
|
||||
|
||||
## Who is in a Small Team?
|
||||
|
||||
No more than 6 people, but that's the only rule. It could be any group of people working together.
|
||||
|
||||
## Will this lead to inconsistent design?
|
||||
|
||||
Eventually, yes. Other companies have a UX team that build components for everyone to use. Since we currently use [Ant Design](https://ant.design/), we don't need this just yet.
|
||||
|
||||
## Can I still [step on toes](/handbook/values)?
|
||||
|
||||
Yes. In fact it's actively encouraged. We still expect people to have an understanding of the entire company and what various people are working on. In engineering, we still expect you to understand how the entire system works, even if you're only working on infrastructure. You can only do your job well if you understand how it fits in with other parts of the system.
|
||||
|
||||
You're actively encouraged to raise pull requests or propose changes to stuff that doesn't have anything to do with your small team.
|
||||
|
||||
## Can people change teams?
|
||||
|
||||
We try to keep moves infrequent and when needed. We anticipate moving people roughly every 3-9 months. We'd rather hire new people than create gaps by shifting people around.
|
||||
|
||||
There are two scenarios that will trigger a move:
|
||||
|
||||
* The Small Team may realize they no-longer need someone, or that they could really do with someone currently in another Small Team internally.
|
||||
* An individual team member may wish to move in order to develop their skills or experience.
|
||||
|
||||
It is at the discretion of the _manager_ of that person if they can move.
|
||||
|
||||
## Aren't most our Small Teams way too small?
|
||||
|
||||
In certain cases, but not everywhere. This will clarify where people will work. In fact, it'll make sure we keep the scrappy fun side of working here as we get bigger. A team doesn't _have_ to be six people.
|
||||
|
||||
## How does hiring in the Small Team work?
|
||||
|
||||
The Small Team is responsible for creating roles for those that they need.
|
||||
|
||||
We have a centralized team that will then help you hire.
|
||||
|
||||
James and Tim will meet every hire we make - it's a standard startup failure for founders to get too removed from hiring. We are very happy to then give you complete autonomy on the work you do, as best we can.
|
||||
|
||||
## Does a Small Team have a budget?
|
||||
|
||||
Spend money when it makes sense to do so. See our general policy on spending money.
|
||||
|
||||
## How do you keep the product together as a company?
|
||||
|
||||
Marcus (Tim until Marcus starts) will be ultimately responsible for us having (i) no gaps in product (ii) eliminating duplicate work (iii) making sure all Small Teams are working on something rational. This is how we manage the product.
|
||||
|
||||
## How do you stop duplicate work?
|
||||
|
||||
Marcus (Tim until Marcus starts) has the ultimate responsibility to make sure we don't build the same thing in two different teams, or that we don't accidentally compete with each other internally.
|
||||
|
||||
By keeping communication asynchronous and transparent, this is made much easier to do than is typical at other organizations.
|
||||
|
||||
## Can a Small Team "own" another Small Team?
|
||||
|
||||
Not for now, no. Perhaps when we're much larger this is something to think about.
|
||||
Reference in New Issue
Block a user