At GE Capital, the business is focused not simply on providing financial
services to mid-market companies but also selling the company's industrial
expertise. They might help franchisees figure how to reduce power consumption or
aid aircraft companies with their operational problems. "It's our big
differentiator," says GE Capital CTO Eric Reed. "It makes us sticky."
And within IT, Reed is looking not for the best Java programmer in the world or an ace C# developer. He wants IT professionals who know about the network and DevOps, business logic and user experience, coding and APIs.
IT Specialist Out, Full-Stack Engineer In
It's a shift for the IT group prompted by an exponential increase in the pace of business and technology change. "The market is changing so much faster than it was just two or five or, certainly, 10 years ago," says Reed. "That changes the way we think about delivering solutions to the business and how we invest in the near- and long-term. We have to think about how we move quickly. How we try things and iterate fast."
But agility is a tall order when supporting a $44.1 billion company with more than 60,000 employees in 65 countries around the world. "There are several markets we play in, and we can't be big and slow," says Reed. "But the question is how to we make ourselves agile as a company our size."
Like many traditional IT organizations, GE Captial had one group that developed and managed applications and another that designed and managed infrastructure. Over time, both groups had done a great deal of outsourcing. It wasn't an organizational structure designed for speed.
An engineer by training, Reed saw an opportunity to apply the new product introduction (NPI) process developed at GE a couple of decades ago to the world of IT development. Years ago, a GE engineer might split his or her time between supporting a plant, providing customer service, and developing a new product. With NPI, we turned that on its ear and said you're going to focus only on this new product," explains Reed. "You take people with different areas of expertise and you give them one focus."
That's what Reed did with IT. "We take folks that might do five different things in the course of the day and focus them on one task -- with the added twist being that you can't be someone who just writes code," says Reed.
A New Type of IT Team Forms
Last year, Reed pulled together the first such team to develop a mobile fleet management system for GE Capital's Nordic region. He assembled a diverse group of 20, who had previously specialized in networking, computing, storage, application, or middleware, to work together virtually. He convinced all of the company's CIOs to share their employees. They remained in their initial locations with their existing reporting relationships, but for six months all of their other duties were stripped away. "The CIOs had to get their heads around that," Reed says
The team was given some quick training in automation and given three tasks: develop the application quickly, figure out how to automate the infrastructure, and figure out how to automate more of the application deployment and testing in order to marry DevOps with continuous application delivery.
There were no rules -- or roles. "We threw them together and said, 'You figure it out,'" Reed recalls. "We found some people knew a lot more than their roles indicated, and the lines began blurring between responsibilities." Some folks were strong in certain areas and shared their expertise with others. Traditional infrastructure professionals had some middleware and coding understanding. "They didn't have to be experts in everything, but they had a working knowledge," Reed says.
The biggest challenge was learning to be comfortable with making mistakes. "GE has built a reputation around execution," says Reed. "My boss [global CIO of GE Capital] and I had to figure out how to foster an environment were people take risks even though it might not work out."
Project Success
The project not only proceeded quickly -- the application was delivered within several months -- it established some new IT processes. They increased the amount of automation possible not only at the infrastructure level, but within the application layer at well. They also aimed for 60 to 70 percent reusability in developing the application, creating "lego-like" building blocks that can be recycled for future projects.
Business customers welcomed the new approach. In the past, "they would shoehorn as many requirements into the initial spec as possible because they didn't know when they'd ever have the chance again," says Reed. "Now it's a more agile process." The team launches a minimum viable solution and delivers new features over time.
For IT, "it was a radical change in thinking," says Reed. "We've operated the same way literally for decades. There were moments of sheer terror." And it wasn't for everyone. Some opted out of the project and went back to their day jobs.
But Reed is eager to apply the process to future projects and rethink the way some legacy systems are built and managed. "We had talked about services-oriented architecture, and now we have something tangible that shows it can be done," Reed says. "On the legacy side, we have to decide if we want to automate more of that infrastructure and keep application development the old way or invest in this."
Some employees remained with the fleet management app team. Others started a new project. And a few went back to their original roles. "We're trying to make disciples so more people can learn about this process," Reed says.
Reed can envision the IT organization changing eventually. "What we look for in people when we hire them will change. There were years when we went out in search of very technical people. Then there were years of outsourcing where we sought people who could manage vendors and projects," Reed says. "Now we need both, and we need to figure out how to keep them incentivized."
And within IT, Reed is looking not for the best Java programmer in the world or an ace C# developer. He wants IT professionals who know about the network and DevOps, business logic and user experience, coding and APIs.
IT Specialist Out, Full-Stack Engineer In
It's a shift for the IT group prompted by an exponential increase in the pace of business and technology change. "The market is changing so much faster than it was just two or five or, certainly, 10 years ago," says Reed. "That changes the way we think about delivering solutions to the business and how we invest in the near- and long-term. We have to think about how we move quickly. How we try things and iterate fast."
But agility is a tall order when supporting a $44.1 billion company with more than 60,000 employees in 65 countries around the world. "There are several markets we play in, and we can't be big and slow," says Reed. "But the question is how to we make ourselves agile as a company our size."
Like many traditional IT organizations, GE Captial had one group that developed and managed applications and another that designed and managed infrastructure. Over time, both groups had done a great deal of outsourcing. It wasn't an organizational structure designed for speed.
An engineer by training, Reed saw an opportunity to apply the new product introduction (NPI) process developed at GE a couple of decades ago to the world of IT development. Years ago, a GE engineer might split his or her time between supporting a plant, providing customer service, and developing a new product. With NPI, we turned that on its ear and said you're going to focus only on this new product," explains Reed. "You take people with different areas of expertise and you give them one focus."
That's what Reed did with IT. "We take folks that might do five different things in the course of the day and focus them on one task -- with the added twist being that you can't be someone who just writes code," says Reed.
A New Type of IT Team Forms
Last year, Reed pulled together the first such team to develop a mobile fleet management system for GE Capital's Nordic region. He assembled a diverse group of 20, who had previously specialized in networking, computing, storage, application, or middleware, to work together virtually. He convinced all of the company's CIOs to share their employees. They remained in their initial locations with their existing reporting relationships, but for six months all of their other duties were stripped away. "The CIOs had to get their heads around that," Reed says
The team was given some quick training in automation and given three tasks: develop the application quickly, figure out how to automate the infrastructure, and figure out how to automate more of the application deployment and testing in order to marry DevOps with continuous application delivery.
There were no rules -- or roles. "We threw them together and said, 'You figure it out,'" Reed recalls. "We found some people knew a lot more than their roles indicated, and the lines began blurring between responsibilities." Some folks were strong in certain areas and shared their expertise with others. Traditional infrastructure professionals had some middleware and coding understanding. "They didn't have to be experts in everything, but they had a working knowledge," Reed says.
The biggest challenge was learning to be comfortable with making mistakes. "GE has built a reputation around execution," says Reed. "My boss [global CIO of GE Capital] and I had to figure out how to foster an environment were people take risks even though it might not work out."
Project Success
The project not only proceeded quickly -- the application was delivered within several months -- it established some new IT processes. They increased the amount of automation possible not only at the infrastructure level, but within the application layer at well. They also aimed for 60 to 70 percent reusability in developing the application, creating "lego-like" building blocks that can be recycled for future projects.
Business customers welcomed the new approach. In the past, "they would shoehorn as many requirements into the initial spec as possible because they didn't know when they'd ever have the chance again," says Reed. "Now it's a more agile process." The team launches a minimum viable solution and delivers new features over time.
For IT, "it was a radical change in thinking," says Reed. "We've operated the same way literally for decades. There were moments of sheer terror." And it wasn't for everyone. Some opted out of the project and went back to their day jobs.
But Reed is eager to apply the process to future projects and rethink the way some legacy systems are built and managed. "We had talked about services-oriented architecture, and now we have something tangible that shows it can be done," Reed says. "On the legacy side, we have to decide if we want to automate more of that infrastructure and keep application development the old way or invest in this."
Some employees remained with the fleet management app team. Others started a new project. And a few went back to their original roles. "We're trying to make disciples so more people can learn about this process," Reed says.
Reed can envision the IT organization changing eventually. "What we look for in people when we hire them will change. There were years when we went out in search of very technical people. Then there were years of outsourcing where we sought people who could manage vendors and projects," Reed says. "Now we need both, and we need to figure out how to keep them incentivized."
