One thing to check out if you are joining a company as an early design hire & expecting to build design culture:
- does the org recognize that this will be extra work on top of delivering outputs?
- does it recognize the value that work and commit to support it?
Commitment to support looks like:
- Budget, tools, and other resources
- Invitation to rebuild processes across the org
Commitment to support does not look like:
- "Sure, if you can submit a proposal proving the ROI"
- "We actually hired an Agile coach to do that already"
Can an IC be a leader and build culture? Yes, absolutely.
Can an IC do this without existing executive buy-in, if they were only hired to produce outputs in support of existing processes? Yes, but it's a miserable slog and you can find a better place in the industry.
If you are a designer joining a place that does not already recognize the value of design (and has material evidence of this, such as designers in leadership roles), expect to constantly defend your own role rather than doing any kind of building.
Engagement metrics: When you don't know why people use your product, but want to make up a metric to measure your PMs on because you read an article about how numbers are objective
Ostensibly customers want to use your product to fill a need, then put it down. But engagement doesn't measure filling of needs. In fact, it measures the opposite - time spent using the tool, with the need going unfilled (what @jmspool calls tool time) articles.uie.com/dividing-user-…
@jmspool Setting a metric to track implicitly or explicitly drives the team to improve the metric. By selecting Engagement as a key metric, you run the risk of telling your teams "we want you to add more things to click, and delay the user reaching their goal for as long as possible."
Often, the gap in the process isn't a lack of user research, but a lack of mechanisms that incorporate user research insights into product decisions. Don't take it for granted that this is something obvious for everyone.
This can be as simple as calling a meeting, putting your list of insights up next to the list of decisions, and asking "in light of this information, do these decisions still hold?"
Which is why it's crucial to have one central place where you can document those decisions.
If your stakeholders can't clearly articulate their decision points for the product or what evidence they used to make the decisions they did, it will be much harder to get them to change their mind through presenting new evidence.
"Empowered" teams are often like "agile" teams or "flat orgs" - the term is used as a feint to stand instead of the capability, rather than to signify it.
They have the same logic: an executive team who wants to mollify the workers, but doesn't want to give up their control (because they are still under the illusion that certainty is possible).
You are empowered to do anything you like, so long as it's what we tell you.
"We are design driven" = the executive team decided what they wanted the designers to do, then did a "design thinking" workshop to make themselves feel good about it