Leadership Lessons from Brian Wrobel and Robert Schmidt

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.

Lessons in Leadership from Paul Bahler: Contingency Planning

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.

Lessons in Leadership 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).

Lessons in Leadership from My Dad: 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?

Lessons in Leadership from Terry Francona

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.

Lessons in Leadership from Jim Williams

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.

FedEx Days at IGS Energy

Google is known for allowing their employees to devote a certain amount of time to work on projects that might not pertain to their day-to-day responsibilities. This practice gives Google team members an opportunity to flex their creative muscles while providing them with the freedom to work without limits. It has lead to the creation of several successful products (including Gmail). Following this same model, FedEx days (also referred to as ShipIt days) are typically a 24 or 48-hour period where employees are allowed to create and innovate with very little parameters or instructions.

Several months ago, it was decided that the IT department at IGS Energy would hold their own FedEx days. The idea was announced to our entire team at a department meeting. In the days and weeks leading up to the event, additional details were shared with the group. These details included a few rules.

IGS FedEx Days Rules…

  • We could work on anything we wanted as long as it’s not part of our regular job.
  • We could work in our system or work area, but not on items in our current backlog
  • The official clock started on a Thursday @ 2pm
  • We couldn’t start creating prior to 2pm but we could research
  • We had to show what we created or learned by Friday @ 4pm by creating a 2-minute video highlighting our work and outcome
  • Not everything will be a success, but often failure teaches us the most.

I wasn’t sure if I was going to participate at first. I had a lot of work to catch up on and could have used some time to focus on a few tasks. Fortunately, I was encouraged by a few co-workers to participate in the event. That left me with a  very important decision…what should I create?

About 10 months ago, I found myself in a situation where we needed all hands on deck to help solve a production issue. Since the issue occurred on a Sunday afternoon, it took me roughly 45-60 minutes to call everyone and explain the situation while discussing our next steps. I decided to spend my time calling instead of sending emails and text messages because texts/emails can be easily overlooked on a weekend. Afterward, I thought about ways that I could automate that process but I never really had time to devote to solving that particular problem. I decided this would be my challenge for FedEx days.

Before joining IGS, I wrote Python apps and lengthy PowerShell scripts but it had been about 2.5-3 years since I had even touched a piece of code. The idea of writing and deploying an app in 36 hours was really exciting. However, I wondered if I could actually get the work done in that short of a time-frame. I ended up partnering up with one of our Directors of Application Development (Matt). It had been about 10-15 years since Matt had written a line of code as well. We knew we had our work cut out for us but figured we would start by identifying our application’s requirements.

The requirements were really pretty straightforward…

  • The program should automatically call a list of people and play a brief message for them
  • The message should notify them there is a critical issue and that they would receive a follow-up communication with further details
  • The program should send out a text message & email with information about how to dial-in to a conference bridge
  • The program should be easy and quick to execute
  • The program should send out a Tweet when executed…because…why not?

Over the last few months, I had seen blogs about how people have creatively used Amazon Dash buttons to automate tasks. In fact, Amazon now sells AWS IoT Buttons that can be easily connected to AWS. This seemed like a fun way to kick off our process. Matt was responsible for connecting the button to AWS and ensuring that it could execute my python script.

A FedEx days project should celebrate failures. I would have been perfectly content if I gave this a shot and didn’t produce a working product. I was happy to just spend some time writing code and solving a problem with technology. Fortunately, thanks to some extremely helpful Python libraries and technical blog posts, we had a working script in just a few hours. After a few additional hours of tweaks, we even had the script executing from AWS after pressing our IoT button! We knew that there were potential improvements to make but we had solved our initial goal!

When it was all said and done, we had the following components in our solution…

  • AWS IoT Button – used to kick off our process
  • AWS Lambda – used to host and execute Python script
  • Python Script
    • Trello – used to make a phone call and send a text message
    • Tweepy – used to post a Tweet to my personal account
    • SendGrid  – used to send an email
  • Digital Ocean Web Server running Apache – used to host XML configuration file that was leveraged by Trello

We didn’t end up filming a video. This is mostly because Matt and I had to fit in a few meetings leading up to the final presentation. It also was a result of us making code changes up until 15 minutes before the projects were due. The lack of a video left us with a much more exciting yet nerve-wracking opportunity…a live demo.

We hadn’t tested the IoT button outside of Matt’s office and were a bit nervous about the recent code changes that we had made. We ended up configuring the script to call 16 people that we knew would be in the room during the presentations. When Matt pressed the button, I braced myself for the fact that the indicator light might turn red and the script wouldn’t execute. Sure enough, the light turned green and phones around the room started to ring. My Twitter account even sent out a test message (below). It was awesome.


There were a bunch of other great projects ranging from mobile applications to unique experiments involving spare laptop batteries. I was really proud of everyone that participated, particularly those that I work closely with on the Infrastructure team. Overall, I had a great time, learned a lot and I’m really looking forward to our next FedEx Days.