stating something as a personal need -- not an observation of the system, or a theoretical debate -- can go a long way.
"I need data to inform the decision whether to..."
is way more powerful than
"We need more data"
I think this is hard bc (1/n)
...especially if you are the systems thinking type, you might be drawn to the bigger issue at hand ... the thing impacting more people. A cause.
the problem? That is too abstract for most people.
Another example...(2/n)
...saying "My morale is low today because I'm not really sure whether this work is actually having an impact" is way less threatening, and a lot more poignant than "we work in a feature factory"
So I guess the tip is ... don't be afraid to make it personal. (3/end)
• • •
Missing some Tweet in this thread? You can try to
force a refresh
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.
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)
🧵a huge challenge with scaling B2B SaaS is the exploding complexity problem.
through heroics and brute force you can try to contain the problem...until you can't. At which point it consumes everything.
Why does it happen? ... (1/n)
first is the general non-linear nature of the problem
innocently we imagine that adding a new product (or person, segment, etc.), for example, is like going from 10 to 12. Instead, it is like going from 10 to 20.
you quickly overwhelm systems designed for linear things...(2/n)
second, is that the exact efforts to contain the problem at first -- the heroics, the longer hours, the more complex meetings, the project plans, the dependency wrangling -- HIDE THE PROBLEM.
It just gets soaked up into our brains and our processes (3/n)
the distance between those adding complexity to the business and those having to deal with the increased complexity in day-to-day decision making
without healthy feedback loops, you can get a massive increase in complexity before the alarm bells go off
in addition to pure distance (hops between people), you also get some interesting effects.
experienced ppl tend to notice the early signals, bc they are able to juggle the ramifications.
e.g "for *that* persona we'd do this a bit differently..."
...less experienced team members may not notice as quickly. They will artificially reduce added complexity and/or just not do anything with the extra cognitive load.