Teamwork is hard; it demands perspective, talent, and commitment

Another elusive challenge in managing software teams is that outstanding economic value derives from the effectiveness with which software developers themselves work together. For the manager, this requires managing the collection of direct reports such that the whole actually is greater than the sum of its parts. Teamwork brings superior performance and a bigger picture.

Collaboration is more often said than done. Teamwork requires teams, which are often more apparent than real. At its heart, this means the manager must manage the collaboration around the work -- who is doing which tasks, but not directly manage the people. This is especially elusive for inexperienced managers whose minds are more on “being boss” instead of “getting things done”. No good can come from such a situation.

Effective software teams are uncommon; high-performance ones rarer still. When it comes to exemplary teamwork, the fundamental problem for developers isn’t that they can’t or that they won’t; instead, it’s that they haven’t learned how. And more often than not, they’re managed in a manner that precludes effective teamwork.

To perform as a team, developers require common purpose and must act in concert with teammates, adapting to a singular and interdependent focus. Teamwork requires that their actions are coordinated in time, that they are attentive- and responsive- to the work of their teammates, that workloads amongst them are fairly balanced, and that their actions have purpose. Teamwork requires that people’s minds are on the task at hand and that they’re not distracted by worries or gambits.

Excellence requires attention, focus, and discipline. Working together requires clear purpose, accurate and timely communication, and intended, coordinated activity. An effective mechanism to bring a group of individuals into performing together as an outstanding team is via a choreography of occasional meetings and regular activities. Outstanding team work comes from a focus on the temporal matters of “what to do now” coupled with performance matters of “how to do this thing.”

Operationally, this means implementing a small set of activities and a smaller number of meetings, executed like clockwork in a most deliberate manner. It means that priorities of action always the drive workflow, that the idea of “sustainable system” is always at the forefront of activity, and that clear historical records of “who” did “what” and “when” -- especially project or product managers -- is kept current for all to see. Project and product managers are renown for their too-prescriptive approaches or their too short-sighted shifts of focus. Outstanding team performance requires that all these problems be tallied and regularly revealed to everyone who is watching. Visibility is the natural enemy of mischievous shenanigans. As US Supreme Court Justice Brandeis wrote: “Sunlight is the best disinfectant.”

As a cautionary tale, these approaches may be unfamiliar. They shape attention, and can be politically disadvantageous in the short term for those managers whose ambition supersedes their duty. In some situations, the organization itself operates to thwart all teamwork, irrespective of company propaganda. Teams deliver superior economic advantages. Team effectiveness requires astute and attentive management. It is a milieu where “we” trumps “me” and rewards openly endorse such. So. Now what?

Stay tuned; soon we’ll discuss backlogs, retrospectives, and cycles -- the elements of the choreography that yield a sustainable pace for today, tomorrow, and the days forthcoming.

Speaking truth: why “when we’ll be Done” is unknowable

Another challenge in managing software teams to outstanding performance derives from the tawdry custom of decreeing the future date a software system will be “done” (which usually means a compete feature set delivered and operational). If only wishing could make it so. Prima facie: every target date is subject to myriad uncertainties, changing demands, and rapidly shifting forces. Each day does unfold a bit differently. Every future date is a statement of hope, not fact -- especially not in the realm of new product development.

In these situations the manager decides whether to speak in terms of facts or in terms of hopes. A guess must be seen for what it is -- a conjecture, a speculation, a bunch of B.S. In the milieu of some workplaces, dates (i.e., “when” speak) drowns out other topics. At times, “date-debate” becomes a cesspool of political stratagems. In truth, only the roughest and broadest date range can be guessed. Expecting guarantee of a firm date for a particularly scoped set of features is silly to be sure. It is economically damaging to be certain, especially as dependencies grow around those expectations. Efforts that will likely become wasted are initiated, all based on hope. You can be smart about this, but that takes backbone.

Big plans, long-term visions, and the next big thing, are much more hope than fact: dreams and schemes are more likely to remain wishes than to become a reality. What else could new product development be other than … uhm … new. New product development is exactly that: something that has never been done before. Expect surprises. Otherwise don’t expect anything new. It’s one or the other: new or old.  The future isn’t predictable in any manner that matters for most software services/products in a place where projects shift directions, personnel change, the market shifts, new technologies appear while others become obsolete faster than planners anticipated.

It’s fascinating to see how often product managers want to be able to iterate on their designs, but don’t comprehend that in order to accommodate that, then developers likewise need time to adapt the code by iterating and refactoring. Product managers often attempt to fix a date on developers but not on themselves. Instead, the product manager should prioritize either a date or a feature set over the other -- it’s not possible for them to be equally important. Which takes priority? If it’s the date, then cut to fit. If it’s the scope, then keep everyone apprised of progress so they know when to leap into action.

It’s somewhat comical to watch how marketing and PR will be quick to talk about the constraints of their lead times -- which are typically small and predictable. Yet, they often want engineering to specify a fixed date far in the future. They’ve got it backwards. If marketing needs, say 6 weeks lead for printing and distribution, engineering can easily let them know 7 weeks in advance. What can’t be determined (as fact) is what things will look like 5-6 months from now.

Having an important business need doesn’t translate into software development becoming predictable on a scheduled timeline. Authority and command cannot make it so. All they can do is pressure someone to lie. To Speak The Future Date (in new product development) is to knowingly speak falsely. That’s the genesis of many problems, much stress, low morale, and employee turnover.

Others then come to depend upon that date as if it were real, expecting the complete feature set as a given (never mind it probably hasn’t yet been really defined, and PMs will want to tweak it as time goes on). Worse yet, personnel then face having their performance judged on whether they made the fiction come true -- which they can (once), of course, but at the cost of incurring substantial technical debt, delivering bug-infested and undocumented code, and thus sending huge costs downstream that vitiate an enterprise’s capacity for future innovation due to induced burdens such additional maintenance, support, and forced deprecation.

Spurred on by the quick half-life of software projects, of product shifts, and of staff changes, the codebase quickly becomes calcified and brittle. Acting only one step ahead leads to a “hackolution” instead of an “evolution” of the codebase. Continual piecemeal hacks optimize for the here and now, yet flexibility tomorrow means preparing for it today.  In part, that means that recognizing that its less expensive to build in monitoring and testing today than it is to waste much time debugging and fixing in the future.

By nature, short-term actions prevail to the degree they’re rewarded. The short term can be good for the software author, for the product manager, for the marketing manager, but not as good for the company itself. For the longer horizons of the company, the manager is obliged to remain mindful of the economics of the codebase, thereby keeping a mental tally of its value, burden, and opportunity costs in light of development activities underway.

Balancing the short and long term is delicate and unique in every situation. In each case, the business needs, the available personnel, the project resources are different. Nonetheless, good engineering practices today makes for a better system tomorrow.  Developers can easily become “too clever by half” to speed up code development -- something that can save half a day today may well cost two or three days to find and fix down the road in six to nine months or so. An unreasonable demand for a feature by a date can induce this behavior easily. Often, managers are the ones who actually create the downstream problems by lacking discipline at this point.

Haste today often precludes innovation tomorrow. Promising silly dates for feature-replete products yields premature dependence on fragile infrastructure. Burdensome downstream expenses accrue. Although an early release may be opportune for marketing purposes, it may also become crippling burdensome to the company over time. For a company that wants to last, or just not become a one-trick pony, prudence cautions managers to apprise every project’s performance in terms of both value today and opportunity for tomorrow.[1] Focus is served by ensuring everyone knows what matters most. A conscious choice is the responsible thing to do.

A real pernicious circumstance occurs from bandying about hopeful dates without recognizing actual capacity or necessary features/scope that can likely be ready by that date. The cost endured here is more subtle and more damaging than those mentioned above. Discussions of “dates” changes the milieu of the workplace -- thoughts shift from “what we are working on”, to who’s talking to “me” and when “I” am expected to be done with something that probably hasn’t yet been invented or defined. The predominant outcome from “date posturing” is to distract developers from their work. As a result, people become unsettled, and each developer’s thoughts naturally become drawn to conjuring up worrisome fictions, and fretting over the future. Like an evil Gresham’s Law of conversation, the  milieu spawned from “when” chatter is combustible and predisposed to political shenanigans. Team performance becomes suppressed. Every person, for survival, optimizes for the self.

Commitments to future dates ask people to claim and then stand behind statements that are known to be speculative guesses. These are circumstances with capricious career impacts, either good or bad. No productive value is afforded by this focus, by this claim on attention. Whereas a plan of record is sensible, a date of future record is folly. How else could it be? Such talk of dates is the slippery slope that rapidly transforms a collaborative workplace milieu into one best described as “me first”. Heroes are bred here. Kiss teamwork goodbye. Recurring discussions of “when” foster rampant worry unless the discussion are accompanied by notions of “cut to fit”. That is, to have conversations that reflect pragmatism regarding what can actually be accomplished by that sacred date. In themselves, dates are fine -- it’s the unspoken baggage of feature completeness that is the hidden toxin.

Coding is an exacting, by-hand, attentive practice akin to the work of the finest artists and craft masters. Even tiny systems are built in pieces by different people, often with myriad small and interdependent parts. The economic value of that software is shaped by how well this blizzard of components and their relationships work together, and how costly it will be maintain or rewrite. Of the myriad uncertainties in software development, the human element clearly predominates. Such is ignored only by folly or snoozing or conniving.

But there a practical solution to this: pick which is more important -- the date or the feature set, then plan accordingly. It can’t be both.

US President Teddy Roosevelt offered plain-speaking guidance: “Do what you can, where you are, with what you’ve got.” What you as the manager can do is to speak in present tenses and keep everyone’s focus on “what” needs to be done. Shield the developers from the allied roles or executives clamoring for “when.” Stay alert enough to bring witness to shenanigans. Have the backbone to expose them to sunlight. You’ll get more done, and the developers will be a happier lot.

_______________________________
[1] From the vantage point of this author, “quickies” are necessary for startups and early stage companies, but notable deleterious to  those orgs with greater resources, longer horizons, and larger workforces. Sadly, it seems at least, so many of this “next stage” orgs act according to the circumstances they used to be in instead of where they are and have evolved to.

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.

Challenges in Fostering High Performance Software Teams

Great teams, to quote legendary hockey coach Herb Brooks[1], are comprised of the “right” players, not necessarily the “best” players. The essence of “right”, in this case, is the capability for people to perform well with others -- as a team, a unit, or an ensemble.

Acquiring the “right” developers, and then managing them as a team is fraught with challenges. Experience and observation, again and again, have revealed these underlying challenges:

• Recruiting a team from amidst a hotbed of celebrities and soloists
• Engaging with developers as the communicative humans they are
• Speaking truth: saying that “when we’ll be done” is unknowable for new product development
• Working as a team is hard; it demands character, talent, and commitment
• Raising developer’s individual sense of professionalism and excellence
• Inducing a positive milieu exceeds the apperception of many technical managers

The manager must draw the “right” people together; this luxury doesn’t manifest quickly. In many workplaces staffs and work groups are just assigned. So this challenge comes to include mentoring people on how to act -- i.e., perform -- as team players. For the time being, think of people in a choir, symphony or soccer-team, etc.  That is, they are performers. This requires guiding developers in ways of working together that foster outstanding performance.

The adept manager needs to have a mental model of how teamwork is performed. That is, the acts of the performers. This is wholly distinct from “what tasks need to be done”. Teamwork is induced by the manager, sustained by the group. The manager needs to maintain a public agenda of teamwork, and then communicate it clearly and frequently. It’s up to the manager to create this expectation.

Walter Wriston, while leading Citicorp, insightfully said about capital: “it goes where it’s wanted and stays where it’s well treated.” The same can be said about talent, and that means software developers. Recruiting the “right” people, and mentoring them to work together in a “right” manner to get things done is at the forefront of the manager’s responsibilities. And people tend to be set in their ways, with their own ambitions and resolve. It is attentive work. It’s hard to do well.

The Primary Challenge: Recruiting a team from amidst a hotbed of celebrities and soloists.

The primary challenge to achieving outstanding team performance is recruiting team players. This means drawing in people who in their essence prefer the rewards of teamwork more than a spotlight on themselves. For these people, team contribution trumps personal ambition. These are people who seek to participate, as the saying goes, in something that is “larger than themselves.” This challenge arises because the software development workplace is often a welcoming haven for wizards of the arcane and celebrities of crises -- two types of heroes who are inimical to teamwork. Of course, this is not surprising as many companies lucratively reward “stars”.

Building a team of the “right” players is where it all starts. Outstanding team performance expects personal excellence ahead of individual cleverness. It means that everybody must adjust their own individual pace in a manner such that the team, and consequently the project at hand, can step up its pulse. This approach blooms with ramifications -- it means not always putting the “best person for the job” on the job, for example, if the work is being managed to broaden the skills of other team members. It might mean that everyone on the team may be expected to use the same tools, instead of personal favorites. It all depends on the circumstances.

Perhaps this “religious war” is unknown away from the software development workplace milieu: emacs vs. vi. Each provides a specialized editor for authoring code. A third one is Eclipse (mainly for Java). Developers’ passions boil over regarding which editor to use. Their preference typically points to the editor most familiar to them personally. For the team’s sake, though, it may be better that only one editor is in use such that anyone can offer quick help to another and be working in a common environment. This is a deeply personal act; team players will be disappointed but not become argumentative. Solo artists will wail and whine endlessly. A manager can learn much about the personnel by raising the topic of “only one editor” at a staff meeting. Pay careful attention to who says what and keep a sharp eye for changes in body language and fidgeting. Make mental note of those who complain the most.

An outstanding term achieves success via well-rehearsed, collective finesse, not from the individual actions of a cast of stars. With a team, even when stars do fall or are just away for a day, success remains at hand. In teams, people work together towards a common goal. Here, they happily fly in formation. Finding people who are like this, the ones who excel personally and work well with others, is the fundamental challenge to achieving outstanding team performance. Recruit the right players, not the best players. Coach people to perform together, as a unit, as an ensemble

Playing well together trumps all; progress never stalls. Returns continue to accrue.

________________

[1] As immortalized in the classic show Miracle on Ice chronicling the 1980 USA Men’s Olympic Hockey team and their spectacular win, Herb Brooks, the coach, when putting the team together said: “I’m not looking for the best players; I’m looking for the right players." The rest, as they say, is history.

Teams Trump Groups When Creating Software

Managing software development is my vocation. It has been for nearly three decades. I’ve been asked by various peers to write down some of my observations, theories, opinions, techniques, and suggestions. Thus begins various comments regarding managing software teams.

Software is written by people. It all starts there. Some people are better than others at working together. Some just don’t know how. It all ends there. In a nutshell, what I’ve found is this: manage the work, and let the people manage themselves. Ensure they do so as a team. Why?

Without software, contemporary civilization could not exist. Billions and billions of lines of computer code are necessary to keep our lives in working order -- code that is expensive and difficult to author, and then yet more challenging to maintain. Defects are common, sometimes glaring. Although software automates much of the world, and underlies all contemporary communications and financial transactions, the act of creating code is in itself a painstaking and individual activity. Building any software system, irrespective of whether for services, infrastructure, tools or products, has been repeatedly shown as frightfully expensive[1] and a high-risk undertaking in terms of both time and money. Economic returns are highly variable. Disappointment abounds. Nonetheless, this tiger can be tamed.

Creating and maintaining software is challenging and difficult work -- far more difficult than anyone who doesn’t do it can realistically imagine. The act of authoring software requires razor-sharp technical acumen, extensively refined knowledge, proficiency with algorithms and languages, adeptness with tools, and all while requiring an excruciating attention to detail as a clock is ticking and people are pushing. Nonetheless, the mental aspects of coding can be intoxicating, highly satisfying for those with an intellectual bent and those who truly enjoy the life of the mind.

Mastery of the art when it comes to coding does demand an attentive physical activity of dexterous keyboarding, coupled with creative mental focus, usually amidst noisy and distracting surroundings. For the developer, coding can be a combination of wonderful mind flights and wizardry skill. It’s what produces “that nifty code” that “does that shiny thing”. The work of the best of them is brilliantly beautiful. The act of authoring software can be a great solo experience. And the pay is really good.

Yet, in the interests of the employer, superior economic value, in a sustainable manner, cannot be based on the actions of individuals, of solo performers. Instead, enduring economic returns are founded on the collective actions of several or more people, preferable acting as a team where all members pitch-in to ensure that the tasks to be done get done in a timely and effective manner. It takes people who see to the mentoring of each other, and who keep systems running, and continually improve[2]: (1) how they work together; (2) the tools they work with; and (3) with whom they work.

With a team, forward progress on a project never stalls. In contrast, if a deliverable depends solely on the actions of an individual, progress on that task just freezes should that individual be sick tomorrow, go on vacation, or be called out of town. The underlying challenge for the manager is to reward team performance while recognizing individual excellence. It’s harder than one might think at first glance.

Many paths lead to success. The activities suggested in this series of posts are among those that experience and observation have taught me do indeed lead there. Every manager can take simple steps to foster outstanding performance among software developers.

The suggested activities described in this series of posts will be a breath of fresh air for many developers yet an anathema for some others. Why? Because the first requirement for having a software team is to expect, empower, and reward teamwork -- which is much more elusive and difficult than popular management literature reveals. And not everyone in an org wants to be part of a team; especially in celebrity milieus where individual results are rewarded disproportionally over team performance, irrespective of whether the true accomplishment was that of a team. The mindset and methods presented here, however, are team activities for sets of team players. Personal experience suggests that outstanding performance will result from practicing the approaches described in these posts.

Stay tuned!

____________________________________________

1. C.f., Robert Charette, "Why Software Fails", IEEE Spectrum 2005

2. Kaizen