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.
Ever wondered what your contribution is?
As developers, we’re often measured by metrics that have something to do with code. The amount of code used to be a common metric, at least until managers realized that we could write programs that could generate programs that could generate programs. (It turns out that software is great for automating tasks—who knew?) We create it, we design it, we architect it, we test it, we deploy it, we modify it, we sometimes replace it with more of it, we even sometimes get the chance to delete it, but no matter how you slice it, it feels like the key contribution developers make is entirely around code.
Except that’s not really the case.
Developer Contribution
Let’s imagine for a moment that you’re looking for a new place to live. You go and talk to a real estate agent about finding a place to live. They immediately come back with a list of six different places, ranging from $700,000 to $900,000 in price, on some lovely lots, all across the Eastside Seattle area. That would be great, except you were looking for rentals in Florida. Was it reasonable to expect the real estate agent to understand that you wanted to rent instead of buy, or that you were looking for a place in the Sunshine State rather than the Pacific Northwest? Perhaps, but the real estate agent could easily come back with, “Yes, but my job is to help people buy property.”
Except that’s not really the case. Your job, dear agent, is to help me find a place to live. And if that’s not something you can help me with, then I should probably find a new agent.
In the end, that’s really the point: If I engage with you in some sort of economic transaction, what I’m really looking for is satisfaction. In other words, I compensate you when you’ve provided me with some good or service that, for some reason, I don’t care to provide for myself (regardless of the reason—it’s immaterial whether I can’t or simply choose not to).
When developers fall back on the idea that their contributions to the world revolve entirely around code, they take a dangerously short-sighted view of what the transaction is between customer and provider. Developers—or, rather, their organizations, either internal or external—are retained to provide satisfaction to the customer. Certainly, it’s often the case that the customer wants some bespoke software created, but to make that assumption going into the exchange is making the same mistake that the real estate agent made earlier. Sometimes the right answer is to write some bespoke C# applications that are full-blown Web applications; at other times, though, the right answer is to slam out a PowerShell script. And in most cases, the answer will be a range of possible solutions, and it’s up to the developer—and the organization—to help the customer find the “right” solution, where “right” is something contextual to the customer’s particular situation. The “right” solution may—and often will —involve bespoke code, but that’s simply a step toward the actual goal. When developers lose sight of this basic reality, we lose sight of so many other things that all of the other trappings (like Kanban boards or burndown charts or bug counts or…) essentially lose all meaning.
Management Contribution
What if you’re in management? What’s your contribution there?
To many of those new to the role or observing it from a distance, it seems that management’s job is to make big, strategic decisions and then observe the results. For this reason, managers are (sometimes inspirationally, other times aspirationally) referred to as “leaders” or “leadership,” and are expected to be the rallying point for the company and so on. (For the moment, we’ll ignore the more cynical take, that managers make no contribution whatsoever.)
Frankly, this is a pretty distorted view of the job.
To be sure, managers are sometimes called upon to make hard decisions. This often isn’t by choice or preference. Many companies seek to make decisions by consensus, but this often leads to an unacceptable state of affairs; when the entire room has to come to an agreement before they can consider a decision made, the person willing to be the most stubborn and intransigent often gets the decision they want, largely because others just reach a point of emotional exhaustion. Weak managers prefer this approach, because it means that they can avoid the consequences of a bad decision: “Hey, the team agreed, so it’s not my fault.” As much as it may feel authoritarian to overrule members of the team, strong managers understand that a decision made is often better than languishing in a pit of ambiguity for months or years.
The act of making decisions or setting out grand strategy is, in and of itself, only a small fraction of the job. Management—or leadership, if you prefer—is much more about seeing what the job needs and moving to adapt. “The executive who keeps on doing what he has done successfully before he moved is almost bound to fail,” writes Peter F. Drucker, of the Drucker School of Management. “The executive who fails to understand this will suddenly do the wrong things the wrong way—even though he does exactly what, in his old job, had been the right things done the right way.” Management is about much more than “same job different title” that many developers (and other leaf-node contributors) believe it to be. Technical leads can make technology decisions. Developers can figure out which testing framework to use. Management is about people—and more to the point, about figuring out how best to work with the highly nondeterministic, incredibly diverse collection of skills, history, and preferences that they represent.
Drucker talks almost specifically to developers when he talks about “specialists” and “knowledge workers” in the same section. “Knowledge workers do not produce a ‘thing’,” he writes. “They produce ideas, information, concepts. The knowledge worker, moreover, is usually a specialist. In fact, he can, as a rule, be effective only if he has learned to do one thing very well. By itself, however, a specialty is a fragment and sterile. Its output has to be put together with the output of other specialists before it can produce results.” In a world where we find ourselves in companies that have begun to collapse developers with QA and operations folks into teams of DevOps, this seems to be entirely prescient.
“The task is not to breed generalists,” he continues. “It is to enable the specialist to make himself and his specialty effective. This means that he must think through who is to use his output and what the user needs to know and to understand to be able to make productive the fragment the specialist produces.” That is to say, we have to think about how best to combine the various output of the different specialist communities within our organizations—developers, QA, operations, agilists, business analysts, product owners, or however your company has segregated your specialization—into a concrete and useful outcome.
This means that managers are, in many ways, troubleshooters. The job of management becomes that of figuring out what obstacles lie in the path of the team and removing them. “A policy does nothing by itself,” Drucker quotes a new chief executive as saying. “My contribution is to make sure that this actually gets done.”
Your Contribution
This, then, brings us to the last point of contribution: What’s your contribution? Regardless of role or position in the hierarchy, you can begin to walk this path of management-slash-leadership by asking yourself this basic question: What can I contribute? This doesn’t have to be something that’s unique to you, or even within the company, but it does require an honest and thorough assessment of your skillset and the needs of the company around you. What do you do well? What does the company do poorly that you can take on as a personal quest?
Drucker sums up by suggesting that “the focus on contribution by itself supplies the four basic requirements of effective human relations: communications; teamwork; self-development; and development of others.” In other words, if you focus on how you can contribute, you can communicate that more effectively with your own management, you begin to see how your contribution is used by others and can tailor it accordingly, you begin to see where you require additional growth, and you can see how you can help others grow in turn.
Summary
Contribution is, in many ways, the lifeblood of the successful enterprise (commercial or otherwise). When you have a team of people who are engaged in asking themselves how they can contribute and who see their efforts as part of the larger fabric of the team and the company, they begin to develop the necessary view to be successful in making others successful, which in turn becomes the force multiplier that the company needs. But it all begins with the basic question: What can you contribute?
