As a maker of aircraft engines and power plant turbines, it's a good thing that General Electric engineers get risk reduction engrained into their DNA from the first day on the job. The downside: How does a company like GE learn to develop products faster in such an environment? How does IT experiment with cutting-edge tech without cutting corners?

GE CIO Jim Fowler addressed this tension between speed and risk management at the InformationWeek Conference in April. A major reason GE opened a large software development center in San Ramon, Calif., in 2013 was to create a culture more aligned with developing products faster, he said.

[Technology is great if you know how to use it. Read Internet of Things Done Wrong Stifles Innovation.]

"If you're an engineer at GE you learn about quality from day one, and you learn about process rigor and control, and unfortunately sometimes the process rigor and control get in the way of speed," Fowler said. (See video excerpt below.) Fowler was CIO of GE Power & Water at the time; he has since been named CIO of GE Capital.

{videoembed|1279055}

GE is trying to take some of the tactics used in the San Ramon center (which now employs more than 700 people) and apply them to the rest of GE, without sacrificing the quality and controls essential to the company's products. Those tactics can include relying on 10-person dev teams instead of 100- to 150-person teams, and focusing on 30-day outcomes instead of three-year timeframes. CEO Jeffrey Immelt refers to this idea of embracing new tactics and innovation as "Fast Works."

Netflix's developers think they can turn the speed vs. risk management dilemma on its head: Add new features more often to the company's web-based video streaming service while lowering the risk of downtime at the same time. Adrian Cockcroft, former Netflix cloud architect and current Battery Ventures technology fellow, described the process at the InformationWeek Conference. (See video excerpts below.)

{videoembed|1279053}

{videoembed|1279052}

Netflix removed the multiple stages and departments required to deploy a software change to the production environment. "There's no 'meeting with Ops' to put a feature in production," Cockcroft said. New software relies on APIs that deliver about 600 different micro-services, so a new feature relies on very little new code, he said.

The reasoning: By making small changes to the live production environment very often, the rate of change increases but the risk decreases, because only a small part of the system is impaired if the code is flawed, so the required fix is quick and easy. "It's much easier to switch one thing back if it breaks," said Cockcroft. He compared that approach to a conventional big-bang software release process, with 100 software changes bundled together so that if one element breaks, "you end up backing out 99 things that didn't break."

Our InformationWeek Elite 100 issue -- our 26th ranking of technology innovators -- shines a spotlight on businesses that are succeeding because of their digital strategies. We take a close at look at the top five companies in this year's ranking and the eight winners of our Business Innovation awards, and offer 20 great ideas that you can use in your company. We also provide a ranked list of our Elite 100 innovators. Read our InformationWeek Elite 100 issue today.