Leadership Lessons from Ben Burgett: Tell a Good Story

I started at IGS in March of 2016. It was a really exciting time in my career. It felt great to join a company that had recently won a “best places to work” award. That being said, there was a lot of work to do from a technical and personnel perspective and I was a bit anxious to get started.

I decided to begin by collecting information about each team member about their primary concerns. Overwhelmingly, they cited a lack of system redundancy and disaster recovery processes. All of our systems operated out of our primary data center in Dublin, Ohio with our backups stored at a nearby colocation facility. We didn’t have near enough capacity at the offsite facility to restore our critical systems. This was clearly less than ideal.

Working in IT Infrastructure, we often have to strive to have our best work go unnoticed. Our team could have implemented a robust disaster recovery program without anyone knowing it existed. That being said, it was clear we needed to focus on copying our systems and network to a geographically redundant data center.

We researched and tested solutions over the next few months. We felt we landed on a robust solution that would help our organization recover in the event of a serious issue. We felt the solution was pragmatic. We weren’t spending unnecessary funds but also weren’t cutting corners. Unfortunately, the solution still had a hefty price tag.

I had no idea how to sell this investment to our Executive Team. Even though we had a formal “project charter” process as a mechanism for this type of project, I wasn’t sure exactly to present it to the group. I started to put together a slide deck but didn’t feel great about it.

I ended up reaching out to my coworker Ben Burgett. Despite the fact that Ben worked in a completely different area of IT, he was always my primary sounding board for anything that was user-facing. Ben reviewed my pitch deck and tore it apart. He told me not to overthink it and just tell a story about how we discovered this problem, talked about our research and then presented our solution. If I used storytelling to make a compelling argument, nobody would bat an eyelash at the cost.

Ben also advised me to make the problem personal to the Executive Team. For example, how would this risk impact them if it came to fruition? He ended up advising me to tell a story about what would happen to the executives if we encountered a disaster TODAY and then what it would look like if we implemented our solution.

I ended up completely reworking the slide deck into something I felt confident in. I started my presentation by presenting a hypothetical disaster involving the destruction destroying our building and collocation. The “fake” disaster concluded with me calling the executive teams to notify them of the problem and state that I was not confident WHEN or IF we could bring our systems back online.

I quickly transitioned into talking about when we identified the problem and our research process for identifying a solution. We talked through different types of DR solutions and why we selected a “warm site” using cloud technologies. We also discussed our testing process and why we felt comfortable with the solution. As Ben predicted, by the time I got to the part of my presentation where I discussed the cost of the solution, nobody questioned the need to make the investment. The team began implementing the solution shortly thereafter.

Although Ben no longer works at IGS, I still pick his brain often about how to approach a particular situation and greatly appreciate all of his advice.

Leadership Lessons from Brian Wrobel and Robert Schmidt: Show Up

One evening at 10:45PM, I received a phone call from a colleague. Before I even answered the phone, I knew it was bad news. My colleague’s first words were to ask if I was sitting down. OK, it clearly was very bad news…our file server experienced corruption and we lost access to the data.

This particular system had already identified as a risk to the organization. We knew about the system’s fragility and were working to improve its reliability and redundancy. We knew that any issue affecting this system would bring our company’s productivity to a halt. In short, this was as bad as it gets.

I arrived to the office at around 11:15PM. I made a few phone calls and notified the IT department of the issue via email. By 11:30, I saw a familiar face. It was Brian Wrobel. He had a bag filled with energy drinks and candy. He pulled up a chair to my desk and made it clear that he was here to support us in any way he could. Brian wasn’t going to leave until we did.

By midnight, I saw another familiar face. Robert Schmidt arrived with another bag filled with candy and energy drinks. He also made it clear that he was in it for the long haul. Both Robert and Brian serve on different teams within IT. The problems we encountered weren’t directly theirs to solve. It would have absolutely been sufficient if they simply offered us positive vibes and well wishes from their homes.

Robert and Brian stayed with us throughout the night. They offered guidance, support and encouragement. Their actions minimized the impact of the issue and allowed some of our critical business processes to complete. Even as the sun started to rise and the reality of the situation set in, they maintained their positive attitudes and offered continued support.

Before this outage, I honestly don’t know if I would have followed Brian and Robert’s actions under similar circumstances. So many times throughout the day we see opportunities to help and support others but let those opportunities pass. Brian and Robert have inspired me to be not just a better coworker but a better person. I may not be able to pay them back but I will absolutely try to pay it forward.

Leadership Lessons from Cindy Hom: Celebrate Success

I graduated from Ohio University in the summer of 2008 which was just a few months after the collapse of Lehman Brothers. Despite having a degree in a cutting-edge field, I really struggled to find full-time employment. After applying to hundreds of jobs, I was hired by a medical care management company called American Health Holding (AHH) as a Technology Support Analyst.

I had a difficult start at AHH. Even though I had obtained my degree from OU, I was unprepared for the workforce and lacked some of the key technical skills required for my entry-level position. Since I was making minimal contributions to the team, I struggled to establish meaningful relationships with my peers. My confidence was shot to the point where I wondered if I even had a future in technology.

I attempted to make up for my lack of experience by having a strong work ethic and positive attitude. I was able to leverage the customer service skills (and patience) gained while working for my family’s retail store in high school to provide a solid experience for my internal customers at AHH. I may not have been able to have been the fastest to find a solution but I always tried to convey a sense of empathy and urgency. I finally felt like I was finding my place within the organization.

I received a call from our Vice President of Sales (Cindy Hom) about 6 months after joining the company. Her laptop hard drive died while she was on the road. I tried to resolve the issue remotely but was unable to fix the equipment. I quickly configured a replacement laptop for her and overnighted the workstation to her hotel. I didn’t think much of the situation at the time. I was just doing my job

AHH was family owned business. It started with just a few people in the 90s and grew to over 450 employees by the time I joined the organization in 2008. Our CEO (Michael Reidelbach) made an effort to get to know each and every one of the 450 team members. There are only so many hours in the day and I hadn’t had a chance to meet Michael and a majority of the other Executives despite working at the organization for a few months.

This all changed when I received a random email from Cindy. She was so impressed with laptop replacement process that she felt compelled to email Michael and the rest of the Executive Team. Michael and the other members of the senior leadership team replied to the thread to thank me for getting Cindy back up and running. The email probably only took Cindy a few minutes to write but the gesture meant the world to me. As I mentioned earlier, just a few months I had been wondering whether or not I belonged in the field. I finally realized that I was exactly where I was supposed to be.

I often try to remind myself of the email that Cindy sent. The simple act of letting someone know that you appreciate them and their efforts has a lasting effect. What might seem insignificant to you might mean the world to someone else. Take a little extra time and be more like Cindy.

Lessons in Leadership from Brandon Childers: Be a Duck

At one point while working for IGS Energy, our Chief Technology Officer (Brandon Childers) pulled me aside to let me know that I would be added to a meeting later that afternoon. This meeting would be the kickoff of a huge project that would impact every employee in the organization. Due to the nature of the project, it was abundantly clear to me that the IT team would play a large role. I was freaking out.

I’ve been told that I have the world’s worst poker face. It must have been abundantly clear that I was already panicking about the upcoming endeavor. I knew it would be a lot of work for us and we were already stretched a bit thin. Brandon easily sensed my discomfort and proceeded to advice me to “be a duck”.

I had no idea what he was talking about. Why should I pretend to be a duck? Brandon explained that a duck may appear to be calm but underneath the surface they’re doing everything possible to tread water. They inadvertently project a sense of calm despite the fact that they’re literally struggling to keep their head above water.

It became clear to me why I needed to project a sense of calm to the IT team members and the rest of the organization. As a leader at IGS, my actions and attitude can be contagious. If I appeared to be panicked or stressed, it could spread to the rest of my team and perhaps others in the company. This conversation with Brandon made me realize that I was worrying about things that either won’t happen or were beyond my control. Instead of wasting time getting worked up, I realized that I needed to take a step back by beginning to understand the project and working with my coworkers to start solving the problems one-by-one.

Over the next few weeks/months we met put together comprehensive plans for the project. I immediately started to feel at ease as we broke down the work into digestible chunks. Once we started to execute on our strategy, I felt even better about our ability to meet the aggressive timelines. At one point, I wondered why I even let myself get so worried to begin with.

When in doubt, be a duck.

Leadership Lessons from Paul Bahler: Plan for the Worst, Hope for the Best

I’ve been working with Paul Bahler at IGS for almost 4 years. During a majority of that time, Paul has lead our IT Operations team which includes Database Administration and DevOps. I’ve seen Paul lead our department of over 125 talented individuals through major accomplishments and incredibly difficult situations. Regardless of the outcome, I manage to learn something from Paul’s years of experience.

When I think back about the key lessons that I’ve learned from Paul, the first story that jumps out was when we were in the process of launching a new website. This launch involved using technology that the team was unfamiliar with and we had encountered several unforeseen issues. In short, we were behind schedule and in danger of missing a critical deadline that had been communicated externally.

In a situation where deadlines will likely be missed, people have a tendency to still move towards the happy path. One of the key lessons I learned from Paul during this issue was how quickly he forced all of us to consider what failure would look like. Instead of simply pressing forward and hoping for the best, Paul asked us to come up with a contingency plan in case we were unable to hit the deadline. Based on the information we discussed, we realized that failure was not an option for our team but we learned that we could make some concessions in an effort to reduce some of our workload until after the launch.

The prospects of missing a deadline and/or cutting corners increased the tensions among the team. At the first inkling of conflict and finger pointing, Paul immediately squashed it. He didn’t dismiss the fact that we needed to make improvements to ensure that we didn’t find ourselves in this same situation during our next big project. Instead of looking back at the root cause of our problems before even we completed the project, Paul suggested that we hold a formal “retro” at the conclusion.

Fortunately, we launched the website on time and without any major hiccups. The project team met at a restaurant a few weeks after the site went online. We discussed what went well and most importantly the areas we could improve. I remember walking away from that meeting feeling a lot closer to the team along with a sense of what I could do better next time.

While I hope I don’t have to use these lessons in contingency planning and continuous improvement anytime soon, I’m really glad I have gained this perspective from Paul and look forward to working with him for years to come.

Leadership Lessons from Kim Rometo: No Surprises

A few years ago, I participated in a panel discussion in front of Ohio University students with Kim Rometo. Kim and I went to grad school together and she has one of the coolest jobs in IT (CIO of the Miami Dolphins). I really enjoyed some of the lessons that we were able to share with the undergraduates. At one point, I mentioned to Kim that I wish I had received the same advice when I was in their shoes. She responded by saying that we probably had but were too stubborn to listen.

Kim shared some valuable lessons during the panel discussion. The first was a credo that was adopted among her team. “No surprises” has a multitude of meetings for Kim’s team members. They use this saying to make sure that their leadership team is never blind sighted by a particular issue or outage. Few things make your boss look more unprepared than finding out from a 3rd party about an issue that occurred within their team. While it can be difficult to balance fixing a particular problem while sharing the appropriate details, effective communication a key component of crisis/incident management.

As I transitioned into leadership, one of my biggest challenges was to stop performing the actual technical work. This was especially difficult during a systems/network outage. I thought I was being helpful when I jumped in to address the problem but I was actually creating additional challenges. I eventually realized that my role in those situations was to make sure that my team had the necessary support that they need and that the organization (including my leadership) was not “surprised”.

It’s also important to proactively identify issues before your business partners discover them. This could be something as simple as implementing a monitoring solution that focuses on user experience. Customers tend to be a lot more patient and understanding when the issues are brought to their attention with transparency and tact as opposed to them being the one to identify the problem. Nobody likes surprises.

The second lesson that Kim shared was not to bring up problems without offering solutions. There are few things more frustrating in the workplace than a team member who consistently complains about a particular issue without demonstrating any ownership or offering a potential solution. For the most part, people within an organization want to do the right thing but are faced with complicated decisions. You’ll often find they will genuinely appreciate any feedback that you have especially if you have an idea for how to improve a particular situation. However, simply complaining for the sake of complaining doesn’t help anyone (including yourself).

Leadership Lessons from Mike Luck: Eat Your Own Dogfood

When My Great-Grandfather (Joe Luck) started selling work boots in 1919, he used a pushcart to get his product to Akron rubber workers. 100 years later, Lucky Shoes is still owned by my relatives and has almost 20 locations around the state. My Father and Uncle also owned/operated a chain of Stride Rite shoe stores in Columbus from 1983 until 2011. I worked part-time at my family’s shoe store while I was in high school and learned more about business in the process than I did in 4 years of college.

At one point early in my tenure at the family business, I showed up to work wearing a brand of shoes that we didn’t carry. My Dad (bluntly) told me that I should wear the brands that we were trying to sell. If our customers didn’t think that our own family wore the shoes, why should they? This was my first lesson in the importance of eating your own dog food.

This has a clear translation into IT. We are often put into situations where we gain early access to the latest/greatest equipment before the rest of the organization. There can be value in IT testing the newest model laptop or piloting the largest monitor. However, this can easily create a sense of resentment among your customers.

Also, due to our administrative access, we can often circumvent critical security controls that are leveraged by the rest of the company. If we aren’t willing to follow the same rules, why should our customers? If the rest of the organization finds out that the IT team is taking shortcuts to avoid security controls, this will just increase the likelihood that they will make poor decisions to circumvent the controls that were originally put in place.

If the rest of the organization thinks that we don’t use the solutions we support, why should they?

Leadership Lessons from Terry Francona: Learn by Observation

I recently had the opportunity to see Terry Francona speak to a small group of IT professionals. Terry geared a lot of his conversation towards his approach to leadership. One of the key concepts that initially jumped out to me was the fact that he focuses a lot on creating a culture where the team “wants to come to the ballpark every day and do the right thing”.

When I first became a hiring manager, I focused too much on technical aptitude during the interview process. I asked detailed questions about a particular system or network but didn’t spend much time talking about how they approached situations or problems. While we ended up hiring folks that were experienced, in some cases, they lacked a genuine passion for technology. In more extreme instances, they didn’t work well with other team members. I obviously needed to make some sort of adjustment.

Fortunately, I heard Terry Francona speak at the right time in my career. I’ve focused more on hiring the qualities that can’t be easily coached or developed since that event. This has led me to work on finding individuals that are curious to find out how technology works as opposed to just technicians that have obtained massive amounts of knowledge. I also try to gauge whether or not the candidate operates with a level of integrity. These adjustment have helped create a culture where all of our team members that want to come to work every day and do the right thing for our customers.

Another lesson that I learned during this talk was to learn by observation. Terry Francona mentioned all of the managers that he coached with and played for during his career. He said that he learned a lot about how to be a great coach by playing for great coaches. You might not ever get the chance to sit down and have a career-focused conversation with someone that you admire. Fortunately, there is ample opportunity to learn from the example that they set and how they approach a particular situation.

Through observation, you can also learn valuable lessons about what not to do. This part of the conversation reminded me of times in my career where I worked for less than stellar bosses. I took the time to think about what they did in particular that I found demoralizing. It made me realize that I need to keep in mind not only what motivates a team but what could demotivate them as well.

I had hoped to just shake the hand of a future hall of famer but I walked away with some lessons in leadership that will hopefully serve me well for the rest of my career.

Leadership Lessons from Jim Williams: Give Praise in Public, Reprimand in Private

I can definitively say that I would not be where I am today without Jim Williams. I first met Jim in 2008 when I accepted an entry-level role in Jim’s IT organization at American Health Holding. Despite the fact that my initial responsibilities centered around technology support, I was encouraged by Jim to assume responsibility for Systems Administration and Information Security. Jim’s encouragement enabled me to expand my skill set which ultimately allowed for continued advancement in my career.

2 years after I joined American Health Holding, I was promoted to oversee the entire Infrastructure team. Jim made the decision to promote me despite the fact that I did not have any formal leadership experience and had just graduated college a few years prior. Looking back, I’m confident that Jim saw something in me that I didn’t see in myself. Shortly after my promotion was announced, Jim pulled me aside and told me, “I am going to teach you more about leadership in the next 5 minutes than you learned in any management course you took in college.” Sure enough, Jim explained several management fundamentals that not only enabled me to be successful at American Health Holding but in all of my future roles.

One of Jim’s key lessons was to “praise in public but don’t be afraid to reprimand in private”. Throughout your career, you are going to run into situations where you must take full responsibility for one of your team member’s mistakes despite the fact that the situation was beyond your control. By not reprimanding the individual in public, you will allow them to save face and quickly rebuild their reputation. That doesn’t mean that they can avoid accountability but that discussion should remain private.

Another lesson shared during that initial meeting was to “share the credit but accept all blame”. There are few things more demoralizing than when your boss steals credit for your idea or hard work. I had it happen a few times during my career and I really struggled with it. That being said, few things made me work harder than recognizing that my boss fell on the sword for one of my mistakes.

I don’t think I’ll be able to ever pay back Jim for all the help and guidance he gave me throughout my career. However, I will absolutely try to pay it forward.

Recommended Reading For IT Leaders

A co-worker of mine (Rick Kierner) challenged me to read 24 books this past year. I completed the challenge with just a few days to spare in 2018. I ended up reading some great books that offered valuable perspective. Here’s a brief list of some of the books that I think other IT leaders might find interesting…

  • The Goal by Eliyahu M. Goldratt, Jeff Cox – The Goal came highly recommended by a coworker of mine. It chronicles a fictional character’s struggle to save a factory in his home town. I found myself fully vested in the book’s main character as he looked to find balance in both his personal and professional lives. Despite the fact that the book focused on a manufacturing plant, a lot of the lessons learned applied to leading technology teams.
  • 5 Dysfunctions of a Team by Patrick Lencioni – This book is a fictional account of a CEO that takes over a struggling technology company. The main character quickly finds out that they need to work through some core personnel issues if they are going to succeed. The book offers lots of practical advice on how to overcome dysfunction and build a high-performing team.
  • Phoenix Project by Gene Kim – I can’t say that everyone would be enthralled by a novel about an IT Operations leader struggling to stabilize his company’s core systems. However, I really enjoyed this book and found that it outlined a lot of great methodologies for streamlining and optimizing IT Infrastructure.
  • How to Win Friends and Influence People by Dale Carnegie – I’ve read this book several times and always manage to learn something new. Despite being written in 1936, Dale Carnegie’s lessons still offer a lot of value today.