I've shared this verbatim with my team and pointed out how it will affect our work in the coming quarter.

Jon has done a great job ramping up on all things Invoca and focusing on building out the UX discipline and helping push us to be more customer centric.

Jon has balanced time improving processes/personnel within the UX group (for ex: instituting the weekly design critique meeting) and helping create the right conditions for UX to succeed with key stakeholders (primarily PM & ENG leadership). I believe this overall area should continue to be Jon's Q2 focus while begining to take steps to evangelize and show off results of UX output to stakeholders. We discussed a few ideas such as Trios sharing/demoing their work in settings like Invocation, CKO, Company Connect. Jon & team have also started using Lattice to publicly praise good work in Slack.

Other candidates for UX growth discussed: * Building out UX personas/profiles under 'business centers' - to be used both in product development and by the organization to be more customer-centric and raise the visibility of UX. * Building muscles as a trio and working projects in scoped iterations en route to GA vs. larger chunks shipped. * Removing barriers or reliance on PM/others for UX to get more direct interaction with customers; having UX lead respective customer sessions (and bringing insights back to the teams) vs. being in the passenger seat. * Jon & team potentially spending more time learning the product in conjunction with projects and their focus areas in the platform.

I also want to call out the good work Jon has done building trust and goodwill with the 'First Team' in R&D. I hope we can continue to focus on problems and improvement areas collectively (being open to sharing in the leadership Slack channel, etc) and use 1:1 discussions as warranted vs. the way to solve problems.

Pretty good?

• Quarterly coaching is done. I might be the first to complete it among the managers.
• Our pilot recruiting of prospective research participants (recruit them before you need them) has begun.
• I'm hatching a plot to investigate "diving saves" performed by our support team to find and sell revenue-linked usability project to the PM team. In a moment where general experience improvements are met with skepticism, making the effect on the customer of action or inaction really clear is critical. And I have a handful of ideas where to find other such improvement possibilities.
• I'm feeling mostly ready for our leadership on-site next week (I guess it's an on-site when remote people come together at HQ?) having written and received helpful comments on many pages of pre-read material. A deadline helps!

It's common for non-design folks to assume that research and design rigor will slow the overall process down. (I've heard epithets such as "constipate" – unpleasant and rude.) How might the UX team contribute to speed of value delivery?

• Improving our understanding of our customers (and especially of our users) so that we can make better decisions about direction, scope, interactive details, etc. and especially things not to build. The fastest feature is one you don't build.
• Ensuring that every design intervention is a response to a user or customer problem or a benefit that we are sure our customers will value. This is a subset of the above, but deserves special mention because a cool idea is not actually cool unless the person we hope to serve will appreciate the benefit it delivers enough to pay for it.
• Answering business questions through small doses (in pharmacology the minimum effective dose) of research, concept evaluation, and usability testing.
• Helping to manage scope by offering simpler alternatives that users can use to possibly meet seemingly more complicated needs. This is sometimes the opposite of what UX is tempted to do.
• Uncovering opportunities to improve usefulness and usability to improve adoption, retention, and time-to-value, which make the business itself faster and more efficient.
• Delivering detailed designs, business roles, states, labels, etc. at an appropriate level of fidelity and no fancier, incorporating many elements only by reference to the design system.
• Continuously improving the design system so interfaces can be built faster and with greater consistency, and to steadily improve the usability, familiarity, and accessibility of capabilities delivered on the front-end.

And everyone should practice active self-management within the project.

I was fielding complaints about slowness in the UX team's contribution to projects until I started talking to the people I support about this concept. Turns out it is good for anyone who works on a team, anyone who works with others.

When starting on or working on a project, I expect everyone to:

• come to a project with a plan,
• share and negotiate that plan, and
• be conspicuous in fulfilling that plan, by
  • regularly offering work-in-progress for discussion (there's no such thing as "not ready to look at yet"),
  • regularly offering the status of current work,
  • regularly predicting when the current activity will be done,
  • allowing for the renegotiation of the plan, and
  • offering modifications to the plan as project or business conditions change (active renegotiation).

You'll note that the default mode here is active – actively planning, actively sharing, actively predicting, actively responding to change.

Last week was tricky motivation-wise; there's an onsite meeting coming up in two weeks that is very important and I'm nervous about the outcome. That's typically a recipe for procrastination. So

• I got four of five quarterly coaching sessions done (structured procrastination for the win).
• We started a pilot to recruit prospective research participants; if this works we'll have significantly lowered one of our key barriers to user research. And if not, we can pivot and use the work that went into this pilot in other channels rather than having to start over. Planning your experiments in advance is good.
• I got some pre-reads written for the meeting by starting them roughly and sharing prior to their completion. Near as I can tell this is going to produce a better overall result as these docs are already drawing useful comments, and people are aware that they are works-in-progress so there's no expectation that they are perfect expressions of what I think. Share early; it works!