Welcome to the first article, of the series: Do’s and Don’ts: Communication in Growing Teams. 

Over the next three weeks, we will be sharing the insights, experience and teachings from Amit Patel, one of our amazing Hub members. Here’s part one: 

Amit Patel
Amit Patel, previously the Lead UX Instructor at General Assembly, and now he runs his own education startup, Experience Haus, hosting creative courses, workshops and events for the curious — as well as connecting students with mentors within the industry. Amit also likes iced coffee, sneakers and basketball.

Earlier this year, over a breakfast session, I was invited to speak about the importance of communication in a growing organisation to the team at Conde Nast International Digital. Having grown from 15 to 100 people in just over a year, the natural strains in the organisation, communication and ensuring teams continue to work efficiently in unity are certainly to be expected.

Over my career, I’ve had the opportunity to work across many industries and with various sizes of companies, from startups (areas such as media, fin-tech, transport) to industry-leading companies such as Scotiabank, OVO Energy and Crossrail, Europe’s largest construction project. I was previously Lead UX Instructor at General Assembly, and have now founded my own education startup, Experience Haus.

Having taught various workshops and courses over the last few years, and working with a large number of students, I’ve noticed good communication is a major key to success for product and design teams.

But wait, what does communication actually mean?

“the imparting or exchanging of information by speaking, writing, or using some other medium.”

From my experience, I have seen many of us make the assumption that communication is easy. Furthermore, we think it is as simple as scheduling meetings between teams and team members as that seems to make sense, right? Good (and effective) communication requires a significant amount of human effort, and a lot of this is down to building good working relationships.

Great products are the result of people and teams working together effectively. Communication is key to making this a reality.

In this 3-part blog series, I’ll be sharing some lessons I’ve learned from my past working experiences, how to successfully improve communication, who to involve and when, and some other useful tips. Stay tuned.

Lessons Learned:

Share anything you know that might be useful to the rest of the team

This first lesson comes from a few years ago when I worked with a small startup based here in London, Adio, where I was the Product Manager. Our team consisted of myself, a few developers, a CTO, a brilliant CEO and a small social media team. Every day at 10 am, we’d have a team standup (catchup) and there is one particular day that always sticks with me. Not sharing an important insight that I obtained during the design process from a few weeks before, ended up coming back to bite me. Because I hadn’t shared this with the team, especially the developers, it resulted in us wasting a lot of time and resources and led to some difficult conversations – captured perfectly by this tweet from our CEO that morning.

Image for Part 1 - Amit Comms Blog

Literally, anything and everything that you feel might be important to the team, share it. Knowledge and insights that you gain through your work are critical to the progress made, and results produced, by your team. Good communication begins with you committing to sharing this information.

Get decision makers involved early in the design process

Also earlier this year, I was on the periphery of a small project and facilitated a one-day workshop for the design team, who were creating an internal news platform, to help them with the creation of their MVP. The output from that day allowed for a developer to come in and build something quite quickly, but when it was shown a few weeks later to a stakeholder they didn’t seem willing to put it out company-wide. Not having stakeholders present when the initial work was being discussed meant that when they saw the new platform (that had already then been developed and resources/time being used up) they didn’t see the need for it.

More on this later on…