Skip to main content

Everything is a negotiation

I find that most people employed in ICT know what a negotiation is, yet they inevitably fail to see one, even when it's placed right in front of them. I don't know the reasons (maybe our compulsively rational, binary mindset?) and I don't plan to study them.
I will however claim,  rather ambitiously, that if we realize that everything is a negotiation, and deal with it accordingly, we can greatly improve the way we work together, and also be more effective.

Some examples: a colleague reaches out to me and suggests we buy support for the Open Source monitoring product we use, because it's critical to our infrastructure. I say no, briefly arguing my reasons.

We reach out to another team and suggest a change, they decline it.

Are these negotiations? yes! and no!
Yes, well of course they are: as the title says everything is a negotiation. At the same time, the conversation stops short of the discussion with the intent to find a compromise, so it's only just a potential negotiation.

Another example: I ask for a raise, receive an offer for X. Should I take it, leave it, or negotiate? Most of us don't understand this is also a negotiation, much to our detriment. We think we cannot negotiate further, or that it would be perceived as "being difficult". So we often end up accepting the offer, and then complain about that's so much less than what we are worth, and become bitter.

Yet another example: we suggest that we switch to tool X or technology Y, and our suggestion is not considered, or briefly looked at and then dropped. We then go on to complain about how this workplace does not values our ideas, it is not innovating enough, or we will fail as a business if we don't do that. As we were enough business-savvy to understand that (we are not)! My point is that if we actually were business-savvy we would try to understand the reasons for the no, and work with those instead.

So how can we improve our negotiation skills? Here are a few high-level pointers. You'll have to figure out what works for you. There's no 2 days course plus certification for this, I'm afraid.

We are responsible

First off, we must admit that we are responsible for starting or not the negotiation. We must not expect others to do it, lest we accept that our agency exists out of our control.
We enter negotiations with a desire to listen and understand, not to explain and school others. We ask "show me", even when the process seems abundantly clear. We sit down next to them and, if possible, ask that we carry out the work ourselves to better appreciate even the smallest details.

Win-win

We do not enter a negotiation with the goal of defeating our opponent. Instead, we look for common ground and try to come to a compromise where everybody wins.
We remember this is a long-term game we are playing, and we want to keep playing (working) with these people for as long as possible.

Learn to retreat

There are very few (exceptional) cases where we are right, and doing nothing short of what we suggest will cause irreparable harm. We accept this (most of us is not as smart as we would like to think we are), and understand that sometimes withdrawing from a negotiation is the best way to move forward with our plan.
Yes, if we keep insisting and hammer our proposal through, we might end up antagonizing the very people we were looking to work with in the first place. This will do very little to secure the positive outcomes we seek out of our victory, and will certainly not encourage anyone to work with us in the future.
It might work once, but at a great cost.

Instead, if we retreat, we will keep the chance to bring the same proposal up, at a later, perhaps more favourable, time. Again, remember this is a long-term game.

Sometimes we lose

A variant of retreating is accepting that, sometimes, we just straight up lose the negotiation. That is ok. Now it's the time to sit down and understand what went wrong: perhaps it was just not the right time, or we failed to argue our reasons eloquently enough. Whatever happened, remember we are responsible for the outcome, just as much as the other parties.
Wining that our great idea was not understood will not help us. Understanding how we fell short of selling it, will do help us. We engage in constructive self-criticism, not in harmful complain.

Losing, just like failure or an outage, is an opportunity, use it to our advantage. If we learn from it, next time our chances of conducting the negotation successfully will increase. If all we do is complain, we won't even start it.

Optimize globally

In certain occasions we want to suggest an improvement or a change in order to make our job easier. If that ends up helping the whole company or other departments too, it's called a global optimization. If it only helps us or our team, and possibly degrades others, it's a local optimization.
It should be self-evident that global optimizations will be easier to negotiate, provided that you can argument their value adequately (see: you are responsible).

Be effective, not right

We do the right thing, not things right.

Link to a post with more details. Google has plenty of resources on this topic.

Nobody owes us anything (trust is earned)

When we start out in a new organization, initially our trust balance is zero. As we interact with others we either make deposits or withdrawals in the trust bank.
No one else can make those deposits or withdrawals, except for us, through our actions. See, again, we are responsible. The more trust we have in the bank, the more chances we have of getting away with the occasional misdemeanour.

Comments

Popular posts from this blog

Mirth: recover space when mirthdb grows out of control

I was recently asked to recover a mirth instance whose embedded database had grown to fill all available space so this is just a note-to-self kind of post. Btw: the recovery, depending on db size and disk speed, is going to take long. The problem A 1.8 Mirth Connect instance was started, then forgotten (well neglected, actually). The user also forgot to setup pruning so the messages filled the embedded Derby database until it grew to fill all the available space on the disk. The SO is linux. The solution First of all: free some disk space so that the database can be started in embedded mode from the cli. You can also copy the whole mirth install to another server if you cannot free space. Depending on db size you will need a corresponding amount of space: in my case a 5GB db required around 2GB to start, process logs and then store the temp files during shrinking. Then open a shell as the user that mirth runs as (you're not running it as root, are you?) and cd in

From 0 to ZFS replication in 5m with syncoid

The ZFS filesystem has many features that once you try them you can never go back. One of the lesser known is probably the support for replicating a zfs filesystem by sending the changes over the network with zfs send/receive. Technically the filesystem changes don't even need to be sent over a network: you could as well dump them on a removable disk, then receive  from the same removable disk.

How to automatically import a ZFS pool built on top of iSCSI devices with systemd

When using ZFS on top of iSCSI devices one needs to deal with the fact that iSCSI devices usually appear late in the boot process. ZFS on the other hand is loaded early and the iSCSI devices are not present at the time ZFS scans available devices for pools to import. This means that not all ZFS pools might be imported after the system has completed boot, even if the underlying devices are present and functional. A quick and dirty solution would be to run  zpool import <poolname> after boot, either manually or from cron. A better, more elegant solution is instead to hook into systemd events and trigger zpool import as soon as the devices are created.