How To Survive the Switch from Startup to Enterprise Dev

Untitled

There are many positives to doing development work in an enterprise computing environment: top-dollar, state-of-the-art systems; scaling and performance requirements that will exercise every bit of your CS knowledge; complex integrations with systems of all varieties; and ample opportunity to expand your skills and toolset. Not to mention a decent paycheck that arrives like clockwork. Your break room might lack a foosball table, but there’s also very little chance that your CEO will ask if you’d mind having your next check denominated in Bratz Online Blingz rather than dollars to help the company through a temporary liquidity crisis.

Still, for all of that, the enterprise can also be an extraordinarily frustrating environment for any developer who feels passionate about the outcome of his or her efforts, and believes that the art and craft of programming is as essential to success as solid software engineering. Just as important, enterprises also pay a huge price for clinging to outmoded waterfall development practices.

At least, that’s what I discovered when I turned my back on startup hell and joined an enterprise crew nine years ago. I’ve always been driven to make every application I code perfectly fit the needs, workflows, and goals of its users and business owners – my customers. For me, that was easy to do in a startup situation where I was able to communicate directly with my customers on a daily basis, invent freely, and use every tool in my arsenal to meet their goals. It’s considerably tougher in the enterprise, where there are interminable budgeting and approval processes, mountains of immutable requirements carved into stone by eight levels of management, and legions of business analysts, project managers, release managers, compliance auditors, and security analysts standing between you and your customer.

It’s all about change

What I’ve come to realize is that my job – and that of any developer – is all about change. A given project’s identified goal might be to improve capital efficiencies, or to enhance the user experience, or to integrate three systems that have never been on speaking terms – it doesn’t really matter. None of those goals can be achieved without change. And that introduces another challenging dynamic into the process, because while the project team can’t succeed without bringing about change, the infrastructure, processes and groups that govern enterprise development are often oriented towards slowing and minimizing change.

So yes, the enterprise computing environment can impose a few obstacles to success–barriers that can not only frustrate developers but have a significant impact on the enterprise itself, dramatically slowing software development, delaying product rollouts, adding costs, and encouraging the most passionate developers to head for the exit.

It doesn’t have to be that way. No obstacle is insurmountable, and just as the challenge of climbing Mount Everest makes the the view from its summit even more magnificent, overcoming enterprise inertia makes the taste of success all the more sweet when you finally achieve it.

No simple solutions

I’d love to be able to share my numbered list of 10 Keys to Happiness and Success in Enterprise Development, but it’s not that simple. Every organization is different, every project is different, and every developer’s definitions of success and happiness are highly variable.

What I can say is that you can’t expect enterprise success until you recognize that your real job is to bring about change and acknowledge that process likely places you in opposition to powerful change-adverse forces in the company.

You need to find and adopt a strategy that will allow you to succeed despite that opposition.
I like to use a basketball metaphor: Imagine you’re a 5’10” point guard, and there are three imposing seven-footers between you and the basket. You’re not going to be able to just bludgeon your way through the opposition. You need to work the seams.

To gain a better understanding of your organization’s real needs, try putting the requirements document aside for a moment in favor of actually talking to the people involved:

    • Look for what’s broken and push to fix it.
    • Look for what can be improved and push to improve it.
    • Look for problems that haven’t been identified or can’t be solved within the organization’s default contextual framework, and propose solutions for them.
    • And while you’re at it, identify the people who will listen to your ideas and have the power to do something about them.

Changing real-world organizations

When I joined my current employer, for example, all our development work was based on a J2EE stack so complex that it could take six months for a newly hired mid-range developer to begin to grasp it. I took that issue to our enterprise architecture group – the owners of our technology roadmap – and pointed out that our backlog was overflowing with small projects that didn’t need that complexity. Within weeks, I was leading a newly formed Ruby on Rails team, knocking out projects from the backlog as fast as we could, establishing Ruby as a legitimate platform within the organization, and freeing myself from having work with that damned J2EE stack.

Another example of working the seams: Three years ago, faced with the apparent inevitability that we would end up replacing our existing, horrifically bad enterprise content management system with an equally awful ECM from another enterprise software vendor, I wrangled management permission to spend a couple of months prototyping an internally developed content management system that I’d been sketching out. Thus was born a small skunkworks project that ultimately emerged as the replacement for the old ECM. Nobody in the organization was asking the development group to solve the content management problem. But we saw the need, and we took the initiative to address it, resulting in all the good things: Change. Success. Even happiness.

Your path to happiness as an enterprise developer is unlikely to exactly mirror mine. But the thought processes I went through might help you blaze your own path:

  1. First, decide what you would do if you were running a small agile startup and recognized the same problems you see in your enterprise organization.
  2. Then, take the steps required to address them as if none of the enterprise’s obstacles to success existed.

The worst possible outcome is you won’t be staying at a job that would have frustrated you as long as you held it. Every other outcome leads to a much brighter future for both you and your employer. For me, it was worth a shot no matter how long the odds.

*Businessmen image courtesy of Shutterstock.com.

Paul Bonner is a reformed technical journalist who reinvented himself as a web developer during the dot-com boom and hasn't looked back since. While his professional work centers around Ruby development, he's full of opinions about every aspect of web- and mobile-development. He lives in Austin, TX. View posts by .

Interested in writing for New Relic Blog? Send us a pitch!