Career Story: Learning Technologies to Solve Business Problems (Part 1)

?? Author's Note:

Last week, I posted about beginning the process of switching careers from IT consulting to ClimateTech. In addition to developing role-based resumes that highlight my transferrable skills, I'm writing stories that showcase the diverse experiences I've had in my career to date.

Think of these as cover letter building blocks to provide more context on how I adapted to challenging situations, achieved successful outcomes, and learned from my mistakes.

Thanks for reading!

?? Introduction:

For Story #1, let's start at the beginning...

I never knew what I wanted to be when I grew up, but I liked to solve problems.

When it came time for college, I decided to study Finance to give myself the future flexibility to land in almost any industry.

During my Sophomore year at Penn State, I learned about "consulting" as a potential career path from talking with a friend's dad.

It gave off the impression of an "Undecided Major" that would pay me to figure out my life through on-the-job experience.

After exploring options, I initially had my eyes set on Strategy & Operations consulting (i.e., Bain, McKinsey, BCG). That all changed when I randomly jumped in line for West Monroe Partners, a smaller IT consulting firm, at a 2015 Internship Career Fair.

Impressed by the recruiters and the people I met during the office visit, I accepted an offer to be an intern that summer in Chicago.

In addition to exploring the city, I spent the majority of my time supporting a client's ERP implementation project at work.

While ERP implementations aren’t the most fun thing to work on (or any fun?), it showed me how important it was to be the go-to person for a certain topic.

On this particular project, I noticed that the client team had job security because they were domain experts:

• The finance expert didn’t need to know how to manufacture.
• The procurement expert didn’t need to know how to sell.

In those intern days, I had no idea what we were even discussing 90% of the time.

I couldn’t add any value to the conversation, so I did the next best thing: Took a lot of notes, organized them, and sent them to the team.

Pretty soon, I became the reliable notetaker who would capture the details of conversations so nothing would be forgotten.

It was a lot of typing — probably why I have wrist pain while writing this.

?? Reflecting on these experiences after my intern summer, two things were clear to me:

1. I was valuable to the project team by carving out a specific niche. Since I contributed to the project via notetaking, it allowed me the space to ask “dumb questions” if I didn’t understand something. When you don't know how to contribute, add structure (as my friend Nick always says).
2. “Learning by doing” was nearly impossible without a business or technical skill set. I couldn’t gain on-the-job experience in a business function since I wasn’t involved in the day-to-day operations for my clients. Therefore, I chose to learn technologies. Mastering technologies would give me the cover to ask questions and learn business concepts during projects.

? In Practice:

I applied these two reflections to the beginning of my career when I returned to West Monroe full-time in Fall 2016.

Even though I had no prior technology or coding background, I said “yes” to every opportunity to learn a technology and drive innovation. Here are a few examples:

Learning Data Validation for SAP Carve-Outs

My first project was based in Louisiana in September 2016 - an SAP Carve-Out of a global steel manufacturer.

I was 22 years old and fresh out of school. My team would fly into New Orleans on a weekly basis and drive 45 minutes one-way to a small town where the client was headquartered.

As someone new to the project team, I was only supposed to stay for 2 days during my initial trip to New Orleans.

Of course, project craziness resulted in me remaining onsite for 10 days. I was easily the most frequent user of the hotel laundry room during this time.

After being tasked with translating photocopied, hand-written, cursive French to English (I’m not kidding), my main role was helping to confirm data was migrating correctly from one SAP system to another.

I never saw SAP or encountered databases before this point. Let’s just say it wasn’t ‘sexy’ work.

I spent my time copying and pasting names of 1000+ database tables from Excel into an ugly-looking technology and exporting results.

I didn’t understand the context of what I was doing at all, but knew it was important for the project.

If the results of my work didn’t match what I expected to see, I would flag it and report it to someone who knew what to do.

The work was boring and mundane, but I was able to be autonomous and reliable for my teammates.

Through this, I built strong relationships and gained mentors who would teach me concepts and answer my questions about SAP and databases.

Eventually, the project ended successfully — I’ll get into the details in a future post. (Spoiler: It involves, “sweating in a steel hut under the Louisiana sun”, like I mentioned in the Career Stories Introduction).

I wasn’t closer to knowing what I wanted to do with my life, but I was receiving kudos from leadership at the firm for a job well done.

My Takeaways:

• ?? Add value to build relationships. Utilize those relationships to learn new things. It’s important to find mentors early that will explain the “why” to you and repeat themselves multiple times until concepts click.
• ?? It’s okay to learn older technologies to differentiate yourself. You may not like working with it at first, but as you do a task more often, you get better at it. As you get better at it, you like the task more.
• ?? Important work is context dependent — it doesn’t necessarily have to be intellectually challenging.
• ?? Going through challenging times with others creates bonding moments through shared experience.
• ?? Sometimes, day-to-day work can make you miserable, but you can blow off steam by exploring New Orleans and creating fun experiences with coworkers after hours — like riding the mechanical bull at Bourbon Cowboy, which is sadly now permanently closed.

Learning Robotic Process Automation (”RPA”)

Shortly after my first project ended, West Monroe announced that they were starting a “Robotic Process Automation” offering.

Anyone who wanted to learn the technology could take a robust training program free of charge.

The manager from my carve-out project told me to volunteer so I could automate the manual SAP data validation process I just worked on.

Applying automation to this would save days of billable time and be a cost differentiator when selling future work to clients.

Even more enticing, I could lead the charge and be the person to introduce these technical improvements.

I raised my hand to volunteer and spent a few weeks in a conference room with a select group of others. Our days were filled with learning Visual Basic .NET and automation principles from UiPath.

It was my first foray into programming and it was a steep learning curve.

Through my training, I got ingrained in the technical world and experienced a whirlwind of emotions.

• I quickly learned what a ‘bug’ was and how to fix it.
• I found out how frustrating it was to think you typed correct code only to receive error messages that made no sense — I wanted to bang my head against a wall multiple times a day.
• Finally, I learned how intense the satisfaction was when you solved a problem and got the technology to do what you wanted.

I was hooked.

After finishing training and receiving my ‘Advanced Developer Certification’, my first application of the technology was collaborating with a colleague to prototype ?? "GuacBot”, a workflow that automatically ordered guacamole for the office. Talk about life changing work!

It was then time to get serious. I was staffed on an internal project to automate the manual client invoicing process for the accounting team.

At the time, I didn’t know anything about invoicing or why it needed to be automated, but I at least knew how the RPA technology functioned.

Through the lens of technology, I was able to ask the right questions and create a solution to fit the team’s needs.

As the primary developer, I was closely collaborating with senior leadership in my practice and in the finance department.

We had a symbiotic relationship where they explained the business cases of the technology to me, while I explained how my technical solutions worked to them.

Even though they had decades of experience on me, they viewed me as the “expert” in this technology that I learned a month prior. Weird.

My Takeaways:

• ?? Use technologies to learn how businesses operate. Without my technical knowledge, there wouldn’t have been many opportunities for me to learn business processes while still adding value to a project team.
• ?? You can earn a “seat at the table” at 22 years old by utilizing technology to solve the problems of more experienced professionals.

Creating a Data Validation Product for ERP Carve-Outs

After finishing the invoicing project, I began developing the solution to automate the SAP data validation process that was previously the bane of my existence.

My approach was the following:

• Use an Excel-based input file to copy a value from a cell
• Manipulate the computer screen to paste that value into SAP
• Copy and paste the results back into the original Excel file
• Repeat

Pretty simple stuff when you knew what you were doing.

To improve the product, I also learned advanced Excel formulas to create a “Data Validation Report” that I could give to clients.

This would serve as an asset that confirmed the accuracy of data or quickly flagged issues to be fixed if results weren’t as expected.

While developing this solution, my firm sold another ERP carve-out that I was staffed on as the data workstream lead.

I then had the fun task of adapting my automation product to the system in this specific project —JD Edwards EnterpriseOne.

This involved manipulating an AS400 mainframe, which was a new one for me.

After a lot of tinkering, the v2 automated data validation product worked and the project was ultimately successful a few months later.

With this being my second carve-out, business and technical concepts started clicking. I was able to notice the similarities and differences between my projects.

My Takeaways:

• ?? You’re never completely finished with developing a technical solution in a services-based business — individual client needs will be unique.
• ?? The best way to learn is by doing. You need to actually gain the experience, be patient, and trust that things will click over time.

?? Lessons Learned:

Each of these experiences wasn't just about learning a new tool; it was about applying that knowledge to create real-world solutions. Here's what I learned and how it can help you:

Pay Attention:

Staying ahead means being on the lookout for inspiration. You never know when you’re going to encounter ideas that will level up the way you work. Ask yourself:

• Is your firm trying to roll out a new technology?
• Is a competitor doing something novel that could put you out of business?
• Did you come across an exciting technology that could solve a pain point?

The tech world is always changing, but that doesn’t mean technology will be adopted right away.

Pay attention to which technologies are being used in your industry. These technologies could be legacy or cutting-edge.

Become an expert in the old tech if it has staying power or advocate for the adoption of something new if things can improve.

There will always be opportunities to learn new things and differentiate yourself.

Solve Real Problems:

Technologies are tools — the real skill lies in knowing which tool to use.

Don’t overengineer solutions. Abraham Maslow said, “If the only tool you have is a hammer, you tend to see every problem as a nail.”

Don’t blindly assume that the tech you know is the right tool for the job.

A common issue I’ve seen in the workplace is people thinking that it's necessary to automate a one-time task.

Often, you will spend more time coding when manual work would have been faster.

Know when to use technology to solve real problems — don’t create problems for yourself that take you away from impactful work.

Don’t Be Afraid to Fail:

The technology isn’t going to work the way you want it to.

You’re going to get error messages that aren’t in English.

You’re going to be copying and pasting in Google.

You’ll encounter obscure forums on the internet you never knew existed.

This is how you learn:

• Try something
• Collect feedback
• Tweak your approach
• Repeat

Eventually, you’ll get the solution you’re looking for. Even better, you’ll understand why it worked because of all the previous failures.

Enjoy your moment feeling like a genius until you move onto the next problem and have no idea where to start.

?? What’s Next:

In Part 2 of this series, I’ll describe how I kept learning and applying new technologies to help build the IT consulting firm I cofounded.

Until next time,

CB