How to create trust (in a startup ecosystem)
One of my previous articles highlighted the strength of an ecosystem compared to a linear system: the enormous amount of possible connections and transactions which can be performed! It also touched upon on one of the necessities to perform these transactions: there needs to be trust in the ecosystem.
Why is trust so important in a startup ecosystem? For an answer to this question we need to do some one on one bartering, and this is explained in a very clear way in “the Rainforest”, by Hwang and Horowitt. Let me summarize it below:
Coffee and cookies
Let’s say you have a cup of coffee and I have a cookie. We agree to trade, it looks like this:
Imagine that instead of trading coffee and cookies, we trade our knowledge on setting up a business, or on an innovative product. This is basically what two co-founders are doing who are meeting for the first time.
But there is a slight difference: one of them is sharing something of value: a coffee, an idea or an introduction. The other party might return the cookie or the business knowledge only after a few weeks, or years!
When we actually exchange cookies we have fixed this problem with currency. You get paid for the coffee, and you can buy a cookie whenever you want to, from anyone you want. You don’t have to trust anyone any longer to get something valuable in return, because you can just buy it when you want to.
Seems like we solved all our issues with money? Not really, as it is really hard to put a price on the things which are exchanged in startup ecosystems. One (complicated) way to fix this is to start a company, and to exchange founder stock instead of euros, but this is, obviously, not a solution for every connection or transaction in the ecosystem.
So, in most cases in our startup ecosystem we’re back to trading coffees and cookies:
You could say startup ecosystems have a currency of trust. But trust is hard, it does not come naturally! And it gets even harder: We have different ideas of the value of the coffee and the cookie. It took me a lifetime to come up with the tech knowhow, and you took a lifetime to come up with the business knowhow. Yet, I think your business knowhow comes from reading a few books, and you think my idea just popped up. In other words: we have very different ideas on the value of the things we trade. It might even get so far that we never exchange coffee and cookies at all because we can not agree on the (potential) value, let alone we trust each other enough to perform the exchange.
(This also goes for short term vs long term by the way. Focus on the long term also does not come naturally, but when cookies might be delivered a year later, it’s focus on the long-term which you need! Just as you can create an environment of trust, you can create an environment where focus on the long term is rewarded.)
When you talk with a potential co-founder, when you sign your first seed round, when you agree on your first sale, or when you agree to leave the company: these connections with other people, all these decisions, these transactions are somehow based on trust.
The question arises: when you design and build an ecosystem, how will you make sure the actors in the system trust each other?
Can we design trust?
Contrary to what a lot of people think, trust can be designed. Or actually: it should be designed, because if you don’t work actively on trust, it will not be there (as we humans are basically wired to distrust what is different from us, and most CTOs and CEOs couldn’t be more different). The concept of trust is a belief (I believe you will give me a cookie in return), and this belief can be seen in the (real) world by certain behavior.
If you want to change a belief you can start preaching and hoping that something sticks, but it is much more efficient (and easier) to change behavior, because the image above also works the other way around:
This means you can change beliefs by changing behavior: if you see people giving back cookies all the time, you start to believe it is normal to get a cookie back in return for a coffee.
So, instead of trying to infuse (the idea of) trust in the system, the question becomes: how to change the behavior of actors in the system?
Cognitive Behavioral Therapy in ecosystems
I made it sound like influencing behavior is an easy feat, and of course we know it isn’t. Perhaps compared to changing beliefs it is, but compared to buying a coffee, it isn’t. In the Rainforest they use the example of cognitive behavioral therapy (CBT), which is a validated way to change people’s behavior through the process of interaction and helping people link actions, thoughts and feelings.
On the left is the simple model, where certain behavior leads to an event, which leads to appraisal, and emotions and these emotions in turn lead to new behavior. Notice how in the full model not only events influence cognitive appraisal, but behavior and emotions as well? In other words: we’re sensitive to appraisal and it’s not just events which trigger this (good to know in times of remote working).
How to build trust
Copying this approach to ecosystems the goal becomes to create environments of trust where people learn behaviors, can test them in events, get (positive) feedback on this behavior, feel good about it, and do it again. When you look at the model it makes sense to try to influence all four to end up with the desired behavior. Let’s discuss the four blocks and see how you can influence them by design.
Behavior
When we take a look at influencing behavior, you can use “social pressure” to your advantage, in other words: we want to behave like our peers and we want to behave like our role models.
Role models
When ecosystems emerge without design than role models are also “emerging”. Every ecosystems has one or two small (or larger) gurus who everyone knows and watches more closely. The behavior of these role models influences the behavior of the actors in the entire ecosystem! And here is the trick: when you design the ecosystem, design the events, and the programs: you can design the role models as well. You decide who you will put on stage, who you invite on your podcast or who will be the first “entrepreneur in residence”. The rest is relatively simple: never put anyone on stage who you don’t trust yourself and make sure that the role models themselves understand their role and their desired behavior!
At YES!Delft we had what we called VooDoo (in Dutch this was “by entrepreneurs, for entrepreneurs”). We consciously put entrepreneurs in front of our new batches to create the role models we’ve been talking about. We also had a group of entrepreneurs in residence who would meet the new founders in the first week they entered the program, and would be coming back again and again during the program(s). The same goes for our mentors.
Peers
The fellow entrepreneurs are probably an even larger influence on behavior than role models. Where role models are far away, your peers are always close by and therefore their behavior is much more in sight. The downside is that it is much harder to change the behavior of a large group, so instead of trying to change the behavior of the group, make sure you select/scout on trust very early on!
Supernodes
In every network there are some supernodes: the people who have 10.000+ LinkedIn connections, who go to a bar instead of going home to read a book after a long day at the networking event, who will always tell you “I know someone you should talk to”. Map these people in your ecosystem, put them together once in a while and make sure they are aware of their role. They’re different from role models as they not necessarily have to be successful, they don’t even have to be an entrepreneur, they just meet and know a lot of people and therefore you can use them to spread behavior much faster (take a look at complex contagion, and use it to your advantage in an ecosystem).
Event
We should see this block in two ways: the pre-2020 physical network event, and the everyday event (a meeting, a handshake, a digital coffee, a walk around town, a sales negotiation). Where we usually put a lot of effort in designing the first, we are much less aware of the second version of events, but let’s start with the first one:
(Large) Online/Offline Events
Events are useful for building trust for multiple reasons:
1. People learn best by doing, so you can design events in such a way that your attendees are “forced” to display trustworthy behavior, receive appraisal, feel the trust, and do it all over again, multiple times over the course of the event. “Corporate” speed dating is one of way doing this: set up 5 or 10 min slots and mix and match as much as possible.
2. You decide who you invite for the event. It might be open for everyone, but sending out invites to a select few might help to make sure the event is more diverse than usual. As we distrust what we don’t know, a more diverse environment becomes a more trustworthy environment. For instance, at YES!Delft we always tried to invite more women, to make sure the gender balance would be a bit more levelled.
3. It presents you with an opportunity to highlight role models, supernodes or peers who showed trustworthy behavior. Buy a small price and hand it out once a year to the most trustworthy person in the ecosystem!
Everyday events
While these might take much less time and energy to design, be aware that every event in the ecosystem is part of this CBT loop, and therefore either enforces or discourages trust. How you behave, what you share, who are present at the meeting, all of these little things matter for every event as they are basically the physical representation of the desired behavior (you can practice being trustworthy in the bathroom mirror all you want, what matters is how you behave in the sales negotiations).
(Cognitive) Appraisal
Appraisal is simply put an assessment, or in other words: how are we doing? There are two important things at play here: there must be feedback in the first place, and there needs to be some sort of social set of norms, to know if the feedback is actually good or bad.
Feedback
In order to receive feedback, there needs to be someone who is willing to give it to you. These feedback systems don’t emerge out of nowhere, so they need to be designed. At YES!Delft we used a community platform where everyone in the community could schedule a meeting with everyone. After the meeting you would get a pop-up the next time you logged-in: did you actually have the meeting? how did it go? A separate button for “did not show up”, and for things you wanted to share with the other party. As an administrator of the system this gives you a very basic idea of the quality of conversations happening in the ecosystem. Of course this can also be done physically, but it might be slightly harder to get an idea of the overall state of the ecosystem.
The point is: knowing that there is always an option to give feedback (to both sides) changes the events for the better. Giving and receiving feedback can slowly become a cornerstone of your community (and it can even get it’s own spot in the “social contract”).
Social contract / agreement
Feedback is fine and all, but how do you know the social rules? What is considered normal and what’s not? What kind of behavior asks for feedback? How are you supposed to behave in the ecosystem? Do you allow competition in the ecosystem? How open are you to others about your IP or trade secrets? All these questions are valid and can be answered by writing up a “social contract” or agreement if you wish. It should at least contain the importance of trust for the ecosystem, and how you would like to treat each other, but it can contain everything you want.
YES!Delft startups for instance sign an agreement which states what they are receiving when joining the ecosystem, but also states what they are expect to give in return. It also states, amongst others, that the goal of YES!Delft is to create more and “better” startups, and there is no profit and no equity involved.
Startups (and other actors) that know everyone agreed upon the same set of rules (even if there is no punishment clause in the agreement) can get peace of mind. Knowing “the rules” makes it also much easier to give feedback, and to reprimand actors who do not behave according to the rules.
Over time these rules will be internalized by the community and the need to write them down and explain them time and time again will probably slowly disappear. Until then it has a lot of value!
Emotion
This might be the most important part of this feedback loop. Without the emotional confirmation you’re doing the right thing, and other people doing the right thing the loop is broken and will not give the positive confirmation you are looking for. Even worse is a closed loop with negative emotions which might actually enforce a negative feedback loop, something to check on once in a while.
Implementing trust in large (online) ecosystems
Landing in a large ecosystem can be quite confusing. There are too many people to remember, you don’t know the nodes, or the role models, you are not aware of the social norms, and you’re not feeling safe enough (yet) to give and receive feedback. In short: you do not have trust yet. Because of the lack of trust you do not create meaningful connections, let alone transactions and before you know it, you drop out of the ecosystem because you’re not getting any value from it.
The answer here is to make sure people land in a proper way. This can be, for example, through multi day programs. I don’t think programs make much sense from a learning perspective (as I explained in this article) but from a trust building perspective they are great! All of the things I’ve written down above are easier to perform in a small group. It’s easier to give feedback, it’s easier to create a culture of trust, it’s easier to meet and interact with role models, etc etc. Because you meet with the program participants on a regular basis you can easily spot a dysfunctional feedback loop and adjust it. Once you set the social rules in the program, they are ready to play their part in the ecosystem as a whole.
For me this is one of the big reasons why you should keep using batches instead of continuous admittance to the ecosystem! If you do not prefer batches, at least think of a weekly or monthly event where people are welcomed!
Being aware
If there is one lesson in this article it is that trust does not come naturally to people. On the bright side: you, as an ecosystem designer, are in the driver seat. You can mess around with people all you want: put them on a stage, let them tell their story, and create situations where they are nudged to show trust, or nudged to give feedback. You set the norm in the ecosystem by your own behavior. In other words: as a startup support organization you can create an environment and activities within the ecosystem which will all positively enforce the trust in the ecosystem!
Trust in (online) teams
Everything mentioned above can also be used to create trust in your company, amongst your colleagues, or in your own team. It’s probably even easier when the group is smaller, there is already some shared culture, and the role models are, ideally, the c-level executives.
