Changing the World
AOL is a hard place to work these days. Some of this is due to the fact that we are not growing as a company. Some is due to the stock price being flat for years. Some is due to uncertainty of knowing what will get us healthy and growing again. Don’t get me wrong, our CEO has laid out a strategy of moving content and customers to the web which makes sense and is consistent with our competition and the marketplace going to broadband.
But more than a strategy, it is the uncertainty that makes life at AOL difficult. And people just do not like uncertainty. People like to know what is happening, what is going to happen, and like to minimize changes overall. I don’t know why this is, but I know that I am as guilty as anyone in wanting things to stay the same at some basic human nature level. Not that everyone does not want to see the stock price change, but otherwise, people are just people and not always comfortable with change.
But AOL needs change. And closer to home, our technology organization needs change. Just about everyone in Tech Dev management (about 150 people more or less) agreed last week that on a scale of 1 to 10 (where 10 is major change needed) we were an 8. In other words, we do a few things right, but as an organization, we need to change significantly.
But what to change? Is the QAR process broken? Do we need better open APIs? Do we need more scaleable systems? Do we need to work better across teams on larger projects?
While I do not know all the things that need to change across an organization of several thousand people (and you won’t find a list in my next post) I do believe I know what needs to happen. What should happen is that each individual should be looking introspectively to determine what they can change in themselves. When people change something, others notice and it can quickly become contagious. Setting an example is a powerful weapon and it can start anywhere.
- It could be as insignificant as treating co-workers in other teams with respect no matter what the pressure of the situation.
- It could be taking the time to recognize someone for a job well done, even if they are not in your team or management chain.
- It could be setting up a website to share information on a good book you read or conclusions from an offsite you attended.
The bottom line is that it is all of these things and so much more. But the most important thing is to not sit back and wait for someone else to do “it”. We are all leaders and when we work together to improve things, the effect can be orders of magnitude bigger than the individuals participating. Don’t be afraid of changing something in yourself.
What am I doing?
I intend to treat everyone I work with in my team and externally with the highest level of professionalism possible. I have gotten used to the blame game and quickness to point fingers “culture” we seem to live in all the time. I want to break out of this and set a better example.
4 Comments so far
Leave a reply
Aw this is misleading, I thought you’d go into what changes aol will make.
But discuss this also. AOL still has the whatever they touch it is bad disease. What do you do to make it more appealing? Make it technical for power users (to be modernized with the rest of the industry) Or make it simplified and easy (so grandma can use it.)
Good post Carl. Change, especially related to organizational behavior, is probably one of the hardest management challenges. As organizations grown, they usually become fat and slow to respond to change. For example, Microsoft in its heydays was the “Google” of its time. But now they have more org problems, dare I say, than AOL (there is an entire blog run by an anonymous employee devoted to making MS lean — it has a huge following and was mentioned in BusinessWeek as well: http://minimsft.blogspot.com/). Tech Dev (or the organization formerly known as Tech Dev) has its issues but I believe we’re moving in the right direction. But as you pointed out, the onus for making that transition successful rests with ALL of us, not just the execs. There certainly needs to be more dev2dev collaboration across teams. We still have that “silo” mentality and you’ll find lots of similar services being worked on by different teams *cough*CCS & FX*cough*. There is no reason why we can’t avoid this duplication of effort early on in the projects, consolidate the services and the team members who’re no longer needed on that service should focus on some other project — there is plenty of work that we need to deliver.
Carl, change starts at home. Your honest reflections really make me think (and re-think).
Trekker, agreed BIG TIME that overlap is tough - but let me ask you (and I mean this only in the spirit of discussion, so don’t read too much into it please :)): did you consider FX server (to use your example) before embarking on another path? And if so, what drove the thinking?
Remember, change starts at home.
In all honesty, the first I believe I had heard of the CCS was a month or so ago in a PS newletter.
We started FX server development in late 2004. It was esseentially something we needed to do to refactor our abuse systems into SOA-like services. Had we known another team was developing a similar system, I would have hoped we would do something to at least understand what they were doing, how it differed, and maybe even how we could make the roadmaps come together (if not eliminating the duplication at the start).
I am not sure if everyone agrees as to what direction we should pursue now, in terms of CCS and FX, but I believe we should consider the options. I do not believe the CCS guys have started their classification engine development quite yet and perhaps should consider what the FX Server can offer. If it can fit their needs, then it presents a good direction on a proven and fielded technology. If there are significant short comings in terms of meeting their customer’s requirements, then we need CCS to continue (and shame on us for not developing a platform with more diverse capabilities!).
I wonder what else we are doing that might be duplicative to other teams? Its almost like we need a product technology book/site. Ops did this not to long ago. It was not a hard thing to do.
On the other hand, we are reaching out on some projects. ENS is an example where we were/are proactive reaching out to PS as we are aware of their efforts to build a pub/sub infrastructure/bus. And we thought initially it would not suffice for our needs, but Lu assured us that they would be doing two different architectures…one for low volume, reliable and another for high volume, not guaranteed transport.
I think (hope) we have the right spirit on these things. I hope. But I certainly remain open and question myself and actions a lot.