Last updated Unknown Edit Source

Welcome to episode 188 of the Nerd Journey Podcast [ @NerdJourney]! We’re John White ( @vJourneyman) and Nick Korte ( @NetworkNerd_), two Pre-Sales Technical Engineers who are hoping to bring you the IT career advice that we wish we’d been given earlier in our careers. In today’s episode we share part 2 of an interview with Joe Houghes, discussing his technical community involvement and what sparked it

Original Recording Date: 07-07-2022

Joe Houghes is a Senior Solutions Architect at Pure Storage, primarily focusing on FlashStack (made up of Cisco UCS, Cisco Networking, and Pure Storage in a single solution). Catch part 1 of our interview with Joe from Episode 187 if you missed it. Follow Joe on Twitter @jhoughes.

Joe Houghes Pure Storage Episode 187

# 2:44 - Boosted by the Community and a Technology Wave

• Joe jumped into the technology community in 2008 or 2009 when he attended his first [VMUG](VMware User Group)]( https://www.vmug.com/) event. Listen to the story of how he was welcomed at the local UserCon event.
  • Joe mentions a couple of the original vExperts said he looked like a nerd and wanted to introduce him to everyone. vExpert
  • It was an event Joe had heard about, technology he was interested in learning that he was not using at work, and the first socially outgoing person he ran into latched on and wanted to help.
• VMware technology was something Joe thought might catch on at his employer and wanted to get ahead of it, thinking he could be the first person there who learned about it.
  • Because Joe did a number of jobs at the company, he felt like he could solidify himself within the company using this new technology.
  • Joe ended up getting let go from that company during a reduction of force.
• Being interested in this specific technology helped him land his next job. At that point he had never used the technology outside of playing with it in a home lab, but Joe had an entire network of people he could ask reach out to for questions if he had them.
  • Nick makes the point that we cannot always get expertise / guidance on something from our co-workers.
  • There were only 2-3 online forums out there to go for help with questions related to this technology that Joe knew of at the time.
  • “Taking on a whole new technology, I didn’t know where to go.” - Joe Houghes
• Joe moved into a role where VMware technology was coming into the organization. The fact that he had played with the technology in a lab and knew it better than others at the company caught those making hiring decisions’ attention.
  • The fact that Joe had taken the initiative to play with the technology on his own outside his day job is what he believes ended up landing him the role in the end.
  • The IT department was looking for anyone who could come in and do tech, but when the credit union president learned about Joe’s personal drive, it was an impressive differentiator.
• Nick says not everyone is driven to do this, nor do they understand it can be leveraged as relatable experience in an interview just as Joe used it.
  • Some people told Joe he would be working with the technology as a primary focus so much in the next few years that he didn’t need to do anything on the side, while others told him the experience at CompUSA and tinkering meant he needed to build a home lab, blog about it, and tell everyone else (i.e. go overboard).
• John cites catching the early part of a technology wave (which we heard from Manny Sidhu in Episode 80). If the wave is big enough, and you are on the front part of it you can take you a long way in your career. But you have to catch the right wave. Episode 80
  • Joe cites David Bombal (a Cisco trainer) speaking about these waves of technology. Be aware of what is out there. If you have been on a technology wave to where it is on the downturn or if you are no longer interested in it, pick something else. David Bombal
    • Check out David Bombal’s free video library here and this video on what to learn in 2022.
  • People have talked on the show about losing the love or excitement for what they do and it being a contributor to burnout. Following the interest and excitement is important.

Specialist vs. Generalist

• In the last couple of years Joe has taken a hard look at things he has done, wants to do, and those which he wants to influence for others in his career.
• A decent amount of the teachings Joe has internalized have come from Don Jones and his book Be the Master (now called Own Your Tech Career) and bringing the apprentice, journeyman, master concepts into the technology. The book has some lessons from Don’s experience working as a civilian contractor for the Navy. Own Your Tech Career
  • We should be helping and training others on their journey instead of leaving them on their own.
  • A jack of all trades may be a master of none, but it can be collectively better than a master of one. This is something people often forget in their tech career.
    • If you get really specialized in something it isn’t necessarily a bad thing…unless you only do that one thing really well.
    • At some point you might fall victim to a technology trend (i.e. expert in Cisco IP telephony when Zoom comes along as a technology) making things more accessible without needing a subject matter expert. Introduction of this type of technology makes it hard to justify the need for specialists in the domain.
    • If you’re no longer conversational on the technologies you may work your way into a niche that drives you deeper and deeper into a single area rather than being able to move in a different direction.
    • Perhaps it is easier for the generalist to become more specialized?
    • It’s much harder for the hyperfocused specialist to become more general. They can fall into the trap of not paying attention of the trends that are coming and going.
    • It should be a goal for people to be aware of adjacent things to what they work on today.
    • But this is a balancing act. It is easy for a generalist to be a firefighter, a backup for other teams, or management fodder when people ask why something was not done on time or on budget. These same things may not be asked of someone highly specialized.
    • When technology changes, unless you are a specialist in something relatable or something translatable to the new technology, it could harder for you than the generalist who is aware of the change or has taken the time to go and play with some new technology.

• John gives the analogy of the surfer. The surfer’s expertise is not just riding one wave but multiple waves (never losing sight of the greater surroundings).
  • You may be involved in 3-5 big technology waves in your career, but this also doesn’t mean you cannot move around within a wave (going deeper, pulling back, and then repeating).
    • John gives an example of the layers someone could be a part of just within virtualization (storage, security, networking, etc.).
    • John cites the need to do exactly this to learn more about what a customer needs out of necessity.
  • This is a pattern to add to the pattern catalog.
  • Nick says this is just systems administration - go deep on something to fix the problem and then pull back.
  • Nick suggests that only the person who has been a generalist can understand when the right time to pull back is. If I have been hyperfocused my whole life, I may not recognize it.
  • John says this is like being responsible for a large, complex system. Think about the traditional Unix systems administrator (drive mapping, networking, startup and shutdown routines, operating system and software) who has an overall responsibility for the entire system.
  • Joe says the generalist and the person who has done a lot of troubleshooting can say something is complete or good enough to move on to something else.
  • Sometimes it is us understanding our personalities. You may need to get a state to where your brain can rest and disengage (i.e. not wonder what would have happen if you have tried this one other thing).
  • To the surfer analogy, Joe says it is not only the ability to ride the waves and understand one will go down and another will come.
    • One of the things we should aspire to that we miss is the fact that the surfer enjoys every minute of it (the riding, the anticipation of the next wave, pushing to catch the next wave, etc.). This is something they are mindful of (always in the moment), something that drives them, and something they are appreciative of.
    • Many of us lose the passion or the fun of seeing the new technology (like seeing the first vMotion). You never want to lose that.
    • Andrew Miller talks about not selling your technical soul (see Episode 165 for more on that). You need a grain of inspiration you carry in being close to a technology. Episode 165
    • When it isn’t fun anymore, do something else or get out of tech.
    • We should enjoy riding a technology wave, and when we are not we should really question what it is that we are doing here (in technology).

Career vs. Job

• A basic concept is your career belongs to you and your job belongs to your company. You are the one in the driver’s seat who can take a different role, try out different things (whether within responsibilities of your current job or outside it, at your current company or elsewhere - even doing this on your own time).
  • Many do not take responsibility for what they are doing next.
  • Those of us in tech are not dismissive but are not as analytical of how fast the technology changes are coming compared to in the past.
  • Starting out as a specialist 5 years ago might have provided safety in that you could continue as a specialist for a few years. Now if you become a specialist, there could be a chance that something becomes so commoditized that no one needs the specialty.
  • There are probably people retiring today who spent their entire careers working on Unix and virtualization within technical organizations (with that being all they needed). Maybe these folks caught the tail end of the AS400 wave, but the level of expertise developed allowed them to ride those waves.
    • Now, that might not be good enough for any given career.
    • It is likely no one would choose to be the current iteration of a Cobol developer as an example. Being part of a technology that stays around as long as Cobol has is a dwindling market.
    • Now we have phrases like technical debt. Putting more time into a technology you need to move away from only ties you further to it and makes you pay for it later.
    • Maybe organizations are measuring / at least have some idea of the soft measurement for level of technical debt?
    • John cites a recent headline for FedEx getting off mainframe in the next few years (a realization of the technical debt and a commitment to pay it down now).
    • Technical debt is a fairly recent concept and something that has emerged over the last 10-15 years.
    • Nick brings up career technical debt that can happen when we have lost sight of what the trends are or skills you need to acquire to be relevant in the job market.
      • John makes the point that his ethernet cable termination skills aren’t relevant enough to make $50 per hour these days.

• Joe started as a generalist. Getting into specifics was more of a byproduct of working at larger companies with larger datacenter environments.
• When working as part of larger teams, Joe and others felt people should be specialized on the technology within their area of focus and act as a subject matter expert / main point of contact. In some cases the team he worked on was responsible for supporting a specific team within the organization.
  • This started Joe down the path of specialty. He was the go-to for virtualization but was trying to hand that off to someone else, wanting to focus more on Microsoft System Center Configuration Manager (SCCM).
  • Joe became responsible not just for a specific system but for many systems, needing to consider how to patch over 25,000 systems.
  • The exposure to this kind of team structure helped Joe learn to think about complex systems and how his changes might impact another area while also staying aware of the greater technology footprint for the company and how others’ changes might affect his focus area.
  • Joe was able to draw on his experience in manufacturing to help with this process. He needed to be aware of and conversational in what others were doing and invested enough to learn how what others did impacted his role.
  • This speaks to the investment in interfaces between people and being mindful of upstream / downstream impacts.
• The desktop focused opportunity came about from the person who had originally implemented the technology wanting to move onto the networking team (a move out of Joe’s team of systems administrators). This person also did not want to have to deal with upgrading the system they had originally implemented.
  • Joe had a good rapport with this particular co-worker since they started working together.
  • This co-worker had a similar career trajectory to Joe but entirely inside a single organization, working his way up from cable technician to one of the top systems administrators in the company.
  • Joe’s co-worker suggested the opportunity to him after knowing Joe’s love for tinkering and his desire to implement more automation in the environment. With Joe already working on automation and PowerShell at the time, it was a logical fit for him.
  • Joe took the role more because of the PowerShell / automation focus than the fact that it was geared toward desktop management. There were aspects that were extremely interesting to Joe, and the rest came along as required duties.
  • Nick believes getting exposure to something at this kind of scale can get someone to an entirely new trajectory in their career (scaling the skillset and your thinking at the same time).
    • Joe says at this kind of scale you are still a generalist and get to touch a lot of other things, but at some organizations, the only way to get access to this kind of scale is the very specific focus (i.e. the primary expert / specialist) because of security requirements or pre-defined standards.
    • Many times roles like this require a experience to do well. But in some cases, this type of work is done either efficiently or done well the first time.
      • Efficiency can be easier to get right thanks to incremental changes over time.
      • Did someone put in the effort to do things well the first time? This can be a mix of the individual, the organization, pre-defined standards, and team structure.
    • Being ready to take the at bat you get at that scale comes down to either being confident with your skills OR
      • Being willing to go ask for help when you need it
      • Being willing to go apologize because you did something incorrectly (whether you should have known that or not)
    • It also depends on the support from your team (i.e. expertise) and from management for learning on the job if that is what you will need to do.
    • This is sort of right place, right mindset, and right time. Often times not all 3 of these exist in a way that makes someone feel confident or comfortable taking on the opportunity.
    • Many of us get stuck on not knowing the answer, not realizing that we don’t know until we have done it the first time.
  • Tom Limoncelli said at a conference talk Nick heard, “if a process or procedure seems risky, do it often.” As a result you will greatly decrease the risk. Tom Limoncelli
  • Joe says in a lot of cases it comes down to minimum viable product. What are the smallest incremental changes I can measure to ensure I am headed in the right or wrong direction?
  • John says recognizing these things is a skill (breaking down complex processes and problems), but when you’re at tens of thousands, that is a large blast radius.
  • Joe speaks to the pressure of operating / supporting this kind of environment for devices in hospitals and thoughts that go through your head about impact of a problem with normal system operation at this scale.
    • “I hope my phone doesn’t just start blowing up….At that point if I have 7 hospitals that call me and say hey, our computers rebooted and now they’re all black…I don’t know what I would do.” - Joe Houghes

# 36:52 - Change Review and Impact at Scale

• This was an organization where they did not have an official CAB (change advisory board) but a loosely defined process where the director of technology services wanted the primary and secondary subject matter experts to know when changes were made.

  • Also, there was a shared calendar among the systems team, the network team, and the medical imaging teams so that too many changes would not happen at once. There were also no maintenance windows.
  • The team understood the idea behind change control to minimize the blast radius when things go wrong. However, it took a major system outage to formalize the change control process within the company and forced people to think differently about how they did their job (more focus on impact of change to others inside the company and possible scenarios where something could go wrong).

• John mentions this type of role has an incremental deployment strategy (test this on 10 machines, then 100, then 1000, etc.), which very closely maps to the DevOps and SRE (site reliability engineering) concepts of blue-green and canary deployments. Blue-Green

• Joe provides context here that the machines in question were physical machines wired into the network inside hospitals that may or may not be anywhere close to where Joe lived in Texas at the time. It was a little scary.

  • One rollback plan was that technicians would grab as many already imaged machines from the “bench” (or working inventory) to take to critical areas of the hospital.
  • The other was to physically grab the machines at a specific location that stopped working after a patch or update and re-image them (i.e. get them back to working state again).
  • These possible scenarios were in his mind every time there was a patching window. There was no other contingency plan so many physical devices spread across various hospitals.
  • Joe says they would generally pick the Tuesday of the month that was a week after the traditional Patch Tuesday to deploy new patches.
  • They would patch a handful of systems to test before trying it on 10-100 and then out to 25,000 systems.
  • There was a designated calendar slot and schedule (2 AM on each specific Tuesday), and people knew when computers would automatically reboot to receive new patches. Joe would be available because he had to do server side work during this process, but sometimes he would get messages from people on call letting him know they didn’t want to receive any calls about stuff not working.

• Referenced in the outro:

  • Range by David Epstein Range
  • There was a lot of great advice in this episode about riding technology waves. Be careful if you don’t have a community to support you when digging into a new technology (may indicate you’re too far ahead), or maybe that is your chance to build the community!

Contact us if you need help on the journey.