Update company.md (#5063)

All edits are recorded by line:

9 added “.” to end
10 added”,” after “agents”; added “.” to end
11 added “.” to end
12 added “.” to end
13 added “.” to end
19 replaced “wider” with “broader”; deleted “from” after “contributors”; replaced “all over the world” with “worldwide”; replaced “submit” with “submits”
22 replaced “, and we” with “. We”; deleted “broadly” before “open”; replaced “business;” with “business,”
25 replaced “their” with “its”
28 replaced “certain” with “specific”; deleted “ who is” after “individual”
38 removed capitalization from “error”; added “.” to end
39 removed capitalization from “layouts”; added “.” to end
40 removed capitalization from “flows”; added “.” to end
41 removed capitalization from “interactions”; added “.” to end
42 removed capitalization from “help”; added “.” to end
43 removed capitalization from “button”; added “.” to end
44 removed capitalization from “forms”; added “.” to end
45 added “.” to end
46 added “.” to end
47 added “.” to end
51 added “we're” after “when”
58 replaced “3 week” with “3-week”
61 replaced “3 week” with “3-week”
64 replaced “4 week” with “4-week”
65 deleted “always” after “Everyone”
93 replaced “markdown” with “Markdown”;replaced “markdown” with “Markdown”
96 replaced “markdown” with “Markdown”
97 replaced “markdown” with “Markdown”
111 replaced “ they work with” with “with whom they work” to avoid ending with a preposition; deleted extra space before “Having”
116 replaced “be” with “Be”; hyphenated “customer-first”; added “.” to end
127 replaced “consider with “Consider”; added “.” to end
128 capitalized “For”
129 capitalized “Ask”; replaced “like” with”as”; added “.” to end
130 capitalized “Assume”; added “.” to end
131 capitalized “Be”; added “.” to end
132 capitalized “Quickly”; added “.” to end
133 capitalized “Be”; added “.” to end
134 capitalized “End”; added “.” to end
135 capitalized “Role”; added “.” to end
136 capitalized “Don't”; added “.” to end
137 capitalized “Developers”; added “.” to end
138 added “The” to beginning; added “.” to end
139 capitalized “Bugs”; added “.” to end
140 capitalized “Patch”; added “.” to end
141 capitalized “Confusing”; deleted “,” after “helpless”; added “.” to end
142 capitalized “Error”; added “.” to end
143 added “.” to end
144 replaced “hospitality” with “Be hospitable.” 
145 capitalized “Be”; added “.” after “helper”; replaced “mr rogers” with “Mr. Rogers”
146 capitalized “Think” added “.” to end
147 capitalized “Use” added “.” to end
148 capitalized “Talking” added “.” to end
149 capitalized “Embrace” added “.” to end
150 capitalized “Make” added “.” to end
151 capitalized “Be”; added “.” to end
152 capitalized “Apply” added “.” to end
153 capitalized “Be”; added “.” to end
154 capitalized “Better”; added “.” to end
161 capitalized and punctuated sentence
162 capitalized and punctuated sentence
163 capitalized and punctuated sentence
164 capitalized and punctuated sentence
165 capitalized and punctuated sentence
166 capitalized and punctuated sentence; added “the” before “business” and “total”
167 capitalized and punctuated sentence
168 capitalized and punctuated sentence
169 capitalized and punctuated sentence
170 capitalized and punctuated sentence
171 replaced “prefer” with “Favor”; added “.” to end
172 capitalized and punctuated sentence
173 capitalized and punctuated sentence
174 capitalized and punctuated sentence
175 capitalized and punctuated sentence; replaced “==“ with “equals”
176 deleted “-“ after “this”; added “()” around “there's a great community of people able and happy to help”
177 capitalized and punctuated sentence
178 capitalized and punctuated sentence; added “of before “who”; added “()” around “ask other contributors how you can help, regardless of who is assigned to what”
179 capitalized and punctuated sentence; deleted “;” after “done”; added “()” around “help unblock team members and other contributors to deliver value”
180 capitalized and punctuated sentence
181 capitalized and punctuated sentence
182 capitalized and punctuated sentence
183 capitalized and punctuated sentence
184 capitalized and punctuated sentence
185 capitalized and punctuated sentence
186 capitalized and punctuated sentence
187 capitalized and punctuated sentence
188 capitalized and punctuated sentence; added “your” after “Better”
193 replaced “iterate” with “Remember to iterate.”
194 added “Work in”; added “.” to end
195 capitalized and punctuated sentence
196 capitalized and punctuated sentence
197 capitalized and punctuated sentence
198 capitalized and punctuated sentence
199 capitalized and punctuated sentence
200 capitalized and punctuated sentence
201 capitalized and punctuated sentence
202 capitalized and punctuated sentence
203  capitalized and punctuated sentence; replaced “;” with “and”
204 capitalized and punctuated sentence
205 capitalized and punctuated sentence
206 added “Go for”; added “.”
207 capitalized and punctuated sentence
208 capitalized and punctuated sentence
209 capitalized and punctuated sentence; replaced “==“ with “equals”
210 added “Complete tasks” added “.” to end
211 capitalized and punctuated sentence
212 replaced “to” with “This will”; added “.” to end
213 capitalized and punctuated sentence
214 capitalized and punctuated sentence
215 capitalized and punctuated sentence
216 capitalized and punctuated sentence; added “your”
222 capitalized and punctuated sentence
223 capitalized and punctuated sentence; replaced “truly listen” with “listen truly”
224 capitalized and punctuated sentence
225 capitalized and punctuated sentence
226 capitalized and punctuated sentence
227 replaced “underpromise, overdeliver” with “Underpromise and overdeliver.”
228 capitalized and punctuated sentence
229 capitalized and punctuated sentence
230 capitalized and punctuated sentence
231 replaced “prioritize truth (reality)” with “Prioritize the truth (reality).”
232 capitalized and punctuated sentence; replaced “,” with “and”
233 added “Think”; added ”.”
234 capitalized and punctuated sentence; added “the”
235 capitalized and punctuated sentence
236 capitalized and punctuated sentence
237 added “Hold”; added “.”
238 capitalized and punctuated sentence
239 capitalized and punctuated sentence
240 capitalized and punctuated sentence
241 capitalized and punctuated sentence; added ”think like a computer”
242 capitalized and punctuated sentence
243 capitalized and punctuated sentence
244 replaced “better rigour” to “Better  your rigor.”
249 replaced “anyone can contribute” with; Anyone can contribute to Fleet.
250 capitalized and punctuated sentence
251 capitalized and punctuated sentence
252 capitalized and punctuated sentence
253 capitalized and punctuated sentence
254 capitalized and punctuated sentence
255 capitalized and punctuated sentence
256 capitalized and punctuated sentence
257 replaced “write things down” with “Write everything down.”
258 replaced "handbook first” with “Use the "handbook first" strategy.”
259 replaced “it” with “your work”;  capitalized and punctuated sentence
260 capitalized and punctuated sentence
261 capitalized and punctuated sentence
262 added “Have”; deleted “()”; added “.”
263 capitalized and punctuated sentence
264 capitalized and punctuated sentence; replaced “,” with “and”
265 capitalized and punctuated sentence; added “a” after “consensus”
266 capitalized and punctuated sentence
267 capitalized and punctuated sentence
268 added “Everything we do is”; added “.”
269 added “We”; added “.”
270 capitalized and punctuated sentence
271 capitalized and punctuated sentence
272  capitalized and punctuated sentence; added “your”
This commit is contained in:
Desmi-Dizney 2022-04-13 01:09:26 -05:00 committed by GitHub
parent a594f89e8a
commit 3aff4e8c18
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23

View file

@ -6,26 +6,26 @@ Fleet Device Management Inc is an [open core company](https://www.heavybit.com/l
We are dedicated to:
- 🧑‍🚀 automating IT and security
- 💍 reducing the proliferation of agents and growing the adoption of osquery (one agent to rule them all)
- 🪟 privacy, transparency, and trust through open source software
- 👁️ remaining the freshest, simplest source of truth for every kind of computing device and OS
- 💻 building a better way to manage computers
- 🧑‍🚀 automating IT and security.
- 💍 reducing the proliferation of agents, and growing the adoption of osquery (one agent to rule them all).
- 🪟 privacy, transparency, and trust through open source software.
- 👁️ remaining the freshest, simplest source of truth for every kind of computing device and OS.
- 💻 building a better way to manage computers.
## Culture
### All remote
Fleet Device Management Inc. is an all-remote company, with team members spread across 4 continents and 8 time zones. The wider team of contributors from [all over the world](https://github.com/fleetdm/fleet/graphs/contributors) submit patches, bug reports, troubleshooting tips, improvements, and real-world insights to Fleet's open source code base, documentation, website, and company handbook.
Fleet Device Management Inc. is an all-remote company, with team members spread across 4 continents and 8 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.
### Open source
The majority of the code, documentation, and content we create at Fleet is public and source-available, and we strive to be broadly 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.
The majority of the code, documentation, and content we create 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.
### Direct responsibility
We use the concept of [directly responsible individuals](https://fleetdm.com/handbook/people#directly-responsible-individuals) (DRIs) to know who is responsible for what. Every group maintains their own dedicated [handbook page](https://fleetdm.com/handbook), 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").
We use the concept of [directly responsible individuals](https://fleetdm.com/handbook/people#directly-responsible-individuals) (DRIs) to know who is responsible for what. Every group maintains its own dedicated [handbook page](https://fleetdm.com/handbook), 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").
#### Group Slack channels
Every group at Fleet maintains certain Slack channels, 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 who is responsible for keeping up with all new messages, even if they aren't explicitly mentioned (`@`).
Every group at Fleet maintains specific Slack channels, 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 (`@`).
## Things new and old team members should know
### Why do we wireframe first?
@ -35,34 +35,34 @@ Every group at Fleet maintains certain Slack channels, which all group members j
- We can throw it away after changes. Coding first leaves verbiage that is difficult to update, if it ever gets done at all.
- It allows you to simplify the creation and testing of error messages.
- Iterating in wireframes first lets us do all this for:
- Error messages
- Layouts
- Flows
- Interactions
- Help text
- Button text
- Forms
- URLs
- API parameters
- API response data…and more
- error messages.
- layouts.
- flows.
- interactions.
- help text.
- button text.
- forms.
- URLs.
- API parameters.
- API response data…and more.
### Why mono repo?
- One repo keeps all of the relevant work in one place. The only exception is when working on something confidential.
- One repo keeps all of the relevant work in one place. The only exception is when we're working on something confidential.
- One repo means that there is less to get lost.
- One repo pools GitHub stars to reflect Fleets actual presence better.
### Why organize work in team-based kanban boards?
- Kanban boards provide a uniform layout across all teams where anyone in the company can look to see what other teams are working on and have coming up.
- The different columns on the boards allow us to create a game plan for our to-do list for each 3 week iteration.
- The different columns on the boards allow us to create a game plan for our to-do list for each 3-week iteration.
- These boards allow anyone in the world to contribute.
### Why 3 week cadence?
### Why 3-week cadence?
- Fleet product is released every 3 weeks, so everyone in the company is synced up to this same schedule.
- Other companies use a 4 week release cycle, but at Fleet, we like to move a little faster to get more done.
- Everyone always knows when the new release is, so they also know when their work is due.
- Other companies use a 4-week release cycle, but at Fleet, we like to move a little faster to get more done.
- Everyone knows when the new release is, so they also know when their work is due.
### Why agile?
@ -90,11 +90,11 @@ Our values and mission.
- Generated documentation via tools like Swagger/OpenAPI has a tendency to get out of date and becomes harder to fix to make it up to date.
- There is less control over how to add annotations to the doc.
- It has less visibility/ accessibility/ modifiability for people without Golang coding experience.
- Fully integrating with swagger's format sufficiently to document everything involves more people on the team learning about the intricacies of swagger (instead of editing in markdown that looks like any other markdown in the docs/website)).
- Fully integrating with swagger's format sufficiently to document everything involves more people on the team learning about the intricacies of swagger (instead of editing in Markdown that looks like any other Markdown in the docs/website)).
- Autogenerating docs is not the only way to make sure docs accurately reflect the API.
- Generated docs become just as out of date as handmade docs, except since they are generated, they become more difficult to edit and therefore gated/siloed. Adaptability is efficient.
- Using markdown allows anyone to edit our docs.
- Replacing markdown files with code comments makes API reference docs harder to locate and edit.
- Using Markdown allows anyone to edit our docs.
- Replacing Markdown files with code comments makes API reference docs harder to locate and edit.
@ -108,12 +108,12 @@ Fleet's values are a set of five ideals adopted by everyone on the team. They d
4. 🔵 Objectivity
5. 🟣 Openness
When a new team member joins Fleet, they adopt the values, from day 1. This way, even as the company grows, everybody knows what to expect from the people they work with. Having a shared mindset keeps us quick and determined.
When a new team member joins Fleet, they adopt the values, from day 1. This way, even as the company grows, everybody knows what to expect from the people they work with. Having a shared mindset keeps us quick and determined.
### 🔴 Empathy
Empathy leads to better understanding, better communication, and better decisions. Try to understand what people may be going through, so you can help make it better.
- be customer first
- Be customer-first.
<!-- TODO: Figure out what to do with this commented-out bit. I wrote it, but it's too long. Maybe just delete it. (mikermcneil, feb 26, 2022)
> #### Customer first
@ -124,152 +124,152 @@ Empathy leads to better understanding, better communication, and better decision
> Imagine you are the person making the decision to buy Fleet. Imagine you are responsible for all of your organization's laptops and servers. Imagine you log in to the product every day. Imagine you are the developer writing code to integrate with Fleet's REST API. Imagine you are deploying the server, or running the upgrade scripts. Imagine you are responsible for keeping your organization's computers secure and running smoothly.
>
> You would rest easier, knowing that everyone who works at Fleet is seeking to deliver the experience they would want for themselves, in your shoes. -->
- consider your counterpart
- for example: customers, contributors, colleagues, the other person in your Zoom meeting, the other folks in a Slack channel, the people who use software and APIs you build, the people following the processes you design.
- ask questions like you would want to be asked
- assume positive intent
- be kind
- quickly review pending changes where your review was requested <!-- TODO: (when you are requested as a reviewer in GitHub, respond quickly. If pull requests start to stack up, merge conflicts can arise, or the original author can forget, or lose context for why they were making the change. The more pending changes there are, the harder it is to sort through what needs to be reviewed next.) -->
- be punctual
- end meetings on time
- role play as a user
- don't be afraid to rely on your imagination to understand <!-- TODO: (When making changes, put yourself in the mindset of the end user. Keep in mind how someone might use the product or process you're building for the first time, or how someone accustomed to the old way might react to a new change.) -->
- developers are users too (REST API, fleetctl, docs)
- contributor experience matters (but product quality and commitments come first)
- bugs cause frustrating experiences and alienate users
- patch with care (upgrading to new releases of Fleet can be time-consuming for users running self-managed deployments) <!-- TODO: (patch releases are important for improving security, quality, and stability. Cut a patch release if there is a security concern, previously stable features are unusable, or if a new feature advertised in the current release is unusable. But remember that people have to actually install these updates!) -->
- confusing error messages make people feel helpless, and can fill them with despair
- error messages deserve to be good (it's worth it to spend time on them)
- UI help text and labels deserve to be good (it's worth it to spend time on them)
- hospitality
- "be a helper" -mr rogers
- think and say [positive things](https://www.theatlantic.com/family/archive/2018/06/mr-rogers-neighborhood-talking-to-kids/562352/)
- use the `#thanks` channel to show genuine gratitude for other team member's actions
- talking with users and contributors is time well spent
- embrace the excitement of others (it's contagious)
- make small talk at the beginning of meetings
- be generous (go above and beyond; for example, the majority of the features Fleet releases [will always be free](https://fleetdm.com/pricing))
- apply customer service principles to all users, even if they never buy Fleet
- be our guest
- better humanity
- Consider your counterpart.
- For example: customers, contributors, colleagues, the other person in your Zoom meeting, the other folks in a Slack channel, the people who use software and APIs you build, the people following the processes you design.
- Ask questions as you would want to be asked.
- Assume positive intent.
- Be kind.
- Quickly review pending changes where your review was requested. <!-- TODO: (when you are requested as a reviewer in GitHub, respond quickly. If pull requests start to stack up, merge conflicts can arise, or the original author can forget, or lose context for why they were making the change. The more pending changes there are, the harder it is to sort through what needs to be reviewed next.) -->
- Be punctual.
- End meetings on time.
- Role play as a user.
- Don't be afraid to rely on your imagination to understand. <!-- TODO: (When making changes, put yourself in the mindset of the end user. Keep in mind how someone might use the product or process you're building for the first time, or how someone accustomed to the old way might react to a new change.) -->
- Developers are users too (REST API, fleetctl, docs).
- The contributor experience matters (but product quality and commitments come first).
- Bugs cause frustrating experiences and alienate users.
- Patch with care (upgrading to new releases of Fleet can be time-consuming for users running self-managed deployments). <!-- TODO: (patch releases are important for improving security, quality, and stability. Cut a patch release if there is a security concern, previously stable features are unusable, or if a new feature advertised in the current release is unusable. But remember that people have to actually install these updates!) -->
- Confusing error messages make people feel helpless and can fill them with despair.
- Error messages deserve to be good (it's worth it to spend time on them).
- UI help text and labels deserve to be good (it's worth it to spend time on them).
- Be hospitable.
- "Be a helper." -Mr. Rogers
- Think and say [positive things](https://www.theatlantic.com/family/archive/2018/06/mr-rogers-neighborhood-talking-to-kids/562352/).
- Use the `#thanks` channel to show genuine gratitude for other team member's actions.
- Talking with users and contributors is time well spent.
- Embrace the excitement of others (it's contagious).
- Make small talk at the beginning of meetings.
- Be generous (go above and beyond; for example, the majority of the features Fleet releases [will always be free](https://fleetdm.com/pricing)).
- Apply customer service principles to all users, even if they never buy Fleet.
- Be our guest.
- Better humanity.
### 🟠 Ownership
<!-- TODO: short preamble -->
- take responsibility
- think like an owner
- follow through on commitments (actions match your words)
- own up to mistakes
- understand why it matters (the goals of the work you are doing)
- consider business impact (fast forward 12 months, consider total cost of ownership over the eternity of maintenance)
- do things that don't scale, sometimes
- be responsive
- respond quickly, even if you can't take further action at that exact moment
- when you disagree, give your feedback; then agree and commit, or disagree and commit anyway
- prefer short calls to long, asynchronous back and forth discussions in Slack
- procrastination is a symptom of not knowing what to do next (if you find yourself avoiding reading or responding to a message, schedule a Zoom call with the people you need to figure it out)
- we win or lose together
- think about the big picture, beyond your individual team's goals
- success == creating value for customers
- you're not alone in this - there's a great community of people able and happy to help
- don't be afraid to spend time helping users, customers, and contributors (including colleagues on other teams)
- be proactive: ask other contributors how you can help, regardless who is assigned to what
- get all the way done; help unblock team members and other contributors to deliver value <!-- TODO: (collaborate; help teammates see tasks through to completion) -->
- take pride in your work
- be efficient (your time is valuable, your work matters, and your focus is a finite resource; it matters how you spend it)
- you don't need permission to be thoughtful
- reread anything you write for users <!-- TODO: (Check everything that a user might read for clarity, spelling errors, and to make sure that it provides value.) -->
- take your ideas seriously (great ideas come from everyone; write them out and see if they have merit)
- think for yourself, from first principles
- use reason (believe in your brain's capacity to evaluate a solution or idea, regardless of how popular it is)
- you are on a hero's journey (motivate yourself intrinsically with self-talk; even boring tasks are more motivating, fun, and effective when you care)
- better results
- Take responsibility.
- Think like an owner.
- Follow through on commitments (actions match your words).
- Own up to mistakes.
- Understand why it matters (the goals of the work you are doing).
- Consider the business impact (fast forward 12 months, consider the total cost of ownership over the eternity of maintenance).
- Do things that don't scale, sometimes.
- Be responsive.
- Respond quickly, even if you can't take further action at that exact moment.
- When you disagree, give your feedback; then agree and commit, or disagree and commit anyway.
- Favor short calls to long, asynchronous back and forth discussions in Slack.
- Procrastination is a symptom of not knowing what to do next (if you find yourself avoiding reading or responding to a message, schedule a Zoom call with the people you need to figure it out).
- We win or lose together.
- Think about the big picture, beyond your individual team's goals
- Success equals creating value for customers.
- You're not alone in this (there's a great community of people able and happy to help).
- Don't be afraid to spend time helping users, customers, and contributors (including colleagues on other teams).
- Be proactive (ask other contributors how you can help, regardless of who is assigned to what).
- Get all the way done (help unblock team members and other contributors to deliver value). <!-- TODO: (collaborate; help teammates see tasks through to completion) -->
- Take pride in your work.
- Be efficient (your time is valuable, your work matters, and your focus is a finite resource; it matters how you spend it).
- You don't need permission to be thoughtful.
- Reread anything you write for users. <!-- TODO: (Check everything that a user might read for clarity, spelling errors, and to make sure that it provides value.) -->
- Take your ideas seriously (great ideas come from everyone; write them out and see if they have merit).
- Think for yourself, from first principles.
- Use reason (believe in your brain's capacity to evaluate a solution or idea, regardless of how popular it is).
- You are on a hero's journey (motivate yourself intrinsically with self-talk; even boring tasks are more motivating, fun, and effective when you care).
- Better your results.
### 🟢 Balance
Between overthinking and rushing, there is a [golden mean](https://en.wikipedia.org/wiki/Golden_mean_%28philosophy%29).
- iterate
- baby steps <!-- TODO: (look for ways to make the smallest, minimally viable change. Small changes provide faster feedback, and help us to stay focused on quality) -->
- pick low-hanging fruit (deliver value quickly where you can)
- think ahead, then make the right decision for now
- look before you leap (when facing a non-trivial problem, get perspective before you dive in; what if there is a simpler solution?) <!-- TODO: When facing a (non-trivial) problem, take a step back before diving into fixing it - put the problem back in context, think about the actual goal and not just the issue itself, sometimes the obvious solution misses the end goal, sometimes a simpler solution will emerge, or it may just confirm that the fix is the right one and you can go ahead with better confidence -->
- move quickly
- "everything is in draft"
- think, fast (balance thoughtfulness and planning with moving quickly)
- aim to deliver daily
- move quicker than 90% of the humans you know
- resist gold-plating; avoid bike-shedding
- less is more
- focus on fewer tasks at one time <!-- TODO: (By focusing on fewer tasks at once, we are able to get more done, and to a higher standard, while feeling more positive about our work in the process.) -->
- "boring solutions"
- finish what you start, or at least throw it away loudly in case someone wants it
- keep it simple (prioritize simplicity; people crave mental space in design, collaboration, and most areas of life) <!-- reduce cognitive load -->
- use fewer words (lots of text == lots of work)
- as time allows ("I would have written a shorter letter, but I did not have the time." -Blaise Pascal)
- make time for self-care
- to help you bring your best self when communicating with others, making decisions, etc
- consider taking a break or going for a walk
- take time off; it is better to have 100% focus for 80% of the time than it is to have 80% focus for 100% of the time
- think about how to best organize your day/work hours to fit your life and maximize your focus
- better focus
- Remember to iterate.
- Work in baby steps. <!-- TODO: (look for ways to make the smallest, minimally viable change. Small changes provide faster feedback, and help us to stay focused on quality) -->
- Pick low-hanging fruit (deliver value quickly where you can).
- Think ahead, then make the right decision for now.
- Look before you leap (when facing a non-trivial problem, get perspective before you dive in; what if there is a simpler solution?). <!-- TODO: When facing a (non-trivial) problem, take a step back before diving into fixing it - put the problem back in context, think about the actual goal and not just the issue itself, sometimes the obvious solution misses the end goal, sometimes a simpler solution will emerge, or it may just confirm that the fix is the right one and you can go ahead with better confidence -->
- Move quickly.
- "Everything is in draft."
- Think, fast (balance thoughtfulness and planning with moving quickly).
- Aim to deliver daily.
- Move quicker than 90% of the humans you know.
- Resist gold-plating and avoid bike-shedding.
- Less is more.
- Focus on fewer tasks at one time. <!-- TODO: (By focusing on fewer tasks at once, we are able to get more done, and to a higher standard, while feeling more positive about our work in the process.) -->
- Go for "boring solutions."
- Finish what you start, or at least throw it away loudly in case someone wants it.
- Keep it simple (prioritize simplicity; people crave mental space in design, collaboration, and most areas of life). <!-- reduce cognitive load -->
- Use fewer words (lots of text equals lots of work).
- Complete tasks as time allows ("I would have written a shorter letter, but I did not have the time." -Blaise Pascal).
- Make time for self-care.
- This will help you bring your best self when communicating with others, making decisions, etc.
- Consider taking a break or going for a walk.
- Take time off; it is better to have 100% focus for 80% of the time than it is to have 80% focus for 100% of the time.
- Think about how to best organize your day/work hours to fit your life and maximize your focus.
- Better your focus.
### 🔵 Objectivity
<!-- TODO: write short preamble, like the others -->
- be curious
- ask great questions & take the time to truly listen
- listen intently to feedback, and genuinely try to understand (especially constructive criticism) <!-- TODO: Trust the feedback from counterparts. Its easy to quickly say “no” or ignore feedback because were busy and we often default to our way of thinking is right. Trust that your counterpart is making a good suggestion and give it the time/consideration it deserves. -->
- see failure as a beginning (it is rare to get things right the first time)
- question yourself ("why do I think this?")
- underpromise, overdeliver
- quality results often take longer than we anticipate
- be practical about your limits, and about what's possible with the time and resources we have
- be thorough (don't settle for "the happy path"; every real-world edge case deserves handling)
- prioritize truth (reality)
- be wrong, show your work (it's better to make the right decision than it is to be right)
- "strong opinions, loosely held" (proceed boldly, but change your mind in the face of new evidence)
- avoid sunk cost fallacy (getting attached to something just because you invested time working on it, or came up with it)
- be fair to competitors ("may the best product win.")
- give credit where credit is due; don't show favoritism <!-- as it breeds resentment, destroys employee morale, and creates disincentives for good performance. Seek out ways to be fair to everyone - https://about.gitlab.com/handbook/values/#permission-to-play -->
- facts, over commentary
- Be curious.
- Ask great questions & take the time to listen truly.
- Listen intently to feedback, and genuinely try to understand (especially constructive criticism). <!-- TODO: Trust the feedback from counterparts. Its easy to quickly say “no” or ignore feedback because were busy and we often default to our way of thinking is right. Trust that your counterpart is making a good suggestion and give it the time/consideration it deserves. -->
- See failure as a beginning (it is rare to get things right the first time).
- Question yourself ("why do I think this?").
- Underpromise and overdeliver.
- Quality results often take longer than we anticipate.
- Be practical about your limits, and about what's possible with the time and resources we have.
- Be thorough (don't settle for "the happy path"; every real-world edge case deserves handling).
- Prioritize the truth (reality).
- Be wrong and show your work (it's better to make the right decision than it is to be right).
- Think "strong opinions, loosely held" (proceed boldly, but change your mind in the face of new evidence)
- Avoid the sunk cost fallacy (getting attached to something just because you invested time working on it, or came up with it).
- Be fair to competitors ("may the best product win.").
- Give credit where credit is due; don't show favoritism. <!-- as it breeds resentment, destroys employee morale, and creates disincentives for good performance. Seek out ways to be fair to everyone - https://about.gitlab.com/handbook/values/#permission-to-play -->
- Hold facts, over commentary.
- speak computer to computers
- a lucky fix without understanding does more harm than good
- when something isn't working, use the scientific method
- especially when there is a bug, or when something is slow, or when a customer is having a problem
- assume it's your fault
- assume nothing else
- better rigour
- A lucky fix without understanding does more harm than good.
- When something isn't working, use the scientific method.
- Especially think like a computer when there is a bug, or when something is slow, or when a customer is having a problem.
- Assume it's your fault.
- Assume nothing else.
- Better your rigor.
### 🟣 Openness
<!-- TODO: preamble -->
- anyone can contribute
- be outsider-friendly, inclusive, and approachable
- [use small words](http://www.paulgraham.com/writing44.html) so readers understand more easily
- prioritize accessible terminology and simple explanations to provide value to the largest possible audience of users
- avoid acronyms and idioms which might not translate
- welcome contributions to your team's work, from people inside or outside the company
- get comfortable letting others contribute to your domain
- believe in everyone
- write things down
- "handbook first"
- writing it down makes it real and allows others to read on their own time (and in their own timezone)
- never stop consolidating and deduplicating content (gradually, consistently, bit by bit)
- embrace candor
- "short toes" (don't be afraid of stepping on toes)
- don't be afraid to speak up (ask questions, be direct, and interrupt)
- give pointed, respectful feedback <!-- (in the same way you would want to receive it) -->
- take initiative in trying to improve things (no need to wait [for consensus](https://twitter.com/ryanfalor/status/1182647229414166528?s=12))
- communicate openly (if you think you should send a message to communicate something, send it; but keep comments brief and relevant)
- be transparent
- "public by default"
- build in the open
- declassify with care (easier to overlook confidential info when declassifying vs. when changing something that is already public from the get-go)
- [open source is forever](https://twitter.com/mikermcneil/status/1476799587423772674)
- better collaboration
- Anyone can contribute to Fleet.
- Be outsider-friendly, inclusive, and approachable.
- [Use small words](http://www.paulgraham.com/writing44.html) so readers understand more easily.
- Prioritize accessible terminology and simple explanations to provide value to the largest possible audience of users.
- Avoid acronyms and idioms which might not translate.
- Welcome contributions to your team's work, from people inside or outside the company.
- Get comfortable letting others contribute to your domain.
- Believe in everyone.
- Write everything down.
- Use the "handbook first" strategy.
- Writing your work down makes it real and allows others to read on their own time (and in their own timezone).
- Never stop consolidating and deduplicating content (gradually, consistently, bit by bit).
- Embrace candor.
- Have "short toes" and don't be afraid of stepping on toes.
- Don't be afraid to speak up (ask questions, be direct, and interrupt).
- Give pointed and respectful feedback. <!-- (in the same way you would want to receive it) -->
- Take initiative in trying to improve things (no need to wait [for a consensus](https://twitter.com/ryanfalor/status/1182647229414166528?s=12)).
- Communicate openly (if you think you should send a message to communicate something, send it; but keep comments brief and relevant).
- Be transparent.
- Everything we do is "public by default."
- We build in the open.
- Declassify with care (easier to overlook confidential info when declassifying vs. when changing something that is already public from the get-go).
- [Open source is forever](https://twitter.com/mikermcneil/status/1476799587423772674).
- Better your collaboration.