mirror of
https://github.com/fleetdm/fleet
synced 2026-05-23 08:58:41 +00:00
Add CTA to apply to Fleet, swapped with company page for visibility (#9880)
.
This commit is contained in:
Mike McNeil
GitHub
parent
991858d6d5
commit
b3e9db8789
3 changed files with 103 additions and 98 deletions
|
|
@ -1,15 +1,5 @@
|
|||
# Business Operations
|
||||
|
||||
## Open positions
|
||||
|
||||
Fleet is currently hiring for the following positions:
|
||||
|
||||
- 🚀 [Engineering Manager, MDM](https://fleet-device-management.breezy.hr/p/41ad774fe34a-engineering-manager-mdm)
|
||||
- ⚗️ [Product Designer](https://fleet-device-management.breezy.hr/p/68ef1b6ace54-product-designer)
|
||||
- 🫧 [Revenue Operations Manager](https://fleet-device-management.breezy.hr/p/c28cce9abf5e-revenue-ops)
|
||||
- 🫧 [Field Marketer](https://fleet-device-management.breezy.hr/p/3bd97ce5f54a-field-marketing-manager-enterprise)
|
||||
|
||||
> Interested in joining the team at Fleet, or know someone who might be? The [company handbook page](https://fleetdm.com/handbook/company) is a short read with more information about the company, including our vision, values, and history.
|
||||
|
||||
## Meetings
|
||||
* At Fleet, meetings start whether you're there or not. Nevertheless, being even a few minutes late can make a big difference and slow your meeting counterparts down. When in doubt, show up a couple of minutes early.
|
||||
|
|
@ -132,6 +122,13 @@ Fleet's founders [evaluate and update compensation decisions yearly](#workiversa
|
|||
The [CEO handbook](./ceo-handbook.md) details processes specific to Mike McNeil, CEO of Fleet.
|
||||
|
||||
|
||||
## Open positions
|
||||
|
||||
Please see [handbook/business-operations#open-positions](https://fleetdm.com/handbook/business-operations#open-positions) for a list of open job postings at Fleet.
|
||||
|
||||
> Interested in joining the team at Fleet, or know someone who might be? The [company handbook page](https://fleetdm.com/handbook/company) is a short read with more information about the company, including our vision, values, and history.
|
||||
|
||||
|
||||
## Team member onboarding
|
||||
|
||||
### Training
|
||||
|
|
@ -280,19 +277,6 @@ When the final signature is added to an envelope in DocuSign, it is marked as co
|
|||
|
||||
|
||||
|
||||
|
||||
## Security
|
||||
|
||||
At Fleet, we care about security. Here are a few resources about Fleet's security policies and best practices.
|
||||
1. [Security policies](https://fleetdm.com/handbook/security/security-policies#security-policies)
|
||||
2. [Human resources security policy](https://fleetdm.com/handbook/security/security-policies#human-resources-security-policy)
|
||||
3. [Account recovery process](https://fleetdm.com/handbook/security#account-recovery-process)
|
||||
4. [Personal mobile devices](https://fleetdm.com/handbook/security#personal-mobile-devices)
|
||||
5. [Hardware security keys](https://fleetdm.com/handbook/security#hardware-security-keys)
|
||||
6. More details about internal security processes at Fleet are located on [the Security page](./security.md).
|
||||
|
||||
|
||||
|
||||
## Hiring
|
||||
|
||||
### Creating a new position
|
||||
|
|
@ -452,6 +436,18 @@ Once you send the agreement, add a new row to the [advisory board spreadsheet](h
|
|||
When you complete the agreement, make sure it is in the correct Google Drive folder, update the [advisory board spreadsheet](https://docs.google.com/spreadsheets/d/15knBE2-PrQ1Ad-QcIk0mxCN-xFsATKK9hcifqrm0qFQ/edit#gid=1803674483) to show that the agreement has been signed, and ask the new advisor to add us on [Linkedin](https://www.linkedin.com/company/71111416), [Crunchbase](https://www.crunchbase.com/organization/fleet-device-management), and [Angellist](https://angel.co/company/fleetdm).
|
||||
|
||||
|
||||
|
||||
## Security
|
||||
|
||||
At Fleet, we care about security. Here are a few resources about Fleet's security policies and best practices.
|
||||
1. [Security policies](https://fleetdm.com/handbook/security/security-policies#security-policies)
|
||||
2. [Human resources security policy](https://fleetdm.com/handbook/security/security-policies#human-resources-security-policy)
|
||||
3. [Account recovery process](https://fleetdm.com/handbook/security#account-recovery-process)
|
||||
4. [Personal mobile devices](https://fleetdm.com/handbook/security#personal-mobile-devices)
|
||||
5. [Hardware security keys](https://fleetdm.com/handbook/security#hardware-security-keys)
|
||||
6. More details about internal security processes at Fleet are located on [the Security page](./security.md).
|
||||
|
||||
|
||||
## Finance
|
||||
|
||||
### Monthly accounting
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
# Company
|
||||
|
||||
## About Fleet
|
||||
## Purpose
|
||||
|
||||
Fleet Device Management Inc is an [open core company](https://www.heavybit.com/library/video/commercial-open-source-business-strategies/) that sells subscriptions that offer [more features and support](https://fleetdm.com/pricing) for Fleet and [osquery](https://osquery.io), the leading open source endpoint agent.
|
||||
Fleet Device Management Inc is an [open-core company](https://www.heavybit.com/library/video/commercial-open-source-business-strategies/) that sells subscriptions that offer [more features and support](https://fleetdm.com/pricing) for Fleet and [osquery](https://osquery.io), the leading open source endpoint agent.
|
||||
|
||||
We are dedicated to:
|
||||
|
||||
|
|
@ -14,32 +14,40 @@ We are dedicated to:
|
|||
## Culture
|
||||
|
||||
### All remote
|
||||
Fleet Device Management Inc. is an all-remote company with team members spread across four continents and eight time zones. The broader team of contributors [worldwide](https://github.com/fleetdm/fleet/graphs/contributors) submits patches, bug reports, troubleshooting tips, improvements, and real-world insights to Fleet's open source code base, documentation, website, and [company handbook](#about-the-handbook).
|
||||
Fleet Device Management Inc. is an all-remote company with team members spread across four continents and eight time zones. The broader team of contributors [worldwide](https://github.com/fleetdm/fleet/graphs/contributors) submits patches, bug reports, troubleshooting tips, improvements, and real-world insights to Fleet's open-source code base, documentation, website, and [company handbook](https://fleetdm.com/handbook/company/why-this-way#why-handbook-first-strategy).
|
||||
|
||||
### Open source
|
||||
The majority of the code, documentation, and content we [create](https://twitter.com/mikermcneil/status/1476799587423772674) at Fleet is public and source-available. We strive to be open and transparent in the way we run the business, as much as confidentiality agreements (and time) allow. We perform better with an audience, and our audience performs better with us. Learn more about [why we use open source](https://fleetdm.com/handbook/company/why-this-way#why-open-source).
|
||||
The majority of the code, documentation, and content we create at Fleet is public and source-available. The Fleet handbook is the central guide for how we run the company, and even it is open to the world. We [strive to be open](https://fleetdm.com/handbook/company/why-this-way#why-open-source) and transparent in the way we run the business, as much as confidentiality agreements (and time) allow. We perform better with an audience, and our audience performs better with us.
|
||||
|
||||
### Why this way?
|
||||
At Fleet, we rarely label ideas as drafts or theories. Everything is [always in draft](https://about.gitlab.com/handbook/values/#everything-is-in-draft) and subject to change in future iterations. But to get [results](https://fleetdm.com/handbook/company#results), we need to balance being smart with moving quickly. That means embracing decisiveness in the face of uncertainty.
|
||||
|
||||
To increase clarity and encourage teams to make decisions quickly, leaders and [DRIs (directly responsible individuals)](https://fleetdm.com/handbook/company/why-this-way#why-direct-responsibility) should explicitly mention when they are voicing an opinion or a decision. When an [opinion](https://blog.codinghorror.com/strong-opinions-weakly-held/) is voiced, there's space for near-term debate. When a [decision](https://about.gitlab.com/handbook/values/#disagree-commit-and-disagree) is voiced, team commitment is required.
|
||||
|
||||
The ["Why this way?"](https://fleetdm.com/handbook/company/why-this-way) page discusses some of Fleet's decisions about the best way to work. For example: ["Why open source?"](https://fleetdm.com/handbook/company/why-this-way#why-open-source) and ["Why do we use a wireframe-first approach?"](https://fleetdm.com/handbook/company/why-this-way#why-do-we-use-a-wireframe-first-approach) and ["Why handbook-first strategy?"](https://fleetdm.com/handbook/company/why-this-way#why-handbook-first-strategy).
|
||||
|
||||
|
||||
## Open positions
|
||||
|
||||
Please see [handbook/business-operations#open-positions](https://fleetdm.com/handbook/business-operations#open-positions) for a list of open job postings at Fleet.
|
||||
Fleet is currently hiring for the following positions:
|
||||
|
||||
- 🚀 [Engineering Manager, MDM](https://fleet-device-management.breezy.hr/p/41ad774fe34a-engineering-manager-mdm)
|
||||
- ⚗️ [Product Designer](https://fleet-device-management.breezy.hr/p/68ef1b6ace54-product-designer)
|
||||
- 🫧 [Revenue Operations Manager](https://fleet-device-management.breezy.hr/p/c28cce9abf5e-revenue-ops)
|
||||
- 🫧 [Field Marketer](https://fleet-device-management.breezy.hr/p/3bd97ce5f54a-field-marketing-manager-enterprise)
|
||||
|
||||
> Interested in joining the team at Fleet, or know someone who might be? Click one of the positions to read the job description and apply, or you can share a [direct link to this page](https://fleetdm.com/handbook/company) for a short read about the company, including our vision, values, history, and all currently open positions. Thank you for the help!
|
||||
|
||||
|
||||
## Org chart
|
||||
|
||||
Fleet's organizational chart is accessible as a sub-tab in ["🧑🚀 Fleeties" (private google doc)](https://docs.google.com/spreadsheets/d/1OSLn-ZCbGSjPusHPiR5dwQhheH1K8-xqyZdsOe9y7qc/edit#gid=0). On the other sub-tabs, you can also check out a world map of where everyone is located, hiring stats, and fun facts about each team member.
|
||||
|
||||
### Product groups
|
||||
|
||||
## Product groups
|
||||
Fleet organizes cross-functional groups focused on particular business goals. These include members from Design, Engineering, Quality, and Product. For more information, check out this page [Product groups](./development-groups.md).
|
||||
|
||||
|
||||
## Why this way?
|
||||
|
||||
At Fleet, we err on the side of being opinionated about conventions and processes we believe in, but we always keep in mind the possibility that we could be wrong. In other words: strong opinions, loosely held. And everything is in draft.
|
||||
|
||||
You can read more about the background behind why Fleet does things the way we do in ["Why this way?"](./why-this-way.md)
|
||||
|
||||
|
||||
## 🌈 Values
|
||||
|
||||
Fleet's values are a set of five ideals adopted by everyone on the team. They describe the culture we are working together to deliver, inside and outside the company:
|
||||
|
|
@ -93,24 +101,6 @@ Openness leads to better products and stronger partnerships. Being open about yo
|
|||
- **Be transparent.** We build in the open. Everything we do is public by default. Declassify confidential information with care.
|
||||
|
||||
|
||||
## About the handbook
|
||||
|
||||
The Fleet handbook is inspired by the [GitLab team handbook](https://about.gitlab.com/handbook/about/). It shares the same [advantages](https://about.gitlab.com/handbook/about/#advantages) and will probably undergo a similar [evolution](https://about.gitlab.com/handbook/ceo/#evolution-of-the-handbook).
|
||||
|
||||
While [GitLab's handbook](https://about.gitlab.com/handbook/) inspires this handbook, it is nowhere near as complete (yet!) We will continue adding and updating this handbook and gradually migrating information from [Fleet's shared Google Drive folder](https://drive.google.com/drive/folders/1lA38aTxsl4_qDtHCrYHcAaadES5ws0yJ) as time allows.
|
||||
|
||||
### Contributing to the handbook
|
||||
You can review more information about contributing to Fleet's handbook on this page [Contributing to the handbook](handbook/company/handbook.md)
|
||||
|
||||
### Handbook first
|
||||
At Fleet, we make changes to the [handbook](#about-the-handbook) first. That means before a change to how we run the business is "live" or "live" or "official", it is first updated (with changes merged) in the relevant handbook pages and issue templates.
|
||||
|
||||
This keeps everyone in sync across the all-remote team in different timezones, avoids miscommunications, and ensures the right people have reviewed every change.
|
||||
|
||||
> See also ["Why handbook-first strategy?"](https://fleetdm.com/handbook/company/why-this-way#why-handbook-first-strategy).
|
||||
|
||||
<!-- todo consolidate handbook first section here into "why this way" and link from here -->
|
||||
|
||||
## History
|
||||
|
||||
### 2014: Origins of osquery
|
||||
|
|
@ -126,8 +116,6 @@ When Kolide's attention shifted away from Fleet, and towards their separate, use
|
|||
Zach partnered with our CEO, Mike McNeil, to found a new, independent company: Fleet Device Management Inc. In November 2020, we [announced](https://medium.com/fleetdm/a-new-fleet-d4096c7de978) the transition and kicked off the logistics of moving the GitHub repository.
|
||||
|
||||
|
||||
|
||||
|
||||
## Slack channels
|
||||
|
||||
The following Slack channels are maintained by Fleet's founders:
|
||||
|
|
|
|||
|
|
@ -1,5 +1,11 @@
|
|||
# Why this way?
|
||||
|
||||
Here are some of Fleet's decisions about the best way to work, and the reasoning for them.
|
||||
|
||||
Any past decision is open to questioning in a future iteration, as long as you act in accordance with it until it is changed. When you want to reopen a conversation about a past decision, communicate with the [DRI (directly responsible individual)](https://fleetdm.com/handbook/company/why-this-way#why-direct-responsibility) who can change the decision instead of someone who can't. Show your argument is informed by previous conversations, and assume the original decision was made [with the best intent](https://about.gitlab.com/handbook/values/#assume-positive-intent).
|
||||
|
||||
Fleet's CEO is the directly-responsible individual for the decisions on this handbook page.
|
||||
|
||||
## Why open source?
|
||||
|
||||
Fleet's source code, website, documentation, company handbook, and internal tools are [public](https://github.com/fleetdm/fleet) and accessible to everyone, including engineers, executives, and end users. (Even [paid features](https://fleetdm.com/pricing) are source-available.)
|
||||
|
|
@ -20,6 +26,42 @@ Here are some of the reasons we build in the open:
|
|||
- **More timeless.** You are not doomed to disappear forever when you change jobs. Why should your code? In most jobs, most of the work you do becomes inaccessible when you quit. But [open source is forever](https://twitter.com/mikermcneil/status/1476799587423772674).
|
||||
|
||||
|
||||
## Why handbook-first strategy?
|
||||
|
||||
The Fleet handbook provides team members with up-to-date information about how to do things in the company.
|
||||
|
||||
At Fleet, we make changes to the handbook first. That means, before any change to how we run the business is "live" oror "official", it is first changed in the relevant [handbook pages](https://fleetdm.com/handbook) and [issue templates](https://github.com/fleetdm/confidential/tree/main/.github/ISSUE_TEMPLATES).
|
||||
|
||||
Making changes to the handbook first [encourages](https://www.youtube.com/watch?v=aZrK8AQM8Ro) a culture of self-reliance, which is essential for daily asynchronous work as part of an all-remote team. It keeps everyone in sync across the all-remote team in different timezones, avoids miscommunications, and ensures the right people have reviewed every change.
|
||||
|
||||
> The Fleet handbook is inspired by the [GitLab team handbook](https://about.gitlab.com/handbook/about/). It shares the same [advantages](https://about.gitlab.com/handbook/about/#advantages) and will probably undergo a similar [evolution](https://about.gitlab.com/handbook/ceo/#evolution-of-the-handbook).
|
||||
|
||||
To contribute to the handbook, click "Edit this page" and make your [edits in Markdown](handbook/company/handbook.md).
|
||||
|
||||
|
||||
## Why the emphasis on training?
|
||||
Investing in people and providing generous, prioritized training, especially up front, helps contributors understand what is going on at Fleet. By making training a prerequisite at Fleet, we can:
|
||||
- help team members feel confident in the better decisions they make at work.
|
||||
- create a culture of helping others, which results in team members feeling more comfortable even if they aren’t familiar with the osquery, security, startup, or IT space.
|
||||
|
||||
|
||||
## Why direct responsibility?
|
||||
Like Apple and GitLab, Fleet uses the concept of [directly responsible individuals (DRIs)](https://about.gitlab.com/handbook/people-group/directly-responsible-individuals/) to know who is responsible for what.
|
||||
|
||||
A DRI is a person who is singularly responsble for a given aspect of the open-source project, the product, or the company. A DRI is responsible for making decisions, accomplishing goals, and getting any resources necessary to make a given area of Fleet successful.
|
||||
|
||||
For example, every department maintains its own dedicated [handbook page](https://fleetdm.com/handbook), with a single DRI, and which is kept up to date with accurate, current information, including the group's [kanban board](https://github.com/orgs/fleetdm/projects?type=beta), Slack channels, and recurring tasks ("rituals").
|
||||
|
||||
DRIs help us collaborate efficiently by knowing exactly who is responsible and can make decisions about the work they're doing. This saves time by eliminating a requirement for consensus decisions or political presenteeism, enables faster decision-making, and ensures a single individual is aware of what to do next.
|
||||
|
||||
You can view DRIs in:
|
||||
1. The [CODEOWNERS files](https://github.com/fleetdm/fleet/blob/main/CODEOWNERS) of the fleetdm/fleet and fleetdm/confidential repositories.
|
||||
2. The `name="maintainedBy"` tags at the very bottom of the raw markdown source for [every handbook page](https://github.com/fleetdm/fleet/tree/main/handbook) and [individual article](https://github.com/fleetdm/fleet/tree/main/articles).
|
||||
3. The job titles and reporting structure indicated by the [company's organizational chart](https://fleetdm.com/handbook/company#org-chart) and the roles in our [cross-functional product groups](https://fleetdm.com/handbook/company#product-groups).
|
||||
|
||||
> In some cases, multiple subject-matter experts can merge changes to files even though there is a dedicated DRI configured as the "CODEOWNER". For examples of this, see the auto-approval flows configured as `sails.config.custom.githubRepoDRIByPath` and `sails.config.custom.confidentialGithubRepoDRIByPath` in [`website/config/custom.js`](https://github.com/fleetdm/fleet/blob/main/website/config/custom.js).
|
||||
|
||||
|
||||
## Why do we use a wireframe-first approach?
|
||||
|
||||
Wireframing (or "drafting," as we often refer to it at Fleet) provides a clear overview of page layout, information architecture, user flow, and functionality. The wireframe-first approach extends beyond what users see on their screens. Wireframe-first is also excellent for drafting APIs, config settings, CLI options, and even business processes.
|
||||
|
|
@ -45,27 +87,6 @@ At Fleet, we keep everything in one repo. The only exception is when we're worki
|
|||
- One repo pools GitHub stars and more accurately reflects Fleet’s presence.
|
||||
- One repo means one set of automations and labels to manage, resulting in a consistent GitHub experience that is easier to keep organized.
|
||||
|
||||
## Why organize work in team-based kanban boards?
|
||||
It's helpful to have a consistent framework for how every team works, plans, and requests things from each other. Fleet's kanban boards are that framework, and they cover three goals:
|
||||
|
||||
1. **Intake:** Give people from anywhere in the world the ability to request something from a particular team (i.e., add it to their backlog).
|
||||
2. **Planning:** Give the team's manager and other team members a way to plan the next three-week iteration of what the team is working on in a world (the board) where the team has ownership and feels confident making changes.
|
||||
3. **Shared to-do list:** What should I work on next? Who needs help? What important work is blocked? Is that bug fix merged yet? When will it be released? When will that new feature ship? What did I do yesterday?
|
||||
|
||||
## Why a three-week cadence?
|
||||
The Fleet product is released every three weeks. By syncing the whole company to this schedule, we can:
|
||||
|
||||
- keep all team members (especially those who aren't directly involved with the core product) aware of the current version of Fleet and when the next release is shipping.
|
||||
- align project planning and milestones across all teams, which helps us schedule our content calendar and manage company-wide goals.
|
||||
|
||||
## Why use agile methodology?
|
||||
Releasing software iteratively gets changes and improvements into the hands of users faster and generally results in software that works. This makes contributors fitter, happier, and more productive. See [the agile manifesto](https://agilemanifesto.org/) for more information.
|
||||
|
||||
## Why the emphasis on training?
|
||||
Investing in people and providing generous, prioritized training, especially up front, helps contributors understand what is going on at Fleet. By making training a prerequisite at Fleet, we can:
|
||||
- help team members feel confident in the better decisions they make at work.
|
||||
- create a culture of helping others, which results in team members feeling more comfortable even if they aren’t familiar with the osquery, security, startup, or IT space.
|
||||
|
||||
|
||||
## Why not continuously generate REST API reference docs from javadoc-style code comments?
|
||||
Here are a few of the drawbacks that we have experienced when generating docs via tools like Swagger or OpenAPI, and some of the advantages of doing it by hand with Markdown.
|
||||
|
|
@ -79,27 +100,6 @@ Here are a few of the drawbacks that we have experienced when generating docs vi
|
|||
- Autogenerating docs from code comments is not always the best way to make sure reference docs accurately reflect the API.
|
||||
- As the Fleet REST API, documentation, and tools mature, a more declarative format such as OpenAPI might become the source of truth, but only after investing in a format and processes to make it continually accurate as well as visible, accessible, and modifiable for all contributors.
|
||||
|
||||
## Why handbook-first strategy?
|
||||
The Fleet handbook provides team members with up-to-date information about how to do things in the company. By adopting the handbook-first strategy, we can encourage a culture of self-service and self-learning, which is essential for daily a-synchronous work as part of an all-remote team.
|
||||
|
||||
This strategy was inspired by GitLab, which uses it with great effect. Check out this [short three-minute video](https://www.youtube.com/watch?v=aZrK8AQM8Ro) about their take on the handbook-first approach.
|
||||
|
||||
## Why direct responsibility?
|
||||
Like Apple and GitLab, Fleet uses the concept of [directly responsible individuals (DRIs)](https://about.gitlab.com/handbook/people-group/directly-responsible-individuals/) to know who is responsible for what.
|
||||
|
||||
A DRI is a person who is singularly responsble for a given aspect of the open-source project, the product, or the company. A DRI is responsible for making decisions, accomplishing goals, and getting any resources necessary to make a given area of Fleet successful.
|
||||
|
||||
For example, every department maintains its own dedicated [handbook page](https://fleetdm.com/handbook), with a single DRI, and which is kept up to date with accurate, current information, including the group's [kanban board](https://github.com/orgs/fleetdm/projects?type=beta), Slack channels, and recurring tasks ("rituals").
|
||||
|
||||
DRIs help us collaborate efficiently by knowing exactly who is responsible and can make decisions about the work they're doing. This saves time by eliminating a requirement for consensus decisions or political presenteeism, enables faster decision-making, and ensures a single individual is aware of what to do next.
|
||||
|
||||
You can view DRIs in:
|
||||
1. The [CODEOWNERS files](https://github.com/fleetdm/fleet/blob/main/CODEOWNERS) of the fleetdm/fleet and fleetdm/confidential repositories.
|
||||
2. The `name="maintainedBy"` tags at the very bottom of the raw markdown source for [every handbook page](https://github.com/fleetdm/fleet/tree/main/handbook) and [individual article](https://github.com/fleetdm/fleet/tree/main/articles).
|
||||
3. The job titles and reporting structure indicated by the [company's organizational chart](https://fleetdm.com/handbook/company#org-chart) and the roles in our [cross-functional product groups](https://fleetdm.com/handbook/company#product-groups).
|
||||
|
||||
> In some cases, multiple subject-matter experts can merge changes to files even though there is a dedicated DRI configured as the "CODEOWNER". For examples of this, see the auto-approval flows configured as `sails.config.custom.githubRepoDRIByPath` and `sails.config.custom.confidentialGithubRepoDRIByPath` in [`website/config/custom.js`](https://github.com/fleetdm/fleet/blob/main/website/config/custom.js).
|
||||
|
||||
|
||||
## Why group Slack channels?
|
||||
Groups (`g-*`) are organized around goals. Connecting people with the same goals helps them produce better results by fostering freer communication. Some groups align with teams in the org chart. Other groups, such as [product groups](https://fleetdm.com/handbook/company/development-groups), are cross-functional, with some group members who do not report to the same manager.
|
||||
|
|
@ -107,6 +107,27 @@ Groups (`g-*`) are organized around goals. Connecting people with the same goals
|
|||
Every group at Fleet maintains their own Slack channel, which all group members join and keep unmuted. Everyone else at Fleet is encouraged to mute these channels, using them only as needed. Each channel has a directly responsible individual responsible for keeping up with all new messages, even if they aren't explicitly mentioned (`@`).
|
||||
|
||||
|
||||
## Why organize work in team-based kanban boards?
|
||||
It's helpful to have a consistent framework for how every team works, plans, and requests things from each other. Fleet's kanban boards are that framework, and they cover three goals:
|
||||
|
||||
1. **Intake:** Give people from anywhere in the world the ability to request something from a particular team (i.e., add it to their backlog).
|
||||
2. **Planning:** Give the team's manager and other team members a way to plan the next three-week iteration of what the team is working on in a world (the board) where the team has ownership and feels confident making changes.
|
||||
3. **Shared to-do list:** What should I work on next? Who needs help? What important work is blocked? Is that bug fix merged yet? When will it be released? When will that new feature ship? What did I do yesterday?
|
||||
|
||||
|
||||
## Why scrum?
|
||||
Releasing software iteratively gets changes and improvements into the hands of users faster and generally results in software that works. This makes contributors fitter, happier, and more productive. See [the agile manifesto](https://agilemanifesto.org/) for more information.
|
||||
|
||||
> TODO: expand
|
||||
|
||||
|
||||
## Why a three-week cadence?
|
||||
The Fleet product is released every three weeks. By syncing the whole company to this schedule, we can:
|
||||
|
||||
- keep all team members (especially those who aren't directly involved with the core product) aware of the current version of Fleet and when the next release is shipping.
|
||||
- align project planning and milestones across all teams, which helps us schedule our content calendar and manage company-wide goals.
|
||||
|
||||
|
||||
|
||||
<meta name="maintainedBy" value="mikermcneil">
|
||||
<meta name="title" value="Why this way?">
|
||||
|
|
|
|||
Loading…
Reference in a new issue