Transcript

It’s been a rough decade for the concept of trust. Faith in major institutions is at an all-time low. The tech industry has, if anything, streamlined its ability to burn people out. And to assume your employer has your best interests at heart often feels like a quaint notion from a bygone age.

But trust is useful! When we put trust in ourselves, we spend less time mired in self-doubt and more on personal growth. When we extend trust to our teammates, we accomplish more together than alone. And when our organizations earn our trust, aligning on a shared vision can transform how we work.

So that’s why I wrote this talk. Consider it a reflection on how we—as individuals, teams, and organizations—can recover from the (justifiable!) pervasive distrust in our industry by reframing trust as an intrinsic orientation instead of an extrinsic commitment. In it, I share six stories from my career as a software developer to illustrate how trustful and distrustful orientations can each create reinforcing loops towards increasingly vicious and virtuous outcomes, respectively.

This presentation was recorded as the keynote address for the inaugural Reliable Web Summit.

If this talk resonates with you, please share it with your friends and colleagues! In addition to software development, Test Double helps its clients improve how they work as a team—if your team is working to improve, we’d love to talk to you. And if you’re interested in helping other teams foster high-trust relationships, consider taking a look at our open positions.

00:00
(upbeat music)
00:03
- The title of this presentation is how to trust again.
00:07
And you know what, as soon as I typed that,
00:09
I knew that I might be a little over ambitious.
00:11
In fact, the last time I gave a how to talk,
00:14
it was titled how to program.
00:16
And so maybe I'm just inclined to over promise
00:19
and under deliver.
00:20
A more honest title might be how to take a moment to pause
00:24
and reflect on your relationship with trust as it pertains
00:26
to software development through six personal anecdotes
00:28
that may or may not resonate with you.
00:31
Yeah.
00:32
So anyway, we're talking about trust today and,
00:36
I think that it's only fair to say that
00:37
when you buy a product, you assume that you can trust it.
00:40
So it's natural to trust software by default too right?
00:44
And that would be true.
00:46
But if you know me, if you follow me on Twitter,
00:48
you've probably seen me just tweet the word neat
00:51
accompanied with a screenshot of software
00:54
and hardware, failing me in interesting and surprising ways.
00:57
And I can't speak for you, but at least for me,
00:59
I've come to distrust software by default
01:02
over the course of my career.
01:03
And a lot of my work has been to try to like make it better.
01:07
In fact,
01:08
almost 10 years ago now I co-founded a software consultancy
01:11
called Test Double.
01:12
And that was the first half of our mission.
01:14
That software is broken.
01:15
And then the second half being
01:16
that we're here to make it better.
01:19
So if you are either a company
01:21
that needs more senior engineers
01:22
and you could use some additional help,
01:24
or if you're looking for a new opportunity
01:26
and you're interested in consulting,
01:27
I hope you'll check us out.
01:29
My name is Justin Searls and you can reach me here
01:31
or find me on Twitter, GitHub, LinkedIn with my last name.
01:35
Searls as my handle.
01:37
And I hope we'll be able to connect.
01:40
Now, it's conference season
01:41
and so that means people are excited about new tools
01:44
and practices and ways of doing stuff.
01:46
And it's true.
01:46
There's a lot to be excited about,
01:47
but maybe I've just been at this too long,
01:50
but I've got this nagging question about tools, which is,
01:52
why is it that one person who could have one problem
01:56
prescribe a particular solution and have a great outcome,
01:59
but another person with the same problem
02:01
and prescribing the same solution could have
02:03
the exact opposite negative outcome.
02:06
And so, these two people might run into the hallway track
02:10
at a conference and say,
02:10
Hey, you know, like Searls advocate for this thing.
02:14
And the other person say, no, it's a hoax.
02:16
It's a total waste of time.
02:17
And you know, the weird thing about this is that
02:19
they're both kinda right,
02:21
they're speaking to their own valid experiences.
02:23
But like you wouldn't expect this to happen
02:25
as often as it does in software
02:27
where we just have people line up on either side and say,
02:29
one tool is awesome and the same tool's terrible.
02:32
And it keeps fueling the fires of us reaching for novelty
02:35
and new tools and process.
02:37
So to think about this more generally,
02:39
let's switch to a radically different context and imagine
02:42
that there was an avocado conference.
02:44
And you could imagine a bunch of tools there for slicing
02:47
and storing and keeping avocados, or,
02:50
preserving them in different ways
02:52
and all sorts of creative avocado innovations,
02:54
like how to grow one out of a seed like this.
02:57
And yeah, that would be really cool.
02:59
And people I'm sure would be excited because tools are good.
03:02
Like, for example,
03:03
if you've ever had the problem with an avocado
03:04
turning brown, you could use a tool to keep it fresh longer,
03:07
and then it stays green and there you fixed it.
03:10
But tools are good most of the time,
03:13
but they can have unintended consequences.
03:15
So for example,
03:16
if you've got a brown avocado
03:18
and then you decide to use some avocado colored markers
03:20
on it to green it up again, sure you fixed it,
03:23
the avocado isn't brown anymore,
03:25
but have you really solved the underlying problem?
03:27
And I feel like when it comes to software,
03:29
when you have a bad experience or bad outcome,
03:31
we tend to jump to the conclusion
03:33
that the solution is more software or better tooling.
03:36
Whereas, maybe the bad software is just a symptom
03:39
and we're skipping right over a root cause analysis,
03:42
which leads us to a solution to just assume
03:44
that we need more software when we really don't.
03:47
Go back to that brown avocado for a second
03:49
and imagine you color it in, you make it green,
03:51
you hand it to somebody,
03:52
it's not gonna be particularly appealing, but like,
03:55
if you try to solve that by just putting
03:56
some guacamole seasoning on it,
03:58
now it's just gonna be covered in little dust flakes.
04:00
And, you might try to solve that then by putting something,
04:04
artificial avocado flavoring on to kinda restore
04:06
the original flavor.
04:07
And at this point it's disgusting, right?
04:09
Like it's obviously not the solution,
04:12
but had this been a software conference,
04:13
maybe people's reaction be like,
04:15
we need better avocado tooling
04:17
instead of questioning the premise.
04:19
So whenever we find ourselves treating the symptom
04:21
in this industry, it's worth interrogating,
04:23
whether we're just creating new problems
04:25
and distracting ourselves from the root cause.
04:29
I'm using the word trust a lot.
04:30
And so it's probably worth clarifying what I mean by that.
04:33
Sometimes people use trust to mean like hope
04:35
or a commitment or a promise
04:37
or some sort of reciprocal agreement to rely on one another.
04:40
And really today I'm just talking about it
04:42
as a default reaction, an orientation
04:44
that we have to, novel stimuli.
04:47
So like,
04:48
if you imagine trust as a compass
04:49
where north is the direction of trust.
04:52
When I'm personally operating from a place of trust,
04:54
I tend to assume that other people are competent
04:56
and that their ideas are valid
04:58
and that new things are worth giving a try.
05:00
But when I react out of distrust,
05:02
I doubt the competence of others and,
05:04
with it I react negatively to their ideas and to their work.
05:08
And so just like a compass,
05:09
that orientation determines where we're going.
05:12
And I think that one of the reasons tools gets conflated
05:15
in here is because whatever tools we use,
05:17
are just gonna get us going
05:19
where we're already headed faster.
05:21
So, as you go in a direction like say with distrust,
05:26
it tends to compound the further you get
05:28
sometimes in vicious cycle,
05:30
sometimes just in second order effects,
05:32
but the same is true for trust.
05:33
And so the same exact tools
05:35
can be used in a trustful orientation.
05:37
And those vicious cycles could just as well be
05:39
virtuous cycles as we build out and reinforce
05:43
and have a larger positive impact.
05:45
And so today I'm just gonna share a few stories
05:47
from my own career about experiences
05:49
with both trust and distrust.
05:51
And let's kick things off by talking about
05:53
the kernel of distrust,
05:55
because it winds back to me as an individual
05:59
at the beginning of my career.
06:01
And so at the time I really doubted myself
06:04
at my first programming job.
06:05
I walked in and it was like Charlie Brown's teacher
06:08
with just like blabbing 40 proper nouns.
06:10
I'd never heard before.
06:11
And people spouting aggressive deadlines
06:14
and talking about how failure wasn't an option.
06:16
It was really intimidating.
06:18
Now we were a Java team and we're using this IDE
06:21
or integrated development environment called eclipse.
06:24
It looked something like this.
06:25
And if you've ever used an IDE,
06:26
a funny thing about them is that like you have to dig
06:29
and look very, very like just itty bitty code there.
06:31
That's where the actual code is
06:33
because most of the user interface Chrome
06:35
is actually tied up with all of these supporting tools.
06:38
They help you navigate or edit the thing or refactor stuff
06:42
in an automated way as opposed to spending
06:44
as much time writing code.
06:46
And they are indeed very Neato.
06:47
In fact, only like a few weeks later
06:49
because I was so self-conscious
06:52
about how I didn't really know how to write code well.
06:54
Eclipse became my security blanket.
06:56
I was able to kind of grow up around the environment
07:00
and find a way to be quasi productive
07:02
by just right clicking on stuff
07:04
and discovering new user interface elements
07:06
that could do stuff for me.
07:07
So I was coming from this place of feeling lost
07:09
and overwhelmed and not confident.
07:11
And the first thing that I found was the IDE
07:14
could help me navigate around in the code.
07:16
And so looking at a function here,
07:17
if I wanted to know what this particular steam method did,
07:20
I could just control click on it and then I'd be there.
07:23
And I could see the code listing
07:25
and start working from there.
07:28
But what I found was,
07:28
I wasn't building real good mental model of the system.
07:31
So somebody had asked me about that particular feature
07:33
and what was responsible for it.
07:34
I wouldn't really remember and that was concerning.
07:37
But as time went on, it is a couple of months now
07:40
and I didn't know where anything was.
07:41
And so I came to rely on another feature.
07:43
It was auto-complete and fuzzy finders in the system.
07:45
And so here,
07:46
if I'm writing a function to validate addresses,
07:48
I could start writing form
07:50
and then hit my auto-complete button
07:52
and then get a whole bunch of things that start with form.
07:54
And then I pick, okay, well I wanna format address.
07:56
And so I pull that method in.
07:58
And so you'd see the top of every file,
08:00
just start to import all of the stuff
08:02
that you'd auto completed in.
08:03
And they could just be methods from wherever,
08:04
but sometimes you'd end up reaching and grabbing
08:07
like really silly stuff like production code
08:09
that pulls in a test helper method,
08:11
just because it looks like a thing that might be useful.
08:13
And that's wildly inappropriate,
08:14
but like it makes sense
08:16
because systems are kinda just graphs, right?
08:19
Of objects invoking methods.
08:21
And those are the vectors in the graph.
08:23
And they're easiest to conceptualize when our code is,
08:26
doesn't have any cyclic dependencies
08:28
and it's just things calling other things.
08:31
And so here I am at the,
08:33
writing some code at the bottom of this tree.
08:35
If I'm reaching around to a whole bunch of other units
08:39
throughout the system,
08:40
I'm probably creating a lot of cyclic dependencies
08:43
and it could be having the effect of
08:47
making the system harder for me to understand
08:49
and harder for others to maintain.
08:52
So that only compounded, right.
08:54
So not only had I been like relying on a lot of
08:56
automated tools to make things,
08:57
now I didn't have any confidence at all.
08:59
I could just like write code from scratch.
09:01
And so I started relying on code generators
09:03
and little wizards throughout.
09:05
So here's like what a clips looks like with a blank page.
09:08
And of course, like blank page syndrome sets in,
09:11
and I just don't know how to write Java from scratch.
09:13
But fortunately it has little wizards.
09:15
Like I could create a web service or I could just fill out
09:17
this form and get a Java class.
09:18
And so I started doing that.
09:20
Now, if you're conscientious
09:22
and you're designing a system in a organized way,
09:26
you might have a file structure that looks like this.
09:28
But if you're just using a wizard,
09:30
they generate it all for you,
09:31
like no automated tool can be a substitute
09:33
for thoughtful design and organization.
09:35
And you just end up with sort of a dumping ground of files
09:38
in one place.
09:39
And it makes it harder for you to reason about the code
09:42
and for other people to understand what's going on.
09:45
So I personally spent several years treading water
09:47
like this.
09:48
The tools helped me cope,
09:49
but they really just enabled me to put off learning
09:51
how anything really worked.
09:53
Now, like this sort of thing can spread, right?
09:56
So like what happens when distrust spreads
09:58
throughout an entire team's culture?
10:00
And I joined a distressful team once,
10:02
but even still, I had a really good first week.
10:04
I was proud of what I'd done,
10:05
but it was clear no one valued any of my progress
10:07
because I didn't have any JIRA tickets file.
10:10
So what had happened here was this team didn't believe
10:14
that programmers could be trusted to manage their time
10:16
and their activities.
10:17
And so they required everyone to write those
10:19
into a ticket tracking system and that they'd monitor it.
10:22
You'd have a new ticket, you'd write a summary
10:24
with an estimated and actual hours,
10:26
and then you'd have to assign a reviewer
10:28
to review it for you.
10:30
And so what blew me away was that
10:31
all these incredibly bright colleagues
10:33
who are experts in their domain,
10:35
we're just walking around all day, talking about how to gain
10:37
this ticket tracking system appropriately.
10:39
And, I caught myself doing it too.
10:41
Maybe I wanna create a new service,
10:43
but instead it's like more and morphous ambiguous,
10:46
like where I can define success for myself,
10:48
if I just call it refactoring.
10:49
And I could estimate that it's 12 hours,
10:51
but I know I'm supposed to hit 40.
10:52
So I could just like pad the estimate.
10:54
And if I go over time, I know I'm gonna get in trouble.
10:56
So I'll just kind of like hide time and reduce my actuals
11:00
to make sure I'm meeting my estimates.
11:02
And instead of picking the reviewer
11:03
who knows that part of the system best,
11:05
instead I'm just gonna like find an ally
11:07
who will just approve it for me.
11:09
And this of course didn't lead to anything good.
11:11
And instead what happened was the good quality suffered.
11:14
And instead of like going back on this decision,
11:16
what the team did instead was start to mandate
11:18
code quality metrics in particular code coverage.
11:21
So that's the percentage of lines
11:22
that get executed whenever the test run.
11:24
And it wasn't high to begin with,
11:25
but they had a CI tool that would go red whenever
11:28
like the code coverage dropped after a new commit
11:31
and boom there, oh, it was me.
11:34
I decreased the code coverage and what happened.
11:36
I had a really long method.
11:38
Somebody else had written,
11:39
I added a couple of lines and because there were no tests
11:41
of this method, it dropped.
11:43
So what was the solution?
11:44
While you could just write an empty test
11:46
and then call that method and pass nonsensical arguments
11:49
and not write any assertions.
11:50
And then boom,
11:51
as long as it doesn't have like raise an error,
11:53
you got a lot of code coverage
11:54
and you'd see the code coverage spike.
11:56
And then everyone on the team would congratulate me
11:57
on increasing the code coverage.
11:59
Kinda silly.
12:01
When this happened, everyone was like,
12:03
kind of shell shock.
12:04
They were afraid of writing code
12:06
that wouldn't meet these metrics.
12:07
And so productivity dropped off and the team solution was
12:09
to start benchmarking individual velocity in terms of
12:12
how many lines of code people were writing per month.
12:15
So some people wrote a little, some wrote a lot.
12:17
I actually sometimes deleted more code than I wrote,
12:19
and that got me in trouble again.
12:22
So I'd talk about like, well,
12:23
is it my JavaScript quality metrics?
12:25
Are they not good enough?
12:25
And they say, oh no,
12:26
we actually don't even track those
12:28
'cause we mostly do Ruby.
12:29
And I was like, well,
12:30
does my JavaScript still counts as progress?
12:31
And they're like, oh yeah,
12:32
it still counts towards your individual velocity.
12:34
So we took this application, it was mostly Ruby,
12:37
but then we gave developers this pathway by which,
12:39
path of least resistance,
12:40
they could just write as much JavaScript as they want
12:42
without any judgment.
12:44
So suddenly it became a very JavaScript heavy application.
12:47
It was a totally unintended consequence.
12:49
And so I wrote a lot of code and I got my star
12:51
and I moved on.
12:53
But when my colleagues didn't trust me to do great work,
12:57
it really felt impossible for me to do great work.
12:59
And it became a self fulfilling prophecy attempts to control
13:02
how we created things,
13:04
just distracted from the joy of creating,
13:06
and it became to feel like just another job.
13:09
How has this spread further?
13:11
Right?
13:12
Like what's the impact that distrust as a culture starts
13:14
to take root in an organization.
13:16
And so one time I had a client where we were in this really
13:19
obvious case of just out of touch management.
13:21
They didn't understand software.
13:22
They didn't want to.
13:23
And what they did know is that they wanted
13:25
to move the process to lean because they heard
13:28
that it would reduce waste.
13:29
And so I was game, okay, show me what you've done so far.
13:32
And their premise or thesis was that they were spending
13:35
too much on programmers and their solution.
13:37
Pay less for programmers.
13:38
They looked at a board of years' experience
13:40
and hourly rate.
13:41
And they said Muda,
13:42
that borrowing a Japanese word
13:44
for the sake of calling it lean.
13:45
And they added up the numbers, right?
13:48
So 85 times seven people over 40 hours,
13:50
that's a pretty high run rate
13:51
and they weren't happy about that.
13:52
And so what they did was they started laying people off
13:55
and hiring people with less experience
13:57
and for lower dollars per hour.
13:59
And they succeeded in a sense, they got their like,
14:02
blended rate down in terms of their loaded costs.
14:05
And the seven people were slightly less happy,
14:07
but they didn't account for though,
14:08
of course it was like people with less experience
14:10
and no institutional knowledge took twice as long
14:12
to get anything done.
14:13
And now their overall cost to get anything accomplished
14:16
in the system went up.
14:18
And so that didn't solve the problem.
14:20
But instead of taking that as feedback,
14:21
that that was a bad strategy, they just leaned in and said,
14:24
well, the problem here is the programmers
14:25
aren't spending enough time at their laptops coding.
14:28
And so we need to manage them more strictly.
14:30
And what I saw when I walked into these rooms, it was like,
14:32
this is a really collaborative environment.
14:34
People are getting along great,
14:35
but what they saw was different.
14:37
They wanted to improve it, right?
14:39
So they borrow another Japanese word and they say,
14:41
Hey, we need a product to be inclusive
14:45
and included in all of these design decisions.
14:47
And so they just kind of dropped a plant in the middle
14:49
of the room and that person sort of shut down
14:51
all these conversations,
14:52
which had a silencing effect on everybody.
14:54
And they indeed got what they wanted.
14:56
Everyone was working at their desk all day,
14:58
even though they were very disengaged.
15:00
And, when, as you might expect,
15:04
office morale kind of dropped off a cliff
15:06
and no one was having fun, right?
15:08
And so they decided to just move the developers
15:10
to a new office, they're looking around and they're like,
15:13
well, us business guys all have a lot of fun.
15:15
And so they just said, Mura!
15:17
Unevenness, like we should have concentrated offices
15:20
based on everyone's function.
15:21
And they moved those people out,
15:23
literally down the street
15:24
to like a kind of dilapidated warehouse facility.
15:27
And it was like not fun,
15:28
but to them it was just out of sight out of mind.
15:32
It can be hard to even imagine how an organization can get
15:35
this screwed up,
15:36
but like we can of course relate to ourselves,
15:40
not believing in our own abilities
15:42
or in the abilities of our teammates.
15:45
And I think what we often fail to do is make the connection
15:47
that by the time distrust really takes root
15:50
in an overall organization,
15:51
there's just enough distance and indirection
15:54
to systematize that distrust.
15:56
And it can literally dehumanize people by just assuming
15:59
the worst in them and codifying that into practices
16:04
and policies.
16:05
So that's enough about distress.
16:07
Let's tell a few stories about the difference in life
16:09
when you are in a trusting scenario.
16:12
So first I wanna talk about just the first kernel,
16:15
how trust benefits you as an individual.
16:18
I had a client once and they were very, very smart.
16:20
And so they took their system and broke it down for us.
16:22
They said, well, you know, it's a large single tenant app.
16:24
It participates in energy markets,
16:25
controls millions of thermostats via a radio paging network.
16:30
And it helps keep the grid stable when it's under peak load.
16:33
And that was amazing.
16:36
And then there is more, so your job is just expand that app
16:39
from merely participating in markets
16:41
to instead of establishing and running the market
16:43
for this redacted nation.
16:45
And at this point I just didn't know what to do.
16:47
But I had enough experience at that point to know
16:49
that even though this was more work than I could handle,
16:52
all I gotta do is shrink the problem
16:54
and narrow my focus on something that I can control.
16:57
So I don't get overwhelmed.
16:58
And so I can wrap my head around it.
17:00
So there was this big existing rails application,
17:02
and I was content to just say, that's a lot,
17:05
but I'm just gonna set that aside
17:07
and instead think about just this thin candy shell
17:09
of new functionality that I'm gonna build
17:11
that just take an electricity in dollars
17:12
and does the math that they're asking me to do.
17:15
Now, to get started though,
17:17
I had to get some kind of traction.
17:19
What was the first line of code that I'd write?
17:21
And the answer to that is I wanted to create
17:22
the simplest possible thing I could,
17:24
I was looking for just getting some kind of toehold
17:27
writing something, even if it's trivial that I could use
17:30
to make incremental progress.
17:32
And so one way to do this,
17:33
might've been to introduce a browser
17:34
and start doing web UI stuff
17:36
and maybe render a calculate button, hit a button,
17:38
and then like see it go through the whole system
17:41
and arrive at some outcome.
17:43
That would have worked, I think,
17:44
but it still would have been dredged up
17:46
all of this complexity.
17:47
I wasn't ready to digest quite yet.
17:50
And in addition to add all of this UI
17:53
and browser complexity as well,
17:55
it would just be overwhelming.
17:56
So instead what I did,
17:57
was I just pushed away the larger application
18:00
for a second and treated this new functionality
18:02
as if it was a self-contained library.
18:04
And I started writing a failing test
18:06
and then making that test pass.
18:08
What we were doing was practicing test driven development.
18:10
And TDD as a practice over my career really helped me
18:14
break down problems when I was at lowest confidence
18:17
and find a productive rhythm,
18:18
even when I'm starting something completely from scratch.
18:21
So here you just start with a basic test case,
18:24
just instantiate a new thing, call it with a basic argument.
18:28
And then, if you call it with zero assert
18:30
that you get zero back, something real simple.
18:32
And the name of the game really
18:34
is with each action you take when you have a failing test,
18:36
either make that test pass or change the message.
18:40
Now the first message you get is that
18:41
that class doesn't exist.
18:42
And so you just go in and define the class
18:44
and then it'll say, oh, well that method doesn't exist
18:46
and you define the method.
18:47
Let's say, oh, well that doesn't have this argument
18:49
and you just add a parameter.
18:51
And finally you get the actual assertion error saying, Hey,
18:53
I expected this to be zero, but it was nil.
18:56
And like, these are very, very tiny steps,
18:58
but then you make a pass by adding a zero
19:00
and it really starts to give you this sense of
19:04
forward momentum as you go.
19:07
And boom, there you go.
19:08
We got to our passing test, a dot means passing
19:10
in this test runner.
19:13
And so over time, right?
19:14
I just kept adding more dots.
19:15
And each of those dots represented a feature or an edge case
19:19
or an if then,
19:20
and what it was able to do was give me the confidence
19:23
that I had built something of value,
19:25
'cause this was all to the specifications
19:26
that they'd provided me.
19:27
And so once I had that traction,
19:30
I just had the confidence now to prove that it worked
19:33
by plugging it into the bigger system finally.
19:37
So I had this running test of just this
19:39
in this isolated case.
19:40
And now I was gonna pull in the bigger app
19:42
and write a failing test that just called through my thing
19:45
and everyone else's stuff
19:46
and ultimately get some kind of answer.
19:48
And so to do that,
19:49
I just wrote an empty test case
19:50
that just did the bare minimum of tests set up
19:52
so that it wouldn't blow up when I was done.
19:55
So I ran the test and a lot of time passed.
19:58
And it did pass, it didn't blow up.
20:00
But still didn't look right
20:01
because it took like four minutes.
20:03
And I've learned over the years, that is a really important
20:06
to get fast feedback from my system, right?
20:09
Thinking about this, there's only 480 minutes in a Workday.
20:13
And if it takes me four minutes to run a single test
20:16
that's empty, that doesn't do anything else.
20:18
Then I only can run it 120 times at maximum.
20:21
And that doesn't count thinking
20:22
and that doesn't count typing.
20:23
So like it really limits the number of feedback loops
20:26
that I can have every day or in other words,
20:29
like the number of questions
20:30
that I can ask my system every day.
20:32
Now, the more you can ask of your computer
20:35
and the faster, and the richer feedback you get back,
20:37
the more you're able to build your confidence.
20:39
So this is super important.
20:41
So anyway, I had to make it faster.
20:42
So I pulled out a profiler and I finally,
20:45
as I'm looking at how this code is getting invoked,
20:48
I have the confidence to pull back the covers a little bit
20:50
and start to dig into the individual points of slowness
20:54
throughout the system and optimize them and make them faster
20:56
until I get everything not only passing
20:58
but much more performance.
21:00
And this was a way to take the confidence I've built
21:02
in myself and earn trust with the rest of the team.
21:07
So it had a compounding effect.
21:08
Now, again, trusting yourself in this industry is not easy.
21:12
The two things that helped me here were like,
21:13
breaking down problems into smaller digestible bits
21:16
and adjusting the environment around me to get richer,
21:19
faster feedback from the computer.
21:20
What works for you might be totally different.
21:23
But taking it a step further and talking about
21:25
how trust extends,
21:27
I'd like to talk about how it benefits teams.
21:29
Now I was on one team about 10 years ago now,
21:31
that was the best team I've ever been on.
21:33
It was called Course Reader
21:34
and none of us had ever worked together before.
21:36
And so the first thing we had to do
21:38
is normalize on approach.
21:39
And the first step of that is just to form as a team.
21:41
So we're in this cubicle firm and we decided to tear all
21:44
those walls down and instead come together
21:46
and form a team room around us.
21:49
Once we had, we stormed,
21:51
we like talked about all the different tools
21:53
that we would like to use and different approaches
21:55
and architectures.
21:56
And it went on for like a week and a half or two weeks.
21:59
And the business came along and they're like,
22:00
these people are not programming, that's a problem,
22:02
but we said, don't worry,
22:03
it's gonna work out.
22:04
And sure enough, over not much longer,
22:07
we started to compromise on the tools that we would use.
22:10
And we all kind of came to be of one mind
22:12
about our approach.
22:13
And in order that we'd be productive,
22:15
it was important for us to kind of codify
22:16
these norms upfront and commit to them.
22:18
And so we said, all right,
22:19
so let's take the conventions that we can agree to
22:21
and get started.
22:22
And so we literally printed out this covenant on
22:24
like a plot printer.
22:25
We said, okay, we've agreed,
22:27
we're gonna do a hundred percent test driven development.
22:29
We're gonna pair a program all day every day.
22:31
The second pair, when a first pair finishes a feature
22:34
is going to validate that the feature works.
22:36
And if there's ever an exception,
22:37
let's come together as a team and just talk about it
22:39
and find consensus.
22:40
It's no problem.
22:42
We all literally signed to this and by signing it
22:44
and being bought in, it actually worked.
22:47
And from there very quickly,
22:50
we were able to really start to get traction
22:51
and perform as a combined unit.
22:54
So even though we'd normalize though,
22:56
like we still had a wildly different skills and experiences.
22:59
And the next kind of secret weapon here
23:00
was to pair program intentionally together
23:03
in order to share that experience.
23:06
So, you might call it prolific pairing
23:08
where we have all of us in a room
23:10
and we just randomly pair up at the beginning of the day,
23:12
we work together.
23:13
And then when somebody finishes a story or a feature,
23:16
we switch it up and we switch up at random.
23:18
So everyone has the experience of working
23:19
with somebody else.
23:21
We also did a kind of playfully adversarial game called
23:24
ping pong pairing where one pair would start
23:27
by writing a failing test, ping pong to their pair.
23:30
And then the other person would make that test pass
23:32
while writing the next test as if to throw it on a challenge
23:35
for their pair, ping ponging back,
23:37
who would then make that pass and write a third test
23:39
and so on and so forth throughout the day,
23:41
which is a great way to make sure that both parties get
23:43
a chance to drive equally as well as to make sure
23:46
that everything that we're doing is being demanded
23:48
by a test.
23:49
And we would do this until it got to be, feel pointless,
23:51
where you're in a room together,
23:53
and like you're pairing with somebody
23:54
and your default reaction to every single question
23:57
is the exact same.
23:58
And once we got to that point, then we'd split up
24:00
and maybe work on separate stuff.
24:02
And so you'd see the team start to like kind of
24:04
coalesce naturally as things got higher risk
24:06
or higher uncertainty.
24:08
So for us, that was what pair programming really was.
24:12
It was a mind-meld and it was really awesome.
24:14
It was exhausting, but we got a lot done.
24:16
Whereas I think the popular notion of pair programming
24:18
is much more like colocated troubleshooting,
24:21
where you get blocked by something,
24:22
you can get somebody else's help for 10 minutes
24:24
or you screen-share and kind of just watch,
24:26
like if you can ever try the more engaged,
24:30
like ping pong pairing, I encourage you to.
24:33
So we took that, now we're totally on the same page,
24:36
we're performing,
24:37
but we still don't have much insight into product decisions.
24:39
And at this point we decided to take all that
24:41
positive energy and pull the business into the team
24:43
and help them succeed too.
24:45
So up until that point,
24:46
they'd just been throwing requirements at us over the fence.
24:49
So we just grew the size of the team room and we invited in
24:51
the product owner and the business analyst.
24:54
And first we start with the product owner
24:55
to help them specify user features
24:58
that are written well in a way that we can understand
25:00
as well as acceptance criteria for what it means
25:02
from her perspective for them to be done.
25:05
And we sat with the business analyst and said, okay,
25:07
so given all of these exceptions criteria,
25:08
let's write step by step instructions to understand
25:13
is this thing actually working.
25:15
And so we started out by writing these
25:17
as like automated browser tests
25:19
to make sure that the acceptance criteria were all
25:22
fulfilled, but eventually we stopped because like 90 percent
25:24
of the value was actually just forcing us
25:27
to have these highly specific, intentional conversations
25:30
to determine the product's direction.
25:32
And from there going through those four stages,
25:36
that team was just firing on all cylinders.
25:38
In fact, when I reflect on it now,
25:41
even though it took us a little while to normalize,
25:42
once we did,
25:43
we truly just operated as one unit and it required
25:46
each of us to kind of come at it with the humility
25:48
that we each have things to learn from one another,
25:51
as well as just the genuine
25:52
and through enthusiasm to build something as a team.
25:56
So if you take that positive energy and you push it further,
25:59
where does it get you?
26:00
And I'd like to talk finally
26:01
about just how trust benefits organizations.
26:03
Now, if you're watching,
26:05
this next part is gonna feel a lot like sponsored content,
26:08
because I'm gonna talk about my company Test Double.
26:10
And the reason is, we really founded it as an extension
26:13
on this idea of high trust teams being more productive.
26:18
The first thing that we started with of saying, well,
26:20
controlling people obviously doesn't work.
26:22
And so we need to honor one another's autonomy.
26:25
When we first started,
26:26
a lot of people were pushing us to kind of define
26:28
the Test Double way of like, how do you write code?
26:30
And I pushed back.
26:31
I was like, you know what?
26:32
I would never wanna work for me.
26:35
So why would I define a whole bunch of rules
26:37
that would just tell other people how to do their jobs?
26:39
It didn't seem right.
26:41
And we adopted the mantra early on trust the people closest
26:44
to the work to do the best job.
26:46
And it's really paid off.
26:48
Additionally, we were remote from day one,
26:51
but in the last couple of years,
26:52
a lot of companies had to go remote
26:54
and they've been reluctant about it.
26:55
And so as tools like slack have become popular,
26:58
the green bubble to indicate if you're online or offline,
27:01
has sort of been treated in a lot of places
27:04
like a punch clock or like a time in attendance system.
27:06
And so if you go offline in the middle of the day,
27:08
it sets off a red flag somewhere,
27:09
and they assume that you're just not working.
27:11
We were totally different because for us being remote,
27:14
it was actually a way to promote autonomy among people.
27:17
They could control their schedule
27:19
and figure out how do they work best.
27:22
Todd, our CEO was fond of saying,
27:23
if your client's delighted with your work,
27:25
we don't care when, where, or how you do it,
27:28
as long as they're happy and you're happy, we're happy.
27:31
And so we started there, right?
27:32
We had a lot of people in the room
27:34
who were highly competent,
27:36
loved the like high trust environment and what we needed
27:38
to be successful as a broader organization though,
27:40
was to form strong alignment.
27:42
And the way that we did that was through open
27:44
and honest communication.
27:45
And so the first thing to balance,
27:47
is the signal to noise ratio because some developers,
27:49
they just wanna code, right?
27:50
They want a job that lets them ignore
27:53
how their company makes money
27:54
so that they can go heads down,
27:57
but they have to acknowledge like that exposes you
27:58
to the risk that maybe your supposedly secure job
28:02
is not financially sound
28:03
and they have to lay everyone off.
28:05
For most people that would be not enough signal.
28:09
Some people think that they want radical transparency
28:11
from work, but every time that the company
28:14
would get bogged down
28:15
and every expense that somebody charged
28:18
or some other kind of trivial thing,
28:20
there are more important discussions
28:22
that should be getting heard, but aren't.
28:25
And so that might be an indication
28:27
that there's just too much noise.
28:29
So we're very intentional about like balancing this
28:31
by sending periodic contextual,
28:33
often actionable updates to the staff.
28:36
Todd monthly sends revenue profitability,
28:39
putting it in context,
28:40
Mike shares our staffing forecast.
28:44
Christine has an awesome EDI newsletter,
28:46
Anya with recruiting, Kathy with marketing,
28:49
and then Mary with all of the new people joining
28:51
the company, benefits, changes,
28:52
and leadership opportunities.
28:55
And it's not enough just to kind of send
28:57
the right communication,
28:58
but it's important that they be consistent
29:00
because I don't know if you've ever had this experience,
29:01
but even if I don't have reason for distressed,
29:04
if I only hear from my boss at random times,
29:07
it's natural to worry.
29:08
It's gonna be bad news.
29:09
And that's why it's so important that,
29:12
and I'm so grateful that Todd for almost 10 years now,
29:14
every single month has sent our financials using
29:17
the same charts and the same system
29:19
to contextualize our current performance against history
29:22
so that everyone has the context to respond appropriately.
29:26
And this last part about communication
29:28
should go without saying,
29:30
but the best way to build trust when you're communicating
29:33
is to stick to the truth.
29:35
And before we were Test Double,
29:38
I never realized how much of my brain was wasted
29:41
on keeping track of and playing office politics
29:44
and compartmentalizing information.
29:46
It frees so much of my Headspace
29:48
that I can just keep one story straight
29:49
for pretty much all audiences.
29:51
And to illustrate,
29:52
I'm gonna show you the slides now
29:53
for our most two recent internal meetings.
29:57
First, the board last month,
30:00
we had our Q2 results.
30:01
And then we had an all hands meeting the same week.
30:03
And it was actually basically the same slides
30:06
because there's nothing to hide.
30:07
The company's results are the company's results,
30:09
and we want strong, true alignment.
30:12
So having that openness communication,
30:15
having the people in the room who are themselves providing
30:17
a ton of value, it became clear eventually
30:20
that success wasn't being shared equitably.
30:21
We just had two co-founders.
30:23
And so we decided to transfer ownership to the employees.
30:26
And when most companies give you shares or stock or equity,
30:30
they're doing it kind of for a shorter sighted,
30:33
like objective or a side effect.
30:35
Like if you go to a bunch of startups,
30:37
they might all be long shots,
30:38
but you can imagine that most of the time
30:40
when you're offered equity,
30:41
it's either to recruit you in the first place,
30:43
retain you once you're there or potentially
30:45
to like push you to work lots of overtime
30:48
'cause you've got skin in the game.
30:49
And frankly, our story was just a little different, right?
30:52
Like we trust people with autonomy
30:54
'cause we thought it was right.
30:54
And we saw success.
30:56
We achieved strong alignment because we are communicating
30:59
and we grew,
31:00
but like eventually we kept on growing
31:02
and people would be right to ask,
31:03
can they get a piece of this?
31:05
And it just started to feel like the logical extension
31:08
for our high trust culture was to share that success
31:11
with everyone more fairly.
31:13
So, we went big last year and Todd announced
31:15
that we are going to transfer a hundred percent
31:18
of the ownership of the company to the employees.
31:21
And now that's well underway because we chose
31:23
a well-regulated employee stock ownership plan.
31:26
And it's really transformed the way that we all look
31:30
at the company.
31:31
Because it's not like that long shot startup.
31:33
This is already a successful, proven stable company.
31:37
And it grows incrementally and sustainably every year.
31:42
But again, like it didn't originate from some incentive
31:45
or compensation scheme that we had in mind.
31:47
We just were following this same journey of trust.
31:50
We trusted people to work autonomously.
31:52
We trusted them with the truth and it only made sense for us
31:56
to all share in the same success.
31:58
And what I found over the years is like
32:00
the further you travel down this path of trust,
32:03
the less able I've been to predict
32:05
where it was gonna take me,
32:07
but so far the results have done nothing but surprise
32:10
and delight me at every turn.
32:12
Every stage of the company over the last 10 years,
32:14
I am just incredibly excited about all of the people
32:19
I've gotten to meet and the strong relationships
32:20
we've been able to form.
32:22
And I wouldn't trade it for anything.
32:25
And so there's some number of people though.
32:27
Who've listened to all of this and they're like waiting
32:29
for the how, like how do I trust though?
32:33
And the answer is gonna be different for everyone.
32:35
There's all sorts of different situations,
32:37
all kinds of different people.
32:38
All I can do is offer a starting point
32:40
as a suggestion to try.
32:42
And that would be to say next time
32:43
that you have a visceral distressful reaction
32:45
for good reason or not, try to pause
32:48
and see if there isn't a way to reframe it.
32:50
Maybe it's giving yourself the benefit of the doubt
32:53
or assuming that your colleagues are competent
32:55
and acting in good faith.
32:57
And if you're in a position to manage people,
32:59
to just believe that they all want to do their best work
33:02
and find a way to support them,
33:03
instead of just actively manage.
33:05
So thank you.
33:07
If you're interested in learning more about Test Double,
33:10
I'll hope you check us out.
33:11
We're hiring thoughtful people who wanna improve
33:14
how the world writes software.
33:16
And we're always looking for clients
33:17
who are just trying to accomplish ambitious things
33:20
and they're interested in improving
33:21
and they need some extra help.
33:23
And of course, I hope you'll reach out to me directly
33:25
if you have any feedback or even if you just wanna chat.
33:29
Again, I'm super thankful for you taking the time
33:31
with me here today, in talking a little bit about trust.
33:34
And I hope that you're able to take a little bit of this
33:37
and put it to good use.

Justin Searls

Hash An icon of a hash sign Code Name
Agent 002
Location An icon of a map marker Location
Columbus, OH