I’ve been trying to pen an article on how entrepreneurship “clicked” for me, but I’ve so far been unsuccessful in putting into words how it all came about. So, I’ll write a few posts on tenets that have served me well as an entrepreneur in the hopes that I’ll eventually come around to writing the “introduction to Kyle’s entrepreneurship” article that I desperately want to finish.
The best entrepreneur is the one that is willing to take a bullet for his ideas and actions.
One day, while working a contract position my father-in-law handed to me after I ran my financial investments business into the ground (a story in itself that will be told when my ex-partners and I feel the time is right) and was laid off at Microsoft, I noticed that there were a ton of repetitive tasks being done by hand in our department. I sat down with my co-worker, Steve, and asked him to show me how he did things and why he did them. After observing and asking a few probing questions, I went to my father-in-law’s office (he was my boss) and told him how stupid it was that most of Steve’s day involved dealing with heavily repetitive tasks that had to be solvable with simple scripting. He told me that the development department said automating that process or developing adequate tools was a low priority and was too hard to boot.
Now, I had taken a few Computer Science classes in college, but I had never written a real program that anyone would use, and I had no idea how to code webapps. However, watching Steve despair at doing idiotic tasks all day pissed me off as a guy who has an insatiable thirst for efficiency, so I went to php.net and started reading tutorials on how to code PHP and write SQL scripts to pull data. I read that MVC frameworks were all the rage; I tried CakePHP but had problems with the command line magic that it required, so I eventually switched to CodeIgniter, a framework I use to this day (and have contributed to).
I started doing the demo projects that would be relevant to the task at hand – first understanding how controllers and views worked, then how to simply query a database, then how to display it in a view, and so forth.
I took an early prototype mocked up in Microsoft Excel (which connected via ODBC to a replication store of production data) and showed it to my father-in-law. I told him that I could have a tool that gave Steve the data he needed which would be heavily customizable. He asked me how long it would take, and I told him that it’d be done inside 2 weeks – and I’d get all my other work done as well. He gave me the green light, fully knowing that he would be on the hook for superceding normal development processes within the company.
Nine days later, I delivered a customer lead management tool to Steve. He was blown away. He had some suggestions and recommendations, and I baked them into the product quickly.
A week later, they showed this to the development team, who were more or less forced to give me a full-time position as a developer within their team. I didn’t push hard enough for the things that I knew mattered – I didn’t want to learn Java, at least the flavor they showed me. Slow-moving crap with a lengthy “code review” and “testing” process made me want to work outside their framework. I wasn’t a developer; I was a guy who hacked together code. Still, I took the job, hoping they’d see how I could be valuable in that regard.
Shortly after moving to the development team, I met a man named Bryce. He shared my passion for Rapid Development Frameworks and loved to operate outside the boundaries, much to the chagrin of the supervisors. We worked late nights on projects, he mentored me on how to code (he was a senior developer), and I converted the suit-speak from business units like Sales, Marketing, and Business Operations into pseudocode that we could turn into actual working applications.
I would go on to solve a major problem at the company – how to apply budgets across different types of customers and timelines – through statistical means and reverse engineering an abandoned codebase that few had picked through. I would deliver solutions to business units and they would bow at my feet, praising my work.
I was forced to resign, as was Bryce.
They would explain that I wasn’t a good fit for the development team; that I didn’t have the necessary skillset to succeed. But I had delivered time and again while they fell short!
It really didn’t come as a shock to either of us. We had routinely flaunted the archaic development processes that this company put on display and made them look terrible. We delivered in days, not months, and we didn’t need a project manager to burden us with bureaucractic bullshit.
This type of attitude is unwelcome on most teams, as I’ve come to understand. Most dev teams are full of pretentious anti-social nerds who are unable (or unwilling) to actually speak with the customers of their products. They want to hide behind a project manager, hoping they will shield them from criticism. They have a limited skillset – generally writing enterprise-level garbage in Java, C++, or some other “big time” language – and look down on scripting languages, citing esoteric “performance benefits” and “best practices.”
But all of that just hid the fact that two kids who dropped out of college – one of whom had learned how to write code in 2 weeks – made them all look impotent.
If you are an entrepreneurial type of person who writes code or works in a technical field, you will come across this scenario, I guarantee it. If you believe in the company you’re at (if you don’t, you just quit), you can do one of two things:
- Stick it out, happy to collect a middling paycheck, while you look for a better position
- Stand up what you believe in and find allies within the company
The first choice is the choice of the person who is happy to have a job, one who is a career lifer. It’s safe, and in today’s economy, we should all be thankful for a job.
The second choice is the one the real entrepreneur makes 100% of the time. If he believes in the company and is unwilling to just give up by quitting and contacting his local recruiter, he fights hard for what he believes in to improve the company – even if this means most of the people within will turn against him. There is no better learning opportunity than the one where you are passionately pursuing a goal that you know is right! That’s why the person who picks the safe route misses out on developing his skillset under fire; he misses out on how to manage people in a situation that calls for true desire.
Most companies aren’t ready or willing to employ strong-willed entrepreneurs, but the ones that do find extremely devoted employees who will work around the clock for a cause they believe in – at the cost of having their assumptions and ideas challenges on a regular basis. And that’s the real problem, isn’t it? Most people are unwilling to have their preconceived notions of the world challenged – they want to hold on to the ideas they grew up with, the memories they have been indoctrinated with. (That’s another post entirely.)
My recommendation to entrepreneurs out there: Be willing to be fired for standing up for what you believe in. Eventually, a company will have someone who harnesses your energy and helps you develop as an employee, destined for great things.
If that doesn’t sound like your cup of tea, I have good news: There are plenty of mid-level Java developer positions available on Craigslist.
* Bryce and I now work together at Avalara, where he is the Chief Software Architect and I am a Data Scientist. True to the words above, he is working at the office at 1:45 AM and I’m on the last ferry from Seattle to Bainbridge Island to meet him to get some late-night work done.