Technical Leadership Coaching & Development

Analog Development is now providing virtual and in-person Leadership Coaching Programs. All programs are customized for the individual. Programs range from approximately 6 weeks to 6 months in duration.

Contact us for more information.

Second Edition Now Available!

The long awaited Second Edition is finally here. Updates and new content are sprinkled throughout the book.

Discounted bulk purchases for colleges and universities are available.

Please Note: The Second Edition is currently only available in print form.

Personality Perils in Software Engineering – Part I

We software people have a multitude of positive personality traits. These include tremendous analytical skills, natural motivation (when we’re working in the proper role), and creativity, to rattle off just a few. However, in this blog post I’m going to discuss some of the pitfalls of our software personality type and how we can adapt accordingly. Of course I do understand that we’re all unique individuals and egregiously applying traits across a large population can be dicey. With that disclaimer behind me, let’s take a brief look at some of our more perilous personality traits.

For starters, many of us tend to communicate in extremes. We either avoid others we need to be working with altogether or we dive too deep far too quickly into all the extraneous technical minutia. My suggestion for software professionals is to adopt what I refer to as the 3 & 1 Model.

Here’s how this model works: start by summarizing the problem or issue with others first. Then provide 3 options for addressing the issue at hand; recommend the one you believe is best; and then justify your selection. It’s the justification process that is key, from a psychological standpoint anyway. This helps you work through all the particulars in your mind and then you’ll truly know whether you’re on target or not.

Another area where we tend to struggle is our approach to conflict. This seems to be yet another domain where we operate in extremes. We may either blow up at our adversary or avoid the situation completely. The term adversary may be the key to resolving this matter. Many software professionals view their co-workers as adversaries rather than teammates. The key here is to build Social Capital within the company. However, this must be done on a regular basis by spending time BEFORE any crisis. This is where our introverted ways may sometimes let us down. While introversion allows us to get in the “zone” and become great problem solvers, our social skills may suffer as a result. Finding a reasonable balance here may pay dividends down the road.

Software people often ask me –How do I build social capital? This is not easily answered as you might imagine. For starters though, I encourage people to spend more time with those people they struggle with, rather than less. Our natural tendency, as analytical people, is to avoid those that cause us trouble. This is typically the worst thing that can be done. Spending time when there is no issue or problem to be resolved can yield big payoffs. We need to build these relationships throughout the organization. More specifically, I suggest making a habit of using Active Constructive (AC) responding styles to build Social Capital.

Constructive responses are essentially positive in nature. Any sort of encouraging remark basically. Active refers to engaging comments that show you understand the context of the conversation and care about the other person. So rather than replying with a “That’s great”, an AC response would be something like – “That’s great. That must have made you feel good. How did you pull that off? What did the project manager have to say?”

There’s more on personality in software engineering coming in Part II…

Need a Speaker for Your Software Conference or Event?

Author John R. Fox has developed two informative and practical presentations, one focused on software development and the other tailored towards the software quality discipline.

These talks are both educational and entertaining. Contact John to schedule your event at

Psychology and Software Engineering

This marks the launch of my blog series on applied psychology as a means to improving software development. The entries over the next several months will somewhat mirror my software book entitled: Digital Work in an Analog World, Improving Software Engineering through Applied Psychology.

I’m not proposing that this is an untapped panacea, as many varied remedies have been undertaken over the decades with either minimal or short term, results. However, the prime reason psychology may well play a supporting role in software best practices is due to two primary factors. This being that software development is both abstract and complex – a daunting combination and because it’s largely a team based global effort today.

Whenever one attempts to conquer an abstract activity, such as designing and creating professional grade software, many dimensions of human thinking and emotion may come into play. When you combine this challenge with team dynamics and then mix in a diverse combination of personalities between the business and the development groups, you have the potential for capricious and possibly undesirable results.

Non-technical aspects of development are often overlooked or underestimated by technical professionals. As scientific and analytical people, we naturally seek out technical solutions to our problems because this is what comes naturally to us. We’d rather not focus on making our teams more effective or consider habits to improve our planning activities. Instead we look for new and improved technologies, shortcuts and other silver bullets that we know down deep are probably not the long-term answer.

Our track record as an industry in fact begs for some answers. When only a third (approximately) of software projects are deemed successful, according to trusted industry observers, we really must consider every opportunity to raise the bar in software engineering. Improving the soft skills of technical professionals is one means of moving the bar. Another is to better understand how to make optimal decisions. When is best for individuals to decide and when are you better off having the group pull the trigger? These are the types of issues (as well as many more) that are discussed throughout the book and that will be touched upon in this blog series.

Applied psychology may have something to offer us here. So I hope you’ll join me in exploring the nontechnical aspects of software engineering to better understand what software best practices may linger therein.