diff --git a/handbook/company.md b/handbook/company.md index e28da7cc08..95243cbe29 100644 --- a/handbook/company.md +++ b/handbook/company.md @@ -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 Fleet’s 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. -- 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 - - be punctual - - end meetings on time -- role play as a user - - don't be afraid to rely on your imagination to understand - - 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) - - 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. + - Be punctual. + - End meetings on time. +- Role play as a user. + - Don't be afraid to rely on your imagination to understand. + - 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). + - 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 -- 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 -- 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 - - 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). +- 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. + - 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 - - 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?) -- 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 - - "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) - - 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. + - 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?). +- 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. + - 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). + - 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 -- be curious - - ask great questions & take the time to truly listen - - listen intently to feedback, and genuinely try to understand (especially constructive criticism) - - 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 - - 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). + - 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. + - 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 -- 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 - - 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. + - 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.