Engineering People Can Be Tricky

Designing a solution takes time, mental power, and effort.  To engineers and tech people this is obvious when talking about physical reality.  Building a new product or solution you start by analyzing what you are trying to accomplish.  Then you you research and design the new product to meet those specifications.  Finally you convert those designs into a set of processes that build and deliver the needed solution in an efficient manner.

Checking system tolerance

People engineering uses feedforward and feedback to maintain system control and stability.

Scientists, engineers, and tech people are good at this sort of work.  Unfortunately, it is not just THINGS that need to be created.

In fact, I don’t know about you but on the technical projects I work on, problems are about people as much as about things.  Human solutions are generally necessary before engineering solutions will actually work.

Think about the people issues you have to deal with every day.

  • Bosses that never listen to your good ideas, or
  • executives who randomly change the goal or interrupt the project or
  • make promises to customers with deadlines that no one could keep.
  • Subordinates that want to “fix” things without understanding why you’ve done it this way for the past 6 years.  Or
  • bosses who don’t know how to let go, who hover over you or nit-pic constantly so that you don’t have a chance to do your job.  Or on the other hand
  • bosses that you only hear from when things go wrong.

Individual contributing engineers and techies tend to be passive responders.  But leading technical teams means looking around at what needs to be done and taking a proactive action to move the team and the organization forward through solutions to these problems, toward the goals that it doesn’t even know it has yet.  And that means selling those ideas to others.

Do you know how to do people engineering?  Can you elaborate the technical specifications (values) of your top team members?  Do you recognize their process tolerances?  How often do you need to run quality assurance samples on your best colleagues, and the least experienced?

People are not really machines.  But they are systems with consistent patterns of inputs and outputs.  You can learn to engineer people systems, but you have to adopt variation control procedures and feedforward mechanisms.  Otherwise people systems go chaotic.

Making the change from individual technical contributor to team leader starts with upgrading yourself.  Take a hard look at what you do and do not understand about leadership.  Now is the time.  There are skills, behaviors, distinctions, and ways of measuring performance in dealing with people just as there are in engineering and technical individual contributor roles.  Be honest with yourself.  You went to school to get the basic ideas and vocabulary of engineering, science, and technology.  But you have learned your profession on the job.  Self study can take you a long way when you are ready to learn how to lead others.


A Call For Honest Conversation

I would like to hear from you what differences you have noticed between engineering systems and engineering people.  What is similar?  What is different and difficult?

If you want to learn then you are going to have to be honest and admit what works and what doesn’t yet work for you.  Let me hear your thoughts.




Happiness Doesn’t Come From Getting What You Want


Most of you know that I am an expert on motivation and leadership, and the communication skills that leaders use in leading teams and helping gain alignment, commitment, and motivation in team situations.  With this background my friend Russ Taylor asked me to comment on Dan Gilbert’s work and its relation to the NLP idea of “Well Formed Desired Outcomes.”   He asks,

What would you say is the significance of this data for outcome-based change processes, or even on the ultimate value of change as a goal?

And points to Gilbert’s TED talk:



Hey Russ,

Thanks for the note.  Great TED talk.  I have been thinking a lot about happiness and NLP’s concepts of “Well Formed Desired Outcomes” recently in relation to the “well lived life.”  Here is a summary of my thoughts:

First of all, the word “happiness” is a bit confusing because we have only one word for three different underlying concepts.

The first is immediate pleasure, which we call happiness.  For example, “Yum, that is a good ice-cream cone.”

The second is the experience of being fully engaged in a challenging and interesting experience that we feel is meaningful.  As Csikszentmihalyi‘s research shows, we experience these as “flow” states where we get so involved that time seems to fly by and our sense of self seems to merge with the activity we are involved in.  These states are very rewarding, and we think of them as happiness or sometimes bliss, but when we are in them, we are too busy to think about the pleasure we are deriving.

The third experience we call happiness is the pleasure we derive when we look back on some experience or period of our lives and consider how we were living according to our personal values.  This “narrative happiness” describes past experiences in terms of a coherent story.  If we feel we met our values, we feel we were happy.

It is this third type of happiness that is the subject of narrative rewriting, reevaluation, and the “synthesis of happiness” that Dan Gilbert is talking about.

Gilbert and Wilson’s research is important and sheds light on the exaggeration of choice and the illusion that if you get what you want you are going to feel happy.  I don’t think it is surprising anymore that this is not the case.  In fact, setting desired outcomes, like any other expectations, is a surefire way to create suffering.  Think of what the Buddha said.  If you could live totally in the now with acceptance for all that is as it is, then you cease suffering.

This does not mean that all choices are equal, or that freedom of choices is of itself, bad.  Only that if you think that happiness comes from what you get, you are likely to be disappointed.  Some quote I once read seems right to me, “In the end we are about as happy as we set our minds to be.”  (Abraham Lincoln?)

Nevertheless, we are still outcome driven creatures at all levels of experience, from the micro, “I think I will adjust the temperature by opening the window,” to the macro, “I want to be a doctor when I finish school.”  Achieving goals has little to do with happiness, and lots to do with effectiveness, which has something to do with the first two types of happiness but little to do with the third.

The couch potato might not be happy, but that is not because he or she doesn’t produce results, but because when he looks back on his life, he has neither a narrative that satisfies his values, nor the experience of flow states that come when we are fully engaged in an activity that we find interesting.  Doing nothing, and having no goals, however, may lead to the immediate satisfaction when we feel the relief of stress that comes from relaxing, and the immediate pleasure that comes from programmed entertainment, but it doesn’t lead to feelings of long-term fulfillment.

Now if your choices are constrained by circumstances, you may later synthesize happiness by coming to the conclusion that you did what you could with what you had, and in that sense you did your best and lived the best life you could.

But if you perceive that you have choice and don’t make use of it, that is a prescription for regret and lack of happiness.  Though sometimes this regret and happiness is ameliorated by addiction to mind-numbing alternatives like TV or drugs.  Many people have given up hope for any good life.  They try to “get by” with diversions, distractions, and dissociation from life.  But surly this “coping” does not constitute the good life.

On the other hand, setting goals and going after them doesn’t necessarily lead to happiness either.

Perhaps a better approach is to set goals for effectiveness sake, rather than with some expectation that we are somehow going to be happy when we achieve them.  For example, “well-formed desired outcomes” are more useful as communication tools for coming to a shared understanding and a consensual set of agreements between people than they are for generating happiness.

On the other hand, recent research about goal setting has suggested that if you want to be happy AND effective, concentrate your immediate attention on the process rather than the end goal.  (This idea is not new to Buddhists however)   The attitude that comes from taking up the challenge to continually improve your performance at the tasks we are doing leads not only to Flow States (Intermediate happiness) but to long-term happiness based upon narrative review.

When I teach about goals these days, I still teach the Well Formed Desired Outcome Frame questions as a way to build a shared goal between two or more people.  I think it is important, for example, to be able to think in sensory grounded terms about how you will know if you achieve a goal.  And stating goals in the positive so that you are moving toward some target rather than away from some fear is still a useful distinction.  As are ecology and timeframes and all the rest of the well-formed outcome criteria.

But I also teach about the difference between “Ends Goals” and “Means Goals.”  Well-formed Means Goals provide the distinctions for determining whether your performance is improving or not.  When you pay attention and challenge yourself to improve, and when you have a sensory-based measurement that provides feedback about whether you are or are not improving, you are very likely to go into one of those blissful “Flow States.”

By concentrating on the process you are doing and its improvement, rather than the end goal, you find yourself enjoying your task, and you are likely to improve in ways that are meaningful to you and meet your personal values, and so you feel the bliss of being “in the flow.”  Later when you look back on your improvements, you feel that you were meeting your values and so you experience long-term narrative happiness.

Oh, by the way, this is also the path toward excellence of performance and expertise.  Do it for 10,000 hours and you will become one of the more skilled in your field.  But that can’t really be your motivation if you also want to be happy.  But by focusing on the path, the happiness takes care of itself.

That is what I am thinking.  What are you thinking about goals, happiness, and effectiveness?



If you would like to learn more about using Goals to structure success and effectiveness or Mindfulness practices to connect with deep happiness check out my Course Offerings Page or consider the possibility of treating yourself to one-on-one Coaching.


The 5 most common misunderstandings (Part 4)

In a survey of communication problems across 34 Engineering and IT projects the following five categories accounted for practically all of the communication breakdowns and confusions that affected project delivery schedules or costs.   Do any of these sound familiar from your experience?

  • Assurances Problems
  • Meanings of Goals Poorly Defined
  • Hidden Information
  • Micro Management / Under Feedback
  • Why don’t they care like I do?

In the previous post in this series we learned a couple of questions that help you explore and possibly challenge rules and standards that may keep your work from being a productive as it should be.   Of course, there are often good reasons for rules.  And standards are the heart and foundation for great leadership.  But you must understand them with perfect clarity to make sure your team is really doing the right thing for the right reasons.

In this post, we tackle another of the most common leadership problems that people making the transition from individual contributor to leader so often make — over-management and under-management.  It is important to use the right approach at the right time.

The quality of the results your team will produce depends upon the quality of your communication, both your communications with others and your communication within yourself.  If you miscommunicate with others it will obviously create problems.  But if you miscommunicate with yourself these mistakes can be even harder to recognize.

The most common form of miscommunication with yourself occurs when you confuse the “what” of a project with the “how.”

Let me explain.  To accomplish any goal, a team needs to understand both what they are trying to achieve and how to perform the activities that will create those results.  Taking various resources from some “current state” at the beginning of the process to the “desired goal state” at the end of the process constitutes a set of procedures for transforming resources into a finished work-product.

Engineering leaders often assume that it is obvious to their junior team members how to best accomplish this transformation.  But it may not be obvious to the rookie team member.

The opposite assumption is is perhaps even more dangerous.

New leaders commonly make the mistake of assuming that their team members do not know how to create the appropriate transformation in the most efficient manner.  The manager may think, “I know how to do this, it would be easier if I just did the work myself.”  But that would be a mistake because a leader is no longer being paid for his or her individual performance, rather his leadership role calls for him to coordinate other people’s  efforts.  If a manager did all the work herself, she could never accomplish everything her team should be able to accomplish.

But presuming to tell your people how to do their work is insulting, disempowering, and demotivating if they already know how to accomplish those tasks in a way that produces at at least the minimally acceptable level of quality in a reasonable amount of time, with an acceptable level of materials and at an acceptable level of waste.   So managers must walk a fine balance between telling a subordinate too much about how to do their work and not explaining to them in enough detail exactly what will constitute acceptable accomplishment of work-product requirements.

Number 2:  What vs How      

Engineering, Science, and IT project leaders do not always recognize when it is appropriate to define the process, the “how things should be done,” that will move the project from current state to desired state versus when to only define the target work-product or goal, the “what should be done.”

This issue creates communication problems either by the team not getting enough feedback on a regular enough basis, or conversely, by the leader tending to overly micromanage their staff which generates hard feelings that create ego issues that disrupt clean communication across the team.

Recommended Solutions:  Leaders must assess the capability and maturity of their team members by chunking the project into very small sub-tasks that are less critical, and then assigning these with early deadlines to see how well staff can handle them.

This also provides the advantage that team members get to practice working together quickly and repeatedly on pieces that are typically not yet on the critical path.  This is one foundation of the latest iterative development approaches like Scrum and Agile project strategies in software development.   But they are generally applicable to many types of engineering projects.  To use this strategy effectively, you will have to build in ramp-up time to make this happen, which means you must be able to negotiate these time requirements with your customers and management.

The basic strategy is that your most highly capable staff should be facilitated to define and review the target work-product deliverables, the “what,” in detail.  But rookie staff can benefit from defining both the end goal work-product, the “what,” as well as the process by which they will move from current state to desired state, the “how.”

Review cycle timing for work-products should be defined according to the capability maturity of the individual, not based upon a single standard for the whole team.  Otherwise junior staff will never get the feedback that they need to learn how to be their best.  Additionally, mature staff who are over managed will tend to begin to disengage from controlling their own efforts and provide only the minimal production and quality that they can get away with.

The guiding principle is to over manage beginners.  Then as they prove their capability and responsibility to manage themselves, move toward less management control and more autonomy.  It seems obvious, but many new leaders who come to management from technical, science, and engineering often don’t remember to differentiate between the how and the what of work tasks.

Next time, in the final installment of this series, we will look at how miscommunication can lead you to believe that everybody else around you doesn’t care as much as you do.  Why can’t people just be more committed, like you are?  Then wouldn’t everything work a lot better?


Previous In Series  ◄     ►  Next in the Series





Thinking About Thinking About Engineering Leadership

Philosophy seems very abstract, but in Greek it simply means “love of wisdom.”  To be a wise practitioner of engineering or technical professional you have to think pragmatically about what will and will not work well.  To be a wise leader  of Engineers or Scientists you need to think pragmatically about what will or will not work well in leading people.  So learning to think about thinking is one of the keys to being a wise leader of Engineers or Scientists.

That is one thing we will be doing in this Useful Ideas series.

Where to Start When Your Leadership Stumbles

To Get Where You Want to Go, We Always Begin by Recognizing Where You Currently Are


One marketing division of an international pharmaceutical company that I worked with, “off-shored” the development and maintenance of their marketing relationship database to India.  The requirements were shared, but they were not tied to specific test plans.

When the multimillion dollar system was delivered, independent verification from the company’s distributors, who would be the users in the field, indicated that the system “worked as designed” but that the design was not practical or useable in their day-to-day operations.   The project was mothballed without final implementation.

Have you seen a project that turned into a learning opportunity  like this before?

Poor leadership is the most common reason for major business mistakes like this.  There is always a specific individual who is responsible for the Leadership of the team, so even little communication breakdowns point back to poor leadership skills.

Leadership comes down to standards, values, negotiation rituals, goals, and human beings.


Your purpose as a leader is to coordinate the interactions and efforts of a group of people to achieve valuable results that the individual persons who make up that team could not achieve by themselves.

Each individual offers their unique skills.  But to create a synergistic effect that generates valuable results in an efficient manner requires your serious coordination.

You put the goals and standards you negotiate or dictate to your team in place to constrain team behaviors so that results are measurable and therefore manageable.

The rituals you establish with your team will determine your effectiveness as a unit in the larger organization.

The way you treat your people will determine whether your team will find their work meaningful, useful, and fulfilling, so that they will become delightfully engaged and give you more of their best.  Or whether they will obligingly provide only the minimum necessary to get by and reserve their best ideas and effort for after work.


Consider taking five minutes right now to write down what you consider to be your team’s:

  • members
  • values
  • goals
  • standards of practice
  • key processes
  • key measurements

When you put these down on paper (or the computer), you will find that more details will come to you than if you only did this exercise mentally.   These emergent details are the “little devils” that you will want exorcise or negotiate with to resolve the issues you’re facing.

That is why a leader needs to take a step back and clarify his or her thinking on a regular basis.  It is the leader’s job to understand the overall  team scope, boundaries, and interfaces within the larger system that is your parent organization.  But your range of influence is primarily within the details of your teams specific processes and procedures.  As Marshal McLuhan said, Leaders must learn to

think globally, and act locally.”

Let me know what you are thinking in the comments discussion (see the green tag), or to engage me directly, give me a call.

Keith W Fail