Synthesizers, not summarizers: Move the game forward, don’t just say something.

By Duncan Anderson. To see all blogs click here.

Reading time: 7 mins


Summary: Synthesizers help improve the overall solution, Summarizers just say something. Help people understand how you are trying to help (ie be a Synthesizer), don’t just say things and have others need to do the work to try to understand how what you are saying could help (ie be a Summarizer). 


Positive sum vs Zero sum conversations

  • I find a key way to help a conversation be positive sum (AKA improve the proposed solution) is to try and act as a synthesizer, not a summarizer. 

  • Levels of input: 

    • L0: Just say something

    • L1: Say something + metatag of it being good / bad

    • L2: Say something and say what you feel the net impact of this is on the overall solution (eg despite this bad area the overall solution is still a net win)

    • L3: Say something, explain how it can be viewed as a win (steelman) and a loss (strawman), explain how you think it actually is (eg actually a win despite the standard orthodoxy being it is a loss) and how we can incorporate this into the overall solution to move things forward. 

    • L4: L3 + multiple options of what to do with a recommendation of which proposal to go with! 

  • Managers do an average of what is asked for, leaders chart a path forwards. 

  • Jingle: Summarizers can't see a path forward, Synthesizers can!


Am I being a Synthesizer, or a Summarizer? 

  • The biggest problem is figuring out what the problem is: If you know to try be a Synthesizer, not a Summarizer, then normally this is more than half the battle won!

  • Sometimes one can’t synthesize, other times one didn’t know to synthesize. 

  • Naming a concept usually makes it far easier to use. The main goal of this blog is to give language to an idea I've tried to understand and use in the past. Being able to ask myself ‘Am I being a Summarizer? Or am I just being a Synthesizer?’ should be able to help me much more be a Synthesizer! 

  • What follows is a non exhaustive list of ways to try a be Synthesizer


++++++++++++


A non exhaustive list of strategies to try be a Synthesizer, not a Summarizer. 


Example 1: Put forward pieces, not pictures (partially related blog)

  • What not to do (what a Summarizer does): put forward a summary of the points you have heard from user testings. Eg I’ve heard that there is a lot going on on this slide 5x times. 

  • What to do (what a Synthesizer does): Ask the users if you removed parts of what is on the slide would it make the overall outcome better (ie how to update the picture)? What you can often find is that while a users first impression might be that there is a lot going on they don’t want to remove anything. 

  • Possible outcome: 

    • Summarizer = Remove things from the slide

    • Synthesizer = Keep everything on the slide


Example 2: Put forward a piece and not say how it affects the picture

  • What not to do (what a Summarizer does): Put forward a negative point about a solution without calibrating whether you think overall this negative point means the solution should not be continued with. 

  • What to do (what a Synthesizer does): Almost all solutions have some good and some bad. I often talk about a solution being made up of the following possible parts - dealmaker, nice to have, indifferent, dislike and dealbreaker. Often people will put forward something they ‘dislike’ but then not provide any context as to if this means the overall solution is broken or not. EG the solution also has ‘nice to haves’ and a ‘dealmaker’, so despite the ‘dislike’ we should go ahead with the proposal. I want to know if:

    • 1. The thing you dislike can be ameliorated, or 

    • 2. If yes, the point raised is not great, but overall the solution is still something people will use. IE the net outcome is the proposal is moving the game forward. 

  • Possible outcome:

    • Summarizer = This whole solution is bad

    • Synthesizer = Part of this solution is bad but overall it’s better than no solution


Example 3: Put forward only one option, not a minimum of 2+ options

  • In financial markets, they say ‘bears sound like they are trying to protect you, and bulls sound like they are trying to sell you something’. 

    • Bear view = What is the negative outcome

    • Bull view = What is the positive outcome

  • People often have a built in ‘default’ way of leaning: net negative or net positive. 

  • What not to do (what a Summarizer does): Put forward only one view / option. 

  • What to do (what a Synthesizer does): Put forward 2+ options. Eg explain the 75% positive view (steelman) and the 25% positive view (strawman). Then explain what you think. 

  • Outcome

    • Summarizer = Trying to find why something might not work

    • Synthesizer = Trying to see the full spectrum of views and then calibrating what you feel is the best outcome. 


Example 4: Following conversation rallies through to conclusions

What not to do (what a Summarizer does): Summarizers do the ‘bad’ side, they are not trying to see the bigger meta picture and segway / tangent all over the place ending conversations without coming to conclusions on points (aka synthesizing). 

  • What to do (what a Synthesizer does): The ‘good’ side. 

  • Outcome

    • Summarizer = Conversations where many things are discussed but minimal conclusions are reached. 

    • Synthesizer = Conversations where many things are discussed AND conclusions are reached (synthesis occurs). 


Example 5: Don’t metatag their point before saying it

  • What not to do (what a Summarizer does): I think this point is problematic. 

  • What to do (what a Synthesizer does): Ok, I think this one (point) sub component of the overall solution is problematic, but I’m not sure how it might affect the overall proposal. Can we talk this sub component through and try to figure out how we think it might affect things?

  • Comment

    • Often if putting forward a negative point others can assume you think the overall solution is bad but instead you are just putting forward something new for consideration and want to try to develop the solution set. 


Example 6: Explain the tradeoff

  • Most things involve a tradeoff. They are not 100% win, 0% loss. 

  • As an example we can go at the new high water mark for quality of questions… but this could make the content harder to make, so it could well lower the floor of quality we make as well. Is this tradeoff worth it? 

  • Or, we could go at the new high water mark for quality but this could make something twice as long to create, this means that instead of making a product to help one year we could make a product to help two years at the same time. 

  • A key question to ask to be a Synthesizer (not a Summarizer) is ‘what is the tradeoff here?’ There is almost always a tradeoff, just because you might not be able to articulate it doesn’t mean there isn’t a tradeoff. 

  • What a Summarizer does: Does not ask themselves if there is a tradeoff for the proposal. 

  • What a Synthesizer does: Does not ask themselves if there is a tradeoff for the proposal. 


Example 7: Diagnose before you prescribe 

  • What not to do (what a Summarizer does): Start putting forward solutions before you have a sufficient+ understanding of the problem space. 

  • What to do (what a Synthesizer does): First build a sufficient understanding of the problem space (ideally a 100% problem space coverage framework) and then start putting forward solutions. 



If you only take away one thing: 

  • I don’t think it’s possible to be a synthesizer 100% of the time, but it’s possible to try to be :). 

  • Almost all people are trying to help. I find that most people don’t know they are being a ‘summarizer, not a synthesizer’. 

  • Two key questions: 

    • 1. Am I being a Synthesizer, not a Summarizer? 

    • 2. Am I using some known strategies to be a Synthesizer, not a Summarizer?

  • Often it’s as simple as this!