You just drew your pistols and didn't even notice
I used to think a lot about product management, partly because it's one of the many hats an organisation has ended up labelling me with, and partly because it's that intersection of technology, behaviour and capitalism - linking the micro back to the macro and vice versa.
One of the more common skills of a product manager is learning how to say no, notably in a way where you still can have a working relationship with people. I'm not going to cover why saying no is such an important part of product management, because I feel other product people have covered this extremely well, but I do want to talk about why saying no for all software or tech work is so damn hard, and what we could do about that. And this is something that applies everywhere: support, engineering, marketing, etc.
Yet Another Software Call
I'm sat on a call. This could be any call I've had in the past 15 years, you can swap customer and vendor for other entities. The customer was expecting something to have happened on a particular date. It happened, but not quite in the way they were expecting.
There's some initial shock. The vendor contacts escalate their end, they're not 100% sure what has happened. They're hoping for an answer. They get one, but it's not that it's down the back of the sofa, it's that more time is needed.
Only, the vendor repeats: "this was what was agreed on the contract, and we are still delivering to that".
Chaos. Loud voices escalating between two project leads. Various people in silence. Things do soften, but the relationship has altered and it's not good - even if all the requirements get met later!
The issue here is the conversation failed the vibes check - rather than acknowledging that the expectations might have gotten confused, the response is to fall back onto something firm, something trustworthy... the contract. Only the customer was prior to this point, in the vibes space. The trust was high - the contract is a fallback, not the main working expectations.
Trust the Vibes
This "vibes" space, that is a high trust area - the customer trusts you enough to handle ephemeral information, maybe more disclosure than required.
They assume that trust is mutual!
By using the contract to assert something, you were telling them that you withdrew that trust - that you were moving away from the vibes space and towards more formal, defensive communication. Where there is less likely to be a "everyone wins" solution.
So it's more like a spectrum really...
The further you go right on the above grid... the less trust is assumed in the interaction.
Even spoken communication has a spectrum - a multi-national enterprise all-hands is a very different spoken space from a watercooler chat.
And this matters because the more trust erodes, the less likely the money is going to happen, or continue. Customers don't refer, don't renew. People silently stop using your app. For the internal and/or engineering side, people stop naming your team to do things, so other teams get more visibility and then you are quietly shuffled out.
Yep, you were technically correct and won the argument but overall you lost - notably money or something important.
You therefore want to stay in the vibes space for conflict resolution whenever possible - that's your safe space, and theirs.
Most software language is inherently low trust
Why does communication about software make this so much harder?
- We assume written communication by default - written is normally inferred to be lower trust than spoken communication
- Software words exist further down this spectrum, so default to lower trust:
- "As Designed" is a "project plan says X" level of trust
- "Not a bug" is a "contract says X" level of trust
- "Not in roadmap" is a "email says X" level of trust
- Software people like using precise sounding words, often because they are closer to how code works, and higher certainty tends to move you further down the trust scale as it's more certain and less moveable.
So practically, this tends to look like this:
Customer: "I have an issue where I can't... when I...." (spoken, verbal, soft, uncertain, higher trust communication)
Software person: [explanation] "This feature is as designed." (certain, written, fixed, lower trust communication).
You've instantly just drawn your pistols at noon without even realising it - you just wanted to say "let me help you use this" but what you actually said was "you're wrong, this is why".
So by default saying no as software people is stacked against us - all those tech words and jargon fall back on lower trust communication options. Even basic ones known by all like "bug".
What to do instead
What would a framework for higher trust comms look like as software people? It's not as binary as "stop typing so much", although that does go a long way - the term "keyboard warrior" is a thing.
Stay in the spoken/transient lane
Default to transient comms unless you are intentionally needing to escalate. Try to default to transient comms over static, formal comms unless you need to go formal and static. Choose to use formal and more static comms more intentionally as a tool. (Drafting your followup email prior to the meeting is also a great way of clarifying your thoughts too.)
Don't mix your dirty and clean laundry. Be clearer about what level of formality you're at with your recipients and how you would and wouldn't use comms at each level. This is broadly about having a pattern, and sticking to it. Example - don't use a slack channel for confirming project milestones if it's also where you post all the silly gifs with the same people - use an email. Another one is to use cues or phrases to state you're changing formality upfront so there's less "shock".
Actually just say no. Say no verbally, and own it. Don't fall back on passive stuff like "the project says x", or "this strategy says..." or "out of scope". Say "I don't think this is a good idea".
Change what you say
Talk about outcomes to redirect the conversation. This is a common way to reframe a no - because you're increasing the uncertainty of the message, and inviting the other person to participate in what is likely a verbal discussion.
Avoid certain types of software terms - even if well known! Stop using terms like "bug" or "as designed" unless you really really have to. I also throw in "MVP" there, because people seem to use it to mean "I think this is important" these days rather than it's original meaning.
Reframe "this is not possible" into "ask for help". This one is a little difficult to explain, but rather than restating "x feature does not work in this way" you are instead restating the facts and asking the person to help you solve their problem. Listening makes a huge difference.
Show your working
(yes, this again, just applied differently)
Think out loud. This one makes a huge difference, especially if you announce it. This is you actively demonstrating trust by sharing thoughts you may not have shared otherwise. Bonus points if you invite the other person to contribute.
Admit you don't know an answer. You're inviting participation, showing integrity and demonstrating trust again. Some early to mid career people really struggle to do this one.
Software is growing up - let's regulate our emotions
As software takes over everything, (and right now that seems to be lots of articles about AI too), we've finally entered The Real World as software workers. Where the civil engineers, doctors and chefs live. These professions have structure and centuries of institutional knowledge to allow them to move between the vibes space and the formal space fluently - as we join them, we also need to learn to purposefully move between the vibes space and the serious space. This, with other changes, will hopefully shift those awful "pedantic tech worker" stereotypes and move us towards being part of the furniture.
Boring. Like it should be.
