How we communicate
Communication is necessary to build relationships, clarify ideas, shape new opinions, and establish the facts. Unfortunately, too much communication can become detrimental to actual output. We repeatedly observe two common manifestations of this within companies. The first is ‘design by committee’ decision making and the second, unnecessary meetings.
We’ve created a culture where open communication is absolutely encouraged alongside a deep respect for the time of our fellow co-workers.
Customer communication - Types of communication
Sometimes we achieve this by temporarily allocating people straight into the customer’s office - usually during the planning phase. This allows for faster prototypes, quicker answers, and a faster understanding of the domain.
Scheduled quick meetings via Google Hangouts and dedicated Slack channels with the customer are good solutions.
Email is always a much-used tool. We encourage inbox management once or twice per day rather than attempting to deal with emails in a stream as they come. Any input that removes your present focus or attention should be scrutinised. Email is one of those inputs. Rarely is anything so important that it should become ‘ASAP’.
Truly urgent events relating to customer projects can be tracked via dedicated Slack channels that have third party integrations. An example of this might be reports on elevated error rates on a customer application.
Customer communication - Working with domain vocabulary
The nature of our work means we interact with lots of companies in specialist industries.
Just like the software industry, most specialist industries come with a large amount of domain-specific vocabulary, jargon and acronyms.
Do not be afraid to ask a customer at any moment to clarify a term they use.
At the beginning of each project, we create a glossary document in their customer folder if there is sufficient specialist terminology to warrant it. We allow the customer to access this document too. As team members work on a project, every time they encounter an industry specific word, it gets added to this document.
It is surprising how the glossary can grow over the course of a project. All those terms represent a concept that at one point a team member did not understand. The glossary represents Purepoint’s growing knowledge as a team about that industry. By actively contributing to the glossary, you are helping not only your current team members, but all future team members who interact with that project in the future. You’re also helping management, who might not have the same exposure to the day-to-day jargon.
Although it is often difficult to admit you have no idea what something means, especially if someone is using it flowing conversation, this industry specific jargon is a big blocker to cutting through and understanding the workings of the customer’s company.
Customer communication - Getting everyone on the same page
With domain-driven design, it is very important that everyone is using the same terminology to explain the same concepts. For example, a customer may often, even within their own domain, use words interchangeably.
‘Documents’ may mean different things to different people - one might person might include the idea of data in a database as a ‘document’ and another might not.
Identifying these polymorphic words early on and encouraging everyone to use clearly defined versions can have a huge impact further down the line.
Customer communication - Saying no
One of the most important tools we have is the word ‘no’.
It may seem counter-intuitive to tell a customer who is paying you for your service ‘no’. But in many situations, a ‘no’ prevents a customer from adopting a flawed approach. We believe that a customer is paying us to tell them ‘no’ at the right times.
Saying ‘no’ is just as important as saying ‘yes’. In fact, because of its uncomfortable nature, possibly even more important. Not saying ‘no’ leads to feature bloat, timelines sliding, and whole projects going sideways.
It is our job to understand software and its associated pitfalls and merits so that we may guide our customers towards success. Our customers will often have the best intentions but will not necessarily understand the implications of a particular request. Industry knowledge allows us to realise when a customer may be asking for the wrong solution to a problem. Likewise, if we were asking advice from our customers, there would be industry knowledge they have which we lack.
A software project never failed because it wasn’t large or complex enough.
Infact saying ‘no’ doesn’t just extend towards customers. It applies to management and fellow team members too. Because knowledge is never equally distributed amongst companies and individuals, everybody can make bad requests, as determined by the person who has superior information. If you think that an idea is a bad idea, say so.
But before you say no to something, think about the implications of saying ‘yes’ and try to understand the request from the other point of view. Then rather than just saying ‘no’, have an alternative solution to propose, as well as a strong rationale as to why you think that is a better solution.
Because our teams can be geographically dispersed, maintaining clear communication is critical. It helps with team morale, builds team dynamics, and keeps projects moving on pace.
Regardless of the medium you are communicating through. There are a few key principles we try to follow:
Internal communication - No ASAP
Although something may be urgent for you, odds are it is not urgent for the other person. If you need something ‘ASAP’ odds are it represents an underlying problem. Why do you need something so urgently? What could you have done to avoid that?
Breaking someone’s workflow is detrimental. Emphasising something is of a high priority is fine, but do not expect the other person to break out of their current tasks just because of that.
The nature of our business means that if we are performing our roles well, there should be no surprises and no sudden rushes. Even if customers are sending ‘ASAP’ requests, it is our job to act as a filter of those requests and keep our own processes running smoothly. Setting the expectations of external parties is important.
Every now and then a situation arises where ‘ASAP’ is forced upon us by external factors. These are rare situations like a customer emergency or downtime of a project. In that case, the processes we have in place should dictate how team members act, rather than any ad-hoc ‘ASAP’ requests.
Internal communication - Everyone makes decisions
Decision makers act as bottlenecks within an organisation.
Often when a decision needs to be made, it can be made simply by talking it through with a fellow team member. No further action is required. If you think it is the best course of action and it is in line with the principles contained within this Blueprint, then take it.
Try not to overrule the decisions of other team members unless you have information which renders that decision debatable. If you have an alternative method or solution to propose, ensure that you can debate the given issue from both sides of the table.
Try to follow Bloom’s pyramid when working towards an important decision:
“Bloom identified six levels within the cognitive domain, from the simple recall or recognition of facts, as the lowest level, through increasingly more complex and abstract levels, to the highest level which is classified as evaluation.”
- Rhetorical functions in academic writing: Writing critically
By identifying which level of the pyramid you are currently on, it helps solidify when you have reached a sensible decision. Obviously while still understanding the problem and gathering understanding on available solutions, you are still in the early stages.
Provided all parties inside Purepoint have spent some time working through the available information and have reached the top of the pyramid, they can ‘evaluate’ all possible solutions clearly, thereby enabling them to reach a good solution.
In a structure where you generally cannot just defer to someone ‘above’ to solve the problem, this is an important process.
Internal communication - Stand-ups
Within each project we do have morning stand-ups. Because of the nature of flexible working hours, these are not always in the morning, but we try and arrange times that suit everyone on-board.
Stand-ups generally last no longer than 10 minutes per project. Some people may be involved in more than one project. As a result, they might need to attend more than one stand-up.
Teams can choose how they set up stand-ups to best suit their needs. A fixed time or a flexible time can be decided by all members.
We follow free-form stand-ups, giving each person a couple of minutes to speak and ask questions. A broad format we follow is:
- Let everyone know how yesterday went
- Let everyone know your plan for the day
- Raise any concerns related to the above
- Ask any questions that are relevant to the whole group (though you may not get an answer in the stand-up)
Everyone should try to avoid getting into technical discussions, or answering complex problems during stand-ups. These matters should be dealt with separately afterwards.
Anyone can join stand-ups, even just out of interest.
It is safe to say that as a company we think meetings should be used sparingly.
There are two distinct types of meetings; internal and external.
Meetings - Internal
These are defined as meetings between Purepoint team members.
Use the daily morning stand-ups to your advantage. Address the team with quick questions or plans. If you have questions for specific people do not involve the whole team.
Try to stick with email and Slack as much as possible. Give people at least half a day to respond and use the method of going to others in the company only once you have checked other information sources like READMEs, Internal documentation and files.
If you need to use a meeting for planning purposes (something which typically occurs at the beginning of sprints), then try and keep meetings under 20 minutes. If they look like they are longer, break them up, or question what is so complex that required multiple people synchronously. Prepare beforehand. If possible, do them standing. Use whiteboards and paper. Take photos once you are done and let each person take notes in their own favoured style.
If meetings of longer than 30 minutes occur semi-regularly, it may be worth trying to identify the root cause of that. From experience, those meetings occur when team members have a lack of information from the customer, are faced with complexity of a proposed solution, or lack domain/technical knowledge. Sometimes they are the result of poor management, or a bad flow of information.
Do not be afraid to go outside your team to management or other employees if you feel it will help.
Meetings - External
These are defined as meetings involving prospective customers, customers, and other third parties external to Purepoint.
If you think that an external meeting lacks a clear goal and purpose, do not be afraid to say ‘no’.
When planning external meetings, try and set a fixed goal for the meeting and a duration which allows that goal to be achieved. If possible, organise a meeting via web-conference or tele-conference rather than in person. This ensures that all parties involved can perform the meeting from their preferred location, thereby limiting overall impact on your schedule for the day.
In-person meetings should be saved for exceptional circumstances. Some examples include developing specifications, understanding a customer’s users, or presenting project proposals. For general day-to-day things such as clarifying questions or working out details on specific features, try to keep meetings digital and under 20 minutes in duration.
We understand that some customers favour traditional face-to-face meetings and we cannot always follow our desired structure.
Meetings - Monthly company catch-ups
Every month we do a virtual company wide catch-up meeting. The goal is just to let everyone know what the company is up to, new people, new projects, goals and updates. We try to be as transparent as possible.