Communication inside startups – what and how
Published (updated: ) in Startups.
Once you have more than 1 person in a company, I think communication is the biggest challenge. I don’t think it matters whether you’re working 100% remotely or have everyone in the same office, the challenge of communication remains similarly difficult.
The challenge and how to solve it changes depending on the size of the company but there are common questions that everyone should have a concise and precise answer for at all times:
- What is the overall mission of the company? Why are we doing what we’re doing? How is the company tracking against that mission? What is going well and what isn’t?
- What are the company values? How should we evaluate the ways of achieving our mission?
- How do we work and collaborate together?
- What is expected of me today, this week, this month and this year? How does that link to the overall mission? How am I tracking against those goals? What is going well and what isn’t?
- What is the rest of the company doing?
Practicing complete transparency is the best way to smooth the flow of information to different people across the company, whether they are employees, executives, board members or investors.
There are very few classes of information which may not benefit from full sharing – disciplinary and HR matters, complaints and perhaps individual compensation packages (but having a consistent, open set of salary bands makes up for that).
So what do these different areas involve? What are the key things that need to be communicated?
What is the overall mission of the company?
Later in the life of a company it should be obvious what the product is, but it may be harder to explain the why: Why are we building this? Why have we built that feature? What is the big problem we are trying to solve over the next 10-20 years?
This is crucial to understand because every other aspect of the company flows from this single mission. Everyone needs to know the mission because otherwise they cannot understand why the work they are doing is important to achieving that mission.
The best mission statements are short but specific. Easy to remember and obvious, but hard to achieve and involve playing the long game.
One of my favourites is Tesla:
…the overarching purpose of Tesla Motors (and the reason I am funding the company) is to help expedite the move from a mine-and-burn hydrocarbon economy towards a solar electric economy, which I believe to be the primary, but not exclusive, sustainable solution.Secret Tesla Motors Master Plan
The company was founded in 2002 to revolutionize space technology, with the ultimate goal of enabling people to live on other planets.About SpaceX
These are both very clear about the problem and what the company is trying to do.
But the mission doesn’t need to be as big picture or ambitious as what Elon Musk is trying to achieve – it’s just as important to have a clear mission if your goal is to build a small but successfully sustainable company.
Without a clear, written statement, you cannot align the rest of the company goals, understand how to prioritise what to do next and will certainly find it difficult to hire and retain your team.
Even simple mission statements require constant communication. The whole company need to know not just what the company is working towards but how things are tracking against that goal. With real numbers and commentary on both positive and negative progress, the mission will be reinforced.
This means having regular reporting of KPIs to the whole company. You are probably doing this for investors and your board already so this format can be reused for the rest of the company.
Information about company performance either gets out through actively sharing the real numbers or it is distributed through rumour and gossip. There is no option where information doesn’t travel, so why would you not want to be in full control of the narrative and detail?
Doing this builds trust in good times so that you can call on the team when you enter more challenging times. With everyone aware of the same numbers, everyone has the same context for making decisions, understanding why decisions were made and making their contribution as valuable as possible.
What are the company values?
The company mission is always very high level – it describes “what” and “why” but doesn’t really discuss “how”.
I used to think that the idea of “company values” was a cliché but that is only true if they are vague and written in generic management speak. If the company values don’t prescribe specific behaviour then they aren’t particularly useful.
Netflix has perhaps the most famous description of its culture and values, from the culture deck CEO Reed Hastings published almost 10 years ago:
More recently, these have been written out as a set of high level principles which they then break down into specific values.
Like all great companies, we strive to hire the best and we value integrity, excellence, respect, inclusivity, and collaboration. What is special about Netflix, though, is how much we:
1. encourage independent decision-making by employeesNetflix Culture
2. share information openly, broadly, and deliberately
3. are extraordinarily candid with each other
4. keep only our highly effective people
5. avoid rules
Our core philosophy is people over process.
Whether you use the term “values” or not isn’t the point – it is about having a written description of how you approach things. They describe how the team behaves, help you recruit new people who match those values and evaluate the existing team as to whether they are meeting those expectations.
Note the keyword: written.
The task of writing down the values is a good thought exercise in itself but then they can also be referenced and modified over time. If they’re not written down then there is too much of an opportunity for digression, forgetting key values or people just misremembering.
Another example is GitLab, who are unusually transparent in everything they do. Indeed, this is one of their core values.
GitLab’s six values are Collaboration, Results, Efficiency, Diversity, Iteration, and Transparency, and together they spell the CREDIT we give each other by assuming good intent.GitLab Values
The important thing is making them actionable, for example under “Results” they explain:
Measure results not hoursGitLab Values: Results
We care about what you achieve; the code you shipped, the user you made happy, and the team member you helped. Someone who took the afternoon off shouldn’t feel like they did something wrong. You don’t have to defend how you spend your day. We trust team members to do the right thing instead of having rigid rules. Do not incite competition by proclaiming how many hours you worked yesterday. If you are working too long hours talk to your manager to discuss solutions.
Making the values actionable and measurable is what transforms them from high level clichés into a true set of operating principles for the company.
How do we work and collaborate together?
Do you message someone directly on Slack? Do you send an email with an announcement? Is it expected that you will engage in discussion in the comments on a Google Doc? Does documentation go in Confluence?
These are questions everyone has when they first join a company and so should be part of the standard operating system of the business. Everyone should be using the same tools and processes and there should be exactly one way of doing things. You know this is going wrong when you see such behaviour as:
- Missing crucial information because it was sent as a Slack message late at night in your timezone and there were hundreds of other messages afterwards so you didn’t see it.
- Bugs getting reported through anecdote, mixing multiple issues that then get fixed in an ad-hoc way without tracking the resolution, often resulting in duplicated work as other people try to reproduce an issue that has already been fixed.
- People don’t check their email often because they don’t get many messages and instead work in real time chat all day, meaning they miss meeting notifications or an important customer message.
- Documentation is written in Confluence by one team but another team is using Sharepoint to work on a Word doc.
- People are mentioned in document comments but the answer is provided through another channel and the original comment is left open and unresolved.
- Information and documentation exists in one place but it isn’t easily searchable so people end up asking individuals for work that has already been done.
- Decisions get made without you being aware and you only find out through luck or because someone happens to mention it in passing.
Discipline is easier when the company is small and just getting started – that’s the best opportunity to set the rules and processes, and tell new hires how to do things. When there is a lack of direction, teams will end up using their own tools and systems because it’s better for them but to the detriment of the overall efficiency of the company.
Sometimes changes to working processes are needed, especially when a new tool is discovered that makes a difference to the working practices of the organisation. But adopting something new should be a deliberate evaluation and decision process.
If teams end up spinning off their own processes and tools, that is an indication of poor direction and/or failure of an existing approach. Dissatisfaction with the status quo should trigger a review and debate rather than a secret team/deployment of a new vendor product.
I personally dislike Slack (and any real-time chat) for anything other than general, social chat or deliberate collaboration on an ongoing project e.g. triaging a customer issue with a group of people in real time, doing incident response, or backchannel chat between participants during a sales meeting. These are all instances where a small number of people come together for a specific task and for a specific period of time, after which they disband. Real time chat is an awful tool for anything else because it implies everyone must be available and responsive immediately, at all times. Information is too easily lost.
My personal preference is defaulting to asynchronous communication via email, where I can set up my own workflow, control notifications and respond in my own time and in appropriate detail. Chat has its uses but I consider it (and notifications in general) highly damaging for any kind of focused knowledge work like writing or coding. This is not a unique view:
What we’ve learned is that group chat used sparingly in a few very specific situations makes a lot of sense. What makes a lot less sense is chat as the primary, default method of communication inside an organization. A slice, yes. The whole pie, no. All sorts of eventual bad happens when a company begins thinking one-line-at-a-time most of the time.Is group chat making you sweat, Signal vs Noise
With 10 years of remote working experience with the majority of that spent with chat as a core communication tool, my preferred working style now is to assume that everything is asynchronous by default, with the ability to do urgent interrupts rarely.
Real-time sometimes, asynchronous most of the time.
At Basecamp our perfect-world rule of thumb is “real-time sometimes, asynchronous most of the time”.
Basically, right now should be the exception, not the rule. That creates space and attention for the things that really do have to be discussed right now, and allows everything else to be thoroughly discussed asynchronously and thoughtfully over time.Is group chat making you sweat, Signal vs Noise
Real time chat like Slack has its place, but should be limited by both configuration and convention. For example:
1. Slack is to be used for informal communication only. Only 90 days of activity will be retained.
2. If you use Slack, please avoid private messages. Private messages discourage collaboration. You might actually be contacting the wrong person and they cannot easily redirect you to the right person. If the person is unavailable at the moment, it is less efficient because other people cannot jump in and help. Use a public channel and mention the person or group you want to reach. This ensures it is easy for other people to chime in, involve other people if needed, and learn from whatever is discussed.
…Slack, GitLab Handbook
6. Slack messages should be considered asynchronous communication and you should not expect an instantaneous response; you have no idea what the other person is doing.
Limiting retention forces everyone into the mode of the chat being ephemeral and minimising private messaging helps encourage transparency, avoiding interrupting specific people. And if it really does need to be synchronous, a video/audio call (which can then be recorded, transcribed and stored in a searchable format) is still probably better.
What is expected of me?
At this point we are down to the day to day activities of individual team members. If the above items are done well, each person will understand what the company is doing, what guides their approach and the key tools and processes they should be using. That leaves the question: what should I actually be doing?
The worst kind of work is where you are simply following orders. Sometimes specific tasks will be assigned e.g. preparing a spreadsheet of KPIs or fixing a reported bug. However, most work should be driven by outcomes, leaving the individual to decide how they achieve it guided by the mission, values and tools.
There are plenty of systems that can be used to decide what should be worked on, with the most popular (at least in startups and Silicon Valley) being OKRs. I’m actually not a big fan of them and couldn’t get them to work well at my company, but I do subscribe to some of the key principles of OKRs, specifically:
“The ability to track results on a quantitative basis.” Key results are not general or subjective actions you plan to take. They should always include numbers to make it clear how much has been achieved. For example, if Mary’s objective is to improve her sales prospecting skills, one key result might be to spend two hours a week shadowing Jennifer, the team member who demonstrates the most prospecting success.How to Make OKRs Actually Work at Your Startup
Whatever system you use, the key is that people know what they should be doing and how it links to the overall company mission. OKRs are one way to achieve this but need to be implemented with all the other things discussed above – they won’t just magically solve a communication problem if there is no understanding of the company mission, values and processes. The team should not only know what they’re supposed to be working on and why, but be able to explain it to others:
Following the HR rep’s suggestion, I start to ask questions. Actually, a single two-part question: What are you doing, and Why?50 Years In Tech. Part 12: Cupertino Culture Trouble
For the What, I rely on a variant of my old I Can’t Be Stupid gambit: If I don’t understand what you’re saying, either you don’t actually know what you’re talking about, or you’re withholding something. As for the Why, please don’t say you’re just following orders — I know you have a mind of your own; and don’t hide behind “marketing demanded it” as if you respect marketing. Tell me how your work serves the common purpose. Does it improve performance, reduce cost, increase reliability, forge a killer feature? If you can’t tell me, perhaps you should go back to your desk, gather your thoughts, and come up with some answers that make me feel smarter and safer.
What is the rest of the company doing?
With all of the above implemented, everyone should have a good idea of where the company is going and what is being worked on, at least at a high level. Knowing what is actually happening on a day to day basis is easier in small companies but as the team grows and the product becomes more complex (possibly with multiple products), it becomes harder to know who everyone is and what they’re individually doing.
This essentially comes down to two things:
- Transparency: are the systems, tools and processes open enough so that anyone can look at any document or ticket if they wish (subject to certain restrictions around confidentiality – GitLab again have good guidelines on what is not default-public)?
- Real communication: is there regular discussion from the executive team explaining what is going on throughout the business – whether that is highlighting big (and small) wins, releases, problems or just regular reporting on activities.
There is also a question of relevance. In a company of 10 people it makes sense for everyone to know everything, and to be specifically told about all activities. If you have 10,000 people then the level of detail needs to change. Information should still be available if individuals wish to look it up, they just might not be told the complete detail on a regular basis.
Most companies do a poor job at this, especially the bigger ones. Coordination across teams within a single department is often frustrating enough that trying to get all teams fully aware is a big challenge. That doesn’t mean it can’t be done.
One good example where this is a regular problem is with the selection of technology and building internal systems. Large companies, organisations and especially the public sector suffer from duplication of systems which can only really be solved through proper value chain mapping.
Wardley Maps are a great way to understand the landscape, something which most companies are awful at.
This doesn’t just stop at knowing who is building what but actually goes into the entire company strategy. That’s an entirely separate topic, though. Read the book on Wardley Maps for the real detail.
So how do you achieve this?
Establishing a regular communication and reporting cadence is a standard part of running a public company – financials and progress get announced in an expected format on an expected timeline. If public companies can do this on a quarterly basis, there’s no reason why smaller companies can’t do it too, and likely much more regularly.
At my company, I used to send out monthly updates to all my investors via email. This tied in with my monthly board meetings and included details about all KPIs, an analysis of the results and what the plans were for the next month. I sent out the exact same report to all team members internally as well.
I also ran weekly whole company meetings where everyone had a minute to talk about something interesting they had done during the week, and as the CEO I commented on positive developments, good work I’d seen and provided an update on challenges, problems or anything else that was relevant.
If I was implementing this again I would think about the following:
- Reporting KPIs on a weekly basis via email and highlighting the top 2 metrics in the weekly meeting (likely revenue numbers). A good real-world example of implementing a system of reporting is described in The Founder’s Guide to Discipline: Lessons from Front’s Mathilde Collin, particularly around regular emails and meetings to highlight progress.
- Building an internal KPIs dashboard with real time data that everyone could access.
- Recording and transcribing all meetings so they are easily searchable and reference-able in future, then emailing this out to the entire company (for the whole company meetings, and having a good index for all other meetings).
- Having all individual goals and measures for the “What is expected of me” section public on some kind of internal profile directory. This helps to answer the question of “What is the rest of the company doing?” and means people can directly link to their goals when helping others prioritise work. If everyone knows what you’re working on and why, they can figure out how their request can help achieve the goals of both parties.
- Regularly discuss all aspects of the company mission, values and processes to get input on what is working and what isn’t. Just because you decide on an approach when the company is founded does not mean that you have to stick to it.
- Being more deliberate about having a single source of truth for all documentation, values and the overall company handbook from the beginning of the founding of the company.
Communication is not static. The best way to do something today might change tomorrow. You have to repeat things and ask obvious questions. It can be difficult to know how well communication is actually working but you can certainly tell when it’s poor. Things are often getting done despite the communication overhead. People are guessing what they should be doing and there is a low level buzz about how well the company is truly doing. Nobody has any guiding principles helping them decide what they should be doing and there is often a lot of sudden urgency around arbitrary deadlines like working in a feature factory.
This is a big challenge all companies face, and it is one that is never solved. Whether you have an extreme level of secrecy and control like Apple or at the other side of the spectrum like GitLab, I think monitoring communication and actively working on improving it should be a top priority for the entire executive team.