Vulnerability

If you haven't seen TED Talks, you should check them out. There's a lot of amazing stuff in there. After watching Dr. Brown's TED Talk on vulnerability in June of 2010, it stuck with me. There was clearly something deeply profound about what she was saying, but 20 minutes wasn't enough time to unpack everything she said. After spending some time mulling it, I thought I'd write a summary of what I got out of it.

She talks about how she wanted to better understand human connection – that thing that gives purpose and meaning to our lives. Connection is at the center of the human condition. In her experience, that ability to feel connected is “neurobiologically how we’re wired.” When she asked people about being connected, what she got was stories about being disconnected.

Once she began looking at this need to connect, “Very quickly, absolutely unraveled connection in a way that I didn't understand or had never seen. And it turned out to be shame.” Fundamentally, shame is a fear of disconnection. That whatever is shameful will result in being rejected, or disconnected from others. Shame creates a sense that we are unworthy of connection – “I’m not good enough. . . . I'm not _____ enough. I'm not thin enough, rich enough, beautiful enough, smart enough, promoted enough.”

Following this realization, she looked more deeply into the other side of that coin -- those people that have “a strong sense of love and belonging believe they're worthy of love and belonging.” Fundamentally, she wanted to look into these people that have a deep sense of worthiness. “I took all of the interviews where I saw worthiness, where I saw people living that way, and just looked at those.” She found that the words that echoed throughout those interviews described the concept of being “whole-hearted”. These whole-hearted people had compassion and kindness for themselves, which is required to have compassion and genuine kindness for others. This revealed an authenticity – a willingness to let go of who they thought they should be, and embrace who they were. It turns out that this is a requirement for connection.

In addition to this sense of authenticity, she discovered another fundamental requirement of this sort of connection – vulnerability. Her subjects didn’t discuss vulnerability in terms of comfort or discomfort as she heard in the shame interviews, but as a necessity. They were willing to invest in relationships that had no guarantees – they were willing to take risks in order to connect.

This realization was personally overwhelming for her, and she found that she struggled deeply with vulnerability. She describes this realization as a “breakdown." So she dove into the research once again, trying to understand our struggle with vulnerability. What she found was that vulnerability is a negative emotion. Through this research, she realized that we as a society tend to numb these emotions. She says, “I think there's evidence -- and it's not the only reason this evidence exists, but I think it's a huge cause --we are the most in-debt, obese, addicted and medicated adult cohort in U.S. history. The problem is -- and I learned this from the research -- that you cannot selectively numb emotion.” I found it interesting that she also connected this to what we see today in religion and politics. “Religion has gone from a belief in faith and mystery to certainty. I'm right, you're wrong. Shut up. That's it. Just certain. The more afraid we are, the more vulnerable we are, the more afraid we are. This is what politics looks like today. There's no discourse anymore. There's no conversation. There's just blame. You know how blame is described in the research? A way to discharge pain and discomfort.”

What is the result? How do we put these realizations into practice? I drew two conclusions from her talk. One is that the reward of genuine human connection is worth the risk of being vulnerable. The other, “…which I think is probably the most important, is to believe that we're enough. Because when we work from a place I believe that says, ‘I'm enough,’ then we stop screaming and start listening, we're kinder and gentler to the people around us, and we're kinder and gentler to ourselves." It's worth giving some serious consideration, both personally and professionally.

Automate the Process!

Once upon a time, I managed an IT Infrastructure team. There were a few things that were consistently frustrating for all involved, despite my best efforts. The one that consistently killed both productivity and morale was our change control process. I'm sure any of you that have had to work in an IT environment with a formalized change control process can share your horror stories about how frustrating it can be. This isn’t intended to be a game of one-upmanship, even though I’ve yet to experience worse.

The Problem

For us, it was the single most terrible thing about our jobs. Why? Because it was the antithesis of a good process – completely manual, multiple different document types through multiple channels, each step duplicating data in some way or another. It arbitrarily changed often in response to the whims of the myriad managers involved, forcing us to restart changes already in process. All of these things led to endless frustration, because we had to have this process complete before we were allowed to do our jobs. And it could take months for a change to get through. And you had to answer the same questions over and over. And we had to follow this same process, even if the change was required by directive or regulation. Oh, there was a "fast track" option, but it wasn't much better.

I know, I need some cheese to go with my whine. However, it came to the point where people were threatened with discipline - up to termination - for not following it properly. In every change management meeting I attended, I would be on record saying "we need to automate this process". I repeated this phrase at least once in every meeting until it became a joke. I actually tried to find a company that would make custom Chatty Cathy doll with a recording of me saying "Automate the process!" when you pulled the pull string. I couldn't ever find one that was customizable to that extent. By the time I left the company, that process had been in place for something like six years (and I fought the thing the whole way), and it was still completely manual - and completely frustrating.

I hear you asking "Why didn't you take the reins and automate it then, Mr. Big Shot Manager?”. Believe me, I tried. I had meetings with developers, established a recommended workflow automation product, and even commissioned a fully working demo. It was ready to go. But senior management cited "other priorities", and killed it before it could go live. It never saw the light of day.

What's my point? I learned several things through this experience:

1. It's the process, not the people. If you have otherwise smart people getting confused by one or more of your processes, look at the process first, not the person. This is not exactly new - I've seen it many times in many different disciplines, as far back as the TQM movement in the '90s. Actually, the concept probably came about before that, but that's when I recall first coming across it. The key is that If you have to threaten people with discipline because they're not following your process, it's time to really examine the process. Of course, you'll get folks that ignore the process or can't learn it, but then you've got a different problem to solve.
2. Efficiency. You should be measuring your process to see where the bottlenecks are. Of course, it's easier to measure if you're using a workflow tool, but you still have to make sure you're capturing accurate data. Also remember point 1 – if you’re seeing a bottleneck at a particular point in the process, find out if the process can be improved before yelling at the people associated with it.
3. Communication is critical. And I do mean communication, not just shooting emails at each other. I hate meetings too, but sometimes that’s the best way to get it done. Gather all of the stakeholders in one room and ask the important questions. When possible, be sure to do things like send out an agenda ahead of time so that people aren’t blind-sided. Get to the point and make sure there’s no finger pointing – just find out what’s going on so it can be fixed.
4. Make it mistake-proof. The process needs to make sense and be consistently repeatable. Of course, you need a method for deviating from the process if the situation warrants it – someone needs to have the authority to authorize such a deviation in a reasonable amount of time. There are few things more frustrating than something critical stuck in an arbitrary process. Make sure to carefully document these deviations – it may indicate that a change needs to be made to the process itself.
5. Automate, automate, automate! Where possible (and it makes sense) remove manual actions. Don’t make someone start the process by sending a PDF by email then make them watch a folder for the approval to come in. For some organizations, emails work fine. Others use a system like SharePoint, or a separate tool altogether. Whatever it is, make sure it fits with the existing corporate culture to facilitate adoption.
6. Continuous improvement. It’s important to periodically review the metrics associated with the process (you are collecting metrics, right?). Interview the participants to see if there’s a better way to do things. Write it all down, including the reasons you’re doing things. You want to understand these things so that you can challenge the “we’ve always done it this way” mentality. If your company has a Six Sigma program, it can help to enlist their expertise in formally mapping the process and identify ways to improve it.

Once you’ve gone through all of that, and your process is as good as it can be, make sure you can explain it so someone that’s not familiar with it. In the course of explaining it, they will ask questions to clarify what you’re saying and challenge parts that don’t make sense. It’s a good time to validate that what you’ve put together will actually work in practice.

A Real-life Example

My most recent example is a change control process that wasn't working as well as it could (not the one I referred to above). My customer had a software development project that was at risk, and my job was to identify why and provide recommendations to right the ship. I found that a major contributing factor was their change control process. See, the development team was using agile development methodologies, wherein they would publish a version of the product into production, and the end-users would submit requests to modify the application where it didn't meet their requirements. However, they had a consistent problem – the results of those requests would come out in the next release of the product, but not be exactly correct. Follow-on requests would be submitted to fix that functionality, causing the schedule to slip further and more budget-busting funds to be spent. What I noticed was that there wasn’t a loop in their change process to verify that the requirements had been correctly captured – the requirement would go from the requester to the business analyst to the developer and into the product.

Following my suggestion, they implemented a loop in which their design documents were reviewed and approved by the requester before any code was written. The first one of these we reviewed revealed that the proposed solution had missed the mark due to differing interpretations of a single word in the request.

Conclusion

There are always reasons that a particular process or processes get out of hand. Usually, the people involved are well-meaning, and there are almost always outside forces that affect things. However, I’ve found that applying these practices have helped me make things better. Please feel free to comment if you’ve had similar (or different) experiences.

Communication Lesson Learned

I recently learned a profound lesson in communication. Very early in my career, I was told by my boss that I was a good communicator. I think he was right. And since hearing that, I've worked hard on improving that particular skill. One thing I fairly consistently observed, though, was that would occassionally find myself having difficulty communicating with some people. It happened most often when talking with smart people that have expertise in the same areas I do. I found that each one of us would want to move the conversation along by talking over the other, assuming that we understood what the person was saying without them having to say it. In fact, that ususally started arguments, and resulted in the exact opposite of communication.

What really solidifed this lesson in my mind was a really good example of how not to do it. I recently had an experience in which a co-worker and I routinely had conflict due to mutual failure to communicate. This person consistently failed to listen, even after I told him directly that he wasn't listening. After butting heads a few times and becoming exceedingly annoyed with this person, it occurred to me that I also do this to others and needed to change my own behavior. Through this experience, I've learned to be more aware of this and let the other person finish his or her thought before responding. I also try to paraphrase back to them to make sure I've understood. This has helped considerably with my communication abilities. However, there's a catch.

The catch is that I have to be less concerned about myself and my own position, and more concerned that I'm communicating effectively. There's a very real possiblity that what I was going to say gets lost as the opportunity to say it passes. However, by practicing this, I have found more than once that the other person actually says what I was going to say if I just let him or her finish.

Thinking about this reminds me of a time years ago, when I was part of a consulting team at a customer site. The primary customer point of contact was difficult to work with and didn't listen well. During a particularly contentious meeting, one of the executives sat quietly through the whole thing, and waited until the discussions/arguments wound down. Then, he very quietly summarized the problem at hand, and offered a clear way ahead. I was impressed with both his restraint and insight, and seek to emulate that now.

The downside? I now become more annoyed than I should when I observe that behavior in others.

So what am I really saying? Basically, I've finally internalized Stephen Covey's Habit 5: "Seek First to Understand, Then to Be Understood." It's critical to good communication, and it seems that it's not a natural thing to do for most people. You might say something like "everyone knows that!" Maybe so, but did you know that you can save 15% or more on car insurance with Geico?

Introduction

My plan for this blog is to write about things I know. What do I know? Well, you'll see. My current plan for it is to be generally about being an IT worker and the things that surround that. This is my first blog (well, if you don't count my initial abortive attempt - sysadminlessonslearned.blogspot.com). I hope you enjoy it.