First is a series of "anti-patterns" for initiatives (A,B,C,D), each in its own tweet.
Then a poll about your org.
Then is an open-ended question for reflection.
How you enjoy it!
OK. Here are the initiative anti-patterns:
A: Big batch. 🤯🔥😢🧯
Lots of effort. Large scope. Little experimentation along the way. Promising "big" opportunities. Potentially high impact. But the effort fails spectacularly and visibly (or everyone implicitly knows it failed). May be cloaked by success theater.
B: Middling. 🤷♂️
Not small, not huge. Reasonable opportunity. The effort doesn't "fail", it looks OK/good, but it also isn't a big visible success. The invest was non trivial but not huge. ⏰bells don't ring, and if you squint your eyes you might be able to say "Cool".
C: Perpetual string of "safe" small efforts
...that have reasonable near-term impact, but don't really strike at some of the bigger areas of opportunity. Don't produce new information. Customers say "thanks", but not "woah, THANKS, didn't see that coming but WOW".
D: Repeated small "starts and stops". 💫
Feels directionless. No rhyme or reason. It is hard to figure out the WHY. Iterating to nowhere. There might even be "velocity" but it is going in circles.
So...which anti-pattern (of those listed, you may have others, of course) is most common in your organization?
Finally ... what strategies have you used to counter-act these?
And...are these always "bad" ?
• • •
Missing some Tweet in this thread? You can try to
force a refresh
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).
not sure this anyone would find this interesting...but this is how I go about doing my "loops" diagrams
1. first I use write simple things like this to get connections out of my head. at this point it is very rough...
2. I get a little more detailed/structured. All the while I validate these along the way and try to involve other people (hence my initials here vs. other contributors).
3. I do a lot of these ... it gets a bit out of control. I might end up with with hundreds of hypothesis connections
anti-pattern: using one process/tool to do too many jobs
1/n teams "hire" processes and frameworks to do certain things. the trouble is that we humans get greedy. when someone says "well that does A,B, and C" we get excited. 3 for the price of 1!
The problem? ...
2/n First, it is hard to do lots of things well. The process rarely delivers across all of those jobs. It might do one thing well, but be kind of crappy at the other things...
3/n Second, communicating the Why can be very difficult. Say you have a process that is meant to promote learning/experimentation AND can be used to manage people and promote accountability.