having observed "design advocacy" in many orgs, I've noticed some patterns:
1/n: the very things that get design the "seat at the table" become the limiters for further advocacy. So much effort to create a box ... and then you forever get put in it
2/n: @ryanrumsey talks about this eloquently, but you often see a complete resistance to making a cogent "business case" for why people should care.
Part of this is pride -- which is understandable -- but it becomes "design advocacy" vs. "design as a catalyst for X advocacy"
3/n: Instead of partnering to re-imagine a design-outcomes-friendly flow of product development, the focus is on advocating for how design should "fit in with" or "integrate with" X (whatever the engineering team is doing).
1/n - There is so much you can do IF you accept that you have to do the old thing AND your new idea. People might look confused, but you will not get fired. Here's what I mean...
2/n - Say you work in a feature factory and features get thrown over the wall for you to "deliver". That doesn't stop you listing the various risks with that bet. It doesn't stop you describing the higher level bet/rationale.
3/n - Nothing is stopping you setting up a decision review a couple weeks after the thing has been "delivered", and your team has moved on to the next project. "We expected this ... but this is what happened.." (tip @Amplitude_HQ helps with this)
here's a bit of advice I give to a lot of companies at my day job (@Amplitude_HQ ) re: analytics
Start By Counting Things
Skip magic metrics.
...goal setting and success metrics.
...trying to "justify" a strategy.
..."benchmarks" and what your competitors do.
...focus on counting things that happened that you care about. Stay firmly grounded in the customer domain. Name things sensibly. Add extra context with human understandable properties. Decouple counting from the interface-de-jour.
Start By Counting Things
Why? ... (2/n)
...this is the muscle you need to build.
When you can count things, the rest falls into place ... especially with a product like @Amplitude_HQ which handles the nitty/gritty of making that data useful for you.
too many teams jump straight to a silver bullet (3/n)
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"
... 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.
... 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.