For an industry that prides itself on its analytical ability and abstract mental processing, we often don't do a great job applying that mental skill to the most important element of the programmer's tool chest - that is, ourselves.

In the last piece, I wrote about Peter Drucker of “Effective Executive” fame. To him, there was no higher calling, nor no greater praise, than for an executive to be considered effective: “To be effective is the job of the executive. “To effect” and “to execute” are, after all, near-synonyms. The executive is, first of all, expected to get the right things done.” (The Effective Executive, page 1) (In fact, Drucker's favorite phrase was usually a play on the idea of not only “doing the right things,” but also "doing the things right.")

Drucker clearly understood that despite the number of executives that were out in the world, not all were effective: “[M]en of high effectiveness are conspicuous by their absence in executive jobs” (page 1). Numerous executives are intelligent, creative, and/or imaginative, but any of these qualities, even all of them combined, don't make one effective. “Intelligence, imagination, and knowledge are essential resources, but only effectiveness converts them into results. By themselves, they only set limits to what can be attained.” In his time as a consultant to some of the largest corporations in the world, he spent a fair amount of time studying executives and seeking to understand what made them effective, and concluded (happily) that it wasn't some innate or inborn genetic component, that men of all sizes, stripes, and backgrounds could be effective - or ineffective - regardless of their background, temperament, or skillset.

(It should be noted, by the way, that by 2019 standards, Drucker's book is highly gender-specific; all of his references to executives use male pronouns. In the interests of accuracy, I have chosen to keep his specificity, but bear in mind that absolutely nothing here is specific to the male half of the species. Drucker's later works make the shift to be more inclusive, indicating that he came to understand this as well.)

Who Is the Executive?

Drucker was pretty adamant that the terms “executive” and “management” were not synonymous; in fact, he made it clear that the notion of “executive” had more to do with what one did, rather than which point on the organization chart one occupied. "Every knowledge worker in modern organization is an �executive' if, by virtue of his position or knowledge, he is responsible for a contribution that materially affects the capacity of the organization to perform and obtain results" (page 5). It doesn't take much to realize that this describes the software developer quite well - once fingers hit keyboard, we're responsible for making a number of decisions about the organization and implementation of code, particularly as responsibilities escalate along with the promotion from junior to developer to senior to architect.

Drucker noticed this shift toward “knowledge workers” as the norm, 50 years prior to our current day (2019 as I write this): "[M]any non-managers are also becoming executives in modern society. For the knowledge organization...needs both �managers' and �individual professional contributors' in positions of decision-making, and authority" (page 6). When Drucker first published “The Effective Executive” in the mid-1960s, the US - and much of the Western world - was beginning its transition from an Industrial Age to an Information Age, a transformation that has really only began to make its presence felt in the last decade or so. If the “Information Superhighway” was recognized in the 90s, then in the 2010s, it's finally reached peak speeds and reach. Much of this transition, then, means that we're shifting from traditional roles of managers making decisions and ICs (the popular modern acronym for “individual contributor”) carrying out those orders, to ICs making and being responsible for decision-making and managers, well, managing.

Drucker also makes it quite clear that not everybody who manages is an executive: “Many people… are superiors of other people - and often of fairly large numbers of other people - and still do not seriously affect the ability of the organization to perform. ... [T]hey have neither the responsibility for, nor authority over, the direction, the content, and the quality of the work or the methods of its performance” (page 6). Many developers have experienced these kinds of managers, people whose sole responsibility, it seems, is to consume oxygen and produce paper and process. They are the modern-day timecard-gatherers, who simply shuttle data upstairs and pass reports downward. They either cannot, or choose not to, make decisions, instead deferring upward or downward as seems appropriate. Such individuals rate no concern in Drucker's book. (Literally; aside from the reference in Chapter 1, they're never brought up again.)

If you make decisions, you're an executive in Drucker's worldview. And if you're going to be an executive, then you need to be effective.

What Prevents Effectiveness?

Drucker identifies four “realities” that prevent the executive from effectiveness:

“The executive's time tends to belong to everybody else….Everybody can move in on his time, and everybody does.” This describes the software developer's day far more than we'd like to admit - despite every study that makes it clear that developers need to have uninterrupted time to “get into the flow,” meetings rule the day.

"Executives are forced to keep on �operating' unless they take positive action [otherwise]." By “operating” here, Drucker refers to the idea that they will keep doing what they used to do before taking the executive role. Software developers thrust into a team-lead role fall into this trap regularly and relentlessly: coding is an exercise they know well, so they keep doing it, even when their time is better spent doing activities that will yield broader results. The issue here is that the executive is allowing the flow of events - the day-to-day issues that arise - to dominate thinking. In software developer terms, this can sometimes take on the guise of “yak shaving”: a series of dependency steps that seemingly stretch on forever before any work can be accomplished.

“[H]e is within an organization. This means that he is effective only if and when other people make use of what he contributes.” When we collectively form an organization, we each have to make use of what others around us produce; “organization is a means of multiplying the strength of an individual.” You can be the smartest C# developer in the world, but if others can't make use of that skill, it's all but useless in a larger scope.

“[T]he executive is within an organization.” Meaning, the organization serves as a boundary and buffer and isolation chamber from the outside. Anyone who's ever worked inside a large corporation knows this feeling intimately after a while: You have no idea what it looks like on the outside, much less from the outside. Users are a vague, distant, hazy concept that are collectively either idiots or simply wrong. But, Drucker insists, the results we achieve inside the organization have no intrinsic worth - the results that matter are the business results that touch the outside world. In short, if what we do can't somehow relate to users and purchases and sales and financial transactions, there's no value to them. (Side note: Charities and other non-profit organizations may need to measure their “business impact” in a different currency than raw currency, but the principle still holds: If the organization can't relate its activities to its purpose in some way, the activities have no intrinsic merit.) And the larger the organization, the harder it is to relate to the outside world; Drucker uses the square-cube ratio ("The surface goes up with the square of the radius, but the mass grows with the cube. The larger the animal becomes, the more resources have to be devoted to the mass and to the internal tasks.") to apply to organizations as well: “The higher up in the organization he goes, the more will his attention be drawn to problems and challenges of the inside rather than to events on the outside.”

So how do we fight this?

Know where your time goes. Track it - keep a journal and track what you do every day, for your own clarity. Many people are surprised at where their time goes, but more importantly, tracking it begins the process of making conscious decisions about how you choose to spend your time, rather than frittering it away.

Focus on outward contribution. How can you gear your efforts towards results rather than just “work?” Start with the question “What results are expected of me?” and work from there.

Build on your strengths. Nobody is good at everything, so start from where you, your superiors, your colleagues, and your direct reports have strengths. (And, as a corollary, when you hire, don't hire people who have the same strengths - that just leaves the weaknesses untouched. Hire for your weaknesses.)

“Concentrate on the few major areas where superior performance will produce outstanding results.” Pick and choose your battles, and make sure that they are high-reward areas. Far too often, life is about getting first things done first and second things not at all. Choose your first things wisely.

Make effective decisions. “What is needed are few - but fundamental - decisions.”

These five steps formed the remainder of Drucker's book, and I'll examine each in turn in the coming editorials.

Summary

Remember, Drucker leaves us with a positive note of reinforcement: “Effectiveness is a discipline. And, like every discipline, effectiveness can be learned and must be earned.” In fact, he is pretty emphatic that it must be more than just learned - it needs to be practiced on a daily basis. This makes sense - how often has a developer been able to effectively program in a new language just by reading the book?

Nobody ever said being an effective executive was going to be easy. But to the people working for the would-be effective executive, the payoff is often well worth the work.