Leadership in a Complex Environment

I recently gave a short lecture on the challenges of managing in a complex environment.  To be successful, there are four fundamental building blocks that must be established early on across the organization.  You have to build the right culture; everyone on the team needs to understand that there are certain expectations that go along with being a member of the team.  You have to execute with precision; everyone has to be willing and able to perform their tasks (so motivation and preparation matter).  There has to be accountability; this is the follow up to setting expectations.  And there has to be thoughtful, meaningful, and respectful dialogue at all levels.

Complexity is a kind of filter.  It makes it harder to be successful.  It demands the very best you can deliver 100% of the time.  Leading in a complex environment begins with the basic framework I have described.

Managing Complexity
Leading in a Complex Environment

Graduate Study and Professional Development

Here are a few words I offered to my graduate students this morning.  I thought I’d post them here as well.

A major part of what we are doing within this program is related to “professional development.” As graduate students, you already have technical backgrounds and have demonstrated the ability to learn important concepts and methods and apply them. The goal now is to work together to help each of you find ways to leverage and amplify your abilities so that you stand out as leaders. To be successful in that way, you want to develop your professional presence – your ability to communicate, your ability to express complex ideas, your ability to select a framework or construct a narrative that helps your team or organization move forward in the face of tough challenges. You then become a difference maker.

A Focus on Consulting Skills

I began IEM 630 (Systems Engineering) this term with a strong initial focus on basic consulting skills.  It’s a useful way to help my students develop a mindset that they are not just “learners,” they are problem solvers and problem owners.  In a sense, it personalizes the subsequent course content.  It makes the material “about them.”  Or so I hope.

As I told them on the first day of class, the point of all this is to give them the knowledge and confidence to take ownership of any technical project at any stage of its life-cycle and manage it effectively.

It also moves our overall focus a little more toward systems engineering management – which is exactly where I want us to be.

Building Teams of People (and Machines?)

The way I build a human team depends upon the purpose of the team.

Sometimes I need a team with skills nearly-identical to my own.  Sometimes I need a team with widely varying skills.  Sometimes I need a little bit of both – I need subject matter experts with deep knowledge in a specific area who also have other skills and insights acquired through different professional experiences.

Sometimes I like to include a totally new perspective – perhaps a new hire or trainee or novice or someone from an entirely unrelated discipline because they may see things in a way that the rest of us can’t see or ask a question that the rest of us wouldn’t ask.

Would I do the same things if I were building teams of people plus machines?  For example, would I select multiple machine-learning systems that were written by different programming teams and that implement differing algorithms in order to gain diverse machine insights?

Impromptu Planning in 7 Steps

Have you ever had a general discussion unexpectedly turn into an impromptu planning session?  I’m talking about situations where you’re sharing some ideas on a project or a plan and someone asks you to go to the board and write out the major points.

It’s always easier to do something like that if you already have a framework, a “mental structure,” in mind.  I’ll describe the simple approach I use.

When I first gave this some thought, many years ago, the obvious structure for me to use was a simple one with three categories: hardware, software, and networking.

That basically handled the technical side of things for me – which was my objective at the time.

Over the years, I learned that, practically speaking,  much of the complexity and risk involved in a technical project is introduced by the “people” side of the project.  To factor that in, I included three more categories: people, paperwork, and processes.  (My 3 P’s.)

One last category was needed: other.  You always need a catch all category for things that do not fit within the first six.

  1. Hardware
  2. Software
  3. Networking
  4. People
  5. Paperwork
  6. Processes
  7. Other

When I engage in impromptu planning, I write these seven categories on the board.  This can help broaden the discussion beyond just the technical aspects of the plan and reveal concerns, constraints, and risk factors that might otherwise be left unsaid.