Curiosity and fix-it traits fostered CTO's career

Find out how one CTO's natural drive to make things work has energized him for the demands of his role at a start-up company, and how he manages to make room for the nonwork part of his life.

When Mike Gilger says he’s curious about everything—from computers to biological reactions—he’s serious. The proof is a home library of at least 1,000 books. The TechRepublic member, currently the CTO of Identitech Inc., loves applying his knowledge to hands-on projects, from restoring an old RV to fixing Edison record players and digital video editing. His fix-it enthusiasm has helped the 42-year-old throughout his IT career.

Like many tech leaders who advance within the IT ranks, the Palo Alto, CA, native has seen his share of 14-hour days. Today he strives to balance his work and home life. Serving as a CTO also requires another balancing act—integrating his roles as technologist, communicator, and leader.

And although IT wasn’t Gilger’s initial career choice, it has been a perfect fit.
Vital statistics

Name: aMike Gilger
Title: aCTO
Company: aIdentitech
Years in IT: a20
Age: a42

Most memorable job: aDeveloping an IBM version of signature-verification software
Education: aBachelor of science in Computer Engineering, University of Florida
Favorite support sites: a TechRepublic,,
Hobbies: aFixing, restoring, and building things. Currently restoring an old RV.
Favorite TV show: a Farscape on the SCI FI Channel
Family: aHis wife Cheryl, and two children, Mikey and Katelyn

IT beginnings
TechRepublic: When did you first become interested in IT?
My first experience in programming was during an intro to computers college class while in the Air Force. The Air Force let the school use some of their computer equipment—an HP 1000, to be exact. I wrote a Pascal program that had about 12 lines and tried to compile it. And, 297 errors later, I found that I left off one semicolon! Fortunately, compliers have vastly improved since then. Although I found that I had a knack for computers and programming while taking these classes, I still wasn't going to make a career out of computers.

TechRepublic: What made you change your mind about making a career in the field?
My father was a mechanical engineer, and I love working on mechanical things, so after I got out of the Air Force, I continued my degree work in mechanical engineering. My dean was a bit closed-minded. During a session with him when I was approving my next term’s classes, I told him I wanted to take computer courses to help apply computers to the field of engineering. His response, "Computers and engineering don't mix," just about knocked me over. Not being too satisfied with that response, I went to a newly formed department on campus—computer engineering. When I told them I wanted to take several engineering courses with the computer courses, they replied, “That’s just what we want our students to do!"
So I walked over to the dean of the mechanical engineering department, asked him for my paperwork, and changed my career field right there on the spot.
I think the dean’s close-mindedness did me a great favor. Because I don't often accept that "it can't be done" or “it just isn't done,” I go to great lengths to prove otherwise—with much success.

TechRepublic: What was your first IT job?
My first position out of school was working on building software for a video switching company. I came in with both a hardware and software engineering background and worked side-by-side with analog hardware engineers writing code for the system. Again, someone mentioned that software couldn't be made to perform certain video control functions, and I quickly proved otherwise. The processing power of the 8086 they were using as the heart of the machine was a bit limited, so I would write the pseudo code, then write the code in assembler three different ways, and count clock cycles to determine the fastest way to perform functions. Talk about hand-optimization! Kids today are so spoiled with the optimizing compliers and performance-tuning monitors.
From there, I did consulting jobs in business applications and, as a sideline, custom-built computers for folks.

Meeting the challenges of innovation
TechRepublic: What’s your most memorable IT project?
In 1987, my brother had a great idea for a signature verification system—simply storing a scanned copy of a bank signature card along with the account number, and allowing a teller to visually display the signature at their workstation. He mocked it up on a Macintosh and sold it to a bank.
After he sold the first system, he started a new company called Identitech, Inc. Then he asked me to develop the software on an IBM, using our own database design to store the account numbers and signatures, our own compression algorithms to keep the image size down, our own wide-area network based on serial communication links, and our own display drivers for the then-brand-new VGA 640 X 480 video system. Plus, the system needed custom scanner drivers with extraction routines for defining the signature area, and a central signature distribution server.
He also wanted this all up and running in six weeks.
It sounded like a good challenge, so I did it. We tested the network by going back and forth between offices in our complex to use different phone numbers for the wide-area network. The system worked great, but the GUI was a bit difficult to use. We improved the GUI in the next upgrade, which took six weeks to create.
During the process, I learned a great lesson. You can do amazing things in short amounts of time when you are creating a brand-new product, but as soon as you have a customer base, the time to develop additions grows as fast as the customer base grows.

TechRepublic: Has Identitech branched out from its signature validation system?
The company has since developed imaging systems, document management systems, and one of the first fully integrated from-the-ground-up imaging, document management, workflow, electronic forms, and middleware application framework.

Beyond the trenches
TechRepublic: How have you made the transition to executive-level IT?
Slowly. I've made mistakes along the way, most dealing with the people side. One of the biggest mistakes is expecting everybody to do their jobs, and to do it with the same enthusiasm and drive as you do. Everybody is different, and I had to learn how to work with them and find their strengths and talents, as well as overlook or rechannel their weaknesses.
I am a good communicator, and found that skill to be quite handy at resolving issues and expressing the company vision. Many times, I’ve found that I didn't use those skills enough, and made assumptions that people understood when in fact they didn't.
One of the most important things I’ve learned is to stop solving everybody's problem for them. As an engineer, my training is to solve problems. As a manager, this training is useful, as long as you don't do it for everybody else—especially your direct reports. Two things happen. First, they get lazy and expect you to do all of their thinking. Second, they resent it at the same time.
I used to feel that there was a distinct wall between the sales staff and the engineering staff. That was mainly because the sales staff was known to sell the software before its time. As a CTO, I had to learn that the sales team was an integral part of the organization, and that their unique talents could help me keep abreast of their accounts’ needs, and thus effect my decisions on long-term product planning.
Understanding that technology is not the only tool, but one of many tools, to solve a business problem has also helped me at the executive level. Some people say that the application of technology is more art than science. I disagree. Many of the problems I see in the software industry is that we don't apply best practices that have been learned in other engineering disciplines. Applying that great engineering problem-solving technique that you learned in college works with software as well.
Good engineering is finding a good solution for a problem, even if the solution is complex. Great engineering is finding a good, simple, and cost-effective solution for a problem.

TechRepublic: Are you still very involved with technology, or is your role more business focused?
Yes to both. To me, a CTO must be a jack-of-all-trades—part sales, part engineer, and part marketer—to effectively perform in this position. Business and people skills are important, but they must be balanced with technology skills. I don't mean programming skills when I mention technology, but more along the lines of understanding what technology exists, why it exists, how best to match technology to the business, and what options exist in a specific technology area. Basically, if the technology doesn't add value by increasing an organization's efficiency and/or profitability, then it is not the right technology.

Balance is key to success
TechRepublic: From engineering products for a start-up to becoming its CTO, you must put in serious overtime. How do you balance work and family life?
When I started to work for Identitech, I would work 14 to 16 hours a day, seven days a week. We were building the company, and we had to wear many hats. I didn't have children back then, and I am glad that I didn't. I can't bear to be away from the kids that much. I don't work those hours anymore. Having a great wife and kids changes your perspective on things. I have also found that as you mature, you find it easier to determine what is important, and how to find the balance between work and family.
Since I don't want to take time away from the family, I take it away from my sleep. I can do great work at 4:00 A.M., and found that when I first had to manage people, as well as still play a strong technical programming role, that the only nonmanager work time I had was between 5:00 A.M. and 8:00 A.M., before the fires started when people showed up to work.

TechRepublic: What's your advice for those who want to advance?
Gilger: Take courses and attend seminars in business and managing people. Treat it like any other engineering project: Research to determine the problem, build a plan, and implement it.
In the life of a CTO, there will always be change requirements, personnel, knowledge, talent, as well as technology. You will do well to keep up and adapt to these changes as they occur, and they will occur.
Success depends on your alignment with the business needs. CTOs must understand the business, support the various initiatives, and help apply technology where it can provide a competitive advantage, increase productivity, and/or lower the cost of doing business.
CTOs are part technologist, part communicator, and part evangelist. All are necessary traits to influence and sell ideas and visions into the company. If you are negative, closed-minded, inflexible, or can't think outside of the box, then keep your current job.

Editor's Picks