In tech startups today, multidisciplinary teams are the norm. People from multiple backgrounds and skill sets that come together to solve a problem are the bread and butter of these organizations all across the world. This configuration requires for fast exchange of information, ideas, and overall quick iteration over solutions, which in an always-changing environment is vital for survival.
However, these types of teams bring with them a set of challenges that can be dealt with in a variety of ways. From the coordination of efforts to the setting of baseline communication guidelines, the management of interdisciplinary teams involves a wide range of areas, each of them necessary to build a safe, efficient and open creative environment. The most representative of cases when studying these challenges is the coordination of efforts between Tech and Product teams.
Ask any product manager to tell you the hurdles of finding common ground between people who think, speak, and interpret things differently. It is no easy task to find a system that can perfectly represent and communicate ideas between groups that use things as complex as language in vastly different ways.
Many useful positions and roles have risen from these needs such as Product Managers and Product Owners, yet all of them rely on very specific skill sets that can be useful, regardless if you have that specific role in your team.
While the knowledge basis for dealing with teams from multiple backgrounds can be a bit overwhelming, there are a certain number of key concepts that can improve the workflow between different profiles in a significant way. These can make the difference between a bumpy ride, where frustration with the other team members is the order of the day, and a cordial, smooth transition between stages where everyone can effectively communicate their needs and expectations.
The following are 5 key areas spanning from language agreements to time management, where a dedicated effort to clarify concepts and differences can significantly improve team dynamics. Resulting in a better creative process and, therefore, a better product for the user.
Consider error fixing in deadlines
It's not uncommon, especially for tech-focused organizations, for major product features to be prone to errors and bugs in the development stage. And while tech teams are pretty familiar with the process of bug testing, fixing, and reviewing, these steps can be pretty ethereal and intangible for people unfamiliar with the more technical side of things.
Because of this familiarity with bugs, tech teams often don’t take them into account as a separate category of tasks within their process, therefore omitting them when giving estimates about deadlines and timeframes. As a result, whenever they occur, the deadlines are rendered obsolete and missed frequently.
To address this, a good rule of thumb consists in asking a number of questions that help you determine two things: 1) If an estimate might be too optimistic, and 2) By how much would a deadline should move to accommodate for error fixing. These can look like this:
- “Is this estimate considering unforeseen or potential delays?”
- “What could a barrier while implementing this feature look like?”
- “How long would the worst-case scenario take to fix?”
It is worth noting that while these questions can be used for a wide variety of scenarios, they should come after an evaluation of how complicated a feature is, or how prone to error its implementation might be. If the need to consider extra time for the deadline appears after that, this solution will do the trick!
Learn to say “Hello” in your teammate’s language
When visiting a country where you don’t speak the language, it is not unusual to encounter situations where the most simple of tasks, or the request for basic information turns into a game of Telephone, where each party tries to decipher the strange vocalizations of the other side and information is both delivered and lost with every word.
As it turns out, working with teams from different backgrounds and mentalities can produce the very same results. And, like the previous example, the most efficient and often overlooked solution is to learn common concepts and terms to make your life easier on a daily basis.
The advantage of doing it with other teams is that you can not only learn concepts and specific jargon from each other but also agree on operational definitions that describe something important or recurrent in the project. These definitions can be anything, from a specific technology, name systems for components, and whatever concepts your team deals with consistently.
For example, if a project involves a potential migration to a new framework for your website, ask yourself and your teammates:
- “What is a framework and what does it do?”
- “What are the core features of our current solution, and the ones of the alternative?”
These can clearly define many concepts, directly and indirectly, that will come up throughout the whole duration of the project
Define what “progress” means to the other side
Not often do we want to be on top of another team to make sure a deadline is going to be met, or to check on the progress of an urgent task. However, sometimes that process is necessary to coordinate efforts and adjust priorities in fast-paced environments, where requirements and objectives can change swiftly.
It’s in these situations where a good understanding of what progress looks like from the other side comes in handy, both to respond in a timely manner to abrupt changes or to anticipate possible delays.
Tech teams might rethink their progress as functional as possible in order to provide a useful answer, for example, “We have agreed on the data structure for the app context and set up our endpoints to communicate with our APIs” might turn into “The app is now able to retrieve useful data for the user, and we’ve figured out a way to organize it in a scalable way”, much better!
Use analogies to explain hard concepts
When all communication tactics and strategies fail, when concepts seem too complicated to be said directly, when an invisible insurmountable barrier appears in the middle of two parties trying to understand each other, an analogy just might be the window into the mind of the person in front.
Whether to conceptualize the most ethereal and abstract feeling in a love poem or to explain the core aspects of a new idea for your product, analogies can hold incredible amounts of information in parallel, easy-to-digest situations. Don’t be afraid to use a seemingly unrelated example to explain that very technical process, or to ground a new idea that could improve the user’s experience.
The most useful analogies rely on tangible concepts to which everyone can relate. If the whole process doesn’t fit within an example, don’t worry, only relate it to the aspect it applies to, and go on to make another one for the unexplained parts (if needed).
When this concept is applied, suddenly a complex Cloud Services network for your company turns into a little factory, equipped with storage space, a conveyor belt that moves information packages, and modules that process the raw data until useful information comes out from the other end. The limit is your imagination.
Extra points if you create scenarios where the core topic is already related to your teammate's fields of expertise. If you’re working with designers, try something related to the creative process, or the parts of a visual design. If you’re working with business-oriented people, try to come up with analogies for imaginary corporations, or administrative systems.
In a world where optimizations, technical features, and marginal improvements are ever more intangible, a good analogy might be the difference between uncertainty and understanding.
Always work within agreed requirements and functionalities
There is a habit among people in startups that, while well intended, results in time loss, setbacks, and frustration among stakeholders. Individuals tend to want to please other people in corporate environments, there is an underlying desire to prove one’s capacities and avoid saying “no” to a peer or a superior.
This tendency results in the avoidance of pointing out nonviable solutions from the start and trying to make something work, even if it’s not what was explicitly intended in the first place. Many cases follow this pattern, tech teams delivering something somewhat similar but overall far away than what was previously agreed, all because the non-viability of the solution was overlooked or dismissed when negotiating the objectives.
Such cases cause frustration from the party that expected a completely different feature, delays because the process will be executed twice with the adjustments needed to meet the feature’s requirements, and it will cause uncertainty from the people that won’t know what to expect the next time a feature is proposed.
The best way to address this is to carry out a viability assessment of the proposal that includes its implications, deadlines, available resources, and potential risks. If a feature cannot be implemented in its present form by the desired deadline, the response should not be to reinterpret the idea to present a somewhat similar solution in that time, but to be forefront about all the implications and limitations that the assessment uncovers, and negotiate a more viable solution from the start.
On the receiving end of a proposal to implement there is always time to ask:
- “What does the product need to do at the end?”
- “Into what components can the feature be divided?”
- “What are the resources available to develop and implement?”
- “Is the deadline enough for the feature to be implemented, given the resources available?”
- “Are there any downsides or unforeseen risks to the implementation of this feature?”
It is always a good idea to be mindful of your team’s capabilities and limitations when answering these questions, after all, it is honesty with ourselves and our peers through which we can acknowledge opportunities for learning and growth.
These are by no means procedures set in stone or even novel concepts in the corporate world. However, startups can find value in the adoption of these ideas into their culture and workflows, in whatever way they see fit. Different versions of these tips could appear depending on the people, the culture, and ways of thinking, but at the core of the issue exists a persistent exercise of self-reflection and a desire to understand the people in your team. In the end you not only will have a better product in less time but happier and more efficient teams that embrace their differences.