Things I Have Learned from “McJobs”

I often am amused when society believes that “McJobs”, which most people define as dead-end, no-advancement jobs often in food service or retail, don’t serve a purpose in society. They may not offer much in pay and advancement, unless you somehow make it to the corporate offices of said company (rather unlikely given they usually hire executives from other companies for that) No, the thing I have learned from working in a small grocery store chain, several mid-size companies, a large but newly established franchise restaurant in the area, and a much bigger restaurant chain, is that each company has an organization structure and workflow execution that fits their style of business. The thing is, you being the employee, cook, associate, or whomever, don’t know what this diagram looks like, you just are told what you are supposed to do and how to do it. You don’t make the tough decisions.

Now working for a small software company for a year, one of the biggest hurdles in my first six months was understanding how they did anything that resembled an actual process. They had some rough policies in place and an idea of what to do, but it felt like I was in a room full of people who knew what they were doing, but didn’t know how to convey it to anyone else. The survival point in this company was to know enough to make your own decisions often, and try not to fuck anything up major.

It became evident to me over time that if things were to improve, not only for my fellow team members, everyone else, and even new people, things had to be done to make life easier, steps had to be taken to create and evolve a system that works for us. A lot of people would try to apply big company dynamics to ours, and it’s hard to do so, because we’re small, and our product is built for a specific industry that doesn’t conform to what is common among other software developers. Many of the things I started doing were small, writing technical manuals, guides, diagrams and flowcharts, but as I did, people noticed, and people wanted to take these ideas and use them to build organizational frameworks like real companies have that define how work is done, and who handles it. Suddenly, before I knew it, I became involved in a big mechanical cog of developing a company’s Standard Operating Procedure, and it’s serious business.

Unfortunately it is not all fun and games, and that reality came crashing down pretty hard on me today through a series of unfortunate events. The trouble is, as I have put it to several co-workers, is “Everyone wants a piece of the pie, but someone wants to know what to buy for it, another wants to know how to make it, another disputes how it should be made, another disputes who it should be served to, and everyone can’t decide on the flavor.”.

It’s pretty much like this tree diagram, every department and person has their own idea of how their department should run, and how everyone else to act/react to them, and it’s troublesome, it’s mind-numbly troublesome to the point where I dunno how other companies went through this sort of thing. To me, the concept isn’t that hard, and a more critical and condescending version of me wonders why much of the very basic framework for this wasn’t put down in the beginning. Even if you don’t have the people to fill into those positions, it just seems logical to me to build an organizational foundation for your company before you release the software, so that you are prepared to support the software, and continue to develop it with fewer interruptions. Unfortunately, I’ve been told about twenty times that “We’re a small company…” so on and so forth. I view that as excuses, and lazy. You cannot release something and offer to help support it and then retreat back to the cave when the heat gets to hot for your ass, we don’t get that luxury. Instead, it makes more sense to me to establish how you plan to support the product after it’s release, BEFORE it’s release, and have the positions in place from the beginning. You don’t have to be a mid-to-large size company to do this, you just have to have a few good people who are willing to step up, take charge, and do what needs to be done.

In some ways I might just be pipe dreaming, and I certainly have no animosity towards those I work with. I just get incredibly frustrated when I feel more can be addressed and done to improve the way things go, and my hands are tied by a series of factors I don’t deem necessary to be doing in the first place. I also don’t want to stick out and make a bad name for myself by insisting on things that I shouldn’t, but I got involved in this mess and it’s not going to end until it’s settled, and that’s the hard part, I often just want to go back to being a mindless Support drone that only has to worry about showing up to work on time, eating lunch, and leaving on time. But one does not advance this way, and I am not a programmer, so I can’t take the shortcut out of Support, I have to prove my worth the only way how, and that is calling upon ancient powers of leadership skills from my old scout days, and analytical and practical thinking abilities that didn’t seem to be present for high school but are now.

I still need to learn SQL though, even if I don’t want to program, I’d like to be able to know what I am doing with it.

This entry was posted in Blog Dot and tagged . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *