Embracing change

It’s a month past due so here is my obligatory “I changed my job” post.

Over the last nearly 8 years at Comcast as part of the ‘Online’ group and later as founding member of mighty Comcast Interactive Media I’ve made many business connections, met a number of excellent peers and forged a few relationships that will last a lifetime.

As a happily married 40+ dad with mortgage and college payments I often feel over the hill with regards to blogging and living out loud. As a Manager with a sometimes disproportional ego I also felt an obligation to ‘disappear’ for some time in order to give @tomjbarker room to make the team his own. I’ve no doubt that he will take what we started to the next level.

When I joined Comcast we had acquired a portal using technology from the last millennium (JSP, coded like it was 1999). It was hosted by a company we competed with and after 3 months I gave up trying to get a stable build from the source code. We merged with a development team who hired java test writers because ‘real’ developers don’t waste time writing unit tests. 2 key executives took this mess and in what I have to call a ‘visionary’ move decided to craft a ‘web development’ culture within Comcast. I’ll always be indebted to Sam Schwartz for doing whatever he did to convince Comcast that splitting off a wholly owned subsidiary as a web shop would be a good idea. That gave us the opportunity and Charlie Herrin was the one whose personality and direction shaped our day to day work.

The early days were exciting and we took an empty room and filled it with whirring servers powering a living architecture that grew up to power xfinity.com and xfinityTV.comcast.net (The architecture we used was this new thing called REST wrapping a key based XML document store). We took a team who didn’t understand testing in an untestable environment to a group passionate around TDD.  We introduced Java/Oracle biased executives to the wonders of S3, Node and Rails. Code bases with 0 tests now have thousands of meaningful ones. We went from developers oncall 24/7 and my phone ringing 3 nights a week to me sitting in the park with my kids as the software absorbed feed failures and gracefully degraded.

I was the architect (along with @kmartino) and a primary coder of the software stack and trained a team to support it. That team has surpassed me in every way as coders.  The level of individual talent is staggering.  A CIM jr engineer would be a Sr at any other company in Philly.

The business models of CIM were fairly mature and the products were very much in an incremental growth phase.

At this point I got a call from a headhunter looking for someone to lead a development team for an Energy company.  I was skeptical because I didn’t really get the new competitive energy market and didn’t really trust the companies selling it.  When I met some of the marketing folk they hooked with me with a simple pitch.  Nobody really knows how to market energy and Energy Plus is going to figure it out.  They have a business team that is incredibly agile and data driven with not an ego driven decision in sight.

As a new company they had much of their infrastructure built by waves of vendors who made a hash of their codebase.  They have made a real investment in IT to make us part of their competitive advantage and I’m looking forward to the challenges.  Right now companies build a plant and sell energy, in the future they will have to market it.  Much like Comcast formed CIM to figure out how to do web development, Energy Plus was acquired by NRG in order to figure out how to market energy.

They are doing business iterations and retrospectives in order to invest in what works and adjust what is not optimal.

Nothing hammered how good they are  into my head as much as my first meeting with our finance team.  They were asking for development help for some statistics they were compiling.  I’d heard they were trying to use python to download some data and analyze it in excel.  I walked in thinking I’m the big python expert and with a passing knowledge of ‘R‘ was going to be able to help them. They described the flow of downloading, parsing, processing, analyzing and explained it was a manual process done daily.  I asked how long it takes them thinking I’m about to save some poor human hours a day.  They said about 1omin since its all scripted.  They just have to run a batch file.  Wow, I know developers that don’t take time to automate like this.  The downloading is solid python analyzing is hardcore R.  They are professional enough to come to me to ‘operationalize’ this as the next step.  There really are no ‘B’ players here and when someone on the business side asks me for ‘help’ it is for real.

So in short the only thing keeping us from being fully agile is engineering, which means the only barrier to agile is ME getting it done.

And for this story I have no blockers 😉


Comments are closed.