The Ten Ways of Trust
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 45 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/67286 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
Foss Backstage 202110 / 45
6
10
15
18
28
38
40
41
00:00
TelecommunicationStrategy gameInformation and communications technologyTelecommunicationEndliche ModelltheorieStrategy gameDecision theoryBasis <Mathematik>Data conversionConnected spaceGroup actionAuthenticationOpen setSelf-organizationElement (mathematics)Core dumpInformation and communications technologyMusical ensembleStress (mechanics)Online service providerBuildingEuler anglesComputer animation
02:01
Product (business)Axiom of choiceService (economics)Decision theoryTheoryProjective planeOpen sourceView (database)
02:47
Product (business)View (database)Open sourceSet (mathematics)Computer animation
03:40
Row (database)Data modelData integrityType theoryEndliche ModelltheorieSource codeOpen sourceSoftware testingQuicksortAuthenticationData structureOpen setProduct (business)Materialization (paranormal)Standard deviationLevel (video gaming)Library catalogMultiplication signContent (media)Service (economics)Different (Kate Ryan album)Business modelData miningCategory of beingExterior algebraComputer animation
05:39
TelecommunicationProduct (business)Web pageInteractive televisionTelecommunicationBlogProduct (business)Domain nameDemo (music)Wave packetComputer animation
06:11
Formal languageNumberSoftware developerData structureFormal languageTelecommunicationNoise (electronics)WordSocial classStatement (computer science)WritingHyperbolischer RaumComputer animation
08:01
Descriptive statisticsInformationBitPoint (geometry)NumberData structureComputer animation
08:35
Parameter (computer programming)Content management systemLogicShared memoryObject (grammar)Computing platformPairwise comparisonFigurate numberStandard deviationWritingPoint (geometry)ResultantSet (mathematics)Latent heatNumberInheritance (object-oriented programming)Functional (mathematics)CASE <Informatik>Arithmetic meanCanadian Mathematical SocietyComputer animationLecture/Conference
11:19
Arithmetic meanProduct (business)Binary codeNumberFocus (optics)Fitness functionTelecommunicationNegative numberAbsolute valueBuildingPairwise comparisonComputer animation
12:21
Type theorySummierbarkeitDifferent (Kate Ryan album)Sound effectProduct (business)Traffic reportingStatisticsMereologyCASE <Informatik>CausalityObservational studyNumberExpert systemQuantificationComputer animation
14:37
NumberExpert systemSource code
15:03
DivisorNumberOpen sourceBuildingComputer animation
15:36
Computer virusSource codeNormal (geometry)Connected spaceSource codeOpen sourceGroup actionMedical imagingTelecommunicationMultiplication signComputer animation
16:25
Strategy gameInformation and communications technologyMultiplication signBitFormal languageVotingProjective planeWordStreaming mediaContext awarenessVideoconferencingLatent heatInstallation artComputer fileElement (mathematics)1 (number)Descriptive statisticsSoftware maintenanceLevel (video gaming)Client (computing)TelecommunicationIterationDifferent (Kate Ryan album)Content (media)Type theoryConsistencyRight angleQuicksortSpacetimeAssociative propertySelf-organizationNumberMereologyNormal (geometry)ArmFlow separationModule (mathematics)Archaeological field surveyData structureOpen sourceGroup actionChainoutputMatching (graph theory)Front and back endsOpen setData managementRevision controlHybrid computerInformation technology consultingSoftwareSingle-precision floating-point formatExpected valueElectronic mailing listAxiom of choicePoint (geometry)Reading (process)Range (statistics)XMLUML
Transcript: English(auto-generated)
00:03
As Richard mentioned, my name is Tracey Evans and I'm a partner and co-founder of Open Strategy Partners and I'd like to talk to you today about trust, the 10 ways to build better connections and also build better businesses and better communities.
00:24
OSP was born out of some conversations and strong ideas about communication that has now become our communication model which underpins everything we do and it's called authentic communication and it's based on three elements that we see here,
00:40
empathy, clarity and trust. And so based on that I naturally gravitate towards any material written on these topics and I got the inspiration for this talk from a book written by Canada's former Governor General David Johnston. The book was called Trust 20 Ways to Build a Better Country
01:04
and in this book he implores us to see that trust is gained through our actions and decisions on our doing and not merely saying on the basis that can be observed and measured rationally is a quote from the book and he really wants us to explore the attitudes, habits and approaches
01:24
that make people, businesses, organisations and countries trustworthy and it was really interesting and I highly recommend the book. So in this talk I'd like to share with you 10 very practical tips to mindfully build trust into your communications and
01:46
also to make the argument that if we put actions like these at the core of how we communicate that we can build better connections, businesses and communities.
02:02
So let's step back for a second and think about why trust actually matters and my theory or philosophy is that more and more people are making values-based decisions including but especially around where they work, where they contribute and definitely what tools
02:24
and services they use or support and I would argue that trust is one of the most important underlying values that influence people's choices and for people to engage with your company, your project, your product, they need to connect with you and to do that they need trust.
02:47
So what is trust? Of course we need the Oxford definition of trust and that's the firm belief in the reliability, truth or ability of someone or something
03:01
but actually it's far more complicated than that, that's a really simplistic view. Trust is an often overlooked phenomenon but it's an important one that's worth deeper consideration in my opinion. Trust is especially important in how we communicate the value of open source technology products and services, the value of which is highly complex and often
03:26
abstract and where the story around a given set of features and benefits can be told in a multitude of ways. That's a really important view to have. So I really like Stephen Covey's
03:45
model of trust. To me it stands the test of time and it fits very well with open source technology products and services. When we look at his model we can see that it breaks down into two main categories, competence and character and on the competence side it solves the questions
04:06
things like can you solve my problem, can you solve it better than any alternative and can I expect a high level of knowledge and experience to be baked into your product or service and then over on the character side it looks more at things like do your values
04:26
align with mine and this question I'd like to break this down into three different types of values, those being moral, technical and business values. So for example with moral values
04:41
the question can be do they source their materials in a sustainable way, do they pay fair wages, do they have a diverse recruiting culture. On technical values it could be things like do they and how do they use open source and open standards, does it align with the way that we use it, do they treat users data with respect, do they use devops practices to get highly technical
05:10
and on the third type of value, the business values, it can answer things like is your business model competitive, is it transparent, is it fair and do you communicate
05:21
in an open and authentic way. This sort of structured catalog of questions is something that you should be visiting at both the strategic level as well as the content production level. This should really come through in both of those practices.
05:42
So the domains where trust matters most might be domains that you happen to overlook. We need to bring trust into our communication in all of these domains up here, so support and interaction, training, technical documentation, product communication, things like product pages,
06:01
data sheets, demos and of course editorial communication like blogs, social, PR. So getting down to business, let's dive into the 10 ways. So way number one is be technically
06:21
accurate always. A simple straightforward way to ensure technical accuracy is to interview the expert and if needed ask them to review your work. This is especially important for marketers and technical writers who may not have the depth of knowledge that the developers do, for example. Way number two, be precise in your language and use zero hyperbole. Avoid things like
06:52
best in class, only solution that or overusing the word innovation happens a lot.
07:01
Never say it's the only x you'll ever need or claiming that one technology will solve all of your problems. So avoid things like that and it's not only that these statements are inaccurate, they're also not helpful. They're so broad that it doesn't give the reader a clear
07:21
picture of the value that you can actually deliver them. Way number three, keep your writing tight. Too much noise around what really needs to be communicated dampens the trust that we can build. Crisp, sharp, focused communication, however, gives us the clarity that we spoke of earlier.
07:45
Way number four, a clear narrative structure and this is similar to tight writing in that it provides clarity but it does so by taking the reader in hand and essentially leading them down a clear path. Way number five, so an easy to navigate informational structure
08:07
makes the journey easy and flexible for your reader. It allows them to choose their own adventure and consume the bits of information that's most relevant to them. We do this with things like descriptive headlines, breaking down breaking the text down to smaller paragraphs that
08:23
are easy to scan using bullet points and other formatting to call out the important bits and this is really important for trust. And way number six is always use logical rigor
08:42
and of course avoiding logical fallacies and I'd like to take just a minute here to to provide a few examples of logical fallacies. First one being over generalization. So the
09:02
writer bases the argument on insufficient evidence. The writer draws a larger conclusion than the evidence supports and so if you are claiming that CMS A is better than CMS is a better CMS, you would need to do fairly exhaustive research and comparison with
09:22
objective standards and unbiased results to warrant that claim. You can however talk about a specific set of functionality that supports a particular use case that you haven't seen anywhere else. That's perfectly valid. The second logical fallacy that I want to share
09:42
is non-sequitur or it doesn't follow meaning so this is where the writer's conclusion is not necessarily a logical result of the facts. For example, super simple example stating that because CMS A has more functions it's a better CMS than CMS B. Obviously more doesn't equal better.
10:06
A third one that we have is begging the question. So the writer presents as truth what is not yet proven by the argument. So before an argument on a topic can be made or a solution offered the reader must be convinced that there is a problem. And the last example that I'll share
10:27
with you is called the red herring. This is where the writer introduces a completely irrelevant point simply to divert the reader's attention from the main issue and you may do this
10:41
unconsciously. So in reviewing your writing and reasoning make sure that you examine the suppositions and the conclusions you've made and make sure that you are not making diversionary or non-relevant points to support your argument. A concrete example would be citing sales figures to show that CMS A has higher sales than CMS B.
11:08
This doesn't prove that CMS A is a better platform than CMS B for a given set of needs. Way number seven. So make mindful claims by avoiding things like binary claims which is
11:29
you know stating that something is good or bad or absolute claims meaning best worst and things like that and certainly avoid negativity. It's better to respect the nuance
11:45
in the situations where your product may not actually be the best fit and using FUD or fear uncertainty and doubt in our communication and diminishing the value of the competitor doesn't help us build trust. It's quite the opposite. So focus on what value you deliver and not what
12:06
the competition doesn't. This doesn't mean that you shouldn't do comparisons. Just don't use it to paint the competition into an especially bad light. So way number eight is backing up your
12:31
claims with evidence and so we have a couple of different types of evidence.
12:42
So we have quantitative evidence which is things like statistics, industry reports, other research. We have case studies with quantifiable outcomes and if we want to look at qualitative evidence which is something that we see a lot of that's things like expert claims, testimonials,
13:07
anecdotal stories for examples, and case studies with qualitative outcomes and backing up a benefit claim by explaining
13:23
how the product is actually built to support that benefit. Our product provides x benefit because it's built containing yz features that also helps back up your claim and following on that is also documentation. So the other thing that we want to do when we think about
13:47
claims or backing up our claims with evidence is looking at the quality of the evidence and so it's important to ask ourselves is each piece of evidence in the content
14:01
piece is it valid? Is it relevant? Is it unique? And is the evidence directly connected with a cause and effect relationship to the claim? And we can absolutely make emotional claims without evidence when appropriate especially when quoting somebody else. For example
14:26
making a statement like by working together we make something greater than the sum of its parts and that's perfectly valid. Way number nine. Speak from or reference an authoritative voice.
14:47
The authoritative voice might be your internal technical expert, it might be a community-based expert, you can also reference research from a trusted source to have that authoritative voice. So and last but not least way number 10. Recognize and
15:15
acknowledge others for their expertise and knowledge, contributions and competitive
15:21
offerings. This is something that open source communities tend to do quite well actually and it's a very important factor in building trust. Oh there we go. So I believe that these actions and ways of communicating
15:46
lead to more trust and more trust equals more connection and more connection equals happier people, stronger communities and better businesses. My hope is that trust-infused communication becomes more and more the norm and I also believe that this will make
16:06
the world a better place and I believe that the open source communities can play a leading role in this. So thank you. That was the next one. So sources for all the beautiful images of course came
16:23
from Unsplash and that's everything. So thank you so much for your time and I'm ready for your questions. Thank you so much. That was great. Really excellent to hear how you view trust and
16:42
how you view for open source. For anyone who's listening if you have any questions feel free to drop them in the chat or put them in the questions bar. I thought this was a great talk. I have some questions if you're ready Tracy. I am. I'm trying to click over to the Streamyard tab but it's okay. I'm watching that so I'll let you know. You're getting a few hearts
17:03
right now. Oh great. No questions as of yet. Okay cool. Thank you. Yeah so one question I had was you talk about speaking from an authoritative voice. Yeah. And in open source I increasingly see with small projects this is really easy. You know if it's a small module and there's one
17:23
person then all the docs come from them. Yeah. But with larger projects I often find that things tend to devolve until you have this sort of vanilla marketing normal technical documentation speak where there's no real person behind it and so the authoritative voice becomes
17:41
the voice of the project itself in a way. Yeah. How do you do you advise people to try to put more quotes from maintainers or something? How do you try to make it not so vanilla but also more authoritative and more relevant to people and more personal for larger docs?
18:02
Yeah and I think part of the answer was actually formulated in your question. Sorry for begging the question. I shouldn't have done that. Imagine that in number five. No I think that it's, I think it is important to not just have sort of a vanilla project
18:24
voice. Of course you want some consistency and you want some sort of consistent style of voice but it's also really important to highlight the people behind the technology and so the
18:41
contributors and the maintainers it's important that they have a voice and that they're represented in all of the different types of communication in any open source technology and including documentation and you know it's I think it's really helpful for people when they come
19:02
to consume any of that content if they start to see some names and get to know who are the main players in the community that can also be quite motivating for them to make their own contribution as well and to participate and so I think we should encourage
19:27
highlighting the community's voice contributors and maintainers. Yeah I like that answer. Thank you so much. One question, another question I have is for read me's for again for small
19:42
projects because for much larger ones there's often someone who thinks about these things but for maintainers out there how do you expect people to build a narrative when really it's just description, install, usage, license, contribute and how do you build a narrative through your documentation? Do you have any suggestions? Oh that's a very good question and a very tricky
20:05
one to to answer. I think that you can build a narrative across your documentation by tying all of the the feature and benefit stories together and weaving those throughout
20:24
your documentation and for any given piece like the read me file of course there's like you know the the specific elements that people are expecting but there's no reason why you can't put a little bit of context or a little bit of backstory at the beginning or the end of
20:40
the document to help tie that narrative across the whole all of the technical documentation. That's a good answer thank you. By the way we've lost your video I don't know if that was intentional. No. Okay I just wanted to let you know. Again if anyone has any questions feel free
21:02
to drop them in the chat I'm very happy to talk about this topic because I really love it so I have some more going on. How would you like to speak to policymakers to provide funding? Yes this was an interesting question I had from the very beginning so you say things like don't use the word innovative too much you know avoid buzzwords right? Yeah. What happens
21:24
when an open source project needs to talk to people who use those languages to speak to their constituents? Say if you need funders or you need policymakers they want those words. Yeah they really do they really really do oh and there is no perfect answer to this so just to set
21:44
that up from the beginning. I think there are some careful language choices that you can make where you can get around not using those buzzwords or not using them so often or
22:07
explaining them in a little bit more depth and you know a little bit more of a concrete background. So if you're going to use a word like innovative of course it's not you know we don't have to completely eliminate that from our vocabulary but we should explain how we're
22:27
innovative. How are you actually different? Because the point about not using buzzwords is not is to eliminate the expectation that just using these words at a high level is going to solve
22:40
you know it's going to give them the understanding and the impression that that will have what they need and so as long as we back up those specific claims or back up using those words with a concrete explanation I think that might be the happy path. So that brings me to my
23:04
next question and again if you have any other questions feel free to drop them in the chat or the questions bar for those who missed me saying that the first two times. You talk about backing it up. So a lot of trust isn't just using language but being able to actually embody the language that you use. How do you publicly in the open manage expectations
23:26
with people who now have an expectation that you will back it up? Where do you do you have any tools you suggest for keeping a list of things that you've promised or for making sure that everyone knows like that you're that's more of a project management
23:40
project management question? I just wonder like on the back end how do you make sure that you always fulfill everything that you say in your docs? Actually we have a very specific tool for this and we call it the value map. I don't know that anybody else uses something like this but essentially it's a tool where we collect an inventory of every single feature and benefit
24:08
that a particular piece of software has and we make sure that we that the inventory is complete and we make sure that it's in the language following the principles that we
24:21
believe in and what we've just discussed and all of the marketing communications or technical communications that are built they're built upon that value map so it comes from like this concrete structure so that's essentially how we really approach that issue. That's really
24:48
fascinating. I would love to see one of those in action. What sort of people's open strategy partner normally work with? What sort of organization? What size? Size ranges. We work with
25:00
small and medium-sized technical agencies but we also work with large associations and companies. We operate almost exclusively in the open source space and we have so for example we work with type of three the association as well as the commercial arm the GMBH
25:24
and an agency within that community. We also are quite active in the Drupal community and essentially we love technology and especially open source is our home base.
25:43
So you work with large communities. I mean Drupal is huge and that's great. How do you get values from large communities? You use questionnaires, you use surveys, what do you do? That is a fascinating question and the Drupal community is actually a really great
26:02
example where they've gone through several iterations and effort around building their values and something that we do actually with our clients at a smaller level is help them identify their values so that they can bring out the right character and tone in their communication and there's several different schools of thought about how to build
26:27
values. So there's an inclusive approach where you might survey the community, find out their feedback, collect that, aggregate it, sort it out and then articulate them based on that and there's another school of thought which is that the leadership alone should try to
26:47
develop these values and the Drupal community actually did a hybrid of these two solutions. So it was essentially the leadership team in the association with an external
27:03
consultant that worked on their latest version of their values. They're the best articulated values I've seen so I encourage people to check them out and the way that they went about doing this in a hybrid way is that they, I believe they did interview some key
27:23
people within the community and got their input and then I believe they went away on an executive retreat and you know worked through them and articulated them from there which is a great approach. Yeah that sounds excellent and I think given the 10 steps that you have that would
27:42
also really really help starting from the value chain then going forth and saying does the organization match these things? Are we being honest, forthright, using the right words, putting them anywhere else? This is great stuff. Thank you so much. I really appreciate it.