How to trust again

[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.