One of the distinctive qualities of the high-tech industry is that the people who make technology love technology. They love its powerful capabilities, its potential, and the opportunity it provides for creativity.

But that love can also overflow and drown out little details like business plans and common sense. In the past several years, technological advances leapfrogged over real-world needs.

As a result, a lot of companies and highly creative, motivated engineers expended a tremendous amount of time, effort, and money creating "killer apps" that had no real problems to solve.

A typical example of this is a company that developed a supply chain application for the apparel industry. What the developers failed to realize is that the apparel industry at the time was running quite nicely via fax and paper.

Many of the intended customers for this high-tech application are small companies run by non-English-speaking people. For this application to work in the real world, its developers needed to convince everyone in the industry to (1) decide on a common language, and (2) buy into ­ and learn ­ one system. Guess what. It didn't happen.

It was once easy to find talented engineers to buy into these pie-in-the-sky enterprises, with the lure of untold billions once the product hit the street. But a lot of the senior engineers we talk to today now have a different set of priorities. They no longer ask, "How much stock are they offering and when is the IPO?"

Today's top engineers are no longer interested in building technology for its own sake; they want to build something that will solve real problems. Many of them tell us that they became engineers to make something useful. However, after months or years of hard work, many have found they've created something that's useless.

Chris has been a software architect for the past 10 years. His professional experience spans both startup and major corporate environments. For the past year and a half, he's worked at a major "household name" software company where teams of up to 50 engineers build his software applications.

"People who write software are creative," he says. "But on a large software project with teams of 10 or 20 people, not everyone can create their own error-handling mechanism.

"Lots of engineers come into a major project and think they can do it better, so they go off and do their own thing," says Chris. "The architectural discipline is important. There are lots of aspects that go into the product."

In his experience, many engineers lack the ability to follow an architectural guideline. He attributes this problem to the current focus of software engineering education.

"They spend a lot of time teaching programming languages, so everyone focuses on coding," he says. "But almost no one who's come out of school recently knows what it means to build a product or understands the value of architecture."

Recent engineering graduates entering the corporate world have an understandable need to prove themselves. According to Chris, many of them try to establish themselves by doing things their own way, trying to prove that they can do it better, faster.

"The startup culture encouraged that approach," he says. "Many had very loose, creative environments with people becoming heroes by working 24 hours straight over the weekend."

That culture also nurtured the attitude of "let's make it and then see if it works," which is the complete opposite of what's required when a major company sets out to design and build a product.

Many of these creative, lone-gun engineering heroes now have difficulty working in a collaborate environment, on a specific piece of a very large puzzle.

"From the company's viewpoint it creates issues," he says. "All engineers on the team need to be clear on the product and the architecture. They need to know the technology and the alternatives, to understand the whole product, not just one part of it."

Chris observes that with the startup boom behind us, the interview process has become more effective ­ to a point. "People are looking for very specific skillsets now; they're not just hiring anyone who's available."

Yet the hiring process doesn't always screen out candidates who may be temperamentally unsuited for a large-scale project when the interview consists only of a candidate talking with a couple of people for two hours.

Many of the major companies have implemented more comprehensive, rigorous hiring processes to screen candidates not only for skillsets and technical expertise, but for their ability to work effectively in a team.

Because when creating major products to solve real-world problems, there's a lot more required than creativity ­ and heroism.

E-mail us your feedback. We're always interested in hearing from you.