Business Driven

During my most recent job search, I realized that I am a human being who considers the first criterion of a good company to be whether the company’s business is attractive. What I would do there was far down the list of priorities. I saw myself working incredibly hard to figure out how much money the company’s software was making and had the potential to make.

And I knew in the real world that I couldn’t introduce myself as a geek. I’ve met a lot of really cool developers in my career, and they’ve often wanted to solve more complex technical problems than I do now. I’ve also seen people leave companies because of technical issues rather than business problems or company financials, so I’m not geeky.

Business-driven development is about something bigger than convincing people to refactor when the company has to busily run on business. It’s about tapping into the unique nature of software development. Building a machine is about controlling complexity to produce something that does what you want it to do. The solutions and designs required to control this complexity are irreplaceably cool and fun, and there’s an incredible sense of accomplishment when you solve a problem.

This is why I’m tempted to take software that seems so sublime and virtuous at first glance and turn it into a vehicle that can extract all the value it can for the business. It doesn’t matter if it’s technically fancy. I want to build a strong, resilient machine that can meet all the requirements and deliver value to the business and its users while remaining above average.

I recently worked on creating our web front-end framework to power our company’s products and replace our entire product with it. One of the personal goals I set for myself during the process was to “make the developer experience just a little better than tolerable.” I wanted to make sure that this framework’s developer experience was just a bit better than the level where fellow developers using it would say, “I can’t believe I’m doing this.”

This is a very painful decision on a personal level because I’m an engineer who likes and has a firm taste for high-quality developer experiences. I believe that one of the biggest pleasures of a development platform organization is the ability to elevate your peers’ development experiences, which elevates your work experience.

Every day, it pains me to put up with a terrible developer experience for the framework I contributed and move on to solve other business problems. It’s painful to see my fellow developers struggle with things they shouldn’t have to and go through routines they shouldn’t have to because it’s not 100% optimized. But the framework doesn’t yet accommodate all the business requirements from each line of business, so we need to make it do that first, and DX can be improved in the spare time. That’s right.

It’s not a car with an excellent structure, and you can go, “Boom!!! I built this!!!” I want to make a car that can go really fast, and I want to make a car that can go really fast, and it can hit a wall, and it can go up in the air, and another car can hit it from the side, and it can still maintain its speed and still look the same.

I want to build a car that someone requests, “Wouldn’t it be cool if we put a car on a car and made a King Goddard General?” or “Can we put a dishwasher on a car?” and my fellow makers, who are making good business decisions, will all say “Yes!!!!” I want to build a car that screams, “Yes!” I want to do appropriate engineering that fits a rapidly growing business. I’m excited because it’s hard, and so much to learn.