have been thinking all week about experience...

I've meet execs who swear "we can't do X because we can't hire engineers like [big tech co]". Are they right?

and others who say ... "all you need is psychological safety and empowerment and ppl will figure it out"

hmm (1/n)
... I'm reminded of an environment that had an extremely strong foundation of quality (and safety, and empowerment). And exp. leaders.

In that env, a new grad would take 2-4y to really start figuring out the product thing. AND...would start contributing quickly.

and.. (2/n)
... another env with very talented/experienced folks all with 10+y experience, being mired in complete insanity. Things falling apart. Bureaucracy. Toxic company politics. It was terrible. Many people left. Some people stayed in a Sisyphean effort to fix the org.

... yet other env where extremely skilled leaders misjudged their experience and its applicability to the current situation. Stubborn. Egotistic. Hubris. They figured they were "the best in the world" bc they had worked at [famous tech co].

it bit them...bad .. (4/n)
... other interesting twist. When leaders keep talking about how their team lacks certain skills, but they themselves lack skills. They've never done it.

Or they did it 20 years ago in a completely different context. "Back with mainframes...".

Or ...(5/n)
...when leaders openly admit they don't have skills, but *also* don't trust others in the org to have the skills ... often because of outside influences (e.g. board, consultants, advisors, books).

They also underestimate the impact of their lack of confidence...

...still others who keep rattling on about "we just need the right leaders in the right roles" but there is no internal advancement, and "right" is always someone external, and "right role" is always a silver bullet org charge decision

So, it is...(7/n)
...*not* as simple as skills and experience. Fundamental attribution error is everywhere... (along with other biases).

We blame "the system" for our problems. But other people's problems are their fault.

It seems that...(8/n)
experience matters...
learning matters...
teaching matters...
being context aware matters...
challenging your biases matters...
humility and self-awareness matters...
"the system" matters...
flexibility and adaptability matters...
leadership (formal & otherwise) matters (end)

• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with John Cutler

John Cutler Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @johncutlefish

20 Dec
How should product managers and designers share certain responsibilities?

wrong answers only.
Pm: I pick the right things. You build them right ...
Pm: oh hey for that work we’ve been talking about that is five months out ... do you mind just whipping up some mocks? Nothing serious. Promise. Will not hold you to them.
Read 8 tweets
19 Dec
I frequently encounter leaders who believe their team(s) aren’t “ready” for taking a more outcome focused approach. They talk of “baby steps” and “learning how to crawl before...”.

Here’s what they are missing
... to learn something, it is important to practice the thing (1/n)
You don’t learn this by running a (or working in a) feature factory, cranking out the stuff sprint by sprint.

You learn by doing a version — albeit probably more controlled/structured — of the thing ... (2/n)
What might that involve?
- direct contact w/customers
- some ability to “sense” outcomes qualitatively/quantitatively
- a feedback loop

Instead of
(Someone else learns) - build - build - build - build - build

Learn - build - build - measure - learn - build - measure (3/n)
Read 7 tweets
15 Dec
a question I ask startup founders that they seem to find helpful ...

"what do you need to be the best in the world at?"

(hyperbole intended)

here's what is fascinating about the replies...(1/n)
Some people will list 5-8 things.

"We need to be awesome at a,b,c,d,e,f,g!"

...w/o an ounce of self awareness that being awesome at one thing is HARD. Two things is REALLY HARD. Three? Nope.

Here's another thing...

Most people haven't "unpacked" the value chain (2/n)
Take something like targeted in-app #UX enhancements ...

you need to be amazing at 1) doing that w/o breaking someone's product, 2) doing it quickly, 3) the targeting, 4) all the requisite data plumbing, 5) clean data, 6) marketing it, 7) best in the world at in-app #ux (3/n)
Read 5 tweets
13 Dec
a big learning the last year is the degree to which your most passionate team members will *expect* leaders/managers to coherently frame strategy

this is where "autonomy" often hits a snag. Leaders assume it means "bottom up" planning. But that isn't it ... (1/n)
Writing up 3 vague bullets on a "vision" slide is easy. Also easy is planning out each and every chunk of work for the year.

Much harder is detailing a strategy that leaves room for creativity and agency ... but is also coherent, backed by evidence, and is opinionated ... (2/n)
Opinionated? Isn't that bad?

I don't think so when it is opinionated at the right level. Passionate problem solvers want to know that their company has a perspective and doesn't want to be everything/anything.

"Um hey, so what are your OKRs" doesn't land. (3/n)
Read 4 tweets
6 Dec
a differentiation that many teams get wrong:

time-based goals
persistent models

let's dig in.

left: time-based goals
right: persistent model

why is this important? ... (1/n)
* PS, school example took about 120 seconds. apologies
quarterly goals like OKRs often cloud the actual underpinning model ... the beliefs ... the assumptions ... the mental model for value creation.

spending time on understanding the persistent model makes time-based goals MUCH easier and gets us out of the factory model (2/n)
Even something is "bad" as this mind map (it took a team 5 minutes) ... can help build a common vocabulary.

with each passing quarter you will focus on parts of the puzzle. and you may revise the model. but even this rough first pass gets us started (3/n)
Read 4 tweets
6 Dec
the problem with distinctions like "discover vs deliver" is that they cloud the real issue.

IMHO...solve what constitutes a team and their decision/mandate scope first, and many of the other problems work themselves out.

Why? (1/n)
...take a team arguing about discovery vs. delivery.

What they *really* are arguing about is the clash of engineering team incentives, product manager incentives, and design team incentives.

....hmm...how do we keep THEM shipping while WE figure out the 'right things' (2/n)
design wants more time to do a good job, PdM is being pestered about how they'll solve the problem (and SHIP), and eng is told SHIP.

they proxy this dogmatic debates about what constitutes discovery and delivery, who does what, and how they can do MORE AT ONCE. So...(3/n)
Read 4 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!