Supercharging the Thing
Below is an email I sent to my Fernish co-founder who serves as CEO, Michael Barlow, and Kristin Smith, our president & COO. In the interest of sharing in a low-risk, high-reward way, I’m sharing below largely unedited.
I had originally planned on editing this piece heavily and breaking into multiple posts, but I shared it in its raw form with my buddy Will Doom at AWS Startup BD, and he suggested that editing further would be somewhat antithetical to my POV and modus operandi.
I agree with Will, hence this post in all its raw, gruff, Lucas wonder.
[All notes below in brackets are edits for clarity and context.]
– — — — — — — — -
Hey Michael & Kristin,
(Side note up front: I’ve Cc’d Tom [Frank, Michael’s exec coach] and Matt [Dubin, PhD, my friend and positive developmental psychologist & organizational behavioralist] here as our external org dev/flow brain trust, as they might have pro bono input for us.)
I was reflecting on a request Michael sent me as a late night note to himself, and subsequently followed up with me on Friday at our 1:1.
Michael asked:
“I’m trying to think of a few places where [Lucas] might be able to plug in and supercharge a project — but I want to ensure we go about plugging [him] in the right way.”
Upon reflection over this weekend (and especially while I was in a more non-focused cognitive state early this AM), it occurred to me that this is likely the “wrong” way to look at things.
Here’s why:
- It’s not particularly scalable.
- It doesn’t necessarily teach others to fish, but rather keeps Lucas fishing for them.
- As extension of #2, it doesn’t allow Lucas to create leverage via “teachable moments” or codified methods for “supercharging” a project or process, etc.
Instead, what I think would be more valuable would be looking for ways to further institutionalize “Lucas-thinking”. I’m using that loosely, as, humbly, none of my methods or techniques, etc, are unique to me. They’re a hodgepodge of brilliant thinking from others that I simply put into practice as much as I can.
That being said, Michael, I wanted to collect here some of what I think are behaviors I bring to the table that you may be looking for at-large, or that might be what you were hoping I could bring to projects.
This list includes (and I’m borrowing HEAVILY from Adam Grant here due to some recency bias, but the origin isn’t as important as the application):
1 — Fighting cognitive entrenchment — This one is newer for me, especially since I myself have a significant amount of “institutional” SME knowledge at our business, plus a lengthier career to draw from beyond all but 2–3 of our staff. You saw this most recently in my weekend advocacy for revisiting the dogma around buy-outs, and Kristin and I approached the buy-out/purchase tent + guiding principle doc by throwing Fernish cognitive entrenchment out the window, and revisiting first principles / foundational truths (as tenets) and using those to inform guiding principles. These tenets and principles themselves must be revisited over time via intentional revisitation and rethinking. That being said, re-thinking the dogma got us to a shared North Star rapidly, and ideally that “supercharges” downstream decisions in that context. The same fighting against cognitive entrenchment should happen at the functional level as well as at the strategic level frequently. Fundamentally, we want to instead encourage and inculcate cognitive flexibility: “the ability to apply knowledge to new situations and different domains”. Note that this still allows us to leverage our SME knowledge from elsewhere and institutional knowledge from Fernish, but “apply it to new situations and different domains”.
Great examples here are Sully (https://redsquaredconsulting.com/2020/02/cognitive-entrenchment/) and Wagner Dodge in the Mann Gulch fire (where he used his 10k hours, but did something entirely unconventional: he lit a fire himself, allowing a fuel-less patch to be created within which Dodge laid down with a wet kerchief across his face as the blaze ultimately roared around him…he survived whereas 12 other smokejumpers died in the fire — “mental flexibility” saved him, not religious adherence to training or any sort of “real brilliance”).
2—Approaching problems with confident humility (and vision confidence, vs. plan confidence) — This particular approach is a hallmark of many entrepreneurs, in terms of confidence around the vision but an admitted humility around how the vision will be tactically achieved via a specific plan. I like to think more about the goal and the vision, and less about specific tactics as much as possible. Getting too ingrained in (possibly false) confidence around a specific plan limits our ability to think of more options to achieve a vision. More options equals more outcomes to consider. Viewing things through a narrow lens of duality (for example) inhibits the expansiveness of the possibility, of which the “winning” idea might be beyond the initial limited construct. I think this particular lens is a key part to the “king of hacks” approach.
3—Irrecoverable vs. inconsequential: Or How I Learned to Stop Worrying and Trust the Team to Know the Difference — This one follows naturally from #2, as an array of options can be daunting for many and lead directly to analysis paralysis. I think Bezos articulated this best in his 2015 shareholder letter [1], but it’s been instrumental to Amazon’s success for quite some time: some decisions are recoverable and some are not. And to quote Jeff, “one common pitfall for large organizations — one that hurts speed and inventiveness — is a ‘one-size-fits-all’ decision making.” Amongst the three of us, I know we know this, but I’m not sure we live this and I think it represents a great opportunity for us. I think the question here is: How Might We push “inconsequential” or “Type 2” decisions further downstream in the org, and encourage the [leadership team aka “LT"] to do the same, such that not all decisions are treated like “irreversible” or “Type 1” decisions? Part of this is a firm recognition that Type 2 decisions can be recovered from quickly, and quickly recognizing what is a Type 1 vs. Type 2 decision, and lastly, trusting the LT and their reports to know the difference as well. Ideally, the team at-large can rapidly move through Type 2 decisions, and only slow the pace a bit by pulling in the C-suite or escaping to an LT meeting for Type 1 decisions. Performing this process effectively allows for the team to move quickly through the array of options devised as part of the confidence humility in #2 above. (Also, quoting Dave G from his ‘speed-as-a-habit’ post: “There are decisions that deserve days of debate and analysis, but the vast majority aren’t worth more than 10 minutes.”)
4—Squads over battalions — Squads are atomic, enabled, empowered, and have all the parts needed to make the right decision rapidly. They are not bigger than they need to be to achieve the outcomes they’re aiming for. Battalions are large, slow, bureaucratic, highly hierarchical, expensive, overly consensus-driven…and on and on. Most decisions of the Type 2 variety are perfectly suited for a squad mentality. I think we’ve developed a bias internally for decisions being made in the context of consensus and with more participants than necessary to drive a decision. I unilaterally eliminated “group collabs” involving the entire engineering org for just this reason, and the results have been uniformly positive. Decisions are faster; more ideas can be considered in parallel with concurrent, smaller squads deliberating; and learning is honestly happening at a faster pace. One requirement of this approach for engineering is a dedication and learned muscle around documentation that allows for revisitation of decision-making if the initially implemented idea “fails”; this bootstraps the second (plus) iteration, as well as allowing a wider array of players to come up to speed as needed. [I’m intentionally focusing on the positive examples here, rather than negative examples of “battalion” consensus thinking.]
5—Speed-as-a-habit hacks: Quoting Dave Girouard in his original post, “I believe that speed, like exercise and eating healthy, can be habitual.” Even better though:
You know you’re going fast enough if there’s a low-level discomfort, people feeling stretched. But if you’re going too fast, you’ll see it on their faces, and that’s important to spot, too.
I don’t think we’re going fast enough personally, as I don’t have this “low-level discomfort”. I also really enjoy his HMW-oriented maxim of “Why can’t this be done sooner?” And that we’re comfortable with asking ourselves this exact question “methodically, reliably and habitually.” I think if we err on the side of asking this question regularly, and it becomes instinctual, then we will likely drive higher task conflict but save ourselves from developing relationship conflict by avoiding these — what should be — unemotional task conflicts and thereby letting them compound unnecessarily into relationship conflicts.
6—Creativity over invention/convention: This is also a hallmark of “king of hacks” thinking, methinks, and I’ve been harping on it a lot lately, and on the engineering side of things, Kim [Engineering Director] and Gila [Senior Managers Engineering] are really doubling-down on it as well. I think Nina’s [Fernish Product Director] (shared) idea recently of changing the policy around fees is another great example, as it allowed us to spend less on engineering efforts and fast-tracked a more customer-centric solution. Ideally this can be propagated across the board. How might we get the team to think more creatively, and make fewer linear assumptions that more software software is the solution. A similar variant to this idea is avoiding Maslow’s hammer [2]: in this case if you approach a problem as solvable with any number of tools and any number of disciplines, then (mixing metaphors) any number of roads can lead to the solution.
7—Avoiding the escalation of commitment trap — Very much in the vein of sunk-cost fallacy, I think this is particularly challenging for us and might be better termed “avoiding the escalation of spreadsheet trap”, in ode to Kristin. ;) It’s also a close cousin in many ways to #6 above, as “spreadsheets” become convention or a particular implementation in Admin [our ERP], as example, the team may struggle to think of an alternative implementation to a solution that might be vastly superior to its antecedent or predecessor. Sometimes (oftentimes?) forging a new path is better than building on the previous path. We need to make sure to not continue doubling down on a house of cards.
8—Pragmatism vs. Perfection AKA Perfection is the Enemy of Good Enough — This excerpt from a really good FRC post captures it well, “Now at Plaid, Grezè abides by a pragmatism versus perfection approach. Here’s why: “When I was younger, I really liked the idea of building a perfect system and engineering something really perfectly. And that’s nice in the world of computer science and engineering and in the abstract, but pragmatically, you’re at a company with a budget. And in that world, great engineering is about solving business problems faster and better than your competitors can — and that just boils down to pragmatism,” he says. This particular aphorism is oft said but not practiced with sufficient regularity. Perfection tends to be pursued relentlessly by “creatives”, and it’s something Rachel [senior visual designer] and Megan [principal product designer] and I used to talk about regularly, as an input to driving more rapidity I design decisions. (Clearly a counter-balance here is the Design Sprint, but that is a decidedly time-boxed exercise that, while slower than some other decision-making processes, is at least time-bound at its maximum duration.) I think there are plenty of examples at present within the org where we might be striving too much for perfection, and not enough for pragmatism that self-fulfills more rapid execution. Combine pragmatism with Type 2 awareness, and a multitude of decisions can be made far faster, and experimentation feedback loops can be traversed more quickly as well — which in turn increases the speed of learning.
I’m highly aware that sitting down and writing this out is likely overindulging my academic predilections, but I think it takes exercises like this to manifest an outline for the sort of leverage we need to “supercharge” projects at Fernish. I tried my darndest to avoid stroking my own ego in the exercise above, but admittedly that was challenging given I was trying to identify my behavior or habits that I think inform Michael’s ask for me to dive in and supercharge in a SWAT fashion.
REDACTED STUFF HERE
Thanks,
Lucas
PS I really enjoyed this Medium post about “Confident Humility: A Way to Lead so Everyone Wins”: https://medium.com/personal-growth/confident-humility-leading-so-everyone-wins-6a6a19a259
[1] Invention Machine
We want to be a large company that’s also an invention machine. We want to combine the extraordinary customer-serving capabilities that are enabled by size with the speed of movement, nimbleness, and risk-acceptance mentality normally associated with entrepreneurial start-ups.
Can we do it? I’m optimistic. We have a good start on it, and I think our culture puts us in a position to achieve the goal. But I don’t think it’ll be easy. There are some subtle traps that even high-performing large organizations can fall into as a matter of course, and we’ll have to learn as an institution how to guard against them. One common pitfall for large organizations — one that hurts speed and inventiveness — is “one-size-fits-all” decision making.
Some decisions are consequential and irreversible or nearly irreversible — one-way doors — and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation. If you walk through and don’t like what you see on the other side, you can’t get back to where you were before. We can call these Type 1 decisions. But most decisions aren’t like that — they are changeable, reversible — they’re two-way doors. If you’ve made a suboptimal Type 2 decision, you don’t have to live with the consequences for that long. You can reopen the door and go back through. Type 2 decisions can and should be made quickly by high judgment individuals or small groups.
As organizations get larger, there seems to be a tendency to use the heavy-weight Type 1 decision-making process on most decisions, including many Type 2 decisions. The end result of this is slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention.1 We’ll have to figure out how to fight that tendency.
And one-size-fits-all thinking will turn out to be only one of the pitfalls. We’ll work hard to avoid it… and any other large organization maladies we can identify.
[2] From “The Psychology of Science” (’66): “I remember seeing an elaborate and complicated automatic washing machine for automobiles that did a beautiful job of washing them. But it could do only that, and everything else that got into its clutches was treated as if it were an automobile to be washed. I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”
