Communication, Complexity, and Complication

I had a phone interview with a company today for a project management position. I was told it was a "phone screen." I'm glad I did it because I need the experience interviewing for project manager positions. The call turned out to be more of a full interview and an unpleasant one for a number of reasons.

Two questions among the battery of questions the interviewer asked (with no enthusiasm and pretty clearly reading from a standard form) were roughly

1. What are skills of good communicators? 
2. Describe the most complex problem you've solved in one of your jobs and give specific examples of what you did to solve the problem.

Like the subject of narrative in my last post, I can think of hundreds of things to say about good communication skills. It doesn't help that I just read Management 3.0 and my mind is full of new ideas. I could say so much, I'm kind of thrown for a loop when asked such a general question in such a context.

I get thrown by questions like these when they aren't part of a conversation, and  I can have a hard time with tests. In retrospect, I know I should tell stories that sell my abilities when asked these kinds of questions. Looking at the different types of communicators, I'm definitely not a salesman. However, I believe 'Influencing' is among my capabilities nonetheless.

What I was really thinking was the question was asked was, "Why are you asking this question?" Ironically, I need to work on my communication skills when interviewing. What I heard during the conversation was from the very start was, "I don't want to be interviewing you. I personally don't care about any of your answers." In retrospect,  that's what I heard, and I wish I would have reflected back (in a diplomatic fashion) what I heard instead of continue through an increasing painful interview process.

I've heard the second question many times in software engineering interviews. Now I need to be prepared to answer it in project management interviews. I wasn't prepared for this phone interview. Trying to answer it on the fly, I was flummoxed right off the bat because I was wondering what qualified as a "complex problem." This has tripped me up in the past. The word complex is used in a lot of different ways:

1. Complicated: difficult to analyze or understand

This is how I have usually interpreted "complex" in technical interviews, which are usually trying to determine how smart you are. By default, I think of technical smarts as mostly defined by your ability to solve technical problems requiring complicated math, complicated algorithms, or clever hacking skill.

I found a lot of my hard science coursework in engineering school hard to understand. In comparison to engineering school, the majority of the programming I've done hasn't been that hard to analyze or understand with several notable exceptions. In comparison to engineering school and some programming problems, I don't think of the problems I've solved in project management as complicated.

2. Challenging: requiring full use of one's ability or resources

A lot of the work I've done as a project manager and a software engineer has been challenging. I love being challenged and there lots of different types of challenges. In retrospect, I think this is how I should have interpreted the question.

3. Complex: 1. A whole composed of interconnected or interwoven parts; 2. somewhat predictable (but with many surprises) [the second is the definition applicable for describing complex systems]

I don't think complicated algorithms, complicated math used in games, and clever hacking is complex using these definitions. However, the large software systems I've worked on, and in many cases designed, have had a lot of interconnected parts. There was a lot to manage and organize. I think you could argue that that large software systems are also complex, adaptive systems.

Except for the rare trivial problem, managing people and projects is complex using either definition. How do I deal with complexity in project management?  I use the whole set of practices and tools I've been developing over the last several years and I'm continuing to develop. (Which I had described earlier in the phone conversation).

Well, I told the company I was not interested, but it was good practice. I'll be better prepared for the next test. I like storytelling so I'll come up with some good stories to tell when given a wide open opportunity to sell myself. A former studio GM showed me the value of being a good storyteller.