We are dedicated to
- 🧑🚀 automating IT and security.
- 🪟 privacy, transparency, and trust through open source software.
- 💻 a different way to manage computers.
5 things is too many. But we also care deeply about
- 💍 reducing the proliferation of agents and growing the adoption of osquery (one agent to rule them all).
- 👁️ remaining the freshest, simplest source of truth for every kind of computing device and OS.
While GitLab's 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 as time allows.
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 submits patches, bug reports, troubleshooting tips, improvements, and real-world insights to Fleet's open source code base, documentation, website, and company handbook.
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.
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:
- 🔴 Empathy
- 🟠 Ownership
- 🟢 Balance
- 🔵 Objectivity
- 🟣 Openness
When a new team member joins Fleet, they adopt the values, from day one. This way, even as the company grows, everybody knows what to expect from the people with whom they work. Having a shared mindset keeps us quick and determined.
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.
- Think and make customer-first choices.
- Consider your counterpart.
- For example: keep in mind 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, and the people following the processes you design.
- Ask questions in a way you would want to be asked.
- Assume others have positive intent.
- Be kind.
- Quickly review pending changes when your review is 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.
- Create patches 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 (spending time on them is worth it).
- UI help text and labels deserve to be good (it's worth it to spend time on them).
- Invest in hospitality.
- "Be a helper." -Mr. Rogers
- Think and say positive things.
- Use the
#thankschannel to show genuine gratitude for other team members' 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)
- Apply customer service principles to all users, even if they never buy Fleet.
- Treat everyone as our guests.
- 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).
- Often, you'll need to own processes that won't scale. Not everything should be automated from the start. Your experience with doing things manually will teach us how to scale effectively later.
- 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 over 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
- Finish completely before moving to something new (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).
- 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 its popularity).
- 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).
Between overthinking and rushing, there is a golden mean.
- Iterate your work.
- Look for ways to make frequent, small changes. Small changes provide faster feedback. They are easier to reason about when debugging.
- 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 diving in; there may be a simpler solution).
- Move quickly.
- "Everything is in draft."
- Think fast (balance thoughtfulness and planning with moving quickly).
- Aim to deliver results daily.
- Move faster than 90% of the humans you know.
- Resist gold-plating and avoid bike-shedding.
- Remember, less is more. Focus.
- Focus on fewer tasks at one time.
- Go with "boring solutions."
- Finish what you start, or at least throw it away loudly in case someone else 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).
- 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 helps 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 organize your day/work hours to best fit your life and maximize your focus.
- 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.
- Be rigorous.
- Speak computer to computers. 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 experiences a problem.
- Assume it's your fault.
- Assume nothing else.
- Anyone can contribute to Fleet.
- Be outsider-friendly, inclusive, and approachable.
- Use small words, 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.
- 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).
- Communicate openly (if you think you should send a message to communicate something, send it, but keep comments brief and relevant).
- Be positive, and assume positive intent.
- 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.
When Kolide's attention shifted away from Fleet, and towards their separate, user-focused SaaS offering, the Fleet community took over maintenance of the open source project. After his time at Kolide, Zach continued as lead maintainer of Fleet. He spent 2019 consulting and working with the growing open source community to support and extend the capabilities of the Fleet platform.
Zach partnered with our CEO, Mike McNeil, to found a new, independent company: Fleet Device Management Inc. In November 2020, we announced the transition and kicked off the logistics of moving the GitHub repository.
Fleet has a unique way of organizing work. For more information, check out this page Why this way.
Fleet organizes development groups by their goals. These include members from Design, Engineering, and Product. For more information, check out this page Development groups.
- Public (share with anyone, anywhere in the world)
- Confidential (share only with team members who've signed an NDA, consulting agreement, or employment agreement)
- Classified (share only with founders of Fleet, peepops, and/or the people involved. e.g., US social security numbers during hiring)
There are several special email addresses that automatically relay messages to the appropriate people at Fleet. Each email address meets a minimum response time ("Min RT"), expressed in business hours/days, and has a dedicated, directly responsible individual (DRI) who is responsible for reading and replying to emails sent to that address. You can see a list of those email addresses in "Contacting Fleet" (private Google doc).
There are a number of tools that are used throughout Fleet. Some of these tools are used company-wide, while others are department-specific. You can see a list of those tools in "Tools we use" (private Google doc).
We use special characters to define different types of GitHub labels. By combining labels, we
organize and categorize GitHub issues. This reduces the total number of labels required while
maintaining an expressive labeling system. For example, instead of a label called
platform-dev-backend, we use
#platform :dev ~backend.
|Special character||Label type||Rules||Examples|
||Verb||One or more||
||Adjective||One or more||
|Weekly update reminder||Weekly||On Thursday, Charlie starts a thread in the
|Weekly update||Weekly||On Friday, Charlie updates the KPIs in the "🌈 Weekly updates" spreadsheet, combines the updates from managers into a single message and adds any hiring announcements. Charlie posts the company update in the
The following Slack channels are maintained by Fleet's founders and executive collaborators:
||N/A (announce something company-wide)|
||N/A (say thank you)|
||N/A (be random)|