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 company with $514 billion in assets with more than 50,000 employees in 55 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
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
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.”
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.”