In any organisation, one of the most powerful ways you can empower your team is to give them an environment that allows them to communicate freely at all levels. At Made Tech we actively encourage every member of the team to initiate or join any discussion that interests them, whether it be giving their opinion on how a part of the business runs, or introducing a new way of approaching how we work.
As a result, we’ve had valuable contributions from the entire team that have gone on to improve the way we work, build camaraderie and keep everyone up to speed on the goings on across the entire business.
The benefits of good communication
As organisations grow, it’s often easy for, as the saying goes, the left hand to have no idea what the right hand is doing. Project teams may not be aware of what each other is working on, it may not be clear to the wider team what pieces of work management are trying to win, and it’s especially difficult for peers to know who is trying to develop a particular skill they might be able to help with.
As well as that, such a lack of visibility allows silos to develop naturally, where one or more developers wall themselves off to outside interference in order to concentrate on work. Whilst this is not a bad trait in moderation, left unchecked it can lead to those individual developers having exclusive domain knowledge, which then leads to bigger problems if there’s a problem with the project they’ve been working on and they’re unavailable for any reason.
By increasing visibility, via the methods described later in this article, teams gain a shared understanding of the direction the company is headed in, who’s working on what, and individual projects. Team members are also actively able to help each other grow, which ultimately benefits the entire company.
A good company culture is important, and so giving your team ways to flex their tech muscles outside of obligations to customers is a great way to promote that. Whether it’s an hour tackling a small, fun coding challenge, an entire day learning about a new technology, or a few days away on a company retreat, the time spent will go a long way to both ensuring your team are getting exposure to technologies and practices that interest and excite them, and that they’re becoming a stronger and more collaborative team for it.
Provide open channels and opportunities to share knowledge
The first steps to creating a communicative environment for your team is establishing open forums in which everyone is invited to contribute as much as they’d like. We’ve got a few in place in Made Tech, all of which have had a positive impact on the way we work.
Chris has written about Continuous Feedback and its benefits at length, but in a nutshell: Continuous Feedback is the practice we use to encourage and address regular feedback from everyone about everyone. We found that annual reviews fell short in helping individuals learn and grow, and switching over to Continuous Feedback has allowed us to get a better sense of the goals people are trying to reach, and the areas in which they need improvement. Importantly, it also allows us to act quickly to help them reach those goals, and give them the support they need in the areas in which they need improving.
Share progress and achievements with a weekly email
One of the problems we were having was that it often wasn’t clear what other people outside of your team was working on week to week. They may have been on a new project, running with a new initiative, or on a recruiting drive. Our solution to this problem is what we’ve lovingly dubbed “TGIFs”.
A TGIF is simply an email sent at the end of every Friday, with a short breakdown of what each of the various teams and departments within the company have achieved that week. Each team sends their breakdown to one person, and that person collates them all and sends out the email.
TGIFs are a great way of giving your entire team visibility on what’s happening within the company, and also reminding people of important events coming up the following week.
Retrospectives are a key component of the Agile process, occurring at the end of a period of work and allowing teams to reflect on what went well, what didn’t go so well, and what they can learn from that.
We’ve reappropriated that idea and applied it to the entire company, so that the entire team gathers together every few weeks to discuss our biggest sources of frustration, share our achievements, and figure out what we need to focus on in order to continue to improve the experience we provide to our customers, and the way we work.
Prior to each comradrospective, each team and department have a brief retrospective, and then bring the notes from that to the larger meeting. A Facilitator hosts the comradrospective, going around the room and prompting discussions about what each team found in their retrospectives. The Facilitator then looks for common threads between those discussions, which often leads to the highlighting of a wider company issue that can be focussed on over the next few weeks.
It should be noted that the role of Facilitator doesn’t belong to one person, we actively encourage everyone on the team to take up the mantle for two reasons. One: each person will approach the role differently, ensuring comradrospectives never feel old, and two: it gives everyone a little bit of exposure to standing up in front of people and leading the conversation, which is valuable experience to have when your team is expected to present things like showcases to clients.
No two individuals are alike, and within every organisation you’re going to have an incredibly diverse set of interests and opinions. New technologies and frameworks are released to the public almost daily and, if your team are passionate about their craft, occasionally one of those technologies will resonate with someone on the team. They’ll spend their own time researching it, decide whether it’s for them and, if it is, spend even more time mastering it and becoming excited about the possibilities it provides.
As someone cultivating a communicative environment, it’s important that everyone on your team knows they have a platform for sharing their excitement with everybody. Giving them the freedom to host presentations on topics they’re enthusiastic about means everybody is regularly exposed to ideas and concepts that could potentially offer real value to your organisation.
This sort of exposure to new ideas and technologies then leads to a willingness to implement them in future projects, meaning your organisation is constantly evolving, rather than sticking with practices that will ultimately end up outmoded or obsolete.
Hack days are another great way of exposing your team to new technologies, as well as being a way to mix things up and potentially even produce products you or your customers will use for a long time.
As an example, a customer of ours wasn’t aware that their SSL certificate was due to expire, leading to browsers designating their website as insecure. This is a problem we’ve seen in organisations as big as Instagram, so we decided to hold a hack day dedicated to solving the problem.
The result was SSLCatch, a relatively small application that simply alerts domain owners in the days, weeks and months before an SSL certificate is due to expire. The whole team worked together over eight hours, regularly communicating with each other to get the clearest sense of what everybody was working on, solve blocking issues and ultimately get the application live as quickly as possible.
We now have hack days every one to two months, and they’ve often resulted in new internal tools we use regularly. More than that, they’re always a great opportunity to get the whole team swarming on a single project, solving problems together.
Daily stand-ups, also known as scrum meetings, are an important tool for getting everyone up to speed on what people will be working on that day, as well as for highlighting any issues they have, or how they can help others facing their own issues.
Daily stand-ups should be short, around ten minutes max, and should only involve team members working on the same project or in the same department.
We’ve taken that concept and extended it into what we’re calling “Scrum of Scrums”, where a representative from each team takes part in two or three meetings spread across a week to state what their team’s goal for the week is, and how they’re progressing with it. The objective of these meetings differs to that of a regular scrum meeting, in that it serves only to give even more visibility over what other teams within the company are doing.
Extreme programming is a popular methodology that encompasses many different programming practices, most of which are beyond the scope of this article. That said, two practices in particular are very useful when it comes to promoting communication within your team: pair programming and “whole team”.
We’ve discussed pair programming at length, but, in short, pair programming leads to stronger communication by encouraging each programmer to articulate their thought processes and engage in conversation about the best possible solution for the problem they’re facing.
The phrase “whole team” refers to a way of working in which teams are given the freedom to organise themselves, and whose team members can, between them and their various sets of skills, solve any technical challenge a project might present.
As well as that, when building software for customers, one of the biggest sources of frustration is often not being able to get hold of the customer when a critical question about the work arises. “Whole team”, then, means having the customer, at the beginning of the engagement, designate one of their own team to be the Product Owner throughout.
The role of the Product Owner is to be available at all times to your team, so that they can give guidance and answers to your team as and when they need it. In our experience with Product Owners, we’ve found that having the Product Owner on site leads to an even better experience, as they’re instantly more approachable and, from a wider business perspective, it becomes very easy to build a relationship with the customer.
Challenges in maintaining good communication
Every programmer knows the feeling of being in flow, when they’re highly focussed and incredibly productive, and it’s very important not to make that state harder to achieve, as it can lead to frustration. That said, left unchecked, it can be tempting for some to almost permanently block everything else out, forging ahead on their own path and rarely communicating with the rest of their team.
This then leads to either the programmer having exclusive domain knowledge over a significant part of the application and becoming a silo, or spending time going down a path of work without getting more information from others, potentially producing something that can’t be used.
Too many cooks
On the flip side, too much communication is A Bad Thing. Making time to communicate is important, but when it comes down to it you need to make sure the work you’re communicating about is getting done. Pushing communication too much can lead to discussions or debates where there are so many opinions that finding an actionable outcome to them proves impossible and time consuming.
While it’s important to make sure everyone has a voice within your organisation, there will inevitably be times when action needs to be taken, but you’re debilitated by too much discussion. Judge these situations carefully, and don’t be afraid to take the lead if it means resolving a conversation that’s gone on for too long.
By giving your team an environment in which they’re able to communicate freely about whatever excites them, challenges they’re facing, how your team could be doing things differently and ways they can help each other improve, you’re ensuring your organisation is able to constantly grow and meet any challenge an ever changing industry throws at you.