"According to Steven Covey, writer of the bestseller “The seven habits of highly effective people” (1989), a good leader thinks in terms of win-win situations. This makes sense. There are indeed leaders whom we value because they are always able to create such situations.

But turn this around. A good leader has the courage to think in terms of win-lose situations, the courage to face the embarrassment of confronting the losers. You could equally argue that it is actually this that really makes good leadership – rather than the naive belief in win-win situations. To be fair, there is nothing really wrong with Stephen Covey, but many leadership gurus are like quack doctors: what they say is true, but also untrue."

-from MOOC Delftx - Leadership for Engineers (EdX)

It all began (as some of my stories do) during a college lecture in basic electronics. Taking a brief hiatus after a tedious discussion, our professor made an oblique pitch about a book he read by Stephen Covey, entitled “The 7 Habits of Highly Effective People” [of which I believe most senior readers are highly familiar]. He mentioned the 7 habits that were meant to invoke powerful and eye-opening personal change, proactiveness (or proactivity – I am not aware of the correct noun) being the first of them. At the time, I had a shallow impression of the word “proactive”, understanding it as a loftier standard to self-initiative. Years later, I found a used, though not excessively frayed, copy of the book in a sale with a 50% mark off. Thinking twice on my serendipitous find, I decided to go with the purchase. Little did I know that I was about to get more than what I bargained for.

What did it really mean to be proactive?

So, a stronger sense of self-initiative was only part of being proactive. What it really meant fundamentally was having a firm decision on how we respond to environmental stimuli based on the values we uphold. We can take the initiative, but the actions could be directed by inappropriate social projections and deterministic theories. A solution acted upon may end up being a congenial pretension. The inauspicious yet effective solution will constantly elude us due to a delusive social paradigm. Such practice is described by the habit’s antonym – reactive behavior. 

Being proactive requires acting on the problem by focusing on oneself, and not on others, based on a principle-centered vision. Though consequences cannot be avoided in choosing a response, and mistakes are bound to happen due to our imperfect reference, they ameliorate our decision-making skills and help us make better choices in the future.

Walking the talk, how being proactive applies to the engineering profession

Some of the best ways for one to genuinely absorb and digest a lesson is by sharing it with others and actually putting it to practice. When full understanding is achieved, one can form new ideas and develop the concept further.  There are ways being proactive can help in a nontechnical sense, though I find technical application on a chronic problem I have on the test bench (and I believe most do share the same problem) – on noise and measurement stability.

The stimulus in this problem is the presence of noise and external variables that destabilize measurement consistency. At times, their omnipresence can be so discouraging that common preventive measures are neglected. “If only the neighboring building wasn’t filled with industrial machinery.” or “If only we had one of those expensive, state-of-the-art measurement equipment, then my measurements won’t be so noisy.” These are just some excuses that can ramble on one's mind when one couldn’t get their readings into the desired margins. 

But what if I stopped putting the blame on the noise and shifted my focus on what I can do to solve the problem. By complaining to my colleagues, my supervisor, and the janitor, I’m not solving the problem, I’m being part of it. The noise.

What if I debugged my setup, researched application notes and white papers on common noise prevention techniques from various sources (including, of course, ED), checked my setup again and actually troubleshoot the problem using my analytical skills?

Now, I really don't have problems with noise because of my schema and experience.

This is just one example I can think of. Do you have any ideas or thoughts on the matter?