-
The Blog
Current Post
The Blog
Feb 25, 2006
Two Teams Is Better Than One
by Maxim Porges @ 11:01 AM | Link | Feedback (7)
As if my last blog post wasn't enough, there was another surprise for the department.
Let me set the stage.
I had been in discussions with senior management for some time regarding the Lead Software Architect position. We had come to an agreement that the Project Manager of the Web Development Team (which I previously managed) would take over in my absence at the beginning of 2006. I would then return from two weeks of Christmas vacation, and would immediately begin my new responsibilities leading the technology transition. All was good.
Briefly. Oh, so briefly.
On my last day before I went on vacation, I was pulled in to our CIO's office and informed that one of our development team managers had tendered his resignation. This particular team builds the software for the Sales and Marketing end of our organization, which is arguably the fastest growing/changing part of the company.
This is also the part of the organization from whence I came. I started at CFI as a telemarketer. Since I couldn't sell a bucket of water to a man whose face was on fire, I worked my way through Reservations and Customer Service before ending up in IT as a Dialer System Technician. Once in IT, I rose through the ranks as a System Programmer, Web Programmer, Technical Lead, and finally ended up managing the Web Development Team.
And thus, it was felt that my intimate knowledge of the Sales and Marketing business unit would serve me well as the manager of the team that wrote their software.
While flattered and excited, I was somewhat distraught at the outcome. We'd just announced to the entire IT department that we would be moving toward a radical, aggressive new technology direction - something I was comfortable leading. But instead of being able to focus on that responsibility exclusively, my attention would now be divided with managing the most eclectic business unit in CFI.
The picture slowly became clearer. My anxiety subsided.
There was plenty of room for change in the software for the Sales and Marketing wing. As much as we had tried, we'd never quite hit the mark with regard to giving them the software applications that they wanted. A lot of the reasoning for this falls back on our old tools and lifecycle, and was only exacerbated by the fact that the Sales and Marketing division was a constantly (and rapidly) moving target.
The obvious plus side of this was that, with so much growth and change, Sales and Marketing would be the first division to need new software applications. New applications (or changes to the old ones) would create opportunities to use the new Java/Flex/RUP platforms. And who better to be closer to the action than the new Lead Software Architect?
So, I accepted - which involved rescheduling my vacation and working my ass off for the last seven weeks - but the dividends are already evident.
1) Some modifications to the structure of the team (suggested by existing team members) and the way we manage our business and our scheduling (suggested by me) have allowed us to increase our throughput without increasing our staff. This has created some windows for us to focus on new technology initiatives.
2) The team is comprised of a group of sharp developers, and business analysts who came directly from the business. The work ethic is strong; everybody takes responsibility for their work and their deadlines. As a team manager, you can't ask for anything more. Plus, we've got a number of open positions that will enable us to expand to 20 resources, and really start moving fast on our big project list.
3) Following some discussions with the other department managers, the decision was made to take our QA department and split it up so that each development team got their own dedicated QA resource. The benefits of this approach? Being able to schedule QA directly, and (over the long term) benefitting from having QA involved often and early in the development cycle, increasing the quality of the work - and thus the software product - across the board.
In my experience, change is rarely bad - but it's always a bit weird. However, I'm frankly amazed at what my team has been able to do with seven short weeks and a few small organizational changes.
Case in point: I announced to my boss this week that with my new team humming, I'm ready to start digging in to leading our technology transition as originally planned - and thrilled to be leading one of our strongest development teams along the way.
Let me set the stage.
I had been in discussions with senior management for some time regarding the Lead Software Architect position. We had come to an agreement that the Project Manager of the Web Development Team (which I previously managed) would take over in my absence at the beginning of 2006. I would then return from two weeks of Christmas vacation, and would immediately begin my new responsibilities leading the technology transition. All was good.
Briefly. Oh, so briefly.
On my last day before I went on vacation, I was pulled in to our CIO's office and informed that one of our development team managers had tendered his resignation. This particular team builds the software for the Sales and Marketing end of our organization, which is arguably the fastest growing/changing part of the company.
This is also the part of the organization from whence I came. I started at CFI as a telemarketer. Since I couldn't sell a bucket of water to a man whose face was on fire, I worked my way through Reservations and Customer Service before ending up in IT as a Dialer System Technician. Once in IT, I rose through the ranks as a System Programmer, Web Programmer, Technical Lead, and finally ended up managing the Web Development Team.
And thus, it was felt that my intimate knowledge of the Sales and Marketing business unit would serve me well as the manager of the team that wrote their software.
While flattered and excited, I was somewhat distraught at the outcome. We'd just announced to the entire IT department that we would be moving toward a radical, aggressive new technology direction - something I was comfortable leading. But instead of being able to focus on that responsibility exclusively, my attention would now be divided with managing the most eclectic business unit in CFI.
The picture slowly became clearer. My anxiety subsided.
There was plenty of room for change in the software for the Sales and Marketing wing. As much as we had tried, we'd never quite hit the mark with regard to giving them the software applications that they wanted. A lot of the reasoning for this falls back on our old tools and lifecycle, and was only exacerbated by the fact that the Sales and Marketing division was a constantly (and rapidly) moving target.
The obvious plus side of this was that, with so much growth and change, Sales and Marketing would be the first division to need new software applications. New applications (or changes to the old ones) would create opportunities to use the new Java/Flex/RUP platforms. And who better to be closer to the action than the new Lead Software Architect?
So, I accepted - which involved rescheduling my vacation and working my ass off for the last seven weeks - but the dividends are already evident.
1) Some modifications to the structure of the team (suggested by existing team members) and the way we manage our business and our scheduling (suggested by me) have allowed us to increase our throughput without increasing our staff. This has created some windows for us to focus on new technology initiatives.
2) The team is comprised of a group of sharp developers, and business analysts who came directly from the business. The work ethic is strong; everybody takes responsibility for their work and their deadlines. As a team manager, you can't ask for anything more. Plus, we've got a number of open positions that will enable us to expand to 20 resources, and really start moving fast on our big project list.
3) Following some discussions with the other department managers, the decision was made to take our QA department and split it up so that each development team got their own dedicated QA resource. The benefits of this approach? Being able to schedule QA directly, and (over the long term) benefitting from having QA involved often and early in the development cycle, increasing the quality of the work - and thus the software product - across the board.
In my experience, change is rarely bad - but it's always a bit weird. However, I'm frankly amazed at what my team has been able to do with seven short weeks and a few small organizational changes.
Case in point: I announced to my boss this week that with my new team humming, I'm ready to start digging in to leading our technology transition as originally planned - and thrilled to be leading one of our strongest development teams along the way.
