Meta

Hindsight is 2020: Things we learned the hard way in 2019

Illustrator:

In case the timing of this post didn’t make it obvious enough, we aren’t big on New Year’s Resolutions around here. But with over 50 projects completed in 2019 and a rapidly growing team, we know better than to breeze forward without reflecting on the lessons that got us here. This is a practice we try to incorporate on a regular basis, and the honesty in our project retros and regular town halls often reveal some of our most valuable opportunities for improvement.

So in lieu of yet another Instagram-worthy highlight reel of 2019’s shiniest wins, here’s a quick rundown of our messier moments from last year (and the advice we wish we’d had back then).

One of our Design Directors on why design doesn’t always age well.

metablog

The TL;DR

It wasn’t until halfway through wireframing on a recent project when I realized that I’d neglected to consider what is arguably one of the most important variables in the design of any product: the element of time.

My team and I were on a brainstorming call, and I asked, “What would this look like with completely different content?” From there, the can of worms was open and we saw how unsuccessfully our current execution would withstand the test of time. Our wireframes were designed around very specific—and very minimal—content, but the experience would become extremely jarring if more content was added and changed over time. And it wasn’t just a content problem. There was something inherently problematic about assessing our designs in a state-by-state context since so much of the user experience happened in the transitions that connect those dots.

We’d overlooked the fact that the connective tissue—the transitions, the loading or offline states, the interacted states—reveal a lot about how to accommodate a user’s needs as they move through time. It might sound obvious, but it’s easy to forget that designing for the here and now shouldn’t preclude you from leaving flexibility for future adaptations.

My advice?

No matter how intuitive your layout or how pleasing your color palette, your design won’t be of much use to anyone if it isn’t flexible enough to accommodate a handful of other realities in addition to the one you’re currently facing. You don’t need any super fancy techniques or methodologies to address this, either.

Start by asking if your product’s value proposition changes with different contexts and over time. What can you deduce from previous requirements that might help you predict what will be needed in the future? Look at ideas you’ve previously abandoned and try to argue them back into play.

Lastly, give new prototyping tools a shot; the more fluidity and interactivity they offer, the less dependent we become on states to design for the experience continuum.

Our Director of People Ops on why representation matters.

metablog

The TL;DR

The thriving culture and smiling faces you see on our website aren’t just for show. We try to involve our employees in important decisions, encourage dialogue, and put people first. Generally speaking, we have a genuinely happy group of people roaming the proverbial halls of MetaLab as a result. But for a company that prides itself on its remote culture and global perspective, our lack of diversity is a problem.

**Everyone deserves to be represented in the spaces in which they live and work.

It's a problem not just at MetaLab, but in our industry as a whole. First and foremost, it's a people issue: everyone deserves to be represented in the spaces in which they live and work. Secondly, it's a business issue: when underrepresentation goes unchecked, the quality of the work suffers. We can’t responsibly build products that serve billions of people from all walks of life if our teams aren’t just as diverse. To do our jobs as people and product designers, we have to actively invest in a community of equal representation, access, and inclusion within MetaLab and beyond.

My team and I spent 2019 trying to be part of the solution, starting with a focus on hiring. We hosted events and attended workshops and training sessions. We removed candidate identifiers from our screening process to reduce unconscious bias and launched a new Careers page to reflect a company where anyone could feel like they belong.

Over the course of last year, our good intentions progressed into baby steps forward. It's something, but we’ve got more progress to make. If we've learned anything, it's that taking a top-down approach will move things farther, faster. So this year, we're working with professionals to integrate diversity, equity, and inclusion into all aspects of our company for a more meaningful impact.

My advice?

Look in the mirror and be honest and clear about where you are and where you want to go. Ask for help, and ensure that it’s a priority at an executive and management level. Then, take small, consistent steps towards implementing change. Hold yourself accountable along the way, but don’t shortchange yourself on the self-compassion you’ll need to overcome the reality of how far you have to go. Most importantly, ensure that these efforts are a transparent collaboration all the way through and give every person at your organization a supportive seat at the table.

Our VP of Partnerships on the value of turning down clients.

Photo of Luke Des Cotes, MetaLab's VP of Partnerships

The TL;DR

The folks in the tools are what make our business what it is. At the end of the day, our model is pretty simple: we hire the best people in the world to do incredible work with great clients. Rinse and repeat. Our employees could work just about anywhere in the world, but they choose to work at MetaLab.

That means it's my team’s job to make sure MetaLab is a compelling place to be through the projects we bring in the door. Easy to preach, sure. It’s a whole lot harder when that means leaving millions of dollars and interesting work on the table because something about a client just doesn’t feel right.

We’re relationships people, so we feed off of energy, good or bad. When it’s good, it’s really cool to see the positive impact that it has on the work. When it’s bad, we take it seriously and do something about it. We’ve had enough very good and very bad client relationships to know that when the team suffers, the products suffer, and nobody walks away getting what they came for.

This past year alone, we ended up saying “No, thanks” to hundreds of projects in the name of protecting our team. The ones that keep me up at night are the few that slipped through the cracks, like the two clients that we had to part ways with and the handful of others we should have ended things with much sooner. A bad apple spoils the whole barrel and when our team feels tired, uninspired and frustrated as a result, that’s (partially) on me.

My Advice

Take your time and then trust your gut, even (and sometimes especially) when clients are in a rush to get things signed off. Don't hesitate to slow things down, book that extra call or ask to meet in person before agreeing on contracts. The same goes for stress testing anything that doesn't feel right throughout the process—make a point of challenging them and seeing what happens. Regardless of how big the name or how deep the budget, these relationships are two-way streets. Like any good relationship, they take time and work to cultivate, and the early interactions are typically windows into what to expect down the road.

One of our Engineering Directors on why it’s good to get it wrong.

metablog

The TL;DR

We have a very high bar for shipping functional, polished products, so the better we can integrate our design and engineering teams, the better the quality of the end result. Where many traditional teams usually take a waterfall approach to their development phases, I spent 2019 experimenting with different methodologies to see if I could set the quality bar even higher, faster.

On estimation calls, I’d push to get development started on projects as early as possible. This would allow the team to start looking under rocks, asking questions, and laying a foundation for the rest of the product architecture. In some cases, this worked really well and made projects a million times better. Other times, it was obvious that we’d pushed it too far.

How could development be expected to build a product that hadn’t been designed yet? How could designers be expected to map out the data flow when they didn’t yet have the actual data? Both questions were equally valid and frustrating, so we had to get creative with staffing projects to keep things moving forward. Still, what we’ve gotten from these experiments far outweighs the perceived safety of a singular approach to engineering. As the classic “waterfall vs. agile” debate rages on, we’re focused on building an engineering team and schedule that maps to each project’s unique needs.

My advice?

Don't be afraid to tinker with the status quo. You might break some things in the process, but you’ll learn a lot more in veering “off-course” than you might have otherwise and your solutions will be even more foolproof as a result. But before you start taking things apart or moving in an unconventional direction, make sure you’re clear about your team’s non-negotiables.

I managed to feverishly champion finding ways to be 10% better while also reiterating the need for everything to be delivered on time and on budget. Whenever you run a new experiment, over-communication (both internally and with stakeholders) is the key to protecting the integrity of the product during the trial and error that comes along with trying something new.

Our COO on why imposter syndrome is worth talking about.

metablog

The TL;DR

“What do you do at MetaLab?” The question wasn’t out of line or invasive for a networking event, but it didn’t make answering it any easier. Like I had done so many times before, I found myself sharing that I “worked in Operations” rather than telling people I was the COO of MetaLab. I’m immensely proud of where I work and the teams I get to lead, but sometimes I'm still uncomfortable with the title that comes with it. In my mind, broadcasting my C-level role sets me up to fall short of expectations that people might have of what a “good COO” should be. Underpromise and overdeliver, right?

It wasn’t until well into my career that I had a name for the healthy dose of self-doubt I’d carried with me over the years: imposter syndrome. I can tell you from experience that this negative self-talk doesn’t discriminate across skill level, expertise, or any other differentiator. While it’s a mild nuisance for some, it can be debilitating for others. For me, the voice telling me that I could do better makes it hard to celebrate my successes, but it’s also what motivates me to succeed in the first place. As a result, I’ve tried to embrace the ways in which this voice serves me and be more aware of what happens when it starts to get in the way.

My advice?

There are no dumb questions; your curiosity is an investment in your growth.**

I find that past performance is a great indicator of the future, so the quickest way to stop thinking you’re falling short is by internalizing any cold, hard evidence to the contrary. If others tell you you’re doing a great job, you probably are (and probably will again). When you need direction, keep in mind that there are no dumb questions; your curiosity is an investment in your growth. For example, I recently joined a project team for a couple of months to gain first-hand product design knowledge to boost my subject-matter confidence (spoiler alert: it worked). Also, stop trying to “fake it ‘til you make it:” I’ve learned that humility and a willingness to learn gets you a lot further.

New and improving.

It’s good to talk about these things. And talk and talk. But instead of just waxing poetic about all the things we’ve learned, we’ll be a lot more comfortable when we have tangible changes to point to the next time we sit down to chat. We’re approaching this just like we would any other project: take things week by week, step closer, step back, invite feedback, implement learnings as early and as often as possible, and always, always produce something real in the end.

Wish we’d addressed a different topic, or want us to dig deeper into something that we covered here? That’s what our AMA forum (answersplz@metalab.co) is for. We’re all ears.