![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
A Difficult Book
So our CEO gave everyone this book called, Difficult Conversations last week and there have been all kinds of jokes about the book going on around the office. No one likes being told what to read or what can help them, I guess.
But everyone got a copy in their mail, and I, wordaholic that I am, started reading it just 'cause it was in front of me.
It was hard to read.
Mostly because the examples they had in the book probably reflected every difficult, argumentative and hard conversation I've had in my life. It was oddly a relief to know that everyone has these kinds of conversations and has them blow up so completely, and also oddly stressful and terrifying, in some ways, to read these things because of all the hooks they had into old conversations that I never felt that good about. The first third of the book was incredibly hard for me to read.
Until I hit the 'know your tendency' bit about some folks tend to blame others and other folks tend to soak up blame. I suddenly tied in the fact that I really, truly soak up blame partially because I believe that if I know that I was at fault then I can do something about it in the future. But I realize, now, that I nearly always go too far in that, especially when I'm talking with someone who really tends to want to blame others. I knew it in vague ways before it was stated so plainly, but now it's pretty damned clear.
It was odd to realize that and realize that a lot of my discomfort in reading this stuff was because I was going back to all those old conversations and thinking, "Damn... I fucked that up..." and at the same time I was also thinking, "Why do *I* have to do all the work all the time?" add to that all the old emotions of "But I can't care so much when I get hurt so badly." With the additional information, it was clear that while I have made mistakes, it isn't up to me to fix them *all* and I can't go back in time and I can do better with the people that really do care to listen to me and that lifted the worst of the reaction. Whew.
I've always thought arguments were pointless, and I've realized in the past that on the most part, whenever I've been in a strenuous argument with anyone all it does is harden each person in their position. I always thought it was just human nature and always felt kind of sick and guilty about fighting, but never really figured out *why*. This book finally gave me the key as to *why*. There are far more important and interesting things to figure out in a conversation with someone than who is 'right' or 'wrong' or 'to blame'... and it was really cool to get a concrete feeling as to why and exactly what those more useful, constructive things are and why there are so many people I really enjoy talking with. Whew.
I also realized why I actually have no problems even talking about sometimes delicate stuff with most people, but there have been three or four people that have made me feel like it was all my fault that we couldn't seem to talk about anything without a fight. While I did do stuff to escalate what was happening, it isn't just me, and it was especially important to me to figure out to really look at the fact that there are many other people that I am comfortable talking with and whom are very, very comfortable talking with me about stuff they never could talk about with anyone else. Balancing the reality of my relationships and interactions against how a few people decide to see me. But now I can see why they decided some of that, too. That was very cool to learn.
So I'd recommend this book to anyone that is terrified of talking to *someone* about something they don't want to hear.
But everyone got a copy in their mail, and I, wordaholic that I am, started reading it just 'cause it was in front of me.
It was hard to read.
Mostly because the examples they had in the book probably reflected every difficult, argumentative and hard conversation I've had in my life. It was oddly a relief to know that everyone has these kinds of conversations and has them blow up so completely, and also oddly stressful and terrifying, in some ways, to read these things because of all the hooks they had into old conversations that I never felt that good about. The first third of the book was incredibly hard for me to read.
Until I hit the 'know your tendency' bit about some folks tend to blame others and other folks tend to soak up blame. I suddenly tied in the fact that I really, truly soak up blame partially because I believe that if I know that I was at fault then I can do something about it in the future. But I realize, now, that I nearly always go too far in that, especially when I'm talking with someone who really tends to want to blame others. I knew it in vague ways before it was stated so plainly, but now it's pretty damned clear.
It was odd to realize that and realize that a lot of my discomfort in reading this stuff was because I was going back to all those old conversations and thinking, "Damn... I fucked that up..." and at the same time I was also thinking, "Why do *I* have to do all the work all the time?" add to that all the old emotions of "But I can't care so much when I get hurt so badly." With the additional information, it was clear that while I have made mistakes, it isn't up to me to fix them *all* and I can't go back in time and I can do better with the people that really do care to listen to me and that lifted the worst of the reaction. Whew.
I've always thought arguments were pointless, and I've realized in the past that on the most part, whenever I've been in a strenuous argument with anyone all it does is harden each person in their position. I always thought it was just human nature and always felt kind of sick and guilty about fighting, but never really figured out *why*. This book finally gave me the key as to *why*. There are far more important and interesting things to figure out in a conversation with someone than who is 'right' or 'wrong' or 'to blame'... and it was really cool to get a concrete feeling as to why and exactly what those more useful, constructive things are and why there are so many people I really enjoy talking with. Whew.
I also realized why I actually have no problems even talking about sometimes delicate stuff with most people, but there have been three or four people that have made me feel like it was all my fault that we couldn't seem to talk about anything without a fight. While I did do stuff to escalate what was happening, it isn't just me, and it was especially important to me to figure out to really look at the fact that there are many other people that I am comfortable talking with and whom are very, very comfortable talking with me about stuff they never could talk about with anyone else. Balancing the reality of my relationships and interactions against how a few people decide to see me. But now I can see why they decided some of that, too. That was very cool to learn.
So I'd recommend this book to anyone that is terrified of talking to *someone* about something they don't want to hear.
no subject
sounds good.
no subject
Reminds me of a book I saw called "The Art of Verbal Self Defense." Also, mostly about winning or not losing arguments. I'll have to check it out.
Picking Fights
no subject
12 years or so ago I was making the transition from being a student employee to full-time staff at Ohio State. My references praised me quite well - but one point always came up: "Jim tends to speak his mind, sometimes pretty tactlessly." Heh. It surprises people these days when I tell them that I'm now much, ah, mellower and tactful than I was then. Needless to say, I've taken various versions of "How To Deal With Difficult People" seminars a couple times during my professional career. But it's been a long time since a refresher - and this book sounds good in that it doesn't put the onus on reader to be a Better Person. Thanks.
Re: Picking Fights
It goes more into the fact that most people that seem to be trying to pick a fight usually have something going on, probably emotionally. And that one way to defuse them and *not* leave 'em twitchy is to try and get to the bottom of why they're trying to pick a fight, acknowledge the emotion *without* agreeing with them and see if simply having the emotion acknowledge defuses the real problem, and then it doesn't leave them to go pick on someone else, too.
I liked the fact that they also point out that there are times when it's just not worth talking with them, especially if they're itching for a fight and you don't see any benefit on either side for having one.
no subject
But then I'm a highly analytical, confrontational, challenge-based personality, just the kind of person management hierarchies need more of but are terrified of, and want to defuse with books like Difficult Conversations.
no subject
And knowing what's important to a user is a nicely slippery slope where there are very, very few actual *facts* (i.e. statistically meaningful studies). Most folks go off gut feel and, as far as I know nearly NO software engineer will admit that we're just going off their gut feel. We just believe we're right and everyone else has to be wrong. Simply realizing that what we have isn't a fact but a feeling for what we *think* is right based on past experience (which may well be completely different than the past experience of whom we're talking to) is, in my opinion a huge win. I'm really tired of our people designing tools off what *THEY* would want when our customer is actually a hardware engineer, not a software engineer, and doesn't and will never think like a software engineer. I'm also really, truly tired of software engineers who believe they have all the answers and repeatedly tell me, "Well, if the stupid user would only do it right..." and never see the irony.
So that's where I'm coming from, and I find that when I start getting into who's right or wrong, we don't get a damned thing done and we're almost always *both* wrong about our initial assumptions or our understanding of what the other person is proposing
no subject
As the rant I put in the last reply is a prime example of...
So, yeah, I understand the leeryness.
Pretty much everyone in my group was highly dubious about this book before reading it. As I said, the only reason I read it was 'cause it was in front of me. But of the three that have 'tried it just to see', so far, they've found it useful as it's pretty concrete it's pretty hard nosed about really digging deep about what axioms everyone is basing their system on.
I guess the question that got me into it was, "Am I really happy with how my conversations about hard stuff to talk about turn out?" "And do I really understand what's going on or am I assuming something incorrectly?" I'd rather be curious and find out what's really going on than certain and blind.
no subject
If I'm designing software for a hospital management system, and insist on the process being about what database we use during the specification phase, I'm wrong. There's no way around that fact and no amount of trying to convey sympathy and understanding will change that fact. If I don't know what's important to a user on a project (and you usually don't until you actually sit down with them and see what it is they want to do, and how), then if I proceed under that false asumption, I'm wrong. If I'm letting my past experiences blind me to present facts, I'm wrong. Conversely, if someone else is doing these things, they're wrong. This isn't really rocket science, honestly. Its simple logic and science.
Its a terrifyingly easy trap to fall into to say "Well, its all just a matter of perspective." But its really not. Its either sensical, or not. Logical, or not. Defensible, or not. Of two things are equally defensible, then one considers efficiency. If axioms differ so far on whether or not something is defensible or not, the only solution is the death of one of the conflictants.
Really, its simple.
no subject
I'm generally curious until I realize my opponant is blind, then disgusted. This happens with such regularity I just started being disgusted all the time to save the effort. It works remarkably well.
no subject
It's cool to know the context of that argument, and that case is very clear cut for you. So knowing your context and knowing exactly what kind of argument you're talking about, yes, it isn't applicable.
In the context of 'should the GUI have a menu item labeled 'Delete Implementation Data' or 'Reset Project Status'. Or 'Should we put in a Source Control System'? It *is* entirely a matter of perspective.
Your conversation and my conversations are different conversations about different things.
Also, from what you originally wrote, it seems that I did misrepresent the book, as it's actually about the fact that 95% of all conversation do end up about being what's wrong or right, and the question simply is, "Is that where you really want it to be?" Sometimes the answer is yes. I just fine that, usually, it isn't nearly as useful as other conversations I could be having.
And in your case, it clearly is yes. But 95% of my conversations aren't about things that are that clear
no subject
no subject
The conversations that I'm afraid of are the relationship and emotional conversations. The 'Mom, we're not making it to your house for Christmas' conversations, the 'why do you do that, it makes me so mad' conversations. That's what I found this book to be really helpful with.
Also, as I get more and more into the murkier depths of being more manager than engineering, everything becomes more about relationships and getting an understanding rather than right and wrong. It's murkier, less clear, far more challanging, now, and far more useful for my engineers to have me clear the path to start. I'm more *useful* talking to a bunch of people and getting real requirements and writing a specification so my guys don't have to hunt around and try to get answers out of people that don't have to talk to them. They have to talk to me, and I find that both useful and sometimes really hard, because I can't just blow them off, as it makes everything that much more difficult for my people.
It's more about long term consequences and doing the job that has to be done. It's interesting knowing that my context has changed that way.
no subject
Interface issues are always fairly clear; you can argue about exact phrasing, but let's be honest: just labeling the thing with what it is solves 95% of those issues. Now, if the question is whether or not you should give the user the ability to do that, well, that's not your call. Ask the client. If they don't know, add the feature and an option to toggle it off, and be done with it. That's not an issue for discussion, its a way for people to dick-off actual working in preference for "discussing soft issues." Ie. be slack.
When it comes down to it, there are only two kinds of meaningful decisions:
Is this true?
and ...
Which is more efficient?
If it can't be boiled down to one of those two, especially in the accomplishment of a task, its wasted time.
You'd never know I do high-end corporate technical support; 99% of my co-workers seem to have bought in to the whole "give them warm fuzzies and ignore the problem" clap-trap. This may be why they get yelled at by clients, and I get respected.
no subject
"Mom, we're not coming to your place this Christmas. I despise my relatives and your cooking sucks. We'll be in South Beach. Email if you need me."
"You realize when you do that it makes me want to gouge your eyes out with a dull fork, right? Why do you persist in life-shortening behaviours? Does this seem efficient to you?"
The more management courses I take, the more I realize why the management in the 80's which took their queues from Sun Tzu and Musashi is far, far more resonant with my own than "modern" TQM and other garbage which seems to examine all the particulars of a thing except actually getting the job done. If you establish premises and expectations up front, and actually have the backbone to stick to them, the rest of the interaction becomes much less murky, much more clear, and as a nice side effect, it becomes clear when you're going out of your way to meet someone in the middle, rather than that being the expectation ... and requiring you to go that much farther to them and placing an unfair burden, just so their perception is properly skewed.
no subject
no subject
We do hardware tools for hardware engineers to design chips. Do hardware engineers need a source control system? Do they need it now? What parts to they need? Can we actually do it better for them than the tools they already have? Do we have the time to include it when we have to trade off twenty other features for it?
Sure, the simple answer, without asking question or questioning ones initial assumptions. Then it's easy. You can say it's true because of what you believe to be the problem. It's more about figuring out what more *is* there than your intial assumption.
no subject
no subject
The axioms I run across are far more like one guy who believes "Software should be complete and should gracefully handle error conditions." versus a guy who really believes that 'Software should be written on time and should be clean and efficient code.'
Which axiom is 'right'? For me they both are, but to varying degrees at different times in the design process. And they come into conflict some of the time, but not all the time. Sometimes the decisions they make are the same. Sometimes they're wildly different because of the emphasis they have. That's when I hear one guy muttering about 'slack bastard' and the other muttering about 'turn a perfectly elegant solution that *works* from one page to twenty of illegible code.' Which is right? It may not matter when the real problem is 'what did will take care of the problems the user sees?'
Again, your 'if' makes for a particular kind of context. If it were in the medical equipment shop I once interviewed at the question of databases would never have come up because they only had one that was tested enough for FDA approval. If it were in another software shop I was working at, the real question would have been 'Process, WHAT process?' At yet another, where engineering was told, point-blank, "you do NOT figure out requirements or specifications you code what we tell you", then implementation is where they always started.
Sure. Given a context, there is usually a more efficient and better way to do anything, plus an answer that can be obviously correct to all involved. Given any group of engineers, we usually find something that satisfies the requirements and is sweet to build, that, for us, is 'right' and true. But to assume that it'll work everywhere leads to the engineer that tries using one technique on every problem they face.
no subject
For me, the question boils down to 'Can you get things done?' And are the things you're doing correct for killing the opposition?
Getting things done requires people who are willing and want to work and nearly all of them want to do the best they can. Without marketing, I can't get information on the target. Without SVG, I can't tell if things really are done. Without upper management support, I have no business direction. Burning personal bridges with every other department is not any way to get anything done.
I like it where it all works together. We've reduced our nearest competitor to less than a third of their old earnings and we're now earning more than all our competition combined. This after we were number two four years ago. We get things done and make more than a billion in revenues a year.
And it doesn't get done by pointing fingers and saying, "You're right. You're wrong." and no one listening to figure out a better solution than the one originally assumed.
no subject
no subject
Now, the only real question here with a question on the scale is "Do we have the time to include it when we have to trade off twenty other features for it?" And that one comes down to examining the position of where the software you're writing is intended by the customer to fit into their work flow. If all the ap is intended to do is edit flow control block diagrams, and said diagrams are kept on disks in a cabinet that have to be fetched and replaced with changes logged to a seperate piece of groupware, then the SCS isn't part of the ap, but it definitely has to be in place. If, on the other hand, the customer wants the ap to replace the whole fetch-the-disk/log-the-changes/replace-the-disk cycle, then the SCS has to be built into the software.
Maybe I'm unique, but I'm aware that processes extend beyond aps into how the ap is used, and if you're not part of the design process for that too, you're pretty much going to be implimenting useless shit (like Compaq's upcoming call-tracking system, Pulse, designed by useless yard-apes and management-munchers who haven't taken a call in their lives). There is no question hardware engineers need an SCS. There might be a question about whether or not its in a given ap or not. Maybe. In general, it'll be pretty bloody obvious from looking at the customer's spec and processes.
no subject
Art, on the other hand, generally involves the phrase, "Do you want fries with that?"
no subject
Now, as for what to do with the two programmers above, is get the first one solving the P=NP problem, and while he's doing that, put a bullet into the back of his head. With that as a warning, teach the other guy to include more frequent error trapping as a second-pass implimentation refactoring, and you'll end up with one trained programmer with the right mix of habits. No one that believes that software can be complete can be allowed to live; its bad for the gene-pool. Mainly because I'd rather manage five programmers who believe that code should be in on time than ten of which five aren't hitting the implimentation deadlines. Retasking two of the five on refactoring for error trapping as the final set of deadlines nears assures that I'll get efficient, clean error-trapping on time and thus is a net win.
(This is why I have so much fun in management courses. Of course, I've been refered to as Torquemada, too.)
no subject
See, you've pointed out two seperate issues, and one is vastly more important than the other. If no one points fingers and says "You're right, you're wrong," then how will they know? Where's the internal challenge to beliefs and the shake-up necessary for the process of improvement to occur? Where's the Reaper's Hand, as it were? Its the second issue that's more often missing, people willing to say, "OK, here's why I believe I'm right, if I'm wrong, OK, where do we go from here?" Its the listening and evolving missing from the loop. If the first, the naming of Right and Wrong is missing, sure, everyone may feel really good about themselves but business doesn't get done because you never get challenged to retarget.
I guarantee, if you dwarf your competition in two years, there's an Alex-equivalent Challenger in the management hierarchy somewhere. He's the guy every one of you thinks is an obstructionist asshole, who asks the really hard questions in the meetings that no one wants to deal with, that pushes for processes to change when they're broken (but comfortable) and to stay the same when the new idea has no backing from below. He's the guy most likely closest to burn-out and who secretly carries around the gut feeling he's totally wasting his life and wishes he could be a happy little "yes man," but can't quite shake the desire to be competent and let go of caring about what happens, for all that he or she attempts disaffected disinterest in the verities.
(No, I have no particular insight here, uh-uh.)
The older and more entrenched a company gets, the more Challengers that a company needs, and the fewer they actually have as they get forced out by those who play nicer with others for less pay-off. At Compaq, you can just imagine what enormous fun a Challenger has ... not. This is the company that announced publically a policy to cut raises and "merit-based promotions" for the next year, and bothered looking surprised when morale dropped. Lack of Chalengers up the management hierarchy to say, "Hey, dumbass, doesn't that seem kind of stupid to you?" and demand a solid answer led to that kind of thinking.
What, no, me bitter?
Re: Picking Fights
With my colours on I can be just as bad as you
Have I had a glass too much ? Did I give a smile too few ?
Did our friends all catch the needle match - did we want them to ?
-- Jethro Tull, "Flying Colours"
The number one thing that gets me to fight is when someone predicts my behavior or decisions based on their prejudices about other opinions or behavior I have. "Well, you don't like Linux, so clearly you won't like source control." Me: "Huh?" Usually, sigh, followed by a lunge for the jugular. I'm not so sure *why* that burns me up, but boy does it.
Funny that it's always been the insecure alpha males that go for the ad hominem. Secure alphas (male and female) know that they just have to point me in the right direction. By all evidence I am threat on toast to the insecure ones.
That's *so* depressing. Perhaps I should be reading this book.
On the other hand, what *has* helped in a room full of shouting matches (inevitable when programmers are designing stuff) has been to say, "What problem are we trying to solve? Okay, who is going to use this thing we build? Do we know what they want and need? Okay, how much time do we have? Let's discard the options we can't do in the time available." Focusing on the problem itself, rather than the opinions, belief, or religion of the participants in the discussion, can cool people off. Though, heh, I never seem to be able to ask those questions if someone's got their finger on MY button.
no subject
I work for people who ask hard questions, who look for the Right Answer. Since they don't make it personal, since it's not about Winning, it works very well. I say this as someone who's been subjected to those hard questions, and who hasn't always been Right.
They have immense respect, and they deserve it. The people who asked hard questions in a nasty way, who avoided the social graces, who pushed buttons instead of keeping it professional? They're gone, and that caused an improvement.
The "touchy-feely goodness" doesn't change the facts. It doesn't mean you back down from the truth. What it does is make the facts a lot more palatable to someone who has a lot of emotional investment in their own opinion, so they work with you instead of against you. It's not a zero sum game.
no subject
Its interesting to examine the vectors by which respect trickles in. I'm respected by my co-workers, who recognize a broad-spectrum technical competence and someone who'll say all the unpopular things and even use me as a conduit for voicing their own concerns of that nature, because they trust me to say, "No, that's entirely too doofy," if it is, or actually push the envelope if its not. Its the guys that have no idea what it is that I do that have the problems with me. And, of course, the entrenched sacks-o-shite who don't like being stirred around with.
Ever get the feeling that 7yrs in tech support have pretty much soured me on ... well, pretty much everything? I so need a new career.
no subject
It's hard to imagine doing 7 years in tech support and *not* being bitter, actually. Unless you're getting lots of opportunities to change and grow, or getting put into harder and harder problem solving, doesn't it start getting to be pretty much all the same? System or network administration is a typical career path out, or development. Heh, development is the least prone to future bitter, from what I've seen....
no subject
Pfeh, change and grow. I can't even get into the number of classes I'm supposed to be getting every year. I take management courses when I can because I find the underlying ideas interesting, many times, if only to highlight why these people are so wrong-headed.
What I'd like to get into is enterprise wide data mining/information management, but ... well, its fairly niche.
no subject
But from the view point of an ideal world where, more often than not, I end up supporting this stuff brilliant programmers write... I like all those things. :)
This is apropos of nothing.