Rocket Scientists

This was a directory of Aerospace workers' personal e-mail addresses, created to allow fellow workers to look for and communicate with fellow space enthusiasts and co-workers without having to worry about abusing Government resources. Believe it or not there was a time that even sending e-mail that wasn't directly related to your daily job from your work e-mail could land you in a discussion with your manager and KSC security (you can probably guess how I know :-)).

• Randomly posting thoughts about motorcycles, pictures I take, science, and technology on BlueSky, I rarely go to Mastodon
• Bliss and my Zen by riding my motorcycle hither and yon. Motorcycle and Space Shuttle memes and pictures on Pinterest
• Collecting Space Shuttle documentation that I find around the Internet.
• Humor from a JSC sim instructor that blew up simulated shuttle missions on a daily basis:
• My Dad is a Rocket Scientist (and all that entails)
• The vacuum cleaner
• Adding to my Youtube videos about Motorcycles and Space Shuttle
• Working on a few woodworking projects for the garden.
• Creating ways to disrupt computers with the Rose Attack using Internet Protocol fragmentation.
• While the Veilid Framework is MUCH better for anonymous transmission, I have created / suggested other ways to keep your packets private by routing using Anonymous Anonymity or encoding your HTTP traffic using Anonymous HTTPEncode.
• The Fake E-mail FAQ / alt.spam FAQ, how to read e-mail headers and The Troll FAQ describing what to do about trolls. TLDR - Ignore them

A little about Ken Hollis and my career

• I absolutely abhorred elementary school, middle school and high school. Never found a social or intellectual group that I could get comfortable in. The day I walked into the VCU Computer Lab I realized that I had found my people. I found out that 25 / 30 years later the term that was used for 'my people', people in tech, was 'neurodiverse' or 'on the spectrum'. I embrace them :-)
• I started in the Chemistry department but realized that with a BS in Chemistry I would most likely end up in a lab doing what PHD's told me bathed in chemicals that would eventually give me cancer. Plus Chemistry was boring to me. I changed to the Math/Computer Science department. Changing majors and admitting that what you THOUGHT you wanted is not a setback unless you decide to change in your 3rd or 4th year. Make the decision early

Programmer

• My first real programming job was Jenny of the Prairie. The first computer game specifically written for girls, written while I was still getting my BS degree
• Some Programmer quotes
• There is ALWAYS One More Bug
• The first 90% of the work is getting 90% of the programming done, the last 10% of the work takes another 90% to get it finished
• Heisenbugs don't disappear. They migrate.
• 'Done' is a planning fiction. Shippable is real. Done is not.
• I then received a BS in Math/Computer Science (no pure Comp Sci degrees yet) from Virginia Commonwealth University (VCU) Math Department
• I wanted to get a Masters of Science Computer Science and applied to/was accepted at University of Central Florida. Moved down to Orlando. Figured out quickly that the same Misanthropic teachers in Computer Science that were at VCU worked at UCF also



Aerospace Programmer / Hardware Test/Checkout/Launch Engineer

• Applied to Lockheed Space Operations Company (LSOC) at Kennedy Space Center (KSC)and was hired to program in GOAL (Ground Operations Aerospace Language) the GLS (Ground Launch Sequencer) software and execute that software in the Firing Room to launch the Space Shuttle. The software controlled parts of the launch from T-3 Hours and the entire launch from T-9 minutes to T-0 (Liftoff).
• The first mission I sat on console in the Firing Room for launch was Challenger, STS-51-L (STS-33 to KSC), January 28 1986. I sat at the Integration console as CGLS Backup, Jack King was CGLS Primary - 'GLS Go For Main Engine Start'. A day I will never forget
• Worked on the MPS / SSME software for test/Checkout/Launch after Challenger for Return To Flight, STS-26R
• Applied to and joined the MPS / SSME hardware test/checkout/launch team. This was my first career change from programming to a hardware engineering job
• This was a leap of faith on my part going from programming to working on the hardware as an engineer on the Space Shuttle
• I knew the software so I was familiar with the MPS and SSME system
• Initially I joined the MPS team. I also worked with closely with and eventually was certified in the LSOC engineering team that worked with the Rocketdyne engineers on the SSME's
• I was working with BS or MS degreed Aerospace / Mechanical / Electrical engineers but I knew I could learn. Yes there was some negativity from those engineers that I didn't have a engineering degree ... Showing I could master the job and be useful usually negated most of their negative attitude
• MPS engineers were known as the 'plumbers', we were responsible for most of the pipes in the aft of the orbiter, the 'Aft Plumbers Nightmare', but we were also responsible for pneumatic, actuators, solenoids, sensors, and electrical systems.
• I worked third shift, I was given some autonomy and no 'management help' to make decisions which I enjoyed
• Since I worked third shift and had that autonomy I expanded my knowledge by learning/training (you stop learning you start dying) and passing the Standboard/Certification for MPS (Level I test/Checkout/Launch), SSME and the CCME (Level II, JUST test/Checkout) console positions, the only person certified to sit console for MPS, CSME and CCME at the same time
• It was on third shift right after I was standboarded MPS Test and Checkout (Level II) on console by myself that I had a moment of doubt, I was running a procedure with all caps "THIS PROCEDURE CONTAINS HAZARDOUS OPERATIONS". Did I actually know what I was doing? But I started working the procedure and within 5 minutes I was buried in the operation going to town. Imposter Syndrome had left the Firing Room.
• In 1995 timeframe, same job / job title, the company name changed to Lockheed Martin Space Operations (LMSO) and then to United Space Alliance in 1996.
• I did get to do some REALLY neat things and memories while working at KSC, this was a hard job to leave. Some memories good, some not so good, no particular order:
• All of my coworkers at KSC were VERY smart, I appreciated working around people that caught on quickly
• Working 16 hour shifts 5 days in one week because of scrub / turnaround operations. Less than 8 hours sleep between some shifts for STS-32 (STS-61-C, JSC numbering system)
• Sitting at the INTG (Integration) console in Firing Room 1, at 1 minute 13 seconds after Challenger lifted off on a cold morning January 28, 1986, seeing the 'Y' on the firing room cameras of what was the launch vehicle. Seeing the scrolling yellow on the console screens that indicated loss of signal and the Printer Plotters constantly printing the same message. Looking at OPE (NASA Orbiter Processing Engineer) and asking about a rescue and hearing there would be nothing to rescue, the request from the NTD (NASA Test Director) to verify the phones were disabled, told to leave all paperwork in the firing room and walking out of the door of the LCC (Launch Control Complex) with just my headset bag into the cold bright blue skies just absolutely stunned.
• Seeing Hubble in the payload bay of the Shuttle ready for launch (performing 'MPS Closeout Inspections', and yes, I REALLY DID have paperwork to be in the PCR (Payload Changeout Room) ;-))
• During launch I worked as a "NASA Technician loading the External Tank of the shuttle" (as NASA PAO puts it).
• After an on pad abort performing MPS interface inspections in the aft of the Orbiter after the SSME was removed, connected to a safety harness, crawling out on a 18 inch metal 'pic' board with nothing else between me and the bottom of the flame trench, maybe a hundred foot drop?
• I worked on and inside four of the five flight vehicles (Columbia, Discovery, Atlantis, Endeavour), never got to work inside Challenger. A picture showing me next to the wing of Columbia. OV-102 (Columbia) which was affectionately known as the penguin, RIP
• Most of my work was done in the Firing Room. The usual camera shots of the Firing Room are more like (as a friend put it) a picture of the New York Stock exchange. Sometimes (accidentally) a picture that almost looked like me appeared.
• I supported landing in California for ferry flight back to Florida at DFRC (Dryden Flight Research Center) (Renamed Neil A. Armstrong Flight Research Center (AFRC)) and was able to see planes like the The SR-71 Blackbird (with Jim Drew a co-worker).
• During landings, some at Dryden, some at KSC, I was able to go out to the vehicles shortly after they landed (and were cleared of Hypergols), climb up the staircase outside the aft of the Orbiter and inspect the MPS interfaces (me on the left) and then got views of the vehicle and the runway not many people saw
• Standing on the Fixed and Rotating Service Structure in the morning watching the sun rise over the Atlantic as its rays slowly spread across the beaches and marshes
• Seeing the Hubble Space Telescope nestled in the orbiter payload bay before it was launched, then working on console and helping to launch it
• Friends like Bobbi Waterman, and the many Engineers, Managers, third shift tech's, and QC's (Quality Control) I worked with (in no particular order) John, Rene, Bobby, David, Bob, Lusa, BJ, George, Chip, Travis, Mark, Mike, James, Jeff, Tom, Wes, Ray-Bog Kramer, Etc. Too many to name. There were THOUSANDS of support people at KSC required to test/checkout and launch the Space Shuttle.
• Shaking hands with Bob Crippen and John Young and getting their signatures on a photo when they were inside Enterprise before STS-1. HUGE amounts of respect for those two ESPECIALLY after hearing all the things that almost went wrong and how bad that first launch could have gone. STS-1 was the first launch of the integrated vehicle with a human on board, something NASA had not done before
• Getting my nickname of 'Sasquatch'. You cannot PICK a nickname, it has to be given. The nickname is from the booties we had to put on our feet to go in the aft, they were NEVER big enough to fit my large feet, hence the nickname.
• Lessons Learned (the good and the bad) and quotes from Kennedy Space Center
• Because people could die and equipment could be destroyed, working at Kennedy Space Center drilled good engineering rigor into me starting as a young engineer. Attention to detail. In my almost 40 year career I never had an outage, I attribute this to following the below rules of testing first them implementation. I learned:
• In school you are penalized for plagiarism, at work you are rewarded. If someone has already written a procedure or a piece of software that is close to what you need STEAL IT. They have probably thought of half a dozen scenarios you may not ever think of. Then review it to see how it could be improved or changed for your specific scenario
• Carefully plan the work, write down EVERY step and get someone with knowledge of the system to review, give suggestions and sign off AND THEN TEST IT IN A LAB
• Testing in a lab / sim is critical to ensuring what you THINK is going to happens does indeed happen. A lab that is as CLOSE to the production environment as possible. They had a math model of the Shuttle for testing at KSC and the JSC Shuttle Avionics Integration Laboratory (SAIL) lab for final testing. At ARINC we had a full up lab with real equipment for testing.
• Test for every scenario no matter how unlikely
• Contingency steps and safing of a system if an emergency arises
• Double checking every step while performing the work
• Rollback steps if everything starts to go sideways to get you back to a known good state
• Crawl - Walk - Run --> Crawl is implement at ONE low impact site in production and verify no impact otherwise roll back, Walk is implement on several low impact sites and see how it goes, Run is do all the rest of the sites again checking to see if there is impact (hopefully not) at each site
• If everything DOES go sideways and an outage occurs, then have the PIR (Post Incident Review) to meet and discuss how this could have been prevented and any additional process improvements
• Favorite saying and quotes from KSC:
• From MPS/SSME 'A legend in their own mind, a monument unto himself '
• From Bobby Morgan, third shift tech I worked with when I was trying to get a job done faster but he knew the process that had to be followed --> 'I got two speeds. If you don't like THIS speed you sure as HELL aren't going to like the other one'
• From MPS/SSME 'Kick Them When they are down, you may not get another chance'
• From a LockMart VP when questioned about benefits 'You gotta look at where you are, and where you want to be. If you aren't there go get another job'. This was a lesson that stuck with me for life
• Unknown (But probably the KSC Flow Manager / Program manager) 'Don't let the facts interfere with the schedule'
• As soon as we get good at handling the impossible, it becomes part of our job description - Col Egan, USMC
• Enhansellment - Steve Hansell (RIP) could take ANY procedure and 'improve' it ... And he would. No matter how short and sweet it was he would make changes, 'Enhansellments''
• 'Abandonberg Air Farce Base - Home Of The Semi-Processed Shuttle' - The Space Shuttle was SUPPOSED to fly out of Vandenberg from 'Slick Six' (SLC-6)... But ... Issues Ensued ...
• Unfortunately reiterating alot of the MPS/SSME quotes would land people in the HR office ... So those are left unsaid
• This is the job where I learned that while I have freedom of speech, it was made clear to me that a company does not have to continue to employ me if they do not like what I say. See 'At-will employment'. NASA PAO (Public Affairs Office, now NASA Office of Communications) did NOT appreciate my attempts to inform the public about Space Shuttle Launch Schedule and How To Attend A Launch. I managed not to get fired. My management backed me and I knew the Chief Engineer of Lockheed personally who also saved me. By the skin of my teeth. This was a lesson I carried with me throughout my career, not talking about my current job (whatever it was) or updating this page about my career and where I worked until now since I am retired.
• Aerospace is brutal. Aerospace can be a demanding field with narrow career mobility, so anyone pursuing an Aerospace Engineering degree should go in with clear expectations. Even though you learn all the disciplines, Human Resources will rarly consider your resume outside of Aerospace. INSIDE Aerospace unless you get a NASA government job (good pay and benefits) you are just a commodity to the Aerospace Companies (low pay and minimal benefits). When I tried to discuss better pay / benefits I heard 'Where ELSE are you going to work in manned space'
• The divorce rate on the Spacecoast was much higher than the rest of the country, I always assumed because of the job pressures
• Starting in the 1990's NASA told the United Space Alliance that they needed to be more 'efficient' with the Shuttle processing contract. Since the vast majority of the contract was employees this meant layoffs, minimal pay raises. Every 3 months there was a round of layoffs. I got used to saying to myself for this job and eventually every job in tech that if I get laid off so be it. In this case I was senior enough and third shift so they really did need me. I was eventually able to go to my next job.
• My final job title at KSC after working 11 years was that of a Senior Engineer, the job was fantastic from a learning experience but I could not afford the low pay and small pay increases with no chance for advancement (long story). My coworkers all signed a going away picture (and a small tear rolled down, mostly because they would now have to work 3rd shift ... 😪). I moved onto the next job ...


• For the rest of my career for each different job (position) I changed every 3 or 4 years. Enough time to learn and perform the job well, but not too frequently that I looked like a job hopper. At Microsoft I have 4 different 'jobs'.



Network Engineer / Programmer

• My next job was at Aeronautical Radio, Incorporated (ARINC) , now Collins Aerospace, working on the ACARS VHF system
• This job change gave me the salary I needed to pay off debts that had accumulated from working at KSC (long story over a beer if you REALLY want to hear it)
• This also allowed me to start to catch up with technology, Space launch HAS to have reliable components so the technology at KSC was 10 or more years old. ARINC allowed me to program in current programming languages
• Unknown to me at the time, I would become one of the network engineers. Trained on Cisco routers and switches
• The good:
• This was my next career change, still one foot in programming but now becoming a Networking Engineer, configuring routers and switches
• This job allowed me to visit interesting places like Thailand and China to train the Thai AEROTHAI and Chinese ADCC engineers and install the ACARS for that specific country. I visited the Great Wall, where I wore my Shuttle Jacket. This is a little bit of geek humor. The Great Wall is one of the few man made things that can be (arguably just barely ... or not) be seen from the Shuttle.
• When I was in Thailand my lead Tim quietly said to me 'don't do that' me 'What?' Tim 'say "Wow! It worked" in a surprised tone' ... 'But I AM surprised when I configure something and it works!' Tim 'Just not in front of the customer, OK?'. I learned to control my surprise. Most of the operations I had done a hundred times in the lab, but you know technology ... And how devices in the field can throw you unpeasant surprises you never tested for.
• This was another job where engineering operations / rigor continued to be emphasized. We had a full up lab that had one of every component that was out in the field, high fidelity
• The not so good:
• In Aerospace the technology is at the trailing edge, not the latest and greatest or even emerging tech. If you are on the bleeding edge of technology you WILL bleed (failures, operational impacts) so Aerospace is conservative about the technologies they implement
• ACARS was still working with older technologies like 4-Wire MoDems and X.25, a packet switched network from the 1980's still used mostly outside the US in countries like Thailand and China
• ARINC was JUST getting ready to implement current (at the time) technologies like Frame Relay, but that would be a few years down the road for the system I worked on
• It was still Aerospace. I spent Y2K New Years Eve (Friday Night / Saturday Morning) in the operations center waiting for the clock to tick over to midnight in every time zone. We monitored starting with GMT (London) through the west coast. We were waiting for 'something' to fail. Because of our software changes and extensive testing nothing failed except a printer in some remote favility which just had to be rebooted. The only acknowledgment I got for spending my New Years in a conference room was a hearty 'thanks, have a good night, see you on Monday'
• My final job title at ARINC after working 3 years was Staff Principal Engineer. Pay raises / promotions / new technologies were not in the future for me, I was stagnating again. I moved onto the next job ...



Network Engineer / Network Security

• My next position was pure networking setting up and configuring the Tulsa Public Schools fiberoptic Network. I was hired by Williams Communications Group , later to become NextiraOne , and later (after I left) bought by Black Box. In tech you can expect your company name to be ... Fluid.
• Keeping in contact with coworkers even after they leave was helpful when looking for my next job. A manager from ARINC I knew that left contacted me for the job in Tulsa
• This was a job that not only allowed me to work on the front edge of technology, I also learned a TON
• Charlie an I were the network engineers, he is still a good friend. I was able to stop by and see him on my Route 66 trip
• This specific project entailed learning about a bunch of new technologies for me, Frame Relay, Asynchronous Transfer Mode (ATM) and Cisco big iron (at the time), their Cisco Catalyst 6509:
• For the final configuration the schools needed data networking and telephony interconnected using a Fiberoptic Ring Network running ATM and IP over ATM
• The first step for IP (Internet Protocol) interconnection from each school to the main campus was a Frame Relay network, connected through the local telephone company
• The Frame Relay was brought up to allow the school to have network connectivity while the Fiberoptic Network was being installed
• MOST IMPORTANTLY Charlie and I were able to get the Cisco 6509's into a lab to start configuring AND TEST for the new fiberoptic network
• We were also able to install and verify good connectivity with the 6509's (one at each high school) and the smaller Cisco routers (one at each elementary and middle school) without breaking the connectivity that the frame network provided, no impact to the customer
• As a side note we were Cisco's beta testers for IP over ATM and ATM's connecting the school wide Private Branch Exchange (PBX) network via T1's (Transmission System 1) in the ATM network. We were able to talk directly to the programmers of the Cisco IOS at Cisco for troubleshooting. Very interesting, network engineers usually don't get access to that high level of assistance from Cisco
• This position also started me on the Network Security path, we worked with Cisco PIX firewalls to protect the schools and perform content filtering to minimize the kids from going to sites that they shouldn't (p.s. kids are REALLY creative at circumventing content filtering)
• After 2 1/2 years the network was installed and constant travel around the country working different projects looked like the future for this job, did not fit into my plans



SCADA (Supervisory Control and Data Acquisition) Network Engineer / Network Security

• My next position was still in Tulsa but working for Wyandotte Net Tel as the Senior Network Manager for Southwestern Power Administration (SWPA)
• Likewise, keeping in contact with coworkers was helpful. One of the sales engineers I worked with at Williams pointed me to this job.
• SWPA ran the transmissions line to take electricity from the Army Corps of Engineers Dams (built to control the Red River Flooding) out for Rural Electrification
• By now I felt completely comfortable with IP networks and how to design them
• Once again part of my job was designing and upgrading the network, triple the amount of network gear going from 10BaseT to 100BaseT and Gigabit and adding in multiple hardware firewalls to segment and protect the network
• Ripping out and replacing a network you will ALWAYS find issues from previous engineers, just like buying a home and finding the 'interesting' decisions previous homeowners made. You WILL have to take time to correct those mistakes like replacing the telephone wire someone used for the network cable with a REAL Cat-6 Cable
• My new education was around the Supervisory Control and Data Acquisition (SCADA) network that SWPA was responsible for and how to manage and protect that network from cybersecurity attacks
• I had to negotiate networking best practices with the government employed SWPA engineers, sometimes they accepted my designs, sometimes not
• I also heard the constant refrain of 'we are so small, NOBODY would attack us', that was the early days of nation states attacking SCADA networks
• One of my better moments was when a external Red team tried to get into our network from 'The Internet', I had worked hard to secure out perimeter. They said that this was the first time that they were unable to get into a network, ever
• Another experience was participating in the NIST Industrial Control Systems (ICSs) and Supervisory Control & Data Acquisition (SCADA) Workshop updating the NIST 800-53 R1 standard. This was an opportunity I would not have had at many jobs, giving my expertise in SCADA Cybersecurity
• After 3 1/2 years the network was secured as much as I was allowed. The pay was not great but this was a job that, assuming I could settle, I could work forever. Maybe become a Government Employee. All that was not for me.



Programmer Writer

• I had kept in contact with a friend from college, Helen, she was working at Microsoft on the Protocols Documentation Project
• Since I was a network engineer and know protocols Microsoft hired me to help dissect the protocols and write the documents about what every bit in the packet meant. In the end since there were VERY tight deadlines for the United States Department of Justice (DOJ) and the European Union (EU) this work translated to taking documents from the engineers that wrote the software for the protocols, making sure that what they wrote made sense & adding markup (references, formatting) to make sure that the text was understandable. The documentation had to be written in such a way that it could also be programmatically ingested for automation. I also went back to China to train the protocol writers there, this time Shanghai, China. Yet another career change
• I eventually became a manager for the programmer writers. I began to understand why my previous managers did not seem to always support the front line workers. Those managers either wanted to advance in the company or, at the very least, keep their current jobs. I found out quickly I wasn't cut out to be a manager and how getting crosswise with your manager and their manager can affect your career

Network Troubleshooting the Production Network

• I eventually, through some hard work and tenaciousness, obtained a job in the Network Live Site Emergency Response (LSER) team keeping the 'production network', i.e. all the datacenters running. This encompassed all the Microsoft datacenters worldwide, 400+ and growing as of 2025 and all the different divisions of Microsoft that used those datacenters. Some divisions at the time supported their own networks (X-Box, Skype) so there were some caveats. At Microsoft there are ALWAYS caveats
• I also worked in India to help train the livesite engineers as our team transitioned from supporting the network only at the main campus to supporting the network with a follow the sun model.
• The livesite job exposed me to how HUGE the Microsoft network is. Everything at Microsoft is at a scale larger than people and companies have seen before. Software written for a large enterprise network breaks on the Microsoft network. This is how software like Kusto and Azure Monitor

  CyberSecurity Engineer

• Through my work at network livesite I got to know engineers in the Microsoft Online Services Security and Compliance (OSSC) team, specifically the Cybersecurity response team. They knew was a SME (Subject Matter Expert) on the Microsoft network, they needed that skill and knew that I had experience with network security devices. Once again there was an opportunity to expand my knowledge into pure Cybersecurity and hopefully get more opportunities, so I moved into the Cyber Defense Operations Center Security Incident Management / Security Operations Center Investigations team and changed my career once again

Critical Environments CyberSecurity Detection Program Manager

• My final position at Microsoft was as a Senior Security Technical Program Manager (TPM) driving security detections and health monitoring for the Physical Security and Critical Environments in the data center. I finally had enough experience where all of my previous skills could be put together into one job, started working on day one. But the TPM position was once again another (and final) career change. This work entailed working with the engineers enabling detections for all the different systems, Electrical Power, HVAC, Badging, Cameras, and the supporting systems to ensure that the NIST Cybersecurity Framework was implemented. Detections were written with a focus on the MITRE ATT&CK Matrix for ICS, ensuring as many areas covered as possible. This is a VERY brief summary of the work. I could spend a week teaching a class and STILL just scratch the surface.
• Microsoft was where I learned the MOST about succeeding in corporate life. If you can manage your career well enough to stay at Microsoft and leave on your own terms then you can work ANYWHERE. My lessons learned in no particular order:
• I *thought* I knew what 'spin' was from working in Aerospace and listening to politicians. At Microsoft I learned the professional version of spin, how to say - 'How to make something unpleasant sound not so bad or even good'
• The other lesson was how to answer the question you wanted to be asked & ignore the question that was actually asked. A favorite of politicians once you spot what is happening
• Ask yourself regularly whether or not you are agreeing with AND aligned with your manager. When or IF that gets out of alignment ask yourself if it is your path, if not start looking for a new position EARLY. You don't want to be in a performance evaluation mode which makes it MUCH harder to change jobs. I was almost in that position and getting out of it was a royal pain. I didn't feel TOO bad, some of the smartest people I admired at Microsoft found themselves in the same position.
• At Microsoft each 'org' is like its own company. When changing jobs you have to be tenacious. Meet with people in each org you are interested in. Just because one group doesn't bring you in the group next door might hire you. If you are applying from outside Microsoft it is harder to get in the door but keep applying. Perseverance is the key. At the very least you get experience with the Microsoft interview process and increase your chance to succeed on the next interview if you get turned down from one job
• Over and over I had to 'manage expectations'. If a project was not progressing I would communicate that information to my management whether it was my fault or not. Constantly. Surprising management is BAD
• Also on the subject of questions don't state to someone 'you are wrong', ask 'can you walk me through / describe to me how you came to that conclusion?'. For knowledgeable people in the room you pretty much just told someone that they are wrong. And you also get the chance to see that maybe they WERE correct
• Microsoft also had an annoying culture of not asking questions if someone said something and people didn't understand. I didn't have that problem, I asked :-). My quote is 'there are no dumb questions, just dumb answers'. There is ALWAYS a possibility *I* am wrong
• When you start ANY job sit & listen at the meetings. Get a mentor to ask questions on the side. Learn how the culture works. How a company resolves issues is ALL telling, whether they solve collaboratively or just yell at each other and the strongest voice wins
• When there is a crisis be the Buddha. Be the calm center of the room. In the end the issue WILL be resolved, Microsoft is a big enough corporation that they can devote the resources needed to fix an issue. Ramping up the noise in the room and adding confusion doesn't help anybody
• There was either a reorg or a desk change every 6 months. Get used to it. As long as your manager doesn't change then reorgs can pretty much be ignored, just get with your manager to veryify you are in alignment with their manager.
• You are expected to have enought work for 120% of your capacity, make sure you and your manager are aligned on what 100% DOES get done, clear deliverables but DON'T burn yourself out trying to get the 120% all done ... Unless there are layoffs on the horizon
• EPerformance alone doesn't always protect you during organizational cuts. This is another reminder to manage your career proactively. If your manager is told to cut 'X' people from his team unless you are above the cut line you will be laid off. See above, you are a commodity to be hired/fired/laid off
• After almost 18 years it was time to retire, update my web pages and actually tell people what I did for a living :-). One last thing, I set up an appointment with a nutritionist after a yearly checkup to discuss my diet / nutrition. Discussed ways to improve my 'numbers', she asked me about stress saying that stress can affect the numbers. It was then I realized that my stress had gone from a 7 - 8 the week before (working) versus a 2 - 3 after retirement. YMMV.
• Recently after months of not being at or aroound work I realized that I was licing in a little different reality
• Work had provided a comfortable 'known' framework, things happened in expected ways, interactions with and reactions from coworkers that were known.
• Interacting with 'the public' every day was ... interesting. I had to think carefully about how to have discourse to get my thoughts across.
• Unlike work there is no shortcut language, there are no core basic frameworks to start a discussion, you have to start from the beginning every time.
• Getting up, walking to a coffee machine and getting coffee was WAAAAYY to easy. My caffeine consumption has dropped dramatically.
• After MANY MANY months of retirement I am still not bored. I am still catching up on the things left undone while I worked, finding new things to do, and having more experiences.



• Here are my learnings from my career:

Career Lessons Framework

1. Foundations: Building a durable career

• Make yourself genuinely useful to your manager - not a yes-man, a resource. Know what they need before they ask. A manager who can count on you will go to bat for you when it matters. Mine did, up the line to the Chief Engineer of Lockheed, more than once.
• Document document document. If it isn't written down it doesn't exist. Think about the NEXT person trying to do your job and write it down for them.
• If you are NOT documenting everything because you want job security that is a hint that you need a new job. Document so that you can move into a new and interesting 'next' job.
• Stay curious or fall behind - Keep abreast of the information in technical sources for the next interesting technology.
• Build a career around learning faster than your job descriptions expire
• Continuous learning is survival, not a luxury, in tech if your knowledge is more than 4 years old it probably isn't relevant.
• Take risks early and often, the earlier in your career the less impactful later.
• Geographic and role changes create opportunity, being willing to move across the country expands your opportunities.
• Do not cling to a single professional identity.
• Reassess your trajectory every 3–4 years and review new opportunities - I stayed at Kennedy Space Center WAAAAY too long (for personal not career reasons).
• Add at least one new domain skill or a technical class each year - and your employer should foot the bill, not you.
• Regularly update a notebook or your mental notes of a 'future skills that look interesting' list.
• WHERE you graduated from (unless it is Ivy League) doesn't matter as muich as WHAT your degree is. Try to get a degree that is becoming 'in demand' THAT YOU ENJOY.
• Your teams should miss you when you leave. If they don't, that's information.

2. Adaptability: The skill that outlives all others

• Transition between disciplines as opportunities appear. Do not get comfortable on the trailing edge of technology, move to the bleeding edge (or close to) if you can.
• Your degree does not define your destiny. Your degree taught you HOW to learn and the jargon for your field. You can learn all that again in a new area of learning.
• Your first job is not your forever job.
• Your comfort zone is a warning sign, not a reward. It is that feeling that your manager and the company you work for wants you to depend on until you are no longer useful.
• Treat every new role as a chance to reinvent yourself.

3. Rigor: Applying high-stakes engineering discipline

• Use a 'crawl, walk, run' approach to implementation. Implement in a couple of machines/sites, implement in a small percentage, learn more, then implement everywhere.
• If you use 'bleeding edge' equipment / technology in production YOU are going to bleed. Make sure that technology is tested ENOUGH so that you are comfortable deploying it.
• Test extensively in a safe environment before production (Engineering Test --> Pre-prod (looks JUST like production) --> Deploy to prod).
• Reuse proven procedures where possible. In college plagiarism is punished, at work plagiarism is rewarded (hint: give credit where credit is due)
• Do not deploy what you have not tested. Famous last words 'it was just one SIMPLE change', and your next meeting is a post mortem, if you are lucky.
• It is ALWAYS DNS. This is a little tech humor that is more true than not.
• Do not trust undocumented or unexplained behavior. 'Hmmm ... never seen it do THAT before ...'
• NEVER skip postmortems after failures or incidents.
• Assume systems can fail even if they worked yesterday.
• Perform failover testing when you are implementing IN PRODUCTION to make sure future failures will switch as expected.

4. Resilience: Surviving volatile industries

• You can be a pain in the neck and still keep your job - if you are more useful than you are difficult. I tested this theory regularly. The key word is more.
• Expect layoffs, restructures, and market swings. At Kennedy Space Center we had layoffs every quarter. I delt with it until I could get another job.
• When communicating upward: 'Be Brief, Be Bright, Be Gone'. Managers and executives do not have time for your narrative. Bullet points. Lead with the conclusion, support it with three points, stop talking. If they want more they will ask.
• Do not wait for a crisis to plan your next move.
• Your employer is not your career. You are 'at will' and can be let go at any time for no reason at all.
• Your skills and your knowledge are your real job security.
• Your professional network is your safety net.
• Keep your resume and portfolio current and honest. You should be able to defend EVERY word in your resume.
• Keep your resume short. Bullet points. You can expound in the interview. My resume for decades of work experience was 3.25 pages, should have been 3 pages MAX (I got lazy at the end).
• In an interview use ALL the time alotted. If they stop talking ask questions about the work and their work, talk 20% and let them talk 80%. USE THE WHOLE HOUR!

5. Courage: Making difficult, high‑impact moves

• Recognize that staying put can be the riskiest option. You never know what shenanigans are happening at the 'C' Level (management level) that may end the company.
• It is easy to relax into a familiar job and become afraid of change, to become the 'elder geek', 'resident sage' that EVERYBODY goes to for advice. Comfort should be your warning sign.
• If a move both scares and excites you then maybe you SHOULD take it.
• Be willing to leave stable environments for better fit or growth. You can more safely look for a much better opportunity when you are stable as opposed to looking for new opportunities in a crisis.
• Choose opportunity over comfort when you can afford the risk. Change is never comfortable, but it can be exciting

6. Perspective: Treating time as the real currency

• Money buys pieces of time, not meaning. No One On His Deathbed Ever Said, 'I Wish I Had Spent More Time On My Business' - Arnold Zack.
• 'I have never bought anything with money, everything I have was bought with pieces of time I sold from my life to a job that will never have paid enough when my time is up.' - Unknown.
• Use your career to support your life, not consume it. Your home life and the people in it deserve your attention as much as your work life does. Choose a partner that understands AND supports that delicate balance.
• Invest in experiences and memories more than possessions. If you believe in something after this life memories might be all you will take with you.
• Do not trade your life away for titles or status. Titles and status are only applicable in the framework in which they are created, you will be forgotten at the company in a year.
• Regularly ask yourself if your work is still worth your time, if it isn't then it is time for a change.
• Regularly keep track of your investments to see if you CAN retire in the lifestyle that you WISH to live. Have a goal rather than a wish.
• Retirement is as much a mindset as it is an age.