The Practitioner Defense

when I was 12 years old I got a Playstation 2. at some point it stopped working or i was bored so i took it apart.

as I unscrewed the case’s exterior i noticed even more screws, varied in length and thickness, in Phillips and flat-head variety.

to stay organized i grabbed a few sheets of paper and traced each panel’s outline, punching holes (using the screws) into approximate zones on my drawing.

it looked something like this:

layer by layer i drew rectangles and punched holes in additional sheets of note paper. disassembling is the easy part, of course.

when i began reconstruction of my Playstation 2 — after dusting off the interior components with a rag t-shirt — i realized my schematic shortcomings.

does the hard drive face this way up, or that way? do i set the gear ribbon winder thingy above or below the CD tray?

somehow i got it sorted, and within a couple hours the Playstation booted up and worked as expected.

2013

i started ArtSpot with my neighbor and church companion, Lulu.

while in her apartment one night i decided a landing page, with buttons “I’m an Artist” and “I’m a Venue,” must go live at all costs.

we hired a developer, but it was late and i don’t take “sleep” for an answer.

without knowing how to code, run software locally, debug, etc, i methodically modified bits of text in my Sublime editor, then deployed to a Heroku server and waited 90 seconds to see if my guess was correct.

around 30 deploys and a few hours later i launched 2 working HTML signup buttons to production.

2015

as a marketer, working with developers was never my strong suit.

i followed the “shouldn’t this only take a few minutes?” religion and was impatient (at best) with engineering peers.

when it was time to go live with “Import your portfolio” – a feature for our investment portfolio tool Advise, i flew to Thailand and spent a month wrapping my head around JSON data markup, how to parse payloads from an API, etc.

i fell in love with the process, and have been coding (poorly) ever since.

2016

barely 6 months after my sabbatical in Thailand i bought an app with my friend Justin. we doubled the revenue, then wrote about it.

but getting there wasn’t “easy.” our simplified timeline goes like this: negotiated, hired a dev team, did a couple brilliant marketing tactics, and boom, money.

in the accurate version of this story i sold my television and spent most evenings programming, data modeling, wire-framing, and spec writing well after midnight.

2017

to founders, nothing ships fast enough. you wonder why your team isn’t working as many hours, staying up as late, or cancelling weekend plans to fix bugs.

(it’s a disease, of course, and the antidote is simple: equity, skin in the game.)

this brand of impatience prompts some of us to “just do it ourselves,” even if we’re less competent than team members who are sleeping like normal people.

when we closed Conde Nast as a client, i was so determined to deliver on their requests that i significantly modified huge blocks of code that 1000s of other clients depend on.

i also didn’t write a single test to verify non-breaking changes. we soon reverted that deployment, and lost the client.

manager archetypes

i believe there are 2 kinds of managers: the Delegator and the Practitioner.

recently i asked a founder friend, “do you still push code at your company?” “No,” he said, “the best way for me to add value is to make good decisions.”

this blog post is a reflection of my 6 year technology career as a founder, employee, manager, leader, grunt work-er, intern, agency CEO, freelancer, and that brief conversation with my friend.

the Delegator

• mistakes “Systems” for “Automation” (bad)
• loved “48 Laws of Power” book (neutral)
• works less hard than top employees (good, maybe)
• watches Steve Jobs clips on a regular basis (bad)

don’t let these sentiments fool you… there is a place for Delegators in every organization, which i’ll share later in this post.

the Practitioner

• mistakes company health for personal health (bad)
• says things like “if I want it done right, i’ll have to do it myself” (neutral)
• loves stories about 1-man companies (good, maybe)
• works harder than any employee (good, maybe)

who do you want to be?

a few years ago I became a customer of a new home services company.

unsure of a couple details, i called the support line. after answering my questions, I asked the woman her name so I could compliment her in a review.

“Marcela,” she said. the founder and CEO of Alfred was handling all incoming support calls.

now you know why i’ve taken every Fomo support line call since launch.

in Defense of the Practitioner

no surprise here, i am a Practitioner. on a weekly basis you can cash me outside:

• deploying code
• surveying customers
• drafting specs
• handling refunds
• speaking w/ lawyers
• managing 10+ people
• selling on the phone
• debugging API requests
• building spreadsheets
• writing email newsletters

the list doesn’t end, but these capture ~5 departments or JTBD (jobs to be done) at a typical tech company. and i don’t say this to brag, i say it to make a point.

the Practitioner can take her business apart and put it back together again.

which exposes a flaw in my friend’s mantra on good decisions: all leaders must make good decisions.

so the real question is, are Delegators better suited to make good decisions than Practitioners?

the advice paradox

there’s a lot of startup advice swimming around and readers often ask me, “how do you know which advice to follow?”

this assumes some advice is good and other advice is bad, but the truth is: all of it is true.

• “how we did NOTHING and got to 1 million users”
• “why it was worth spending $10mm to get 1 million users”

see what i mean?

for any strategy there’s an equally viable and opposite strategy.

question: should i ship an embarrassing product to stay lean and validate assumptions, or stay stealth, waiting until the perfect moment because our product is ground-breaking and competitors will pounce if we launch prematurely?

answer: choose one!

founders are dealt the same cards, the same questions, and the same answers. to tip scales in our favor, Practitioners and Delegators must look elsewhere: within.

Practitioner says…

there’s no substitute for experience. a Practitioner consults with previous versions of themselves, perhaps as the Mechanic and now as the Body Shop Manager, to make the right move.

Delegator says…

makers get bogged down with the details. a Delegator sees the forest from the trees and can navigate unknown territory not despite lack of direct experience, but because of it. sometimes, ignorance is bliss.

hm…

fortunately we’re not quite back at Square 1 (are Delegators better suited?), we’ve dug deeper still.

our next question: is it easier to generate experience or wisdom?

lucky formula

they say luck is when preparation meets opportunity.

so far we’ve eliminated external advice as a common denominator in Delegator and Practitioner decision-making, since both leaders have equal access to it.

but do they?

suppose decision-making ability stems from a blend of experience and theory.

70% experience, 30% theory

30% experience, 70% theory

additional common denominators emerge:

1. both leaders believe a weighted blend is better (vs 50/50)
2. both leaders depend at least 30% on theory and experience

what’s left is a 20-40 point variation in preference of content (theory, mentors, podcasts, etc) vs memory (hands-on experience, failure).

except we’re missing one thing: speed.

if i gave you a Playstation 2 right now and told you to take it apart + put it back together again, how would you do it?

would you sketch a crude blueprint and organize screws the way i did ~16 years ago? if yes, would it be because you read about my experience, or because you would have adopted that strategy intuitively?

now suppose you did not read about my experience above — would you assemble a Playstation 2 faster or slower than me, if you had to do it right now?

Observer effect

by sharing a potential Playstation 2 teardown strategy at the top of this post, my previous questions are tough to answer objectively (Observer effect says act of measuring something, changes it).

nonetheless i posit you would be less equipped than i would to perform the task, based solely on my prior experience and your lack thereof.

in cases like these, more books, longer walks, and 10-day meditation retreats won’t help you; $100 says you have never taken apart a Playstation 2, and that’s the only data I need to make a probable wager.

it is this argument that i expand here for businesses in general:

leaders make dozens (if not hundreds) of decisions every day. they’re not always right, but speed is a 4th dimension to good decision making that only theorists have the luxury to ignore.

with experience we move swiftly. with theory, we move gracefully.

in startups, speed matters.

putting it all together

if a startup’s goal is to not be a startup as quickly as possible, then speed is a limiting factor.

after the startup phase, however, speed is necessarily less important.

taking apart a $200 Playstation 2 without a plan is one thing, but taking apart your existing product architecture to rebuild critical features, not so much.

in scenarios like this, our Advice Paradox applies in full spirit:

• “move fast and break things” or
• “be careful – everything rides on this moment”

leveraging wisdom from both experience and theory, we know now to take the latter path… be careful.

but this left swerve at a fork in the road was gained by, you guessed it: experience. our battle of leadership styles, then, is not either-or but when.

when you’re starting up, leaders should do: answer phone calls, deploy code band-aids, give customers a $5 refund. when you’re scaling, leaders should delegate.

there is cyclical nuance, however. i’m not making a case against “small teams” vs “large teams” or “small revenue” vs “large revenue.”

in every business there are periods where the most useful thing a leader can do is pick up a pizza (while engineers hack) or play the team’s favorite song on Spotify (when a big client cancels). this is where a Delegator shines.

but there are also moments when soldiers want their captain alongside them in the trenches, dealing with lawyers or volunteering or explaining why a customer’s data was accidentally deleted.

so as you navigate roles of responsibility and influence, consider these leadership archetypes, and rely on experience and theory to make the best decision.

because those who rely on just 1 of the 2 have neither.