Everyone prattles on about software leadership. Everyone wants to find the leaders. Seminars promise to build leaders. This drivel mainly appeals to the MBA and the white-shirt crowd because it speaks to their outdated, counterproductive, absolutely attractive nonsense to “the management way” of doing things they learned by running production floors when managers prowled the catwalks above the sea of machines and sweaty (uck) backs. They actually bought into the racket that someone can learn leadership by going to class.
I don’t know what it is but I’ll know it when I see it
Everybody wants to know what leadership in software development looks like. This is a problem because it never looks like it did the last time. Software development leadership mutates in every group of developers and every problem set. The only valid question regarding software leadership trips down the broader path of “how can we cajole the universe to reveal software development leaders who already exist inside the software development group?”
When developers must serve under a group that has no idea what software developers do for a living, nothing good can come of it. Do you ever wonder why 90 percent of large software projects come in late, over budget, or just plain fail?
The truth is this: when you get the conditions right, the leadership grows organically. (But it’s not like you think. It’s not like the managerial definition of leadership, whatever that may be at the moment.)
Managerial ceremonies are fads wrapped around 19th-century methods that once worked when the managers were elites and the workers had strong backs and weak minds. Software development tossed those models on their heads, but we still attempt to justify the antiquated models with frameworks and trendy buzzwords.
Prerequisites
Let’s get some things out of the way, first.
- There are fewer leaders than we need.
- There are greatly fewer good developers than we need.
- Nobody has the guts to admit that developing software is dangerous, expensive, time-consuming, unpredictable, and undefinable.
Next, we acknowledge the dichotomy – truly a divorce – between technical and managerial wings of any bidniss (a little Tejas lingo). Only the technical side can develop software. The managers think they’re the only ones smart enough to mitigate all the risks and dangers. (And yet, I’ve never seen a scaffolding, framework, process, technique, trick, coach, master, or anything else who has successfully invented such a nine-toed, eight-headed monster who could possibly do that.)
In most corporations, management is in charge. Management lives at the top on Mahogany Row. Management on Mahogony Row understands middle managers. They, themselves, were once middle managers. There’s an affinity in the organizational structure of the company toward management.
Further, about forty years ago, managers spread the vicious rumor that programmers and all these technical “nerds” were stereotypically anti-social. These emotionally and physically stunted geeks needed a representative to communicate with upper management and with customers. Since the middle managers spread the rumor, it was only fitting that the middle managers volunteered to perform this vital corporate duty.
Developers have been subservient within the organizational topology since that fateful day. I submit that this is a horrible inhumanity, but managers who want to maintain the status quo disagree, and developers shrug off the abuse as part of the trade-off for getting to do what we love. But just because an inhumanity stands, doesn’t mean it should always stand. And we should be the ones to topple the idea.
They spend their entire careers trying to get that right. They fail, every time, with the excuse, “we gave it the ol’ college try,” and then they repeat their own mistakes.
Upper Management routinely grants lower management control over the technical box in the org chart. This single decision usually ruins any chances of technical leadership in most companies and most software development groups. Let me put this another way.
When developers must serve under a group that has no idea what software developers do for a living, nothing good can come of it. Do you ever wonder why 90 percent of large software projects come in late, over budget, or just plain fail?
Let’s pretend
But let’s be optimistic and unrealistic. Let’s pretend the world is made up of rainbow lollipops and powered by unicorn farts. We’ll start by defining the business structure of a mythically fortunate software development team.
(I know, you asked about leadership. Leadership begins with the organizational structure.)
Let’s be rude and honest
Certain realities exist for all software development.
Firstly, nobody knows how long this project will take. We make wild guesses but the most accurate guesses are the least precise. Forcing precision – or even pretending that we can achieve even two-week-time-box precision is ludicrous. It’s all a lie. Let’s not play that way. That means the managers can ask if someone thinks a project is possible within a broad time frame. A “yes” or “no” are really the same answer. The question is, “can the company and the executives tolerate it if they start a software project but it eventually ends up costing twice as much and taking twice as much time as they want? If not, then don’t start.
Software developers deal in uncertainty and certainty. Software developers exist in uncertainty without chaos. Their jobs include turning each uncertainty into a certainty.
Even if the top rung of the company can’t tolerate a minimum of overrun, they start. Their own ignorance misinforms them through overconfidence because they think they can run a software development project like they run building a house.
This is the first and most egregious failure of letting managers run software projects. Management cannot tolerate risk. They hate the unknown. They must know to the penny and to the second what will happen in five years. They spend their entire careers trying to get that right. They fail, every time, with the excuse, “we gave it the ol’ college try,” and then they repeat their own mistakes. How long do we go into tomorrow expecting it to be any different if we use the same wrong-headed thinking we used yesterday?
So managers attempt to control what they can’t and force software developers into processes that didn’t work before. Most developers currently live alongside this back-/ego-/soul-breaking managerial behavior. Managers are able, in one move, to checkmate the whole hope of winning the game. (But that’s what they were taught in management school.)
But developers weren’t taught management
What does this have to do with leadership? Software developers weren’t taught all the techniques that ruin software projects. Therefore, software developers occupy the most likely position of succeeding with their software development.
They can’t do worse than history
Put the 19th-century management structure on the shelf and put the strong minds back in charge of the shop. This means that the developers become the only source of leadership available to the software development group. This will shock even most developers because they’ve previously been told by management to accomplish the impossible: accurately estimate the unknown; plan for all tools first; design the solution before the very first foray into reality – and don’t make mistakes this time. Management calls this leadership.
Yeah. Right.
Anyone who hasn’t been educated to believe management’s lies about software development understands how this mindset stands in antithesis to software development. The degree of impossibility climbs with each delusional demand. Senior software developers know how to do their jobs and they know very well. The rest is malodorous stress.
Mangers got us into this mess. I want a show of hands: do you think management’s solution to the mess they created will be any better?
Don’t sweat on me
The managers must be told to go fret somewhere else. If they must worry, worry somewhere else. Software developers deal in uncertainty and certainty. It defines their universe.
Software developers exist in uncertainty without chaos. Their jobs include turning each uncertainty into a certainty. And then their jobs routinely expect those things that were once certain will become uncertain again. The more senior the software developer, the more that developer has lived the cycle. We’re fairly comfortable with it.
We had a saying in the Navy, “Don’t sweat on me.” That’s fair enough for the civilian world of software development. And why would anyone start the processes if they didn’t trust their developers to have the skill and experience to produce the desired outcome? (Yet, they do it all the time.) Management’s litany of worries won’t make writing one line of software better, faster, easier, or cleaner.
The next point I will make is about frameworks. Don’t. No scrum. No SAFe. No Gantt. No defined coaches or Project Managers or Product Managers. Those are useless. I take that back. They are not useless. They are detrimental.
So the rule is: The software developers are in charge of the schedule (short and long), the budget, and the process.
“Don’t sweat on me.” It’s the software developers’ show.
“Don’t sweat on me.” If the project loses containment.
If the project fails under software developers’ leadership, kill it. But don’t sweat on me until it does.
You think you know
Software development has a beginning and an end but nobody – NOT NOBODY! – knows the line in the middle. You should refamiliarize yourself with the “Family Circus” newspaper “funnies” from the past. My favorites were always the wandering pathway Bill Keane drew between where Jeffy started and where Jeffy ended up. This was always funny because the shortest distance between two points was never the path Jeffy took. He wandered with his dotted line all over the left, right, top, bottom, middle, and every diversion in between. This is the software development map. Only we never know where we’re actually going. Ever. We may think we do. We don’t.
Seniors: every one
The makeup of the development group is critical. I would never recommend any more than five developers work in a group. This is simple mathematics and it has to do with communications. I can show you, algorithmically, how adding another developer to a group of five actually reduces the amount of work possible in a day because now the communication burden exceeds the possible additional work of the original five. I have my theories that this is why Fred Brookes said adding developers to a late computer project will make it later.
Note: Brookes said that it requires (N2-N)/2 communication channels. [N * (N-1)] works, too, but has its flaws.
A single team should have a common construction:
- One or two very senior developers. One of them should hold expert-level domain knowledge.
- One or two mostly-experienced developers with broad technical and development skills.
- One less experienced but still highly skilled developer.
The key developer(s) must know the problem domain. That’s not the technical domain. Communications with the end-user must be understandable at the developer level and the only way to assure that is to have a domain expert present. (The most successful software groups could have written the software without a “customer.” They just didn’t have a reason.)
Note: When a technical domain expert communicates with the business domain expert, they already have a common terminology and world-view. The obligation of the technical member in this conversation is to teach the business domain expert enough about software development that they can have a two-way conversation.
One or two developers should have long years of experience, but not necessarily in the business/problem domain.
One or two of the members of the group should be experienced developers who want to learn to be better developers as well as the domain.
You forgot the junior members
No, I didn’t.
Where does the junior or fresher developer fit? They don’t. Not in production development groups. Juniors belong in training teams that a company hires and builds for the future. Sure, some of them can participate in some production development from time to time, but the cost to the productivity of the rest is too high to do that all the time. And it must be considered when building trust among the developers in the group.
You just don’t assign a junior and expect anything less than a burden on the rest or a negative impact on the product.
It’s a price that we pay as senior developers to mentor junior developers. We must want our junior peers to grow into the best developers we’ve ever seen – even surpassing us. So we must invest in that growth, as the company must. Every junior developer is on the minor-league team. It’s the way it is and when companies violate the way it is, they suffer (as do all the other developers). That still doesn’t mean we endanger projects and groups in order to make junior developers feel good.
This means you end up with a group composed of one or two very senior developers (10-15 years), two highly experienced (7-10 years), and maybe one who has only five or so years’ development.
Here’s the surprise. The senior and mid-level developers needn’t have all that much experience in the language du-jour. Once you’ve written in eight or so languages, the rest just look like reflections. That’s why broad experience is better than narrow.
And remember, there’s no source of leadership available to the software development group except themselves.
Okay. So we’ve got a corporate structure that tells the managers that the developers are in charge. The developers are given the boundaries of their funding and timing, and the group has been defined (and mostly by acclamation). By that, I mean that everybody has veto power about anybody – or they can say they don’t want to be part of the group without any fear of reprisal. Think of this as a suicide mission. It might be. Give everyone a choice.
We’re agile, right?
The next point I will make is about frameworks.
Don’t.
No scrum. No SAFe. No Gantt. No defined coaches or Project Managers or Product Managers. Those are useless. I take that back. They are not useless. They are detrimental. With this level of software development skill, every valuable role that some professional certified MBA dweeb would do – should and can be done by the developers. If it’s a burden on the development group, it must be lost.
Note: Management exists for managers. Management that doesn’t know how to produce software should not think they can manage software production. Managers who can manage traditional production failed for fifty years to understand that software is not widgets and traditional manufacturing misses the mark, utterly, in software development.
Those management processes that have no beneficial effect on overall software development must be eliminated:
- Weekly progress reports
- Burn-down charts
- Backlogs in Jira (or whatever)
All of these must pass. Grieve if you want. Complain if you must. Just don’t try to resurrect what has been dead for decades. The idea doesn’t still have life just because nobody has the courage to bury the corpse.
There should be NO games of telephone. Software developers must participate in every form of necessary communication. There must be no hearsay. The only things that count are facts as witnessed by two or more in the group (and managers are not part of the group; they can’t write software so they aren’t part). The developers must meet in twos and threes with management, customer, end-users, and anyone else with whom significant interaction must occur.
Now; let’s talk leadership
We’ve previously established that there aren’t enough leaders for all the leadership we need. Nowhere. No how. So what do we do? We self-organize. (And remember, there’s no source of leadership available to the software development group except themselves.)
“I have no idea what he does here. Nobody here knows what he does here. If we knew, we wouldn’t need him, now would we?”
A note about self-organization. Electrons self-organize. They work independently on a single purpose but they’re always within a certain boundary within the atom. They move independently while depending on the other electrons to keep the valence correct. That’s an appropriate definition of software group self-organization. One member works closer to the nucleus today. Another works closer tomorrow. Working closer gives authority through knowledge. Technical authority derived from senior software development expertise supports decisions that must be made about tomorrow.
This is leadership.
Some lead longer. Some lead shorter. Some are good at documentation. Some are good at testing. It all comes down to passion. In the professional software development group, everybody leads.
Okay, so we can ask ourselves, “how can that be?” It comes down to expertise and trust. When one of your peers knows an API better than the rest, s/he leads on those decisions, designs, and parameters. When someone else knows security better, the API leader follows. It’s fluid and seamless.
What’s my gift?
There’s the story of the old guy in the church who comes to the preacher and says, “I don’t know what my ‘gifts’ are.” And the preacher asks, “well, what do you like to do?”
The old guy says, “I love to clean up and arrange the chairs before the service, and pick up the coffee pots and clean all the dishes afterward.”
“Your gift is ‘service,'” says the preacher.
“That can’t be right,” says the old guy. “I love doing those things.”
And that’s what self-organized leadership is. It’s what you love to do, technically, turned into a semi-transient role – teaching, guiding, informing, and making decisions about your current passion.
How can we get away with having leaders who aren’t assigned the role? It’s because we’ve:
- taken the pressure off the individual and allowed the group to bear the responsibilities of developing software together;
- chosen experienced, skilled, quality individuals to do the work
- given them the liberty to be more than a coder; and
- told them what is expected of the group and allowed them the freedom to decide who wants to do it – not who has to do it (or how to do it).
Chimera
I’ve seen this kind of leadership, but rarely in a software setting and never for long because the companies always fail in their initial, immediate, and foundational duty to BACK OFF! I’ve seen it in the scientific world and it’s awesome. I’ve seen it in fleeting moments in highly-skilled technical teams in the milliseconds between the moment when the group started functioning as a unit and the moment that management decided that the group was top-heavy.
Locally-compact sets in Hilbert Space
There’s a story about leadership from the Manhattan Project. Remember the Manhattan Project?
That was a World War II effort that collected a hundred some-odd of the most qualified theoretical physicists in the world, gathered them in the New Mexican desert, and gave them a challenge:
Build the world’s first nuclear bomb.
General Groves, back in the Pentagon, was getting nervous about these pointy-headed deletants mucking around in the desert with the Army’s money. So he sent a time and materials analyst – an efficiency expert – out with his books and charts and asked him to study the boys to see if he could help.
He arrived on the first day and was led directly to Dr. Oppenheimer, the overall manager of the project. (technical project; technical manager)
The time and materials analyst expected some push-back but Oppie was thrilled to have any help he could get. “You have the run of the place with the condition that this nice sargeant follow you everywhere you go.” That was his only demand.
This led the efficiency expert to his Waterloo: he stumbled first to the office of Dr. Ulam, the world’s foremost theoretical mathematician.
“What are your fields, duties, and obligations?” the efficiency expert asked.
“Vas?” was Ulam’s response.
“What is it that you do?” he countered.
“I’m so happy you asked,” replied Ulam. “I’m trying to determine if locally-compact sets are dense in themselves in Hilbert Space.”
Not understanding a single word of the answer, he rushed to his books. “If you don’t understand the worker’s response, watch him,” his books told him.
So he watched Dr. Ulam work.
Dr. Ulam read. He wrote on the blackboard. He drank coffee. He smoked his pipe. He stared out the window. He went for walks in the evening. None of this informed the efficiency expert of what Dr. Ulam did for the Manhattan Project.
His books informed him, “if watching the worker doesn’t help, ask his immediate supervisor.”
None of us really knows what the other does. How could we? We become, in our own way, the world’s foremost expert in our little slice of code.
Dr. Ulam’s immediate supervisor was Oppie. (This was true of everyone there.) So the efficiency expert went to Dr. Oppenheimer and asked him.
“I have no idea what he does here. Nobody here knows what he does here. If we knew, we wouldn’t need him, now would we?“
“Then how do you know when he’s doing good work?“
“He tells us.“
“You mean the worker tells the boss that he’s doing a good job?“
“Of course. There’s no one else in the world who could because nobody knows what he does.“
The efficiency expert left for Washington that evening. The next week the fellows at Los Almos detonated the first atomic bomb at the Trinity Site.
Dr. Ulam was working on the probabilities that Oppenheimer and Fermi and Einstein would ignite the atmosphere with their bomb. He gave Oppie the go-ahead before the test.
Note: I’m convinced that, seeing the ever-expanding, ever-rising fireball of the Trinity explosion, Oppie feared he had, in truth, lit our atmosphere on fire. This – in my estimation – is the trigger for Oppenheimer quoting the Bhagavad Gita, saying, “Now I am become Death, the destroyer of worlds.”
I’m so glad you asked
Nothing I’ve ever written in code has the import of building that first atomic weapon, but most of the developers in my groups had the same levels of expertise in the company (and in the business and technical domain) as Dr. Ulam did with his Hilbert Space.
None of us really knows what the other does. How could we? We become, in our own way, the world’s foremost expert in our little slice of code.
We should be helped when possible but left alone at all other times. We’ll tell you when we’re doing well or when we’re not. We’re brutally honest with ourselves. We’re brutally honest with our peers. This, too, is the forgotten leadership of software development.
The companies for whom we code need to show respect, demonstrate patience, and give us the room that will allow us to be honest with each other, with the company management, and with end-users.
And in that, we come to trust each other in the group and ask for help when we need leadership in a problem or role.
And there you have it.
Next, I’ll be less controversial and talk about trust.