Engaging with developers as the communicative beings they are

Myriad challenges are encountered in leading software authoring teams to outstanding performance. After recruiting team players, come the difficulties of communication. And along with that, overcoming the way many authors have previously been managed.

Another challenge arises organically from the everyday, commonplace, without a second thought, mechanistic way that many software projects, and hence developers, are and have been managed. Mechanistic management still blossoms today replete with success for over a century in the industrialized factory. Yet such approaches are often an albatross on team performance. Today’s world is different from yesterday’s world. The mindset and methods of traditional management are revealed as irrelevant to achieving high performance of most software teams today. A mechanistic approach is as counterproductive as not managing the code authors at all, if not more so. 

With software development -- that act of code authoring -- humans create the product, attended to by machines, whereas in the industrial age, machines made the product and were tended to by humans. That old world has now been turned upside down. The management instincts, common sense, and street wisdom that has been passed down from that work in those days are no longer applicable. Now, the environment of the minds, the factors that shape their attention, the conditions beneficial for high productivity are new and matter much.

Project managers, for example, all too often believe they can decompose a software development project into known, appropriate discrete steps, as if wishing would make it so. They then assign “resources” to them as if everybody’s skills are interchangeable and ramp-up time is non-existent. Such problems are further exacerbated by product managers who are oblivious to the debilitating costs of interruptions or directional shifts or late minute “just one small change”. What is being revealed here in each case is the mindset of someone whose expectations are based on how machines operate, not how people behave. Wishes for stability aside, numerous unpredictable unknowns await: staff may change, crises may distract, lawyercats may say no, dependent systems may go awry, a market urgency may arise, mandates may erupt from on-high, who knows what. It’s a good idea to not get overly tied to a plan for a future that most certainly isn’t going to arrive, at least not the realm of new product development.

Software teams and software projects are each complex systems. They’re variable; they adapt; they yield emergent phenomena, they go awry. That’s what complex systems do. Everything keeps changing; little of it predictable. Software is authored by unpredictable individuals. Developers, as thinking beings, pursue self-interest. They are embedded in an unpredictable workplace. Their employer sells into an unpredictable market. They’re surrounded by unpredictable coworkers and yet less predictable managers.

Amongst the group are authors at various life stages, with distinct concerns, personal ambitions, unique personalities, and particular interests. Some workplace milieus are maelstroms. As code quickly calcifies into legacy, expediency induces major downstream costs. Much code becomes no more than a collection of half-used/unused modules.  Docs decay.

The intrinsic value of all the collective human effort becomes manifest in the software, the code. That software is something that is created by temperamental people, tossed into situations where they’re expected to work well with others, where everyone exists in a swirl of partial attention and regular distraction.

A blinding flash of the obvious is that the authored code comes from people’s minds; hence, it matters what the state of those minds are. The fingers just transcribe. The state of what is going on in the author’s head impacts the quality of the code and its rate of creation. Code authors, have -- yes -- moods and feelings, plus myriad reactions to work conditions, coworkers, and tasks. The adept manager wants those minds free of worry, free of apprehension and uncertainty, and instead to be pragmatically optimistic, and engaged with the tasks at hand.

Such a workplace milieu is not a “well-oiled machine” with its predictable rate of production, smooth progress, and trustworthy delivery dates. It simply can’t be; machines are not the factors of production for software. Humans author the code. Instead, it’s a crowd scene that challenges the manager to bring everyone together to get things done; things that are often ill-defined, poorly understood, and politically charged, each of which can raise and then compound a developer’s sense of nervousness, apprehension, frustration, or anger. Developers do quit jobs over architectural disputes. Developers also go where they’ll be well-treated. The workplace milieu matters.

It becomes the task of the manager to organize the work and guide -- actually choreograph or conduct -- these people towards a common goal. Inducing common purpose amongst this crowd is the key to getting things done, despite that it’s a situation where every individual is unpredictable and is acting in self-interest, who is moody, and not necessarily socially adept, Developers are not programmable robots; wishing won’t make it so. They need leadership; they rarely require direction. There is no machine here, only interpersonal chaos is present, yet teams can fly above this maelstrom.

The actions of this crowd are tantamount to a “jam session”. The energy source of a crowd is their communication. Workplace conversations shape people’s attention, thus influencing whether their thoughts are on their work, or more so on matters of career concern or personal ambition or bewilderment at what are perceived as blunders at the executive level (e.g., a poorly handled re-org, buying a company with soon-to-be obsolete technology, etc.).

Outstanding team performance only happens when every mind is engaged in the common goal. Personal thoughts that dwell on worry or become apprehensive of career risks draw precious attention away from the value-creating activities of authoring code. The optimum code creation environment is the relaxed mind.

Whether this crowded conversation becomes the cacophony of a mob or becomes more like the harmony of a choir is shaped by the manager’s handling of the workplace communication environment (its milieu). The attentive manager ensures that vital topics receive sufficient “air time”, that actual decisions are made and labeled as such, and that everyone is kept up to date.

Although companies spend lavishly on tutoring employees about supposedly how to communicate, much rarer still is any guidance on what to communicate about. The manager, to foster outstanding team performance, continually communicates in terms of “what” more so than “when” or “who”, thus guiding the team to aim it thoughts to the shared mission and “what” needs to become “done”.

A company milieu that dwells on “when” (i.e., mechanistically wishing for a predictable “done” date) distracts people from discussing the tactics and strategy most important to actually get things “done”. When topics are commonly about “when” more so than “what”, personal concerns detract from the team goal. Discussions about “when” inject into the body politic a strong sense of risk. (Bad idea.). Developers know any such date would be a fiction; after all, new product development is … uhm … new. Horizons may be clear but paths are unknown, hazards await. Developers wonder why others don’t see the obvious as well. They smell gamesmanship. Personal experience and observation provides evidence for such intuition.

Similarly, a conversational environment that is predominated by discussions of “who”, where communication spotlights “stars”, postures people into direct competition with peers.  Where a workplace milieu dwells on celebrity, an environment of favor where power rests among a small clique's tribal circle of trust is spawned. Team objectives easily then devolve to lip service. Teams never gel. The result is a cast of “stars” and “bit players” -- very Hollywood, but economically debilitating for software development.

Jim Barksdale, Netscape’s CEO through the latter ‘90s, was renown for the mantra “the main thing is to keep the main thing the main thing.”[1] His deftness in the art of plain speaking and charismatic leadership is legendary. He continually presented a unifying voice to all employees encouraging them to focus on their “main thing.” It was up to the manager to ensure the “main thing” was something worthwhile and that it stayed top-of-mind for everyone. This clarity of focus was intrinsic to the business tempo that became known as “Internet time”, and continues to accelerate today. A key aspect of Barksdale’s genius was his deftness at keeping people’s minds focused on the task at hand, to be thinking about their work, to do their job.

Ensure that the “main thing” is phrased in terms of what instead of when or who. Do this by keeping an open ear to conversation, and regularly raise topics of “what” about the work and how it’s going. Redirect conversations about “dates for things” into conversations about “states of things”. Turn conversations about “stars” (or assholes) into conversations about “circumstances”.

The “right agenda” is essential to achieving outstanding team performance. Software authors are people, easily distracted to personal matters. Worrisome concerns draw aside their attention, leaving less cognitive capacity needed by their work. Guide their focus. Give them peace of mind. Make it easy for them get on with their main thing.
______________________
[1] “The main thing is to keep the main thing the main thing” is attributed to Stephen Covey.