Brainstorm questions not ideas
muledesign.com
muledesign.com
I tend to say: "You cannot afford to go fast if you are in a hurry, because this is where stuff goes wrong. And if you are in a hurry you cannot afford stuff going wrong."
If you are a manager and you want your people to deliver the most innovative, creative, best solution you have to lift stress of them and that also means freeing them of their daily duties and giving them the space to think openly about solutions. If your shop will collapse when you relive the best people of their daily duties for a week that means you shop is badly managed.
"Vísteme despacio, que tengo prisa". (dress me slowly, because I am in a hurry)
I mean, you can create a better product by taking more time, and the whole company still dies because you're too late. This is where the stress comes from; managers only translate it.
The company dies anyway, so that argument is moot.
The solution lies somewhere else. For instance, actually taking the pressure off with resources - e.g. the manager can get their status reports by actually understanding the project by short one-on-one interviews and attending design meetings. Instead of asking everyone to come to a staff meeting, or send their status reports and jamming them into one aggregated email and forwarding that as their own work and pretending they did something.
One powerful idea for software development is "integration and promotion" - integrating code from different commits / workers and putting them into one package and testing it and only then moving it forward.
you can take this principle into everything - got a marketing launch? Set up in the room downstairs and run your timings,
Basically "plans" that do not involve early surfacing and use of the product (and just hoping you are a good enough manager to tell everyone what to do) is doomed.
we only do well things we do often
They were likely an IC at some point and now have to answer to higher up power who are under more acute PnL stress hence the pressure flows down to them.
The trick with manager is to release some of that pressure as it goes down to their directs, this might mean taking it head on directly and shielding directs from it or just re-directing it back up the chain.
Right up there with the fake pressure to add a sense of importance.
That is not the point.
Typical organizations very often have both at the same time, but in different places. (Bad) managment sometimes has a hard time telling the two apart, but in my experience they are more afraid of allocating too many resources ("wasting resources") than of allocating too little, because the cost of allocating too much is obvious to their superiors, while the costs of allocating too little is much more hidden, delayed and harder to correlate.
If that really good employee quits after three years of resource-starvation, the causal connection to mismanagment might not be drawn, the manager might even be applauded how well they managed the resources. The friction that comes with replacing that person, however, is real.
There are organizations that burn through employees like it is nothing, and they think that amount of turnover and the waste of resources and time that it brings is normal.
I argued against that.
1. What problem are you using pressure to sweep under the rug? I.e. why are your colleagues disengaged by default? Most people happily do things they find important. Have you hired the wrong people who don't share your values or are you asking unimportant things of them?
2. When you say people work well under a little pressure, do you mean they produce more... things during a given time interval, or that the long-term quality of their work actually improves?
If so, they seem to live in a bubble and are not integrated enough into the rest of the business. Developers need to understand and be involved in financial, customer, and product concerns.
More likely in my experience they are very busy working off technical debt that would be under-prioritised by the manager creating pressure. Some of them may even be innovating new solutions that will open up entire new markets. Sure, not all innovations are successful, but it's enough if a small fraction is.
R&D ("chasing butterflies") is a comparatively very cheap way to acquire knowledge, and what puts you ahead of your competition is the knowledge you have acquired and they have not (yet).
In my experience that's the problem 99.9% of the time. Developers didn't get into their career to care about business, most of them are more excited about reading a new features on kubernetes than they are about solving a real business problem.
In big enough companies there's a lot of silo that is hard to break too. And specialization, someone who has 20 years of experience in $domain-specific-knowledge hardly wants to take a broader view of the world.
> More likely in my experience they are very busy working off technical debt that would be under-prioritised by the manager creating pressure. Some of them may even be innovating new solutions that will open up entire new markets. Sure, not all innovations are successful, but it's enough if a small fraction is.
Then they should communicate better. Your distinction of R&D or not is not relevant.
There are two ways to resolve this. One is for the engineers to learn to accept "wrong-ness" through therapeutic techniques. The other is to remove the external pressure somehow.
Either way, there is pressure that needs to be relieved.
When people refuse to release it's usually because they are afraid of something that comes with it. And yeah, in a "some pressure is necessary" environment, it's a safe bet that it's realizing their technical debit and not being allowed to fix it.
Surely, making them more afraid of tinkering than of releasing does solve that one immediate problem.
Really? What about Tinkering with new tools ? The whole Kubernetes adoption came from a marketing driven campaigns/FOMO.
And your point on releasing is fair too. It's incredible how people are afraid of releasing software and would literally do anything else instead.
Almost nothing is important. The vast vast majority of people work for the paycheck. If you only hire people who truly think that what you're doing is important, you'll have a hard time finding anyone.
So whose power is it, then? There are two ways to tackle this issue: Apply pressure to the ones below you, or buckle up and take a step upwards. One is easier then the other.
Good, 10x people don’t need pressure to perform. They are self-driven. Unfortunately, most places don’t optimize for the right people on the bus, only someone that can do what they are told. A team or organization populated with self-driven people with good judgement is a force to be reckoned with. A team without these types of people needs to be managed.
How do you find 10x people? Optimize for attitude, not skill set or intelligence.
if in a hurry, move slowly
What I argue for is that during normal, daily, non-emergency work hours your employees should not run at or over capacity but with a headroom. And if you want them to solve a long-standing, complex problem and you want them to solve it well, you have to give them the resources (e.g. time, mindspace) to do just that. Sometimes this just means: "Steve, on Fridays you don't have to answer any emails and phone calls, or do any other thing, just focus on finding a good solution to $PROBLEM").
In my experience that yields better solutions and doesn't take much longer (quite often the opposite).
Sometimes the question leads to the first solution that came to mind, but the technique is at its most valuable when it does not. Maybe the checkout page load time isn't as bad as the dark patterns and getting rid of them improves user flow more at a lower cost than rewriting a critical component.
They do not implement that for everything, though. My last order done with a mobile browser, I could not checkout my order, without also choosing amazon prime. I had to activate "desktop mode" that it let me proceed. And I am pretty sure that is intentional to nag more users into prime.
- as a group, explore the problem space (ask more and more questions, diverge your thinking, embrace the waffle)
- as a group, pick something to focus on (converge)
- individually sketch out a solution or two (diverge again)
- individually, asses each others' sketches, identifying what you like and dislike
- synthesise a solution from all the sketches (we did it by voting on the detail points in the previous step; converge)
- storyboard, as a group, with people taking it in turns to drive
- build
- test on users (diverge)
- review (converge)
The coach told us this was mainly derived from Jake Knapp's "Sprint" book.
So when is it ok to brainstorm ideas first and not questions?
Emergency situations may call for rapid execution of any idea. A drowning child doesn't evoke a need for us to ask why we think it should be us that saves the child or what does it really mean to drown anyway? Probably ok to just throw out an idea and spring to action.
Most of the time; however, no one is drowning.
It’s all about the art of asking questions in order to solve problems.
A good question can lead to a better feature.
on edit: typo correction
If your UX guy was anything like 90% of the ones I've dealt with, the answer to those questions would all boil down to "don't know, don't care, I'm focusing exclusively on this cool idea I came up with yesterday".
It appears I've been slightly "triggered", my apologies!
One that comes up off the top of my head is the electronic trial master file in FDA submissions.
Because it has a standard structure, users can navigate it faster through the structured navigation than through a freeform search.
I think other contexts this might hold true are when the content is browse oriented (how often do you use search on HN or reddit?) or it's a mobile context where a structured nav would allow less tapping than typing a search query.
Of course, that all probably happened because somebody involved didn't want your product to have search. Process can not solve political problems.
"Genius is one percent inspiration and ninety-nine percent perspiration."
The flip side of the coin is practitioners who are too focused on what’s immediately in front of them to the exclusion of creativity.