Following on from “Ask Advice, Not permission” See also “Monkey Management”.

Monkey Management ideas aren’t new (eg see this which quotes it as being from 1975). It’s basically describing the problem of how unsolved problems of employees are pushed upwards causing the “monkey” to jump on a manager’s back. This increases workload for a manager and makes focus difficult. This piece nicely discusses the issue in the view of Product management.

From Monkey Management:

Despite the complexity, monkey ownership continues for Product. It is your circus, but not your job to train monkeys.

Monkey management is effective when there is organizational complexity. It has two critical benefits. The first is time management and the second is creating high agency staff who are able to deal with problems autonomously.

If you understand whose back the monkey is on, you can understand the art of time management and delegation.

A comment from HN

The reason monkey keeps jumping around is because there are ZERO directly responsible owners of the delivery of the cross-functional outcome for the business.

In my company, we have PM, Sr. PM, Director of Product, VP of product - interfacing with Designer, Sr. Designer, Design manager, Sr. Design manager, director of design - interfacing with Eng 2, Sr Eng, Eng manager, Sr Eng manager, Eng director, Sr. Eng director, Eng VP.

Nobody can tell who owns the final decisions, decisions cannot be bubbled up, every management chain is only focused on their own goals. There is no decision-making structure at all. Inevitably projects get delayed or there are unaccounted issues. Then each management chain stack ranks their reports for not achieving goals - never once accepting that the empire structure never made any decisions when it was necessary.

The empire structure has to go. It is dysfunctional, doesn’t work, and only causes grief to everyone involved. Tasks are unnecessarily hard. It is easy to do. Just make your highest paid people directly responsible for outcomes. Give them the freedom to pull people from various org functions to get a project to success.

From Ask for Advice, Not Permission

The problem with permission is that you are implicitly asking someone else to take some responsibility for your decision. You aren’t inviting them to participate in its success — permission is hardly seen as a value adding behavior — but if it goes wrong you might end up involving them in the failure: “Hey, I asked that team and they said it was fine.

and

Advice, on the other hand, is easy. “Hey, I was thinking about doing X, what advice would you give me on that?” In this instance you are showing a lot of respect to the person you are asking but not saddling them with responsibility because the decision is still on you.

Its a great read. Whats interesting though is what happens when it goes wrong. From HN

“…and when someone asks for your permission (probably because you’re in the person’s management chain), one response could be: “you don’t need my permission, if you think it is a good idea after getting input, go for it. If it turns out to be a bad idea, share your learnings so we don’t repeat the same mistake.””

So sometimes.. just sometimes.. a couple of months works pays off. Or I guess we could frame this post around successful product development - keeping the end user the focus of your development and involving them at all stages of your development cycle is key. We are proud to shout loudly about this.

So two months ago we saw Judith. Technology has not been successful for her before. (You can read more why in my previous posts). So we rapidly developed a SwiftUI app that was unique in its operation - you dragged from one letter to the next. Trying it with Judith we still had a problem - positional errors and missing letters were high. So we then rapidly worked on a “correct-a-sentence system” and settled on using a Azure OpenAI API (GPT3.5) and then developed our own custom model alongside this (needing something that worked offline and privacy first was key (NB: The videos is this offline model - Not GPT). A few iterations of this and its correcting as good as GPT 3.5 83% of the time.

So two months later, what does this all mean for the end user? They can now write on technolgy to communicate for the very first time. Happy - well so far yes. But long term AAC use is complex and not just down to the technology. So lets be curious and proud at the same time. There is more to do

• Small tweaks in the UI
• Its correcting a bit too much at times - sometimes adding more grammar changes than I would like - and equally dangerous - losing words. To fix this we could further train our custom model.

and then more I’m sure the next time we review this cycle of the iterative development cycle.

What does this process look like overall?

We follow the double-diamond development cycle. It’s a pretty common approach yet following it is not always easy.

So lessons so far?

• Iterate Fast: Rapid prototyping and adjustments are key to finding viable solutions for complex, unique solutions. There is a much longer tail to development for solid, reliable products but getting somewhere fast helps to see whats important.
• User-Centric Design: Keeping the user at the heart of all stages of development ensures that the technology we develop truly meets their needs. Its not always easy but it can be done. Its important to do this as part of a team though. It can so easily be lost as to whether you are getting carried away or whether you are on track. We pride ourselves on at Ace Centre being a transdisciplinary team where never one person sees the whole picture.
• Continuous Learning: Every challenge presents a learning opportunity, pushing us to constantly improve. And heck - its good fun too seeing big gains.
• Passion and Persistence: A keen interest in making a difference and the drive to keep pushing forward are indispensable.

Many years ago, I worked with my colleague David Porter at Oxford Brookes on a study looking at the effect of supportive seating systems on attention in children with Cerebral Palsy. Although we never managed to get it published, I felt it was a useful piece of work and we must redo it one day. But It takes a ton of work to get work like this published (The short story? Supportive seating looked like it helps children attend to the task (and get better scores in games! ))

So I’m thrilled to see this research looking at the effect of physical exercise on cognitive function in young people with cerebral palsy out there. www.degruyter.com/document/…

Big high fives to everyone involved but particularly Dr Shelly Coe, RNutr, FHEA - it’s a great piece of work. Proud to have worked with the team from Oxford Brookes University MOReS group (& other awesome folk like in particular for my bit like Dominika P. ).

If you’re interested, a version of the flanker test that is in the paper is here: flanker.willwa.de (although my personal favorite game that I’ve done for similar work is snap snap.willwa.de - it’s a bit more fun). Kudos to the team for their hard work in getting this over the line!

Objectified (2009, 75 minutes) is a documentary film about our complex relationship with manufactured objects and, by extension, the people who design them. What can we learn about who we are, and who we want to be, from the objects with which we surround ourselves?

It’s a great film (and free to watch from March 14-17!) but in particular, I love this quote from Dan Formosa, Design & Research, Smart Design, New York (around 6 minutes in)

But really our common interest is in understanding people and what their needs are. So if you start to think, well really, what these guys do as consultants is focus on people, then it’s easy to think about what’s needed design wise in the kitchen, or in the hospital, or in the car.

We have clients coming to us and saying here’s our average customer. For instance, she’s female, she’s 34 years old, she has 2.3 kids.

And we listen politely and say, well that’s great, but we don’t care about that person. What we really need to do to design is look at the extremes, the weakest, or the person with arthritis, or the athlete, or the strongest, or the fastest person. Because if we understand what the extremes are, the middle will take care of itself.

View it online at www.ohyouprettythings.com/free

Finding it interesting reading all the Apple Vision reviews. One snippet I’ve been keen to explore is how they solved the Midas touch problem. Well as most of us working in AT know - the easiest way is to use a secondary accept technique - not just your eye position. They went for a tap instead of dwell by default. Neat. But you can use dwell if you need to. Also note it can be controlled by head position, finger or wrist position instead of eyes. See Apples developer videos on this

From daringfireball

you look at things, and tap your index finger and thumb to “click” or grab the thing you’re looking at. It sounds so simple and obvious, but it’s a breakthrough in interaction design. The Mac gave us “point and click”. The iPhone gave us “tap and slide”. Vision Pro gives us “look and tap”.

worth pointing out this comment too. As great as it is we know fine accuracy is tough without somekind of zoom interface (or dasher!)

@zackkatz Not necessary. Just keyboard. But the trackpad adds significant targeting accuracy. I wouldn't have wanted to edit my review using eye tracking for text selection. I'd still be editing it 12 hours from now.