In the previous post, I shared a few notes on internal communication in tech companies. In this post, I’ll take a step back to discuss what types of communication exist in a tech company, highlighting cross-department communication. For each type of communication, I will discuss the tools that can serve you best… and worst.
Here are the kinds of communication that I noticed along the years at Leverate:
Boards = lists that departments maintain so that everyone in the company can check them out. Boards will usually reflect recent work, so their contents will change with time. Examples:
- Next releases board– maintained by the product team
- Latest sales board– maintained by the sales team
- This month’s lead numbers board– maintained by the marketing department
- This month’s birthdays board– maintained by the HR team
- This year’s holidays in our offices worldwide– maintained by the HR team
Boards can come in different flavors:
- Crucial for day-to-day work OR a nice-to-have transparency tool
- Designed for internal communication in the department OR designed for communicating to other departments
If you ever worked in a sales team, you’ve most likely seen a board that sales leaders love: the monthly leader board. Nothing invites more motivation and focus than these cold hard numbers on the wall.
When shared cross-department, boards are perhaps the most simple and to-the-point transparency tool that I’ve seen. People love them (when they’re up-to-date, of course), and they create a feeling of accountability among critical departments. I highly encourage founders to introduce a board for product, sales and marketing to reflect releases, sales data and marketing data respectively.
What do we need in a board tool?
- Public– anyone can easily check out boards
- Collaborative– anyone can create boards, then quickly edit / comment / like items
- Good lookin’– it’s nice to add some colors or communicate planning vs. execution with a ‘dashboardy’ feeling
- Topics & subscriptions– would be nice if people can subscribe for specific boards (e.g. next releases) and get notified on updates
- Interactive– it would be nice to click an item (e.g. a specific planned release) to get more information (the release notes)
Recommended tools for boards:
- The board feature in daPulse
- A public Google Spreadsheet
- Build your own– home-made boards are always an option: in some offices I’ve seen TV screens projecting retention, sales and even revenues data to all employees
- The wrong tool: emails
Shouts = casual cross-department announcements. Usually to the entire company. Usually happy. You don’t know exactly when they will come. They’ll stick around for a couple of days and then they will get washed away. Examples for shouts in a tech company are:
- An introduction of a new key employee that everybody needs to know, including a picture of them with their dog
- An announcement from the CEO about last week’s acquisition
- Pictures from the crazy team building night that the marketing department had last week, including that video of the VP Marketing dancing on a bar table that will haunt her forever
- An announcement from the VP sales on the epic performance of the sales team during Jan & Feb, including a chart
What do we need in a shout tool?
- Notifies everyone, but minimizes spam– shouts are cool, and sometimes you want to announce something to all, but people don’t like getting 12 random emails per week. Better find a tool that minimizes announcements to all, aggregates notifications and lets people choose their topic(s) of interest
- Social– anyone should be able shout on any topic, because everyone has something interesting to celebrate every now and then. A good tool will let other people quickly like / comment on the shouts. It’s also nice to see who in the company read the shout
- Allows attachments– it’s nice and engaging when shouts come with an inline chart, picture or video
Recommended tools for shouts:
- Posts in Facebook at Work, daPulse or Yammer
- Emails (not ideal)
- The wrong tools: your company wiki, Trello
#3 Knowledge bases
Knowledge base = an evolving collection of articles and media items. Think about a company-wide wiki. Knowledge bases are naturally different from boards and shouts because they contain information that you want to evolve and stay long term.
Examples for knowledge bases in a tech company are:
- The employee handbook that the HR department gives to every new employee in the company
- The FAQ list that the sales department maintains for internal use
- The training procedure for new Account Managers
- The list of books that the VP Product is obsessed with, so that all product managers read them when joining. Part of my knowledge base for PM’s was Ben Horowitz’s timeless piece, Good Product Manager, Bad Product Manager
Teams, and even individuals, can start and manage their own knowledge bases. However, I recommend starting one global knowledge base at the company to encourage people to share knowledge with other departments. For example, the sales team can ask a product manager to look at the sales FAQ list and ask them to suggest comments on the answers.
What do we need in a knowledge base tool?
Knowledge bases are hard to create and maintain. You can build them with several tools that are designed very differently (docs in Google Drive or pages in Confluence). Let’s assume that your’re creating a knowledge base for your customer service team over Confluence. Here’s what you need that Confluence helps to achieve:
- Collaborative– anyone can create / edit / share pages
- Rich– different content types and rich pages/documents are crucial. They can be standalone files in Confluence or embedded in a Confluence page
- Accessible- the knowledge base is easy to access from any location, device or office
- Persistent– the content is not getting washed away
- Searchable– with the amount of information in an average customer support knowledge base, your customer service rep will definitely appreciate it
- Shareable– if a customer service rep wants to share a page with their teammate, they should be able to easily get a link
- Interactive– like Wikipedia, your knowledge base would be best if items can link to each other freely, and links/videos/photos will be easy to navigate to
- Permission based– I haven’t seen many reasons to restrict content in knowledge bases, and it’s terribly hard to do in most wiki engines, but you might want to look for a tool that offers access by permissions
Recommended tools for knowledge bases:
- Google Drive
- The wrong tools: emails (not evolving), daPulse, Yammer, Facebook at Work, Slack, shared windows folders (not collaborative)
Chat = a casual conversation between 2 or more people. You know the deal. Examples for chats in a tech company are:
- An account manager explaining problems during new client onboarding to the salesperson who brought the client in. They try to figure out solutions together, and how to avoid such problems next time
- A salesperson asking a product manager/training person if the product supports a specific feature
In both of these cases, people should learn something new in a chat interaction and add it to their team’s knowledge base (see #3). Voila!
What do we need in a chat tool?
Trivial question. We all know tools like Whatsapp which have many desirable features: web-mobile-desktop versions, privacy, group chats, ability to share media. The main point is that 99% of the tools in the world, including emails, are terrible for chat. Especially across time zones. So don’t use them for chat.
Recommended tools for chat:
- Skype / Skype for Business
- The wrong tool: email
#5 Project management / functional tools
Project management = cross-department communication in order to complete a specific project. Think about all tools that multiple departments touch to communicate. These tools contain specialized tools (ZenDesk for managing open tickets) or general (Trello, Asana).
Examples for cross-department project management:
- Sales and marketing departments meeting in front of a list of tasks in preparation for a great expo next month. They discuss 4 pending tasks and 6 completed tasks, and update the list as necessary
- An account manager checking out the progress of a system setup in Asana. They can see that the TechOps team killed 8 steps and has 2 remaining
What do we need in a project management tool?
Project management / functional tools are by far the biggest category here. Managing work/projects can get as rich and specialized as you want, so let’s not try to define requirements. Just remember that an average company has tons of different projects running at the same time. Understand how they’re different from each other and choose the right tool for each one.
Recommended tools for project management:
- ZenDesk (for people to communicate around a specific support ticket)
- The wrong tools: emails, Skype
As you can see, it helps to take a step back and talk about those different types of communication. It really makes it easy to see why people hate certain tools, and why some tools can never serve a specific communication type. Choose a suitable tool for each area and teach your team when/how to use the tools.
When things are going well, you’ll see the magic of one communication type affecting another (for example, the sales knowledge base gets updated after a chat with a product manager). When problems and frustrations surface, this list will at least give you a good model to understand what communicate type is needed, and what are better tools to achieve them.