Subvisual started out in 2012 with a team of 4. All of us fresh out of college, with minimum experience of working within a multidisciplinary team, along with deadlines, clients and all the stuff that make our job so interesting. Not only that, but we also had to account for our team's different cultural background. 3 out of 4 team members went to a software engineering college together in Braga, while I joined the team coming from a design college in Porto.
This posed a challenging context which we failed to understand for the first months of the company. We failed to communicate efficiently, information would get lost in translation between design and development, tensions would often rise and give place to arguments that led to nowhere.
In the meantime, our team grew and so did our issues. We read almost hundreds of web articles and books, watched dozens of talks on the matter and tried loads of 'tips & tricks' to help us get away with it. We patched our process over a dozen times, just to watch it fail, over and over again.
It was frustrating to understand that, despite our best intentions, our attempts were useless and we had no idea how to address our problem. In the angst of our ineffectiveness we realised our problems had a deeper root, a basic preconception intrinsic to the human condition:
We are programmed to fear the unknown.
When faced with different sensitivities and perspectives that we are unable to understand, we get instinctively defensive and abandon our logical thinking. We allow our fear to build walls. In the web universe, designers and developers are often two worlds apart and we needed to build a bridge to serve as a safe path for communication between both worlds, break down those walls of fear and shed light into our unknowns.
It's common to see companies who build actual walls to separate designers and developers, with the excuse that they are organising the office by teams or some bullshit like that. Let's get one thing straight: one company is one team. By separating your team you are neglecting your communication.
For this bridge to have a solid foundation, it had to be built upon trust and respect. We needed to perceive our differences and accept them as something natural and positive while being humble enough to learn from them. We had to create a culture where everyone's opinion was valuable and free. We needed to feed our team with fewer rules and more common sense, get to know each other and understand that, despite the different path we took to get there, we were all in the same boat.
We were all in this together.
Our first step required little resources but could potentially provide us with actionable insights on what our next steps should be.
We started by creating our Friday Talks, which consisted of a team lunch where a few of our team members talk about either things they care deeply about or are eager to experiment. It can be a solid analysis of what went wrong on a particular project, a presentation of an exciting technology or simply an iteration of our work process. There are no rules, if you feel like talking about something, the team's ready to listen.
The goal was pretty simple. We wanted to engage people to share what was on their minds in an open, censor-free environment, while making sure everyone was paying attention. By providing the means for our team to present their concerns and their ideas, we made certain that we'd never settle or turn a blind-eye when something went wrong.
After only a couple of months, we started noticing that Friday Talks were a huge success and served as a safe channel for the team to communicate and make amends.
Small teams need to be able to make big decisions pretty fast. Since we value all of our team members' opinions, we structured Subvisual to be a flat organisation, making sure we hear everyone out.
See, our team consists of a group of talented, strongly opinionated young people, with a peculiar sense of humour. For this group of individuals to speak their minds freely without hurting anyone's feelings in the process, we needed to break the ice and establish personal relationships based on mutual respect and trust.
We had to become more than a group of professionals that worked together. We had to evolve from coworkers to teammates.
The next step was bigger and bolder, aiming to build strong interpersonal relationships and set the mood for people to relax, share experiences and get to know each other. At the beginning of Subvisual's year-two, we went for our first team retreat.
Our team retreat consists of gathering the whole team in a big house, far from our office and our routine, to discuss sensitive company matters, analyse where we are and design a plan to take us where we want to be. We also play table tennis, take a dive in the swimming pool or just start hackathons that extend through the night.
The goal is to break what remains of the walls our fear has built, establish trust and empathy, enabling us to become aware of each other. When someone joins Subvisual, you can easily spot the differences in their behavior after they've been to one of our retreats. They get comfortable to speak their minds even if that means countering the majority in the room.
This openness is our culture's trademark and it is invaluable to our success, hence why we now always schedule two team retreats per year, every year.
Hackathons are fucking awesome. We started doing hackathons on our retreats but soon enough we were doing them on our own time. The excitement of bumping into a new idea and figuring out the pieces we need to put together to build it is exhilarating, and this year we have planned to run six hackathons.
With everyone involved from the get-go in the design process, you're forced to work fast and make shitloads of decisions, as a team, in a short period of time. All of this is still entirely light-weight in comparison to working with clients, so everyone feels comfortable to get their hands dirty, which is particularly interesting for developers who, for obvious reasons, don't usually feel all that cozy when they have to produce rough sketches of their ideas. Since we are always short on time, hackathons also force designers to understand better the cost-benefit of their thoughts when debating them with developers.
Everyone gets to stand on other teammates' shoes for a few hours, which generates a better understanding of their roles and concerns. When you start understanding the unknown, it becomes an observable reality, and your fears begin to fade.
In the end, something comes out as a deliverable and everyone get a sense of accomplishment.
Beginning our third year we started implementing Design Sprints, involving client and developer in the design thinking process, and this is truly where our culture influences our daily work in a practical, tangible way. The pragmatism and functional mindset of the developers on our team is a huge asset that we bring to the table to kickstart our projects, but you don't get by simply forcing the developers to sit in the room with you. This is where the experience of going through hackathons, where they can freely express themselves and gain confidence in their input, really comes to show.
Don't get me wrong, the first couple of Design Sprints were hard and too stiff for our liking because things don't just happen overnight. We are trying to produce structural changes, so you need to give your team time to settle in and find their own voice.
All of these interventions, they take place sporadically throughout the year and although they are vital to the way we designed and shaped our culture, they're not enough on their own. There's a lot of days in between them where you need to keep feeding your team with positive, constructive actions and your culture is mainly defined by the little things.
Ask for feedback, not for praise
"This looks awesome" is not feedback. It's not constructive, not actionable, it's... futile. Feedback is not supposed to serve as a way of approving or validating your work. If you show your design work and ask your teammates what they think of it, you're likely to get a boolean "like/don't like" response. But instead, if you explain the context of the user in that particular design, where they're coming from and where they want to go from there, you'll be feeding them your rationale and giving them the tools to start a rich and constructive dialogue. That's what leads to great iterations and smart decisions.
Listen.
Whenever someone is talking to you, expressing their opinion or presenting their idea, your job is to listen closely and patiently.
This might seem the easiest thing to do and that's precisely why it is the exact opposite. Now you might think you're already doing this but chances are you're not.
Most people are not used to listening, they just wait for their chance to talk. Sometimes they don't even wait for the other person to finish their thought and they're already pushing back and disagreeing with it.
I screw this up all the time because, probably like most of you, I like to have an opinion about everything and I want to express it as soon as someone finishes talking. Jason Fried, co-founder of Basecamp, wrote a beautiful post called [Give it 5 minutes] (https://signalvnoise.com/posts/3124-give-it-five-minutes?120), where he explains how he got into discussions looking to prove something rather than to learn something. If you haven't, I urge you to read it and let it sink in.
It's impossible to communicate if one party is simply not willing to listen, so just give it 5 minutes and think about what you heard. And then, instead of pushing back or expressing your view on the matter, try asking questions.
Again, this is not something that you can change overnight. Even if you believe in this preset and you want to change, be mindful of the times when you don't listen or don't give someone a chance, and don't be ashamed of pulling back. Acknowledge you made a mistake, apologise and then ask questions.
Begin with something small, and maybe invite your colleagues for a drink or something.
Your team is definitely your best investment, and each team is unique so they require a handcrafted bridge to fit their own needs. Be patient and thoughtful. You can't build a bridge in a day. There's no silver bullet, no magical wand that you can wave around and instantly create a solution that perfectly matches your team's peculiarities.
Take your time. Soon enough, you'll start reaping what you sow.