My website

Blog

  • Hello world!

    Welcome to WordPress. This is your first post. Edit or delete it, then start writing!

  • What’s in a Name: Employee Titles and Startup Hierarchy 🪜

    Flat as a Board 🪵

    In 2013, e-retailer Zappos famously adopted a flat org structure called Holacracy, which eliminated managers and job titles. Everyone was equal. Everyone was on the same level. It’s an idea that has been trendy in startups for the past decade, and something I’ve experienced a few times at different companies.

    Typically, as a company scales, it’s harder to pull off a flat structure. When you’re 12 people in a room, it’s easy to point to accountability and job responsibilities. When that number balloons to 150, things become infinitely more complicated.

    Without managers, who will be responsible for evaluating an employee’s performance, crucial for how contributors are measured for comp increases each year?

    How will new employees, brought onboard and expected to jump right in, know who to go to for specific issues and information, if everyone is just ‘Steve in the back corner’ and not titled with something descriptive?

    In my experience, the flat lifecycle typically taps out as you grow, right around the time that your org adopts stricter product methodologies and swim lanes. What I don’t see talked about nearly enough is the lasting impact of flat structure on individual employees: without a job title, it’s harder to market yourself, carve out a niche, or prove your career path to future employers.

    Your Resume Tells a Story 📖

    It’s unrealistic, in this economy but especially in startups, to expect that an employee will be with your company for 20 years. Funding contractions, layoffs, COVID… it’s been an interesting time for tech workers. When they leave your company and start to apply to other jobs, they’ll frequently be evaluated by recruiters (and, in 2024, their burgeoning AI counterparts).

    One of my previous startups had very little cash, and liked to compensate by giving everyone increasingly lofty job titles. Three years in, my salary was the same, but suddenly I was a director. My job duties were overwhelming. At first I thought it was a good sign, that I was being rewarded for my hard work and dedication.

    Fast forward to the advent of the COVID labor market. I was applying to jobs that fit my duties and aspirations, but didn’t necessarily have director in the title, and received rejection after rejection. I chalked it up to strange times until one kindly recruiter told me on the screening call ‘…you’re a director. Why would you want to go backwards? You’d just leave us when something better came along.’ I was floored. The salary would have been a decent pay bump, the benefits an improvement. But my title told a story on my resume that was actually closing doors, instead of opening them. I tweaked my title, applied for the next round of positions, and started getting callbacks right away, all for jobs that paid much more than my ‘director’ salary.

    Desired Verbiage as a Hidden Employee Benefit 💰

    As a founder or leader, one of the kindest hidden benefits you can offer your candidates and new employees is flexibility in their job title. If you’re asking them for manager level work but haven’t put manager in the title, ask yourself if you have a good reason not to. If someone suggests a more descriptive or inclusive title, granting that request makes their expertise clearer to their coworkers, and to whichever HR professional you inevitably hire and entrust with people organization after you surpass the 100 headcount.

    Proper titling also sets employees up for success in five years when you’re acquired and everyone parts ways. You might be thinking ‘Can’t they just call themselves whatever they want when the job hunt?’ Your company might not have required a background check as part of your conditions for employment, but other employers certainly do. It’s a bureaucratic process that involves a third party checking service calling and asking for verification of exact words, dates, and and locations. You’re building a paper trail that allows them to truthfully speak to their experience and prove that they are who they claim to be.

    And to think, offering that benefit doesn’t cost you a dime. 🪙

  • User Documentation – The Scalable Way to Satisfy Customers 📈

    At my first company, we had a gong. Nobody was sure exactly where it came from, but it showed up in the office one day with some badly watered house plants and cemented itself as a permanent part of our culture soon after. In the beginning, every time we signed a new customer, we rang the gong. After a while, we were signing too many customers to regularly keep ringing it without making the other offices on our floor angry.

    It’s a dream scenario: you grow, then grow more, and have a solid customer pipeline. But your early system probably involved personal account management for those customers in the form of emails or calls for every little need. That works with 10 clients, but not 1000.

    An often overlooked but crucial step to scaling is customer documentation. Depending on your product, that might be text, or text and photos, or video clips (or all of the above, if you’re truly prepared). Ten different customers could be reading the same how-to guide at the same time, but only one customer can speak with their account manager at any given moment. Take time zones and distributed teams into consideration, and the benefit of asynchronous customer help becomes clear.

    What Makes Good Customer and User Documentation? 🤔

    A common pitfall I see early stage companies make is the tone and intended audience of their docs. You love your product. You live and breathe whatever it is that you do. Your customer may not. Assume that they need to be introduced to any acronyms, industry terms, or niche concepts. A glossary, or a quick screenshot to identify menu items, can be your best friend.

    That said, keep it as brief as possible. Your reader wants answers, now. Break up text with spacing and images and bullet points to allow for digestion rather than huge blocks of paragraph text.

    Style guides are often an afterthought; a rapidly moving team will throw docs up online and think that any docs are good. But as your product grows, and your docs grow alongside it, the backlog of material to triage and update to a later style preference will become intimidating and costly. Save yourself money and manpower later on by adopting a style guide from day one, even if it’s just simple formatting, key term and tone setting. When in doubt, adopt someone else’s standards.

    The Feedback Pipeline 🗣️

    If you’re successful, many people will be reading your docs. Potentially, you have a huge audience from which to gather feedback. Give your customers and users a clear path to submitting their questions or concerns about the content of help articles and user manuals. My suggestion is always to make it an email address that’s dedicated to just that purpose, or a submission widget if you’re able to get fancy. Letting users comment on help docs, when we know that most comments will come from frustration at either documentation limitations or user error, can leave negative impressions right on the page for the next person who comes to your documentation looking for help.

    And once you collect that feedback, do the right thing and use it. If you have a document that has multiple responses of confusion or frustration, that’s a good indication that you need to tweak the wording, check the content for validity, and even pass that feedback along to QA and Product as a consideration for future releases and design updates.

    Quantity or Quality? 🤝

    My answer: why not both? There’s a myth that good documentation requires big expensive tooling. You don’t need a full Adobe Suite to create impactful and professional images. Tools like Renderforest and Camtasia can get you far enough to produce current visuals that are easily and quickly updated as your product evolves. Plenty of good, solid documentation starts out in Google Drive rather than MadCap Flare or (cringe) Salesforce Knowledge.

    Good customer documentation is about intent, not pedigree. 🐩

  • On Tracking Personal Achievements: Advice For Young Professionals 🎓

    My first job other than teaching was at a data analytics startup. I knew nothing about the private sector, let alone tech. Over my five year tenure there, I had the opportunity to learn some valuable lessons from more experienced coworkers who were on their third or fourth company, but still under 40. Here are two that have been the most beneficial to my own career.

    Pre-Emptive Resignation Letters and Achievement Lists 📑

    I had been the company admin for two years when we hired our head of account management. He had endless energy that I admired, managing to bounce from problem to problem with a tenacity and perseverance that he instilled to every account manager that joined his team. One day on a walk back from our local ice cream shop in Center City, biting into the cone and devouring the melting sugar, he gave me the best piece of advice I was ever gifted as young professional.

    He encouraged me to keep what he called ‘the desk drawer file.’ It held two pieces of paper: a mock resignation letter with a list of why I’d consider leaving the job, written in my first week and tucked away, and a running list of achievements I’d made on the job that I added to as they happened.

    “The first acts as a list of things you couldn’t compromise on when you were emotionally removed from this place. When you’re frustrated, you can look at it and compare what’s happening to determine if you’re compromising on your ethics or values for a paycheck. The list shows you what you learned, what you accomplished, and helps you weigh if staying is/was productive, especially on days when you feel like you’re not learning or doing anything of value.”

    In the years since, I’ve kept a desk drawer file at each of my jobs, even when I’ve worked remotely. When it’s come time to make a difficult decision to move on or have a serious discussion with management about my growth and trajectory, the documentation from my past self has significantly helped me to make rational, well-considered choices. And, perhaps most satisfyingly, when I went on to manage my own direct reports, I was able to pass along this advice to others.

    Yogurt Lids FTW🏅

    A guy who would end up being one of our more senior developers was determined to have us hire him. He applied when we didn’t have jobs posted, when we posted jobs that didn’t suit him, and finally when we could use him as an engineer. Suffice to say, he was driven. But he was remarkably laid back in his attitude, something that meshed well with our existing team.

    When he missed a deadline on a particularly tricky project, something that we didn’t penalize for or particularly complain about as a small group under 30 people that barely had a performance process, I could tell he was frustrated with himself. It took me a few days to notice the pile of yogurt lids stacked on his desk, when he stopped me from throwing away what I thought was trash on a routine sweep of the office.

    “Those are my reminders. Every morning that I eat my breakfast yogurt and I don’t have the job done, I add to the stack.” It grew, and by the end of the week he’d fashioned a chain out of paperclips, hanging the string of them around the corner of his second monitor. Other devs took note, and would drop by to offer words of encouragement or code review. At the end of the month, when he finally did his final commit, there was a round of applause at daily stand-up.

    In any job, we all have our yogurt lid task–an impossible problem, a whale that just keeps getting way from us with shifting priorities. Out of sight, out of mind, right? It’s easy to forget its importance if you can’t see it, especially if your startup is small enough not to use project management or task tracking tools. It snowballs, until finally you get so used to expecting the task not to get done that you stop working on it altogether.

    Personally, I’ve developed a dedicated post-it note system for outstanding tasks. Once a week or once a month, depending on the job, I assess what hasn’t moved. On separate Post-it notes, I block out its title in clear letters with the amount of time it’s been left undone. The little neon squares stick to the bottom of my monitor, reminding me each time I sit down for the day that it’s unresolved and lurking under the surface. The satisfaction you feel when you get to shred that Post-it (or toss that yogurt lid) is immense. And, to me, better than just clicking a task off a Trello board.

  • Assessment Isn’t a Dirty Word 🚫

    Employees hear ‘assessment’ and associate it with the tests they endured in school. It’s important to break that association, either by renaming the term itself or explaining why you’re implementing assessments to begin with.

    You’re a member of a support team. Every quarter, engineering rolls out a new integration, and you’re responsible for knowing all its ins and outs, and helping users become empowered product masters. You attend trainings, and complete training modules. Then what? How do you know that you’re fully up to speed, other than to wait for a customer to ask a question you don’t know the answer to? And how does your manager know that they’re supporting you in a way that’s effective?

    Assessments are tools, simply. They allow learners to self-diagnose what they’re foggy on, and provide important data for learning and development managers to iterate the next version of training to be more effective. If everyone gets question six wrong, you can look at that question’s topic, and determine what additional gaps need to be filled. Tamp down on anxiety for the test-averse by communicating that your assessments are for self-evaluation and help only, not measures of job performance or capability.

    Assessment Doesn’t Require A Big Budget 💸

    Often, I see small companies assume that they need big company tools to achieve their learning goals. If your team is 15 people and you have one trainer, do you really need Articulate? And will they have time to learn and use the software if they’re fulfilling the traditional startup job requirement of wearing many hats? That hefty licensing fee might be better put towards other expenses more essential for an earlier, smaller company. It’s entirely possible to deliver solid assessment, with backend analytics to show you exactly where and how your learners are struggling, for free or very low cost.

    Subversive Assessment 🙈

    Ways to evaluate competency and check for understanding without overtly administering traditional tests and quizzes include:

    Flashcards: let your employees gauge their own competency while practicing key terms and concepts. The COVID digital revolution left us with some great free tools to set up flashcard decks, such as Quizlet and Memozora. These can be set up even if you don’t have an LMS, sent out in to-do tasks for individuals in your existing project management software.

    Gamification: set up live team challenges to use friendly competition to your advantage, or create async games with results that can be tracked in your LMS using H5P. Lumi is my favorite free H5P editor. When files are uploaded to an LMS (Moodle, WordPress, and Drupal all work with H5P), you’ll be able to see the history of each session completed by learners.

    Live Roleplays: have your learners test out their product knowledge on a pre-designed scenario, either via face-to-face human interaction or in a simulation of a product issue escalated via fake support ticket, and see if they can solve the user’s problem with accuracy and efficiency.

    Wrong Answers Should Mean Support, Not Penalty 🤝

    Lastly, with any learning program, you want to make sure that your learners feel safe to disclose when they don’t know something. Set clear expectations for what will happen if they do poorly on the assessment, and never make it a disciplinary action or performance improvement plan related to termination as your first result when rolling out new training programs. Keep in mind that often, their failure to know something can be a reflection on your failure to properly set them up for success. Give clear timelines for when they need to be fully competent on material, and continuously iterate your assessments and activities to hit home on the parts your learners repeatedly stumble through.

  • Mission, Vision, and Other Buzzwordy Guiding Statements 📣

    Talk to anyone who’s worked at a company that has gone through the process of identifying its vision and mission, and I can nearly guarantee that at some point you’ll hear the same sentiments I’ve encountered: I don’t really know the difference between the two, or, perhaps more sinister, I don’t know why they made us do this.

    Many startups go through the drafting process as they scale, wanting to both appear like a more serious company and have something to point to as their raison d’etre. To board members and executive teams, it feels necessary. To the average worker chugging along and completing their work to help run the machine, it can feel like a confusing waste of time.

    Swing and a Miss 🏓

    One of my early companies took up the task of identifying its mission and vision. As a member of its steering team, I was involved in countless regular meetings where we were asked to come up with words and phrases that described what we did, and why we did it. None of us, including the founder, had ever gone through the process before, and we followed their lead as to how to brainstorm and come up with material. Weekly, we’d return to the conference room, spread out the categorized post it notes from our previous sessions, and pick apart the things we’d thought seven days before but now second-guessed. This went on for an entire quarter.

    It was exhausting.

    When we unveiled the chosen mission and vision to the entire company, all sitting in one room, the founder asked for feedback…and got very little. It’s okay, sure. If you say this is what we’re doing, I’m onboard. The disconnect between the people who were leading the team and the team workers who directly served customers and the product had never been more apparent to me.

    Later, at a different company, leadership tried to account for this by starting the process with a survey sent to the entire team. They asked for three words to describe us, with a brief explanation for each choice. When mission and vision were unveiled soon after, they could point to the survey responses as their inspiration. But they failed to properly introduce the difference and reason between the two. Time and time again in the weeks after, I heard employees say Aren’t they the same thing? How does this even affect my work?

    If you’re a small company going through this exploratory process, here are the steps I recommend for how to craft, evaluate, and roll out your guiding statements with both executive and worker bee buy-in.

    Step 1 – Why Are We Doing This? 🤔

    Leadership should have a clear understanding of what they hope to gain by having these standardized statements. The answer to this will differ depending on what your company does. It could be that you want to make a clear banner for everyone to point strategic goals and objectives toward in your planning process. Or, more simply, it could be that you want a concise statement of who you are and what you do to attract potential new hires. Some leaders feel like having these statements will fix whatever organizational defects are already built into their structure and work habits. If you’re relying on these statements as a panacea for your dysfunction, I urge you to consider practical solutions and better management instead.

    Step 2 – Involve Your Worker Bees 🐝

    If you want your mission and vision to be something that speaks to your team, have the team provide you with data on how they feel about your company and their jobs. What is it that they do on a daily basis? What counts as success, considering how the product or service is used? And what kind of language does the majority of the team use to communicate–more buzzwordy business speak, sports metaphors, nerd culture? If you want people to be invested in what you have to say, it’s essential that you speak their language, and meet them on their level. Presenting something you deem so serious in terms and phrasing that doesn’t fit your culture will come across as disconnected and out of touch.

    Step 3 – Draft, Iterate, and Prepare to Educate 🍎

    Using your whole-team feedback, leadership should take on the duties of drafting out final statements. This must include preparations for educating your entire company on the differences between mission, vision, and values statements. If you can’t clearly explain that difference, how can you communicate the importance of each to the people you want to adopt them?

    TL:DR: A vision statement describes where the organization wants to be in the future, and a mission statement describes what the organization needs to do now to achieve the vision. Note that values sometimes come up in explanations of mission and vision. They’re tangentially related, but separate, and honestly deserve their own individual post.

    I like to take example statements from large, well known companies, and compare them for the team.

    Google Mission: To organize the world’s information and make it universally accessible and useful
    Google Vision: To provide access to the world’s information in one click.

    Patagonia Mission: We’re in business to save our home planet
    Patagonia Vision: Build the best products, cause no unnecessary harm, and use business to inspire and implement solutions to the environmental crisis

    Each is different. Each makes sense given our own experiences with their product(s). If you now try to craft a mission around your own product, you can also compare that to these examples to see how your attempt stacks up.

    Step 4 – Display, Mention, But Don’t Overdo 📖

    You have finished statements. Congrats! Now what?

    One odd thing I’ve seen companies do is try to make every action, every day, point back to their statements. That’s not what the statements are intended for and, more importantly, that kind of bureaucratic overkill will create resentment towards your statements and your culture. Point to them when necessary, and consider revision as necessary after significant periods of time.

    Mission and vision aren’t rocket science. Unless you’re NASA or SpaceX. Then, maybe it is 🚀.

  • On Documentation, Jargon, and Rick and Morty 🥒

    The adult swim cartoon Rick and Morty has a running gag about a tool called a plumbus. I’ll spare you a full 360 image of the plumbus, as the other side of the widget looks a little… weirdly NSFW. While traveling to other dimensions and galaxies, it’s advertised on tv commercials as a common, necessary object–so well known, in fact, that there’s no reason to explain it.

    All comedy aside, the plumbus anecdote is an excellent cautionary example for documentation. This thing in our codebase? That internal software tool we’ve been using for half a decade? Everyone knows what it is. Why explain it?

    New hires can be great additions to a team without having 100% of the experience necessary to do their work. Maybe they’re coming from another industry and need a bit of a primer on your specific niche. The gap can also be generational. I once sat in on a career day for a high school group where one of the presenters used the term zip drive to describe storage, and watched every Gen Z teen in the room blink in confusion.

    To craft good, friendly documentation that will work for readers of any background or experience level, you want to ask yourself the following questions.

    Who Will Be Reading the Docs? 📖

    Developers will have an understanding of coding principles. Sales folks, support teams, and account managers may not. Identify who the reader with the largest gap in understanding will be, and build the docs up from there.

    Can I Borrow From What Already Exists? 🤝

    That said, you don’t always have to draft everything from scratch. Let’s say you’re making an internal user guide for Slack. In a software company, most employees will have already used the tool at previous jobs. Recent grads or industry transplants may be experiencing the tool for the first time. Slack has its own excellent documentation. Try linking out to those docs, either in one section for total beginners or interspersed throughout your guide as terms are used for the first time. This allows newbies to follow along without giving paragraphs of overly simple information for your more experienced employees.

    Have I Established a Timeline? 📅

    When explaining a product feature or concept, remember to include a high level history to allow those who join the company after critical events to keep up with the pack. This is crucial for the success of high-growth companies. Which of these statements is more illustrative for any tenure of employee?

    Auto lock is no longer something we offer.

    Or,

    The auto-lock feature was sunset in 2021, but remains for 5% of customers who can’t function without it. We plan to extend this feature for another two years. Account managers have the most current information as to which customers fall into this bucket.

    (Hint, it’s the second one.)

    Can an Image or Video Make This Better? 🖼️

    Visual depictions are no replacement for text explanations, especially in terms of knowledge base and wiki searches that pull from text to return related results. But sometimes, text alone can’t properly explain how to complete a task, or how something works. A well placed screenshot or video snippet can make a world of difference for new and upskilling employees.

    Now, back to plumbuses. Did you know that they’re worth six and a half brapples?

  • Onboarding: Not Just For Customers 👋

    Onboarding is a Funny Word

    To some people in tech, it’s automatically associated with customers, the people who use your product. To anyone in People Ops or HR, it’s a vital part of the candidate experience, taking a new hire and getting them ready for whatever you’ve hired them to do. Small companies and startups only continue forward if revenue comes in. But that healthy obsession with customer lifetime value can often give you blinders to employee lifetime value, or how to make sure you get what you pay for with your team.

    Let’s say you hire your first developer. They stay with you for three good years, and spit out an impressive amount of work product. Then, they leave, at which point you have five other developers. Do they know the information that was rattling around in developer 1’s head? Did developer 1 document everything, or just buzz along without notations because the goal was speed, not foundation? In these scenarios, companies learn a painful lesson. Documentation is crucial to avoiding knowledge loss, especially from original employees who are valuable for their institutional knowledge but might not want to stick around as your company matures and scales into something bigger.

    Inexperienced hiring teams assume that someone will sign their offer letter and sit down to work the next day, knowing absolutely everything about the product and how to build and use it. In smaller teams, the few people sitting next to one another in a room can casually demo and answer questions. That model does not work when your team is 100, 500, 1000 people, and is hard at any size for remote companies. Plus, if a newer hire is feeling overwhelmed and poorly looked after, they’re more likely to job hunt and leave you for someone more organized. Keep in mind, it’s much more expensive to replace an employee than it is to keep an existing one. Think about the time and investment it takes to set up onboarding as a cost-effective way of retaining your talent.

    What Makes a Good Employee Onboarding Program? 👋

    Empathy

    Put yourself in this person’s shoes. Even if they’ve had a job in your industry before, or if they’re coming to your team from another team within your larger organization, they’re going to have to learn new information. Learning by doing is a solid way to build competency, but is it kind to just throw them into the deep end on day one? A sentiment I hear frequently from startup teams in periods of growth is You’re lucky, when I started I didn’t even have a [insert industry-relevant, simple expectation here]. Even if that’s true, don’t revel in your own history of incompetence. It’s everyone’s job to try and make things better for the next employee you hire.

    Setting Expectations

    New hires are excited to get going, but often afraid to look stupid or inexperienced in front of new people who will be their coworkers. Set expectations for how questions can be asked and answered. Leadership that models open communication and the concept that there are no dumb questions will reap future rewards tenfold when that employee’s knowledge has grown. If they’ve been conditioned to pose questions without fear, their open declaration of gap in understanding will be nuanced, and beneficial for the whole team.

    Tone Setting

    For remote teams especially, quality documentation that a new employee can follow is crucial for a good onboarding experience. How you communicate that information in documentation is entirely up to you and your company, but is also an often overlooked tool for building culture.

    A new hire will be trying to get a sense of who you are and what you stand for from day one. Plenty of onboarding involves regulations and legally-significant information. But that doesn’t mean that it always has to be delivered with boilerplate. Which is a better way to direct them to set up their employee profile?

    Enter your full legal name and contact information into this spreadsheet. Failure to do so will result in non-payment for hours worked.

    or…

    Follow the prompts to share your personal contact info in this spreadsheet. Until it’s filled out, we can’t pay you! Consider this a priority–do it first before your tackle your other onboarding tasks.

    Both options communicate the same information, but each has a distinct tone that conveys the culture and vibe of the organization giving the directions. I know which I’d rather work for, from just a few sentences.

    Feedback

    Your employee leaves the nest and becomes a full-fledged contributor–congrats! Now it’s time to collect their feedback to iterate on their experience. What was unclear on day one, 30, 90? What’s something they wish they’d known or been told in their first week?

    Good onboarding for high growth companies requires frequent revision and review, updating your materials and processes to ensure that what you’re communicating is current and effective. Of course, feedback is useless unless it’s read, digested, and actioned upon. Commit to following through. 🤝

  • Slack Is NOT a Proper Knowledge Base – No Matter How Much They Say It Is 🙅‍♀️

    This week, I sat in on a webinar hosted by Slack where they stated multiple times that Slack is a knowledge base. Using Slack as your knowledge base (KB) is a rookie mistake. There, I said it.

    I’ve worked for several startups where this practice was disclosed to me as early as the interview process. “We use Slack to store our knowledge and search for it in there when we need it.” This is usually followed by “…and we have a really hard time finding anything.”

    Slack search is only as good as the messages your past selves sent. Think about the last long, live conversation you had in Slack. You and a few other people probably went back and forth, working through a problem, to get to a solution after 50 messages (which were hopefully threaded🤞). In three months, when a new hire needs to know about that decision, you’ll be asking them to wade through all 50 of those messages, plus whatever else has accumulated before or since that convo about that topic, to make sense of it all. And that’s assuming that they knew about the conversation or could find it at all-what if the conversation involved a project that had since been renamed? A product that was now built around entirely different terms or code? The potential for misinformation or misunderstanding is decent.

    I’ve seen companies try to solve these problems with an abundance of channels. “We’ll make so many channels that the content of each will be streamlined and super specific. That will help with search!” Okay, maybe. But do you have faith that all of your employees will a) know about every Slack channel, b) remember/be held accountable for reading and digesting each Slack channel as it updates? I do not.


    All of this also ignores the possibility of Slack deletion and retention policies, which some companies adopt as a safeguard against potential future legal actions or audits. If your project needs a conversation from January to reach its goals in October, but your retention policy deleted that message after 6 months and took no additional steps to back up messages…poof. You’re left fumbling around in the dark.

    By this point, you might be wondering “What About Slack Canvas?“ Slack rolled out this feature last year to encourage users to store more information outside of channel discussions and threads. Each channel and each user has its own Canvas, a small notepad-like space for collaboration and info sharing. I have most frequently seen it suggested as a place to put high level current updates, like project charters and notes between colleagues. In a traditional development shop, it would be on the project managers to make sure a Canvas’ content is current, with the assumption that they and any other hired documentarians would be updating their larger KB in conjunction.

    My question here is why. If Canvas is too small to hold all permanent knowledge, and you need another tool to fulfill that requirement, why make your project managers update information in two separate spaces rather than link employees out of Slack and to the one, tried and true source of truth–be it a KB or a task tracking/management tool? The cardinal sin of documentation management is failing to keep documentation updated. Expecting that updates will happen regularly, in multiple places, increases the likelihood that something will get dropped, and out-of-date information will be read by someone who takes it at face value and acts as if it’s gospel. Keep Canvas for personal to-dos and channel and tool directories, not duplicitous knowledge snippets.

    Slack is a great tool for collaboration and discussion. But when that discussion concludes, leaving your key takeaways floating around in the ether is both lazy and dangerous. Instead:

    1. Come to your conclusion or arrive at your answer.
    2. Pull that answer out into permanent documentation which lives somewhere other than Slack–Confluence, Google Drive, Guru, Notion, whatever particular flavor of KB speaks to you and your team’s needs.
    3. Copy the link to that documentation and add it as a bookmark to relevant Slack channels. This allows readers to get to the single source of truth from multiple touch points.
    4. Sit back and let the knowledge flow ✨.