Episode 172
# Episode 172
Welcome to episode 172 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 an interview with Evan Oldford, talking through his early career as an intern, a software engineer, life through acquisition, and a transition into people leadership and escalation management.
Original Recording Date: 04-21-2022
Topics – Meet Evan Oldford, Internships, Full-Time Employment and Moving on, Break into Software Engineering, People Leadership and Learning, Thoughts on Acquisition, Escalation Management as a Role and General Tips for All, Managing Stress through Daily Practice Evan Oldford #Cisco
===========================
# 02:51 - Meet Evan Oldford
Evan Oldford is a Senior Director at Cisco Systems of an Escalations group. His engineering team takes issues from support into engineering and they focus on restoring service for customers in the security domain.
People don’t always know what we mean when we say engineering as it relates to a software company. We did interview Mike Wood in Episode 168 and Episode 169 to discuss his experience in software engineering. Episode 168 Episode 169
Evan’s interest in software development date back to college days in the mid / late 1990s when he got his first distribution of Linux and tried to install it, slowly proceeding down the rabbit hole of learning.
He later got into shell scripting in one of his courses.
Evan was an economics major who minored in computer science.
# 04:45 - Internships
During college he picked up two internships.
One of the internships was for Sun Microsystems doing some preliminary development on Netscape Server (before the Netscape Navigator browser launched).
The next summer, he found an internship in the newspaper that also helped set him on this path into software development.
Evan survived the .com boom and bust and got to see the proliferation of how fast things were changing on the internet
We mentioned Mike Wood got in on the early days of the .NET framework and Visual Studio. Evan veered more toward the scripting side, things like Bourne shell, Perl, and eventually C and some others.
Even liked to have a book in one hand, a keyboard in another, and sometimes a debugger…it was trial and error learning.
This fast feedback is what we might classify as deliberate practice. For example, Evan encourages programming “Hello, World!” in as many languages as you can.
Evan did an internship at Whistle Communication. Think of it as an all-in-one (web server, e-mail server, firewall server) solution.
A VP at the company encouraged Evan to quit school, but Evan was not ready to do that. College is where he met his wife.
Evan worked for Whistle over the course of a couple of summers and was able to shadow some extremely smart engineers, learning a lot by looking over the shoulder of others.
After graduation, Evan went to his boss from the Whistle days and let him know about graduating. The former boss was uncharacteristically quiet. It turns out Whistle was going through a period of being acquired by IBM.
After about six months, the previous boss hired Evan in the division of IBM that Whistle became.
Nick points out the decision to continue working and quit school vs. the hybrid approach is a tough one. He mentions seeing Reddit threads quite frequently from people who aren’t sure what to study in school and wondering if they should enter the workforce.
Evan’s philosophy is he went to school for an education. He majored in economics but also gained experience with computers (programming, which seemed like a sure thing). That provided a different perspective. He liked the technical part but also got an education while he was at it.
Many people don’t fully leverage what they learned in school working toward a degree. Test, dabble, and learn as much as you can.
For the career side, find something that is interesting, and this usually sets you on a good path forward to soak up new experiences.
Don’t get too wrapped up trying to pick the perfect major. Go and try and bunch of different things.
In Evan’s case, this was a paid internship. He says it was very generous and way better than delivering papers, for example.
Internships are often underrated. You don’t need to know what you want your eventual profession to be. There is freedom to try things.
Evan wishes more people did more internships and didn’t reserve it just for college. Consider the folks looking to change careers.
During Evan’s internship, his experiences dealing with seasoned engineers was intimidating.
Some are not necessarily there and invested in teaching you (as an intern). Others, however, will be open to spending an hour to explain things in more detail. You will probably see a little of everything.
Try and find engineers invested in letting you learn and try out things in a sandbox that isn’t production. You can learn a lot from this experience.
# 12:26 - Full-Time Employment and Moving on
After getting a full time job at Whistle (a result of his internship), it was sort of a continuation of what he had been doing.
There was a lot of prototyping and testing, which allowed full stack troubleshooting. Evan has kept down this path throughout his career.
Nick feels like Scott Lowe, host of the Full Stack Journey podcast would be smiling to hear about the full stack focus.
The focus on the full stack can in fact promote collaboration among teams.
Evan has seen software developers with a very myopic view, focused on the part of the system they touch and nothing beyond that, but this is a disservice. There is so much more than your own feature and your own area.
Look at what is adjacent for a better view of the full stack.
Evan thinks you can flip a coin between generalist and specialist and be right on both sides.
Some will want to hyperspecialize and be the very best at one small area, only focusing there. And there is absolutely a market for it.
There is also the generalist who wants to touch everything, and that can also work very well.
It depends on how you want to scratch the itch and what feeds your interest.
Generally speaking, there is more demand than supply, which allows you to find a home.
This was around the time when 802.11 wireless was becoming much more popular.
Evan moved from Whistle to a software vendor (Vernier Networks) that was focused on mobility and wireless. There were some engineers who previously worked at Whistle who helped Evan transition.
It was a great learning experience. He was able to get deeper into the systems.
Shortly after this, the manager who had hired Evan into Whistle previously (and his manager for the aforementioned internship) was working for a startup that did e-mail (IronPort Systems), had an opening, and asked Evan to come in for an interview.
Evan had e-mail experience, which was a plus. The role was an Application Engineer, but effectively the role was to troubleshoot the system (which was based on FreeBSD).
# 16:44 - Break into Software Engineering
The tools these days such as IDEs (integrated development environments) make it easier to know syntax for various programming languages.
Start with something that is interesting to you. With open source software, you can get visibility into all kinds of really interesting areas.
Then start breaking it down into smaller parts to figure out how it works (how eventing works, for example). Rebuild from there.
Evan is a big fan of learning from books, specifically O’Reilly books, and then going and doing.
Some others may prefer a more structured course curriculum. Identify the format you prefer, and start clocking the hours to get to your 10,000 hours.
How can those who have a love for scripting much like Evan progress into software engineers?
On the scripting side, look at the problem you are trying to solve. If you then start unpacking some of the scripting, you will eventually run into a limitation of what the script can do.
From there, consider if it could be pulled into / rewritten in a different language. At the time of this recording python is very popular.
Take time to learn about the strengths and advantages of this other language.
Evan suggests trying to rewrite the script in multiple other languages (maybe python and perl).
When you do this, you will start going down the rabbit hole. You will learn about some strengths and deficiencies of the various languages.
Pick the right tool for the job, knowing that you do not have to force everything into one specific language. Tailor your project accordingly. Go and try to learn more.
Evan is very impressed by just how much learning can be done just by simple Googling. You can get some great ideas from what code is being posted.
Take these learnings and start building your portfolio line by line with different variants, techniques, and coding practices. Build from there.
A GitHub repo or something similar with your portfolio demonstrates you are proficient and trying new things.
There are a number of open source projects where you can contribute in the form of patches, testing, and translation.
Github is nice to demonstrate something you might not be able to from your 9 to 5 job (initiative to learn something new, build up your experience in an area).
It makes individuals who have proof of ambition attractive to a hiring manager.
It also seems like learning to code has become more prevalent within the technology industry.
We may not know as IT generalists what a developer does every day, but on GitHub, for example, there is an opportunity to collaborate and learn from others who are willing to share their expertise and experience.
Sometimes you will come across others who are not so generous with their expertise. That is ok. You need to have thick skin in those cases.
# 22:02 - People Leadership and Learning
Evan went into people leadership…a little bit by accident. This was during his time at IronPort, and he transitioned gradually (what he feels is the best way you can).
The manager who hired Evan asked that he step into that role.
From the first day to the second day he was still doing the same things. But it allowed him to start learning and acquiring some additional skills around what is needed. It is definitely a mind shift.
For the previous part of his career, he was all about acquiring technology, figuring out what could go in his technology toolbox. The learning accelerated more because of this.
On the management side, Evan needed to learn what was needed to make the individuals successful.
It was an interesting transition. Evan says people are wired differently, but it worked well for him moving into management.
Some people find that management is not their thing and they would much rather be an individual contributor.
Some individual contributors believe they can only be successful by going into management.
In reality there are two different ladders, the managerial ladder and the technical ladder. Pick the one that is right for you.
Nick says each ladder has a different element of leadership. Perhaps we have to decide how much of the hat to place on our heads.
You don’t have to have a title to be a leader. It comes down to the influence you have.
Whether people report to you or you are influencing through other means it is about how you are demonstrating it. There are two ways to demonstrate leadership, and you need not be a manager to do that.
Evan says he got lucky in that he had a great manager who trusted in his abilities. Evan’s resume didn’t really show that he was a potential manager.
It was sort of the stroke of a pen and there he was.
Evan says he had a lot of learning to do.
He turned to podcasts and books of choice to help here.
The manager tools and career tools podcast have been very helpful to Evan. He’s been listening since 2007.
John has referenced these podcasts a number of times on the show, and they are a great resource.
It surprises Evan that they give this content away for free.
After he started listening to the manager tools podcast, Evan started looking at others.
He also began reading more nonfiction on leadership principles and surrounding content. It helped Evan expand his perspective because you don’t always get the chance to gain the experience needed before going into the role. Going to books is a great way to get a perspective on a technology or idea without having the experience.
This has helped Evan learn more and really helped form his thought process over the years.
As for a reading medium, Evan says it depends. It’s going to be what works for you where you are at the time based on what you want to accomplish.
Evan listens to podcasts and Audible while doing chores around the house.
He also has the Kindle app on his iPad and likes reading it in dark mode because it can be read at night without turning on the light, working through a number of books this way.
Evan does not like bringing the iPad to the beach and uses paper books in this case.
Evan recently read Zone to Win by Geoffrey Moore. He started reading on his Kindle and then switched to the Audible version when it was time to run an errand in the car to keep going. Using multiple mediums can work.
The Kindle app is nice because you can highlight, take notes, and export.
There is another app called Libby that allows you to check out Kindle or audiobooks from local libraries. Even likes to take notes using this app as well.
Evan will also mark up physical copies of books with notes and highlights. When listening to a book, content goes a little too fast. He likes to hit pause and take a note in a Google Doc using his phone and come back to it.
Evan listened to our episodes on Deep Work ( Episode 141 - Episode 147) and hasn’t quite gone to that level of dissection. Episode 141 Episode 147 Cal Newport
Full credit to John White for building the notes we used for the format of episodes in the series. Smart Notes
Nick likes to take down notes in the notes app on iOS here and there to help remember the books consumed via Audible better.
Check out Evan’s list of book suggestions and his ratings here.
Evan got the role leading the same team he had formerly been a part of. The company was still a very small startup. When he joined IronPort, it was about 50 employees.
When you are a small startup everything is scrappy with most people wearing multiple hats. Being the manager was just another hat to wear at the time, and it wasn’t a big deal changing over with the team still being quite small.
Evan started with 1 direct report, and it quickly grew from there.
# 30:29 - Thoughts on Acquisition
Evan works in the Security business group at Cisco today. Ever since starting with his internships, he has been fascinated with firewalls and the underlying security of them, deciding to build his expertise there.
When Cisco acquired IronPort it was pulled into this business group, and Evan did not have to pick it himself. Over the years he has grown in scope and influence.
It seems like Evan’s experience going through acquisitions (two of them) were positive compared to other guests we’ve interviewed who maybe did not have the best experience.
There are lots of lessons learned going through an acquisition. Evan finds the acquisitions that work best are when you embrace the company doing the acquiring.
* At a startup, only the culture matters. You push away everything else. Those may not go as well over time.
People may resent the change over time to a new company and will leave.
You can still embrace the culture and see the positives of being acquired, even if you have to hold your nose through some of it (a bit of a bureaucratic tax that comes along with this process when being acquired by a larger company).
Some folks in management positions may be concerned about being cut when being acquired by another company.
Evan didn’t have that concern so much since working within the escalations group is not a popular place for cuts to happen.
This team is able to demonstrate value on a daily basis fighting whatever fires happen to come up. This is not typically the place where a company would look to optimize operating experience because it has been positioned to be quite valuable in the company.
This positioning of a team’s work as value to an organization is something Evan backed into by accident.
He feels he got lucky in picking a position that is aligned very well with organizational goals.
There are other positions inside a company that are more susceptible to boom and bust cycles than what Evan does (help keep the lights on).
# 34:31 - Escalation Management as a Role and General Tips for All
Maybe an escalation means something needs a higher priority than it has now?
It takes a certain character for someone to gravitate into the escalation management role.
Evan likes it. The adrenaline rush is measured in days and weeks to come to a resolution on things.
*In this role you have a good learning environment and have to solve a really tough, thorny problem once followed by working back into the system. Then you’re off again learning about the next crisis and the next new problem.
It’s incredibly satisfying learning and seeing new challenges on a regular basis.
It does not feel stagnant. You are always changing, always doing something new because you are fundamentally seeing new problems and working that into the system.
Not everyone is wired this way. Some people are long range planners that measure things in years, which is a strength.
Evan finds those who do well in the escalation engineer role are somewhat adrenaline junkies, and they like that shot in the arm daily.
Find the position for which you are wired. Evan gravitated to this, and it has worked well for him.
Nick likes the dynamic aspect to the role and feels the ability to impact products for a company and its customers by eliminating bugs is a huge contributor to job satisfaction (i.e. feeling you are making a difference).
Not everyone has the ability to see how their work is adding impact (depends on the company, the role, etc.).
Evan’s escalation team is the face of engineering. To be able to turn a customer around and provide a resolution is incredibly satisfying. Sometimes you will need to work with the engineers to connect the dots.
This reminds Nick of The Three Signs of a Miserable Job by Patrick Lencioni.
For the technologist, managing your own escalations can come down to communication, relationships, and building trust (could be related to technology failure or something else).
Think about other relationships you are building and the way you’re interacting with other parts of the organization.
In smaller companies you may not have to worry about cross-geography relationships. It could be much smaller and easier to build relationships, but it takes work to reach out and build the virtual rolodex that is your network.
How can we keep connections warm without being overwhelmed by the work involved?
It’s definitely work, and it’s definitely more.
Evan has found that if you don’t you will be working harder to try and accomplish the same thing.
You may be looking to get a certain process pushed through but figuratively banging your head against an organizational wall.
* If you had a connection that was on your program management team, for example, you could give them a call to ask for help. That will save you time but may not be apparent right now.
- Make investments now that you can go back and use later.
# 40:29 - Managing Stress through Daily Practice
Managing escalations does invite stress, and it can wear on you.
One thing that can help manage the stress is giving others access to information.
Evan does a daily report that goes through everything happening in the organization.
The daily report is a lot of work, but Evan has found that he sleeps really well at night. He doesn’t ruminate when his head hits the pillow.
This daily update, when deconstructed, is a form of journaling.
Evan highlights this daily report in a chapter of his book Ghost Rules: Unspoken Secrets of Getting Ahead.
Doing the daily report increases your visibility and value add to the organization. It also de-stresses you a bit because you are not thinking about the problems (i.e. got them out of your system).
Evan believes this is a superpower and competitive advantage over the years.
When you look at it, most people don’t report enough or communicate. This is a way to communicate, get your visibility, and de-stress all in one.
Nick likes the idea of giving someone an update before they need to ask you for one.
This also sounds similar to the daily shutdown routine Cal Newport mentions in Deep Work.
Evan says it is his shutdown routine each day and that it was nice to see the same advice from Newport (validation that he was on the right track).
Evan’s role at Cisco is incredibly flexible (a perk of working for them).
Evan likes to pop out of work each day, do dinner with the family, read with the kids, and put them to bed.
Then he comes online to wrap up the day and create the daily report to end the day. That’s his shutdown routine.
In Evan’s case, he could do it by 3 PM, but he’s still getting information coming in from the day until evening. And doing it this way helps him shut things down for the day.
The daily update needs to be somewhat brief as per the chapter on visibility through reporting in Evan’s book.
Consider it as needing to be short enough to read in line to get your coffee at Starbucks.
When doing this reporting, you are usually reporting up. The demands on people’s time are high. Distill it down to the bottom line / it’s very essence up front.
Evan tries to strip out all extraneous information to get it down to the most important bits.
He struggles with this need for brevity daily (as likely many of us do).
There is so much good that goes into resolving a big problem. You may want to outline the dynamics of the business situation or customers situation, but it is necessary to step back and ask yourself whether details being included are adding to the bottom line.
“It is a constant practice that does not come easy…at all.” - Evan Oldford
This is something we are all encouraged to do whether a manager or individual contributor. There is no need to copy the world but only those who need to know.
This is a great platform for you to be able to add your own insight.
One of Evan’s managers said he liked the daily update because he got smarter by reading it.
Your job with sending the daily update is to make your audience smarter, not just to call the balls and strikes that happened during the day.
Add some color commentary. The insights you add are a great way to demonstrate that you can provide meaningful updates.
Nick had not thought about the daily update being a way to decrease stress and as a form of journaling.
Evan has listened to a number of podcasts that highlighted being mindful and journaling as a way to do it. He thought to himself “I should start this.”
After thinking on it a bit, Evan realized he was already doing it (the journaling exercise he had heard so many mention, part of the daily update). Perhaps this is why he is able to sleep so well at night.