Entry Level Jobs | Customers, Etc.
Sometimes the best jobs are the ones that give us the space to try something new.
Have I ever written about the “inventory shuffling” program I wrote in my first job out of college that saved the company $100,000?
The program was developed entirely in Microsoft Access. Access was kind of clunky, but it was great because everything was in one place: the code, the database tables, the visualization, the user interface. All I needed to do was wire everything up. It was a wonderful playground for solving business problems like a mad scientist.
The business problem I was trying to solve was figuring out how to move inventory from one warehouse that had too much inventory to another warehouse that needed it. If we could do that successfully, we could reduce the amount of inventory we ordered directly from the manufacturer.
And you know what? It worked! It ended up working so well that we were able to avoid ordering an entire truckload of inventory, somewhere around $100,000 worth of goods. That was more than twice my salary at the time.
Maybe I should have asked my boss for a raise?
Starting
Let’s back up a bit. It may help to know that my boss at the time was my dad (👋 hi Dad!). I spent most of my college years majoring in philosophy and studying to be a Catholic priest. Having discerned about three months before graduation that I wasn’t in fact called to be a priest, I had no time to switch majors and think about a “real world” career. Philosophy degree in hand, my dad offered me a job at his company “helping him with stuff on the computer.”
It wasn’t my first time working for the company. I had helped out over a previous summer and done some hacking in Excel to make it easier for him to run reports. So presumably that’s the kind of work I would be doing.
Because it was a relatively low-paid “analyst” position (I never really did have an official job title while I was there), I had a lot of latitude to solve problems pretty much however I saw fit, as long as it was done correctly and on time.
I would be asked to produce a particular kind of report in Excel. Usually that meant importing a report from the ERP system, but it also involved manual data entry and lots of formatting. Because the process was tedious and because I wanted to reduce errors, I would try to figure out how to eliminate manual steps.
I started by learning things like VLOOKUP1. One day, I discovered that Excel macros would let me record keyboard steps that I could play back with a shortcut. This completely changed how I got through manual work. “Dad, check this out!”, was something I probably shouted as I proudly demoed how I was able to produce a report in five minutes that had previously taken him two hours.
Learning
It was in this environment that I taught myself to code2. I didn’t know any better, so I just doubled down and poured myself into automating as much as I could. I discovered that when you recorded a macro in Excel, Excel would generate Visual Basic for Applications (VBA) code that you could then tweak and change.
This completely opened up my world. I bought a book on VBA and another one on Microsoft Access. As I would work on automating reports, I would discover ways to make them more user-friendly and if at all possible, try to make them completely self-service. Why run the report and email it if I could put a file on my dad’s desktop where he could just click a button and get everything he needed?
I had a lot of fun geeking out and optimizing these reports. At the height of my over-engineering, I had made an application that used a combination of Access and Excel working together in side-by-side windows where as you navigated the Excel sheet, it would update the data you saw in an Access window. It was too complicated and I eventually re-wrote the solution to be only in Excel.
Over time, my work evolved to be more strategic. As I was working on a particular report, I would notice aspects of decision-making that were suboptimal. One of the reports, for example, was used to set minimum inventory levels at a warehouse, but it was based on usage at the location, not the demand from the location’s customers. This meant that warehouses that filled backorders from other warehouses ended up with higher inventory levels and that warehouses with lots of backorders ended up with lower inventory levels.
This was where the idea for the “inventory shuffling” solution came in. What if there was a way to move inventory between locations so that all had the correct inventory levels for their location?
Exploring
The challenge was that while it was simple to explain in theory, it was difficult to solve in practice. It was certainly more complex than you could represent in a single spreadsheet. Because the problem was complex, we didn’t really know if the payoff would be worth it. Maybe I would do all this complicated programming work and we would find out, no, the inventory levels were just fine.
We decided to try it. I was still getting my regular work done, but since most of it at this point was automated, I had plenty of time to spend on this skunk works project to figure out how to shuffle inventory.
It was quite the challenge figuring out how to solve the problem, but it was also a lot of fun. This problem felt more “computer science-y” than other problems I had worked on. Most of the code was on the back end and I had to make design decisions about how to loop through supply and demand of inventory at multiple warehouses.
In the end, it worked, and it saved the company a ton of money.
Gratitude
One of the things about entry level jobs is that you almost never get paid very well. You haven’t done the job before so you’re a risk to the company—maybe you’ll fail!—so they take a chance on you and offset the risk by paying you a low wage/salary relative to what you would be worth if you had a proven track record.
If you’re good at your job, though, then at some point your skills will exceed entry level status, but your pay will still be lagging behind. As an employee, this can be frustrating. “Look how much money I saved them!”, you might say, or, “I got them the biggest client they’ve seen in years!”
At this point, you have a choice: do you choose resentment or do you choose gratitude? Choose gratitude. You had the chance to start something new, you got paid to learn on the job, and you were able to spread your wings and explore new opportunities that you wouldn’t have had if the company hadn’t risked hiring you. Always choose gratitude.
Sure, the company might not reward you with a raise as fast as you like. Smart companies who want to retain their best talent are keen to keep an eye out for growth among their employees so they can be quick to bring compensation up to market rate. But if that’s not your company, that’s okay. You don’t need to have resentment. You can be grateful for the opportunity as you look for a new company that will better reward your skills in the marketplace.
Entry level jobs aren’t just for the beginning of your career. Hopefully your career is full of opportunities to learn and try completely new things. If the completely new thing is a full time job, you might not expect to get paid the same as a role where you’re already an expert. But you have the opportunity to start something new, to learn, to grow, to explore, and ultimately, to be grateful.
I know, I know, INDEX/MATCH is better, which I would learn years later. Back off, Excel nerds.
It wasn’t technically my first exposure to coding, but it was the first time I had ever coded in a business setting. I had played around with TI Basic in high school and took a few programming classes in college, but had never done any coding outside of the classroom to solve “real” problems.