Unlisted
Solving for Trust by Building a Company Based on Trust
August 18, 2020
September 3, 2018
The issue of diminishing public trust has justifiably captivated the news industry in recent times. We’ve spiralled into soul-searching postmortems about where it was lost and how it can be earned back. But amid that industry-wide postmortem, we’ve been fortunate to have a blank canvass here in NevaLabs to think about how to build trust within our culture internally so that it carries forward externally with our product. To create a media technology company that is worthy of people’s trust and where trust is baked into our own internal DNA. To solve for trust by building a company based on trust.
It’s an ambitious mission when you consider that most of the team is working together for the first time. Every day is like getting in line for a ‘trust fall’, testing the limits of each other’s strengths and weaknesses, and resolving all the time to do better. Only with trust in each other and in each other’s processes will we actually build a product that maximises externally for people’s trust.
When our team came together last October, the product was yet unknown in some specifics given untested assumptions, and the team yet unproven in its ability to execute. Only with time, trust and a repeatable process could a product emerge. That process required constant testing, measuring, designing, building, and learning, deciding on whether to persevere or pivot, and then starting again but from a different vantage point.
So what did we as designers, journalists, researchers, developers, engineers, project managers and business strategists learn when it came to building a team that gets better every day at its ‘trust fall’? And what does it look like when a team building a news product based on user trust realises it requires a higher level of effort and commitment?
In July, we reached what we called ‘Basecamp’. It came after almost nine months of work on an MVP which transitioned into an MMP (Minimum Marketable Product), during which time we grew from five to ten people.
July’s Basecamp was the end of the beginning of the MMP stage and presented an opportunity to spend a few days taking in the view, looking back on the journey travelled and packing the tools needed for scaling the massive summit head which will see us launch a product to market later this year.
Since the beginning of the climb, we had learned that a ‘diagnostic’ approach to your social media consumption (telling you just how noisy and unbalanced your consumption is) made people feel intensely guilty. But an approach that resonated was one that gave you immediate control, allowed you to focus on the stories that matter to you at relevant moments of the day, and also discover stories that broaden your mind.
We gathered at Basecamp to review the pillars of our design process, the common principles that will keep us coordinated and focused:
A statement of the obvious, I know. But a team that cannot effectively communicate is a team that’s not in the flow; the place where they’re in the zone coding, strategising, designing, testing.
Our team is a classic mix of introverts and extroverts. The introverts amongst us (myself included) work best when we’ve a heads-up on what a meeting will involve, and have time to ‘work alone together’. That’s meant some simple principles like sharing an agenda at least 24 hours in advance of meetings and completing pre-homework (often written exercises around user needs).
In brainstorm meetings, we’ve regularly tried to give people the opportunity to go off with sticky notes or blank white pages to think about the Plan B for unblocking an issue, sketching an idea or collecting their thoughts, rather than collectively sitting around a blank whiteboard and inevitably relying on the extroverts to lead the conversation.
During our daily and weekly meetings, we’ve occasionally implemented the ‘round robin’ technique of asking one person for their thoughts and then following around to every single person to their immediate right or left so that all voices are heard.
My personal favorite point of the week is when we do our ‘On the Balcony’ exercise (courtesy of the Sulzberger Leadership Executive Program in Columbia University) towards the end of our team meeting. In these moments, everyone is asked to step out of the trenches, put on the CEO’s hat, step up onto the balcony and take a view of the company internally and the market externally. For that moment every week, everyone has permission to call it as they see it. It has delivered some important moments of clarity, foresight, and validation.
Often the most powerful moment in a team conversation has been to simply respond by asking ‘why’. Our product testers have continually reminded us of this also — the importance of “explaining the why”: why we offer a feature, why they see certain articles, why they have the option of using their Twitter account as part of the experience etc.
When you’re a new team building a new product, that commitment to fair and respectful communication is what binds you, matures you, and builds trust. Ultimately, an MVP requires time and maturity and gets better the longer you and your team are improving team dynamics and building on new learnings.
Repeatedly, I’ve found myself thinking back to a Facebook wall poster ‘Done is better than perfect’.
There’s a time for perfectionism which means delaying, tweaking and improving a prototype. And then there’s a time for pushing it out in all of its imperfections in order to quickly test assumptions which if unchecked early could be detrimental in the long term. Our ‘user advocate’ on the team, Eilis, has been a big believer in the concept of ‘test often, test early’ in order to build gradual momentum, validation and clarity.
That has meant being clear about what a ‘quick win’ looks like — an insight gained, a capability tested — rather than a product feature being defined, produced and billed as complete. To that end, we’ve continually gained from using platforms like Invision where you can design and test interactive prototypes without writing a single line of code. That has often meant putting up with clunky navigation and basic designs in order to test instead for concepts and ideas, rather than navigation and visual aesthetics. We’ve learned to recognise what our early easy wins and big quick wins look like compared to the big investments.
Trusting in the circuitous loop of design, test, measure, learn, then repeat, means trusting in the process, accepting the wins, misses and mistakes, and finding a way to quickly move on. As the process-oriented person on the team, I often describe my role as that of a sweeper or quarterback who hovers slightly behind the rest of the players whispering tactics and positions to ensure they keep a perfect line that moves from defensive to offensive with a singular goal in mind: winning.
In an environment where some decisions require painstaking discussion and others can be dictated by one, our CEO Mark has often repeated the words of Jeff Bezos: “We are stubborn on vision. We are flexible on details.” We are ultimately agreed on the final outcome, the mission that drives it, but open to negotiation on the tactics, deliverables, pivots and plan Bs that get us there. That of course creates a tension between a willingness to experiment and be creative and a need to execute on the jobs of work on the tight roadmap. But it’s a creative tension that can be of benefit to teams if failure and mistakes are accepted.
In our industry, we talk all the time about the need for innovation, and issue inspirational rallying calls for creative solutions to restore trust in journalism. But that commitment to trust needs to start in our newsrooms and boardrooms so that we’re all operating from a basic set of rules around processes and principles that ground us all for the ‘trust fall’.
