Entrepreneurial Programmers
The definition of 'entrepreneur' is misunderstood. An entrepreneur is so much more than a businessman. Entrepreneurial programmers are those technologists that exhibit similar traits. The best programmers are entrepreneurial programmers (EPs). You want these folks on your team. And you want to be one of them. In this post I'll describe what it means to be an EP. Do you qualify?
The above definition of entrepreneur is from google. That's gotta be the most awful, boring definition of entrepreneur I've ever seen. Let's check wikipedia:
That's even worse than google's definition.
What's entrepreneurship have to do with a blog about data and technology? Plenty.
The best programmers are entrepreneurial programmers. If I needed to hire a new programmer I'd want an entrepreneurial programmer. But you can substitute "programmer" with just about any other title equally well:
- The best managers are entrepreneurial managers.
- If I needed to hire a new sysadmin, I'd want an entrepreneurial sysadmin.
You won't be able to find "entrepreneurial programmer" if you google it...I kinda invented the term. I'm going to show you what an entrepreneur is, what an entrepreneurial programmer is, why you want to be one, and how to become one. This is important stuff if you really want to be the best programmer/manager/sysadmin/whatever that you can be.
What is an entrepreneur?
So you know I don't like the above definitions for entrepreneur. Instead of giving you MY definition, let me show the traits of a good entrepreneur (abbreviated 'neur for the remainder of this post) with examples. In the last column I point out how the entrepreneurial trait is relevant to the best programmers. If you think about it, these traits are equally important for managers, sysadmins, QA folks...really anyone.
This list is in no particular order:
| Entrepreneurial Trait | Example | The Entrepreneurial Programmer (EP) |
|---|---|---|
| Understands that being first-to-market is sometimes better than being best-in-market | Venture capitalists like 'neurs who want to get a product to market quickly. It doesn't need to be the best product...sometimes the goal is to get funding to make it better later...or just get bought out. Make money quickly. | The best programmers aren't always the ones who know the most about coding, give user group presentations, or write successful blogs. Instead, the best programmers can be identified as those that are repeatedly sought out by others whenever a particularly difficult situation arises. The business and their peers trust them. They will get the job done competently and quickly. The business knows that these folks will not worry about having the "most supportable code" or the code with the most unit test code coverage. The business will get the best code as fast as the business needs it. |
| Makes wise decisions despite ambiguity in requirements and environment. | 'Neurs may have great ideas but may not know how to get "there", or where "there" really is. But they will experiment until they get a good product. | EP's don't worry about having requirements nailed down up-front. They'll adjust as the business adjusts to current market conditions. The EP will want to collaborate with her "partners" (product owners and customers) to eliminate ambiguity. |
| Takes calculated risks | 'Neurs take risks with their money. But the risks are not blind. The 'neur knows the costs and benefits to every risky decision. | An EP will take similar calculated risks. Perhaps we can forgo some of the edge case unit tests to get the product to market faster. Perhaps we don't need to fully regression test a module for a given release if we are careful in what we change. Introducing new technical debt does not scare the EP, as long as it is communicated to stakeholders. |
| Identifies causes and gets beyond treating symptoms | A good 'neur wants to solve his customer's biggest problems, not just provide a service or a product to ease some pain. | Some programmers program for the sake of programming. It's fun. They enjoy refactoring an algorithm to make it more elegant. These programmers will tell you that these activities are necessary to have a better customer deliverable. Many times they are wrong. An EP knows that this may not be needed if it does nothing to make a profitable product. The EP knows that a saleable product is more important than an algorithm. |
| Favors strategic thinking over tactical responses | Even when solving simple problems the 'neur is thinking about how this impacts the future. | This may seem contradictory to "first-to-market" thinking, but it isn't. Even when the goal is to get code out the door quickly, the EP is thinking about strategic solutions to the problems for the future. |
| Separates "what must be done well now" from "what can be improved upon later" | A 'neur may not have a complete solution to a problem today, but must be able to show that today's work has a strategic vision for the future. | I'll stress this again...EPs do not fear creating technical debt if it means getting a product to market quickly. As long as the customer understands there will be future improvements to the product this is a perfectly rational path. I see too many coders who will not move on to another, important task until there is full unit test code coverage. This is controversial...but sometimes we need to document shortcomings and move on to the next important tasks. |
| Focuses on results vs process | Profits and happy customers are more important than anything else. | IT folks seem to get caught up in making sure requirements are documented, project plans are up-to-date, unit test coverage is adequate, burndown charts are perfect, points are estimated properly, code is always reviewed, change control boards are always consulted, etc etc etc. The EP knows that these proceses are valuable but sometimes we can skirt process if it can get us the same results faster...profits and happy customers. I call this calculated risk. The EP regularly reviews each process to ensure it is part of the customer's value stream. |
| Manages money wisely | 'Neurs get nowhere without funding...and they know how to manage it once they get it. | Some programmers will spend days refactoring some code to gain a little performance. Others realize that it's cheaper to buy add'l RAM and spend their valuable time on other pressing problems. Which mentality would the EP agree with? Said differently, I've seen some DBAs spend hours removing a database cursor that is called once per month during off-hours. Yes, we all hate cursors, but there are more important ways to manage limited DBA resources. |
| Always customer-focused, even if it means nominal short-term losses to the business | Sometimes customers get irate when the 'neur over-promises and under-delivers. The good 'neurs know that a happy customer is a repeat customer and will do whatever it takes, even if it means a refund, to keep the customer coming back. | When was the last time you heard an IT guy say, "I made a mistake, I'm sorry, let me fix that for you. And we are working on ensuring this doesn't happen again."? Have you ever heard it? Most IT pros like to play the blame game...it's always someone else's fault. The EP knows that denying culpability does not instill confidence in customers. The good EP will swallow her pride and accept blame, even if the blame truly should fall somewhere else. This is how you foster trust and responsibility. |
| Gets to know his customer's needs | Before investing any money in any venture, the 'neur does enough research to understand the target market. | The EP's mantra: "The sooner you start coding, the longer the project takes." Invest the time to truly understand the requirement. "A month of programming can often save a day of thought." |
| Accomplishes volumes of important work | The 'neur knows that if the work isn't important to the customer then it is a waste of resources. | I know programmers that check in hundreds of lines of code per day. All of it is scaffolding and class declaration nonsense that wraps classes in more classes, supposedly to abstract away complexity. I guess. None of this code does anything valuable for the customer. I'd rather code stuff that delights my client and shows tangible value. When you use Amazon do you think about whether the underlying code follows MVC properly or that the database is in proper 3NF? I don't. I want it to work. And I am the customer. |
| Becomes known as an expert to his customer | Customers won't want to work with 'neurs that don't understand their business. | EPs realize that being known as a "business domain expert" is more valuable than being a "database expert". If I'm a hospital administrator and I want to buy a new software package I want my vendor and its programmers to understand healthcare even more than they understand Java, or C#, or whatever the underlying technology is. EPs want to learn about their business domain as much as they want to learn about bleeding edge coding technologies. |
| Loves to talk to and help other entrepreneurs | 'Neurs share ideas with each other. Competition is not a dirty word. My competitor will help grow my industry which ultimately helps grow my business. | EPs enjoy sharing their ideas and code with others. Possibly even trying to open source their creations. EPs do not dread documentation and tend to write the best documentation because they actually value it. |
I could certainly add more traits ad nauseum, but hopefully you see the trend.
Entrepreneurial technologists are the types of folks you want on your team. And YOU want to exhibit these traits.
An entrepreneur is so much more than the google definition...an organizer of businesses that takes on greater than normal financial risks. Entrepreneurs have the ability to change things, even if those "things" tend to be small. So, the next time you are having one of those self-actualizing moments ask yourself if you are an exhibiting entrepreneurial behavior. And if you are interviewing/hiring someone ask yourself if they exhibit those same entrepreneurial traits.
You have just read "[[Entrepreneurial Programmers]]" on davewentzel.com. If you found this useful please feel free to subscribe to the RSS feed. 
Dave Wentzel CONTENT
data architecture management other