We caught up with the brilliant and insightful Graham Ross a few weeks ago and have shared our conversation below.
Alright, Graham thanks for taking the time to share your stories and insights with us today. Can you share an important lesson you learned in a prior job that’s helped you in your career afterwards?
In 1984, I was a hardware engineer on the Lockheed team that built the Hubble Space Telescope (HST). My responsibilities included technical oversight of the design and construction of the reaction wheel assemblies (RWAs) that pointed the HST (there are no thrusters). For redundancy, there were 4 RWAs pointed in different directions such that any 3 of the RWAs could provide complete 3-axis (X-Y-Z) control of the pointing direction of the HST. The HST guidance software calculated the x-y-z torque that needed to point the HST and then converted this to 4 separate commands using a 3×4 conversion table that was based on the physical arrangement of the RWAs.
Out of intellectual interest, I attempted to re-create the 3×4 conversion table from scratch based on the blueprints of the HST spacecraft. It should have been a simple calculation. My first attempt, however, produced a matrix with a “-1” in the Z axis, which is aligned with the telescope axis. This is a catastrophic error in a feedback control system as it would magnify any error instead of reducing it. In this case, it would cause the HST to spin out of control as soon as it was deployed by the Space Shuttle. I was frustrated and a bit embarrassed as this was a straightforward problem. I checked the blueprints and verified that I used the correct angles and repeated my calculation… and came up with the same “wrong” table.
I do not let pride stand in the way of getting things right, so I went to one of the guidance system engineers and asked him to check my work and find out where I had made a mistake. After about an hour, he came to my desk and told me that he could not find an error in my work. He took my calculations back to the software group and initiated a complete review of the guidance software. They discovered that there had been a design change many years earlier that physically moved the RWAs within the spacecraft structure but did not make the matching change in the software. Furthermore, the error had not been found in testing because the simulations that they used to test the software used the same table, a case of two “wrongs” producing what appeared to be a “right” result.
The first lesson of this adventure was that even the simplest design change may cause ripples that spread much farther and become much larger than are apparent at first glance. There 2 solutions to fix this error – (1) change a single number in the software or (2) build 4 long electrical extension cables that would weigh a total of 200 pounds and cost $50,000. While it was the work of 1 minute to change a single number in the software, it would require the project to repeat EVERY test of the software, which was estimated to take 6 months and $1 million. On the other hand, the Shuttle had enough extra lift capacity to handle an additional 200 pounds. Needless to say, we built the cables.
The second lesson was to not expect to be rewarded for finding an embarrassing problem. If the Hubble Space Telescope had been launched with the fix, it would likely have spun out of control when deployed from the Space Shuttle and gone permanently dead within a day. Given the public uproar about the out-of-focus optics, which affected only 1 of the 5 instruments, it is not inconceivable that NASA might have been completely shut down if the entire satellite was instead lost. There was no public acknowledgement that this problem had existed or been solved and I received no tangible reward.

Graham, before we move on to more of these sorts of questions, can you take some time to bring our readers up to speed on you and what you do?
I have been building things since I was a kid and engineering was the only field that interested me when I reached college. My career has been a series of R&D jobs that were in completely different markets yet strangely familiar. I started in fiber-reinforced plastics, which was a brand-new technology at the time, then switched to building spacecraft at Lockheed, followed by working on a mass-produced consumer product for Hewlett Packard, joined a start-up to build a high-bandwidth communication laser, and finally medical devices. These jobs collectively gave me experience with an extraordinary breadth of technologies.
I have always had the courage to stand behind my work and the temerity to ask a question when others would choose to remain silent. One example occurred during my time at Hewlett Packard working on a ground-breaking new inkjet printer. The calibration process developed by the company’s most-senior scientist took 45 seconds, which was far too long for the production line. Although I was not assigned to the calibration instrument, I was aware of the problem and was not willing to stand by and watch the project fail. I broke into the project meeting where they were about to decide to drop this feature, which would jeopardize HP’s entry into the lucrative graphic arts printing market, and I publicly told my director that I could do the same calibration in under 1 second. I was rolling the dice with my career at HP. I was given 2 weeks to deliver a working calibration instrument to be tested by that same senior scientist. It was a simple software change that I had identified by asking the instrument builder a few fundamental questions. The modified instrument was delivered in 10 days and the testing showed that it completed the calibration in 1 second. The feature was retained and led to HP becoming a leader in the graphic arts printing market.
Later in my career, while Director of Research & Advance Development, the CEO of my company began to send me patents that were being offered to the company and ask for my assessment of their value. While I understood the technological concepts of the patents, I also realized that patents are not written in English, although they use English words, but rather written in a variation of legalese that is commonly misunderstood by engineers. I recognized that I needed to learn more about patents and how to interpret them. I studied and then took the patent bar exam, which led to me to move from engineering to being a patent agent. After working at a top national law firm, I am now an independent patent practitioner working with individuals and start-up companies to protect their intellectual property.

How’d you build such a strong reputation within your market?
A friend of mine who works for Comic-Con believes that everyone has a superpower, although most don’t realize it. My superpower is that I understand “technology.” I have worked in most disciplines and have ability to quickly develop an understanding when I encounter a new field. Over the course of 30+ years in R&D, I have been named as an inventor on dozens of patents across multiple industries. The combination of my breadth of knowledge and my willingness to dig down to the fundamentals has given me the ability to bridge the chasm between engineering and patents. My niche is working with highly skilled inventors to first understand their concepts and then identify find the patentable features and obtain meaningful patent protection of that product.

Any advice for managing a team?
My advice is limited to management of brilliant people. My experience is that this type of person is often eccentric and may exhibit some undesirable personal characteristics. They may be compulsive, socially awkward or clinically depressed. They may not play well with others. I absolutely consider it worthwhile to trade the additional work and patience that it takes to manage this type of person in order to benefit from their extraordinary skills. If handled gently, they will deliver miracles. If you earn their respect, and you do have to earn it, they will walk thru fire for you.
My top three recommendations:
1) Keep brilliant people away from company meetings, as they are likely to stand up and call “bullshit” when presented with the typical corporate “mission statements” and other generic HR motivational messages. Brilliant people consider it a waste of time to have to stop work to sit in a meeting and listen to corporate messages. Go to the 2-hour meeting yourself and provide a 5-minute summary to the team afterwards. Let them work.
2) Give a brilliant person a task with a clear objective and well-defined constraints, such as when it must be completed and what resources are available, then GET OUT OF THE WAY to avoid being run over as they charge toward the objective. Require a regular report (verbal or written) on tangible progress and insist on a written summary (a list is fine) of each design choice that shows that they considered multiple alternatives and how they compared them. Your job is to remove obstacles and make sure they are on course, not to impede their progress.
3) Be prepared to soothe other staff when they come to you complaining about your brilliant people. Yes, brilliant people can be irritating, insulting, and even obnoxious to others. They might even talk trash about you. Be the adult and put your ego away. Sometimes it will feel like dealing with a precocious toddler. Do not give them a free pass – talk to them about interpersonal issues in a non-punishing manner and then focus on their work.
It is a lot of work to manage brilliant people and most managers do not have the patience to deal with them. Be the exception. Given the right environment, 2 or 3 brilliant people can generate enough new products and innovative features to keep a dozen regular engineers running full speed to bring those ideas to market.
Contact Info:
- Website: https://eliterobotics.us
- Linkedin: /DrGrahamRoss/





