Episode 158

Last updated Sep 19, 2022 Edit Source

Welcome to episode 158 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 1 of our interview with Andy Syrewicze, talking through his journey in IT from contractor for a school to experience manufacturing on into a MSP and into management.  We’ll talk through how fearlessness and hunger helped Andy increase his responsibilities and as a result, his blast radius. 

Original Recording Date: 12-29-2021 

Topics – Meet Andy Syrewicze, Fear and the #BlastRadius, Life in the #Manufacturing World, Teaching the Users, Getting Cut, Brief #Unemployment, #MSP Life, The Hunger Games, Moving to #TeamLead #Fired #TechnicalEvangelist #SubStack

=========================== 

• Andy Syrewicze is a Technical Evangelist for Altaro Software (now part of Hornet Security).   #AltaroSoftware #HornetSecurity

• With the acquisition, Andy’s responsibility area has grown to more than just backup, touching e-mail security and Microsoft 365 security. 

• Andy had a lot of interest in computer games as a kid (with a 486 being his first computer). 

• He started tinkering enough to get really interested in computers in general. 

• In high school he took every tech class available. 

• They would tear computers apart in class at school, and Andy built his own computers at home (including one with a very new AMD Athlon 64). 

• In the summer of his junior year he went to work for his high school doing IT (desktop administration, refreshing labs, etc.).  One of the first projects was upgrading Windows 98 to Windows 98 SE. 

• This was an interesting and unique experience in that Andy was providing tech support to some of his former teachers and other faculty who would be his teachers the following year. 

• John mentions people are often successful because they have lost the fear of breaking something.  People are inhibited from becoming more familiar with technology because they are fearful of breaking something. 

• When Andy was in high school doing desktop support, he had very little fear of breaking things and faith in himself to resolve any issue he could create. 

• After graduating, Andy went to work for the school full time (his first full time IT job). 

• Andy could resolve most issues on his own, but one time he accidentally deleted an application share from a file server (a very critical one in fact).   

• Andy was at one of the school’s remote sites and had to call his boss to take a look (who verified the data was gone). 

• Andy went to retrieve the tape to restore the data from backup. 

• Luckily everything restored as expected using BackupExec, but Andy learned a valuable lesson to check (multiple times) before doing things that affect data.  He was probably 19 at the time this happened. 

• In the earliest part of Andy’s career, the lack of fear enabled him to get his hands dirty in areas where others might not have ventured. 

• Once you reach a certain level, one must develop a healthy respect for the data, and you become a more seasoned technology professional in similar situations. 

• When your blast radius is smaller, tinkering becomes ok.  But when the blast radius becomes larger, exercise caution. 

• Andy makes the point that for some IT professionals today the blast radius could be the entire US west coast when working for a major cloud provider. 

• Backup is nice, but recovery is what people really want in a tough situation. 

• Andy worked for the school as a full-time contractor for a couple of years. 

• He began doing a little work on the side during this time, picking up odd jobs. 

• Andy did some work for a different school system in the area and for a manufacturing company where some of his friends worked. 

• Andy’s friends knew the folks in IT and got him on as a contractor.  This experience led to his later full-time role for a manufacturing company. 

• It was a big jump from supporting a school system in IT to supporting a large manufacturing company. 

• This was a big jump into the corporate space and had a very different user base. 

• Andy worked for a branch site (a single plant) at the manufacturing company and was not part the larger team that services the entire organization.  The plant Andy supported had 400-600 users, and his team answered to the larger corporate IT organization. 

• Looking back, he is thankful he was not part of the larger IT organization.  It was a good introduction to corporate culture, budgets, etc. 

• Andy and his team remained pretty autonomous as long as they met certain criteria with the exception of software licensing being controlled by central IT 

• Andy and team even ran their own Exchange server for the plant at the time. 

• There were sometimes mandates that came from corporate IT, but if Andy and team needed to buy new physical servers, for example, they had their own budget and reached their own decisions with very little input from corporate IT. 

• Nick makes the point that while someone can be a very talented machine operator out in the shop, that person may not be extremely computer savvy (seems more prevalent in manufacturing than perhaps in other fields). 

• Andy agrees based on his experience.  Most people knew how to open and use the programs the needed to do the job well enough, but that was really it. 

• Nick suggests there was an element of education in Andy’s role at the manufacturing plant to helping end users that is not vastly different than what he does now. 

• Andy was one of the first to volunteer to go and help people, fixing the issue for them and teaching them what to do if it happens again.  The teaching aspect has always been a passion for Andy. 

• John points out that we learn the things we like early on and then tend toward those directions and areas as we progress. 

• Andy was with the manufacturing company for a couple of years.  The manufacturer was in automotive supply chain, and Andy was there in 2007 around the time with the automotive industry started to struggle quite a bit.   

• This was around the time the housing market struggled / began to struggle too.  Consumer spending in a lot of areas slowed down considerably. 

• Andy’s company started to struggle a bit.  He was a contractor at this time (in 2007) and received an e-mail letting him know “next Friday is going to be your last day with us.”  

• Andy refers to this as being a line item on a spreadsheet and nothing more. 

• Andy remembers reading the e-mail.  It felt like the earth fell out from beneath him.  Andy was married at the time (no children yet), but there was a very real fear that took over. 

• Andy started applying for any role that looked to be a fit for him in the IT space. 

• Andy ultimately ended up at a MSP (managed service provider) and was no longer a contractor (full-fledged employee this time). 

• Andy started as a System Engineer Level 1 and ended up working at the MSP for around 10 years in various roles. 

• The job at the manufacturing company was where he began the transition from desktop support to dabbling in server related items like Active Directory, Exchange, and Sharepoint. 

• The MSP really broadened Andy’s experience because when you work for a MSP you touch a lot of different stuff for a lot of different organizations. 

• At this point Andy was looking for a full time position (having been married not long before).   

• The contract positions earlier in his career allowed flexibility and multiple experience, but with priority shifts to providing for a family, the benefits that come with being a full-time employee were needed. 

• Andy was unemployed for less time than he was expecting (turned out to be only about 6 weeks). 

• His direct boss at the manufacturing company graciously gave him 2 weeks notice before his job ended.  That was pretty impressive considering Andy had domain administrator access.  He and his boss also had a great rapport. 

• Andy was more concerned with how he would pay rent and how he would live and didn’t have time to get depressed about it.   

• He was confident about what he could do but needed to find someone to pay him to do it.   

• There was definitely fear involved, but he didn’t let it become a focal point. 

• After Andy read the e-mail about his employment coming to an end he walked into his boss’ office to see if there’s anything that could be done differently. 

• The boss shared that every department was being asked to slash budgets by around 20-30%.  Andy was the low man on the totem pole in the local IT group. 

• After this conversation, Andy understood it wasn’t him but rather an external factor beyond his control. 

• Andy got a good reference out of this situation, and it worked out well for him. 

• There are many who apply to hundreds of jobs and don’t hear back from prospective employers (depending on the market at the time).  John has talked to a number of people and then looked at their resume only to realize the person didn’t format it correctly to highlight their top skills. 

• None of us tends to be an expert at finding another job (with the possible exception of contractors who have to find the next job before the end of their existing contract is up). 

• It’s kind of like being in sales as well as the business of your trade at the same time. 

• Nick believes past guest David Klee would have some comments to make on this.  Listen to David’s experience as a consultant and starting his own business in Episode 119 and Episode 120. 

• Once John got into technical sales, he looked at his resume and job hunting in a totally different way, trying to sell recruiters on the resume. 

• It’s one thing to sell a technical solution that solves a problem.  Don Jones advised in Episode 137 to know the problem you solve.  Episode 137

• Working for a MSP is kind of a mixed bag.  They have the reputation of get as much accomplished as possible with as few engineers as possible.  The flip side is you’re going to learn more about general IT than you may have ever wanted to know. 

• At the branch of the MSP where Andy worked, they supported several nonprofits of varying sizes with shoestring budgets. 

• This was the first time in Andy’s career that he truly saw the impact of his work with end users at these companies (i.e. helping these nonprofits further their purpose). 

• Andy moved up from Systems Engineer to Virtual Systems Administrator (or VSA). 

• He would get assigned organizations that were large enough to see benefit from having a Systems Administrator but did not want to hire their own. Andy was the stand in Virtual Systems Administrator for about 15-20 customers. 

• As a result of this change, Andy relocated to be closer to the MSP’s main office and gained experience serving customers in various industries (government, manufacturing, education, service organizations, etc.).    

• Andy split his time 50/50 between remote support and in-person support of the customers (most were local to the area) with the end goal of being able to support all customers remotely. 

• There was little to no travel involved in Andy’s previous roles. 

• This was the phase of Andy’s career where he was extremely “hungry,” wanting to go and learn everything he could (in new areas like storage, SANs, networking, etc.). 

• He would shadow other engineers frequently and ask questions about the work people did. 

• Andy’s management at the time recognized his ambition and gave him the opportunities to advance.  Any time he was promoted was always a direct result of Andy pushing to learn more or advocating for himself with management. 

• By the end of his stint at the MSP, he was a Senior Cloud Systems Administrator. 

• The MSP owned and operated a very large datacenter running vSphere that hosted a number of customer-facing services (file servers, RDS farms, anything customers did not want to host themselves). 

• This highly redundant, multi-tenant environment was an area of extreme focus during Andy’s last two years with the MSP (which made for a huge blast radius).  It supported about 50 customers. 

• For Andy, all of the growth was really about learning.   

• The title changes and pay raises were a nice perk to continuing his learning.  He looked at the growth from the standpoint of being a provider also and what he could do to better provide for and support his family. 

• At one point during his stint at the MSP, he was a manager.  Nick remembers hearing about this from Andy’s AmpNavigator 2021 talk. 

• Andy was growing tired of being on call and the 2 AM phone call about something being broken. 

• He was getting tired of being the guy in the trenches turning the knobs and running the scripts. 

• Andy was already looking for what might be next for him. 

• He had become aware of Microsoft’s (at the time) Tech Evangelism team and remembers seeing a webinar with Simon Perryman. 

• Andy was hosting a weekly education session for the rest of his peers at the MSP on some technical topic or a best practice and thought it would be interesting to do this as a job. 

• At the time, Andy pitched the idea of him being in an evangelist type role to the MSP, but they didn’t like it.  That would be taking someone in a role with billable time and turning it into non-billable time. 

• The company didn’t want to lose Andy, so they made him the team lead of their NetOps team.  He stayed in this role for about a year before moving to his next company. 

• The hardest part about moving to the team lead position was going from friendly co-worker to the person assigning tasks to others and asking people to stay after hours to fix something. 

• Andy tried to make up for it by letting people come in late if they had stayed after hours (remembering his days in that same role as the break / fix technician).  

• Andy managed the team’s personnel resources but also acted as a technical backstop for the team of 5-6 people. 

• Career progression, whether as an individual contributor or as a manager, generally involves increasing your blast radius.  That can be in the form of taking on more responsibility (i.e. going from answering questions for end users to being responsible for a large datacenter’s operations like Andy did). 

• Sometimes you need to move to a bigger stage to enlarge the blast radius.  And that could mean moving into management, for example. 

• Any time Andy made a change in his career (new role, new company), he took time to understand the responsibilities this would require to ensure he was ok with it before saying yes. 

• This goes back to Andy’s experience early in his career with deleting the application share when he was working for the school.  It taught him there were consequences for certain things. 

• Taking on additional responsibility without the systems in place to support the enlarged blast radius would increase the changes for mistakes. 

• When thinking back on the massive datacenter he managed, Andy says N + 1 was not enough.  He wanted N + 2. 

• Episodes mentioned in the outro: 

• Episode 76 with Josh Fidel - on the sphere of responsibility 

• Episode 42 with Ethan Banks - on getting to management 

Contact us if you need help on the journey.