Software Engineering Management and Leadership — A Series

Table of Contents

1. The Law of the Lid
2. On Being Nice: Is it a Management Mistake? — A Rejoinder
3. How to Enable Productive Arguments
4. Workplace Bullying — What It Is and What It Does
5. Brandolini’s Law, Emotional Certainties, and Effective Bullshit Detection
6. Strategic Tonality — How Tone of Voice Increase Productivity and Encourage Teamwork
7. Strategic Thinking for Software Engineers
8. What Product, Engineering and Business Need to Understand about Refactoring

The leaders who work most effectively, it seems to me, never say “I”. And that’s not because they have trained themselves not to say “I. They don’t think “I” They think “team”. They understand their job is to make the team function… There is an identification (very often quite unconsciously) with the task and with the group.

Drucker, 1992.¹

Alexander Haslam and his colleagues in their monumental work The New Psychology of Leadership noted that leadership is about getting people to want to do things. They describe its purpose as that which primarily concerns about shaping beliefs, desires, and priorities.²

While self-help books may at times be seen with a raised eyebrow, Haslam’s work deviate from the mainstream by providing an in-depth analysis on certain behavioral and cognitive stimuli which are essential to securing a productive organization. They made an interesting observation over the course of their research which a single blog post is insufficient to address. Nevertheless, over the course of multiple blogs (given that I find time to fit them in), my goal is to summarize the important bits of their work with the hope that these principles help leaders make the best judgment to improve productivity.

One of the main problems of Software Engineering Managers (hence EM) is that the skillset required to be a top tier Software Engineer do not translate to the skills needed by an EM. All too often, the cognitive dissonance happen when the Software Engineer engages human beings as though they are machines. This is not entirely their fault. Often, EMs are “promoted” because they were considered to be a longer tenured employee or that they did extremely well in their role as engineers. It is worth reiterating as well the same point made already by Brian Fitzpatrick, Ben Collins-Sussman, David Loftesness and others that a transition from one role to the other for reason of tenure or productivity in the former role does not translate to success in the latter role. Hence, as an Engineering Manager myself (at the time I wrote this at least), I do not consider this new role as a promotion. If anything, this is a role change, not a hierarchy change.

Gallup’s 2015 research is equally revealing. Their research shows that companies fail to choose the candidate with the right talent for the job 82% of the time.³

This backdrop is critical in helping one see through the smokescreen. That is, it is not uncommon for software engineers to be stifled creatively and productively. Gallup’s research also shows that there is almost zero correlation showing how a good software engineer can become a good manager.

As noted in the figure above, all of these are social skills.⁴ None of our architectural excellence, algorithmic sophistication, nor technical eloquence help much in what is required. This however must be nuanced. He who is excellent in his social skills without the technical background to support his leadership will also impede the team’s potential. However, should one be forced to lack in either, let it be the latter.

One must be cautious however that leadership methodologies vary in effectiveness. Given that leadership is people management, the methodology must change depending on the context. Some readers who elsewhere accessed popular literature might approach this statement with caution. Many poorly nuanced claims over the internet compares both with the intent to malign one.⁵ However, a further analysis shows that it is not possible to lead without managing the followers. John Boehner was quoted as saying that “a leader without followers is simply a man taking a walk.” A leader therefore must be a manager and a good leader must be a good manager.

In this series of blogs, I shall tackle several aspects of software engineering management and leadership. Some of them involves fundamentals: those that serve as axioms regardless of situations and contexts. Others are situational, those that work on some contexts but not others. Still others are mistakes I have made myself.

Learning is a lifelong journey. I certainly appreciate feedbacks and comments should the reader find his time worth.

¹ Drucker, P. F. Managing the non-profit organization: Practices and principles. Oxford: Butterworth-Heinemann. 1992. 14.

² Haslam, S. Alexander., et al. The New Psychology of Leadership: Identity, Influence, and Power. Psychology Press, 2011. Kindle location 229.

³ Gallup. State of the American Manager. Analytics and Advice for Leaders. 10. https://integraladvisors.com/wp-content/uploads/2013/02/State-Of-the-American-Manager.pdf (Accessed August 18, 2018)

⁴ It must be noted that the distinction between hard-skills and soft-skills is a semiotic misidentification. The impression that soft skills must take a back seat in favor of hard skills has been pragmatically debunked. They must be seen as two sides of the same coin where excellence in one compliments the other and should one of them suffer, the other suffers alongside.Hence, I used social skills in place of soft-skills. It must be further noted that as one ages, he inevitably realizes that who he know is more important than what he knows.

⁵ The underlying motivation may vary, but the comparison in any event is invalid.