This post is part of a series on The Effective Executive (by Peter F. Drucker). You can find the first post here. In this post I’m going to tackle chapter 3: what can I contribute?

Chapter 3: what can I contribute?

Drucker summed up “what can I contribute?” nicely when he wrote:

The focus on contribution turns the executive’s attention away from his own specialty, his own narrow skills, his own department, and toward the performance of the whole. It turns his attention to the outside, the only place where there are results.

No one hires a computer programmer to write code. Just as no customer is going to accept a 10% increase in the price of a product because it contains 10% more code than last year. People hire programmers to help solve problems and exploit opportunities that are important to them and their customers. They want our results, not lines of code.

It’s your job as a 10x programmer to find out how use can apply your unique skills to make the greatest possible contribution to your company. That was the thesis of my post: How to be a 10x programmer.

Many people would classify all this as obvious. But I can assure you that it’s not obvious to everyone. I can say this with 100% certainty because at one point it wasn’t obvious to me.

How I wasted a week building a feature that no one ever used as intended

Many years ago my boss approached me to build a new feature for our ERP system. He wanted functionality to keep track of a resource that wasn’t tracked in the system. He had it mostly planned out before he came to me and basically said, “build this.”

It was a basic CRUD feature that also tied into a few other existing reports. The form contained 38 fields and had three separate search forms. I thought that many fields was problematic from a usability point of view but he assured me he needed every field. The new reports based on this information just dumped data onto the page. They weren’t searchable, couldn’t be sorted, and they had no filters.

I asked a few questions about the purpose of the feature and how he wanted it implemented. Then, like a good little employee, I dove into the task and a week or so later, I finished it.

The results

The results were underwhelming. Our users never used the form as my boss intended. They entered the minimum information to accomplish their goals, including entering “dummy” information to get around required fields. After several years in production, there were still several fields that no one had ever used. The reports weren’t very useful either. The best users could do was use their browser’s “find” feature to search for text in the report.

What went wrong?

You can probably dissect this project ten different ways but the part I’d like to focus on is that I didn’t have a ‘what can I contribute?’ mindset. My boss gave me a task and I blindly followed his instructions. And, in so doing, I failed my boss and the users of our system. My boss didn’t know anything about building software, user interface best practices, or requirements elicitation. We can’t blame him for not knowing that stuff, that’s why he hired me.

Yet, either one of us could have rescued this project. He could have saved the project by stating the problem he wanted solved and then asking me to figure out how to achieve the best result. And I could have saved the project by asking ‘what can I contribute?’ and realizing that it’s not my job blindly build whatever my boss tells me to build. My job is to figure out what needs to be done and deliver results.

Lessons learned

Looking back on it now, I can see that I wasn’t confident and aware enough to challenge my boss and ensure I built something useful for our customers. I was too focused on pleasing my boss and not focused enough on the users of our system.

These days I’m more assertive. If someone presents me with a solution they want me to implement, I tactfully take a step back and ask how they came up with this solution or why this solution instead of some other solution. Then we usually have a discussion about the actual requirements and perhaps ways we can change the solution to be more useful to the users or easier to implement or whatever. I’ve trained my co-workers and bosses to expect that asking me to build something is going to result in a ton of questions. It’s scary at first but I haven’t been fired yet.


I love that line from Fight Club: “You decide your own level of involvement.” Most positions are defined to be these small, constrained things: Sally is the database person, Julie does front-end development, Bobbi does android apps, and so on. And you can have a whole career within one of those labels if that’s what you want. If you competently do what you’re told and stay in your lane, you’ll get good or even great review but there’s so much more to be had. 10x programmers have the opportunity to make their job as big as they want by delivering outstanding results again and again. It all starts by asking, “what can I contribute?”

So, what can you contribute? Are you just a code monkey that converts requirements into executable instructions for a computer or are you something more? How can you best apply your unique skills and talents to delivery outstanding results for your organization? What do you have to learn to make an even bigger contribution?