When I began my career in front-end development, I remember how excited I was when I contributed my first commit to the company’s Perforce repository. No task was too mundane, and whatever the management wanted went unquestioned in my backlog of tasks, waiting on my eager fingers to type out a quick and efficient solution. Deadlines, it turned out, were mostly unrealistic, usability was a secondhand thought, but I ignored all of these red flags. I was eager to prove my worth. I found myself, naive as I was, quickly falling into a trap of just doing the work. Just doing the work made the organization happy. It kept tickets moving through their Jira boards and gave my manager something to talk about, both to his boss and on up the chain. Project managers proudly displayed progress with pretty pie charts and line graphs. Executives gave great oratory in the quarterly meetings about what features were shipping and how much our customers were going to love them. And then something happened. The product I spent two years working on was abandoned. All the features I had worked on turned out to be features our customers didn’t care about. No one seemed to understand why. I was assigned to another team with a new backlog of features our customers were supposedly going to love. Features that were already proven successes because other companies were already using them or changed the game by inventing them. Any developer can tell you that they’ve seen this idea before. Your marketing department wants the biggest, baddest e-commerce system (because that’s what Nike is using!) even though your catalog has eight products. Maybe your content team looked at Medium’s commenting system and was suddenly, without warning, absolutely certain that duplicating Medium’s notes in your CMS is what you should be focused on in the next sprint. It’s like a child who sees another child playing with a new toy, and they want to play with that toy, too. They’ll insist that whatever feature they’re begging for is going to solve their problems because it solved Company X’s problems; it’s the hero their company needs.

What Happened to Users First?

Chasing features has never really worked out for any company. Once management decides that’s where the company is going to live, it’s pretty simple to start counting down to the moment that company will eventually die. When Medium's team set out to build a comment system, they questioned everything they knew about comments. I’ve personally seen 3–4 different iterations of this feature and it’s taken them a long time to get it right. But that’s the difference between chasing a feature and creating an experience. It seems like UX 101, but I still don’t know of many companies that do this right, and I have a lot of friends who work for tech companies. Creating an experience is more than just adding some feature you don’t already have. It means questioning everything you’ve done to this point, asking your users what works and what doesn’t work, and here’s the important part, iterating. It means solving the problems unique to your users and your platform. Everything else is a shortcut.

Chasing Features

This attitude of chasing features is cancerous, not just to creating an experience, but to everyday work activities. Deadlines are driving us towards mediocrity, not because deadlines are horrible (they’re not), but because companies tend to be unrealistic about them. Developers want to ship and deliver value to the people who are paying them, and if we have to put plywood on the back of the beautiful chest of drawers we built, we will. Can’t write tests because you don’t have time? No problem, ship it! Implemented a solution that has no shot in hell of ever scaling? We’ll cross that bridge when we get to it. Take Test Driven Development (TDD), for example. I’m not the only developer in the world who knows that TDD, as a theory, makes perfect sense. In practice, however, you need the company leadership investing, requiring and advocating for TDD throughout the entire organization. If you don’t have that kind of weight behind you, TDD is next to impossible. Shipping tests quickly becomes a secondary priority, if it’s a priority at all. As a lone developer, it’s crazy to even think of bucking against a monstrous organization structure. Maybe you’re surrounded by yes people and saying no sounds like you’re not a team player. It’s hard to be passionate and care about your work when everyone around you just wants their talking points and pie graphs and quarterly bonuses. So how do you find meaning in your work when the organization is stacked against you? How do you keep learning and growing and making things better, for both yourself and the company?

Be A Catalyst

I remember walking into a company that had every reason to employ a veritable army of front-end developers, only to discover that I was the only one. Congratulations! We’ve been looking to hire someone like you! Up to that point, all the front-end code had been written by C# developers. Things were so bad that I couldn’t commit a piece of CSS without breaking something somewhere in the UI. It. Was. Horrible. Every developer seems to have a war story about a horrendous code base that turned out to be death by a thousand cuts. It could be a code base that suffered side-effects from simple CSS updates (like I mentioned before), it could be a code base that has no test automation, it could be a thousand things; pick your favorite poison, we’ve been there. I had a choice to make on my first day of a new job. Buck against the system by prototyping a better idea and a better implementation or accept things as they were and then quit inside of two weeks. Being a catalyst is nothing more than applying "The Hacker Way" to yourself, whether you have the support or not. It’s taking the code into your own hands, building or applying tools to help you ship faster, and prototyping ideas. It’s not implementing a feature merely because someone saw it somewhere on another website and decided it would be brilliant to have it too; it’s being a catalyst for change, driven by users and for users. So how do you become a catalyst?

• Root-Cause the Issue Back to my earlier example of the horrible CSS codebase. When I found out I couldn’t commit CSS without headaches, I rewrote the entire front-end. There were dozens of ways I could have dealt with this problem, but I chose to rework the entire codebase because this particular solution solved future problems as well as current ones. If I didn’t care about Responsive Web Design or prepping the code to be more flexible and capable of handling the use-cases that future stakeholders might have, I could have just cleaned up a few things and called it a day. Don’t exacerbate the problem. Fix it.

• Prototype the Idea You don’t need permission for prototyping. Apply "The Hacker Way" to your development, knowing that code wins arguments. The opportunities for proving a better solution are everywhere around you, all you need to do is look for them. In fact, you probably already have some side project. The thing with side projects is that you never know where they can go. Maybe what you have is only meant to make your development life easier and maybe, just maybe, it has broader implications for the way your company creates an experience. You never know, but it starts with prototyping first.

• Get Support and Iterate Getting an idea from your desk to the broader organization means getting support. If you have your prototype, find a manager or a stakeholder and show them how your idea can solve their problems. Incorporate their feedback. Iterate. When it came to me presenting a new front-end framework, it took the help of my manager and then my team to cover all of our use cases and get it implemented. Most of the time, you’ll need a manager, a stakeholder or a team to bring your idea to fruition. Develop a coalition and get people talking. Your idea will grow from something small to something that takes on a life of its own.

Being a catalyst means you can be the hero your company needs. You can do more than finish a backlog. You can change things for the better in your organization. Maybe you’re thinking of another developer who is doing something like this right now. Help them! Is it always going to be easy? Of course not. Are you always going to get your idea from your desk to the broader organization? No. But the thing that makes you a catalyst is your willingness to try. It sounds so simple, and maybe it is, but the hard part is taking that risk. So take it. By embracing catalyst development, I’ve found that I derive more meaning from my work and that my happiness as a developer is less dependent on others. Maybe you will too. All we can do is try. (Thanks to Jack Margo and Vida Forrest for their feedback on this article, and to Jack again, for coining the term “Catalyst Developer.”)