I've been at AOL for four and a half years now. When I started in this job, I had no expectation of staying for any length of time; my longest prior employment was just over two years. I wasn't intentionally bouncing around or anything, I just hadn't found the right thing yet.
By AOL standards, I'm a newbie. There are more people who've been there longer than I have than have joined since I did, or at least it seems from my vantage point at the bottom of the well. Being that the employee demographics tend to skew under-40, that means a lot of folks have spent most of their careers at AOL.
There's nothing inherently wrong with sticking around when you have a good thing going. And AOL can be a lot of things to a lot of people. There have been opportunities for technical training, academics and schooling, moving to management, some number of ex-pat assignments, and various other doors for interested parties to open. Or, if you prefer, AOL will allow you to sit in the corner and only do the minimum amount required to not make your teammates' lives a living hell. Your choice, and it's largely up to you to ask for what you want.
One thing AOL has always traditionally been is a home-grown shop. There's a reason for that; when AOL put up the systems and infrastructure that run the products, there were few options for COTS software to solve the necessary problems. Over the years, many of these systems haven't matured, they've simply aged. Reinvestment and refresh is key to keeping up, let alone getting ahead, and many systems at AOL just weren't getting the time and resources needed to stay modern. So, too, the employees tasked with taking care of those systems.
I spent three years running systems based on AOLserver with some proprietary modules baked in. When I got some of the first projects transferred over to me, I was pissed. What the hell was I going to get out of running crappy AOLserver with some half-baked, proprietary extensions in it?!?
There were some number of learning experiences to be had; AOL still managed to run some gigantic sites on AOLserver, regardless of how infuriating it can be, and the lack of new builds, and the politics of the publishing department in 2006.
However.
It's not the proprietary aspects of the projects that make a job into a career, its the ancilliary topics that are transferrable to new platforms that give you an edge when it's time to move on. I don't expect anyone to hire me for my AOLserver knowledge, and I wouldn't want them to.
But step back, and look at the project you're working on. Would you be able to take that project and run it somewhere else? Somewhere that doesn't have whatever random tool XYZ that you rely on at company ABC? What would you do, even if you stayed at ABC, and all the people who knew the inner workings of XYZ quit? (it's more likely than you think) Do you know enough about your tools and platforms, and what they give you, to go looking for a replacement?
It's a hard question to look at objectively. It takes some truth-finding and self-awareness to look at what you do and address your weaknesses from an environmentally-agnostic point of view. Can you look at whatever you're working on, and say "We're using Weblogic. We know we're dependent on feature A, feature B, and feature D. Feature C we only use a little bit. If we had to convert to another Java server, we'd need similar features" rather than "We have to use Weblogic because we've always used Weblogic and it's the only thing we know so you have to use it"?
Homegrown stuff has the added bonus of being horrific to teach to someone from outside the organization. Honestly, nothing looks stupider to a new employee than a gigantic infrastructure built around a central system that could be replaced with some well-chosen OSS package. Inbreeding happens in technology. Without a reason to go looking for a new solution, old projects will sit and fester, becoming more and more expensive year after year. New projects will look like the old ones. They'll all be susceptible to the same health issues, as modern demands outstrip what the old systems can provide. The incumbent employees are caught up in the status quo, and any dissatisfaction on the part of a newcomer is simply chalked up to not understanding just how awesome the homegrown system is.
If only.
If Wal-Mart suddenly became a software dev shop it might have enough employees to match the number of people looking at and working on open source software projects every day.
Your engineering team is likely much smaller than that. What are you missing out on that someone else in another part of the world has thought about? You don't even know. Your proprietary platform becomes an anchor instead of the solid foundation you told yourself it was.
By AOL standards, I'm a newbie. There are more people who've been there longer than I have than have joined since I did, or at least it seems from my vantage point at the bottom of the well. Being that the employee demographics tend to skew under-40, that means a lot of folks have spent most of their careers at AOL.
There's nothing inherently wrong with sticking around when you have a good thing going. And AOL can be a lot of things to a lot of people. There have been opportunities for technical training, academics and schooling, moving to management, some number of ex-pat assignments, and various other doors for interested parties to open. Or, if you prefer, AOL will allow you to sit in the corner and only do the minimum amount required to not make your teammates' lives a living hell. Your choice, and it's largely up to you to ask for what you want.
One thing AOL has always traditionally been is a home-grown shop. There's a reason for that; when AOL put up the systems and infrastructure that run the products, there were few options for COTS software to solve the necessary problems. Over the years, many of these systems haven't matured, they've simply aged. Reinvestment and refresh is key to keeping up, let alone getting ahead, and many systems at AOL just weren't getting the time and resources needed to stay modern. So, too, the employees tasked with taking care of those systems.
I spent three years running systems based on AOLserver with some proprietary modules baked in. When I got some of the first projects transferred over to me, I was pissed. What the hell was I going to get out of running crappy AOLserver with some half-baked, proprietary extensions in it?!?
There were some number of learning experiences to be had; AOL still managed to run some gigantic sites on AOLserver, regardless of how infuriating it can be, and the lack of new builds, and the politics of the publishing department in 2006.
However.
It's not the proprietary aspects of the projects that make a job into a career, its the ancilliary topics that are transferrable to new platforms that give you an edge when it's time to move on. I don't expect anyone to hire me for my AOLserver knowledge, and I wouldn't want them to.
But step back, and look at the project you're working on. Would you be able to take that project and run it somewhere else? Somewhere that doesn't have whatever random tool XYZ that you rely on at company ABC? What would you do, even if you stayed at ABC, and all the people who knew the inner workings of XYZ quit? (it's more likely than you think) Do you know enough about your tools and platforms, and what they give you, to go looking for a replacement?
It's a hard question to look at objectively. It takes some truth-finding and self-awareness to look at what you do and address your weaknesses from an environmentally-agnostic point of view. Can you look at whatever you're working on, and say "We're using Weblogic. We know we're dependent on feature A, feature B, and feature D. Feature C we only use a little bit. If we had to convert to another Java server, we'd need similar features" rather than "We have to use Weblogic because we've always used Weblogic and it's the only thing we know so you have to use it"?
Homegrown stuff has the added bonus of being horrific to teach to someone from outside the organization. Honestly, nothing looks stupider to a new employee than a gigantic infrastructure built around a central system that could be replaced with some well-chosen OSS package. Inbreeding happens in technology. Without a reason to go looking for a new solution, old projects will sit and fester, becoming more and more expensive year after year. New projects will look like the old ones. They'll all be susceptible to the same health issues, as modern demands outstrip what the old systems can provide. The incumbent employees are caught up in the status quo, and any dissatisfaction on the part of a newcomer is simply chalked up to not understanding just how awesome the homegrown system is.
If only.
If Wal-Mart suddenly became a software dev shop it might have enough employees to match the number of people looking at and working on open source software projects every day.
Your engineering team is likely much smaller than that. What are you missing out on that someone else in another part of the world has thought about? You don't even know. Your proprietary platform becomes an anchor instead of the solid foundation you told yourself it was.
