Articles – Page 91 – The Renegade Coder

In my short time as an engineer, I've had several opportunities to deal with miserable management. That's partly because I spent a lot of time rotating through the industry, but it's also partly due to the high turnover rate of management. How Management Came to Be What do you think is the reason for the high turnover rate of management? Personally, I like to cite the Peter Principle, but I think there's more to it than that. For instance, I think most people use management as a rung on their way up the corporate ladder. In other words, most people don't want to be managers; the role is just a stepping stone. In fact, I find it odd that anyone would desire to be a manager. How many of us said "I'd love to be someone's boss" when we were growing up? I don't think I've even seen that in a senior yearbook. Yet, somehow we all become obsessed with climbing the corporate ladder. Just take a look at this screenshot of a Google search for "climb corporate ladder:" Now, if everyone is trying to climb the corporate ladder, managers seem to be doing it best. But, what does it take to successfully climb that ladder? Well, since we're working under the assumption that no one wants to be a manager, then clearly most managers aren't invested in their work. Instead, they're invested in themselves. That appears to be the key to success for the individual, not the team. The 6 Types of Engineering Managers ... and the one you'll never meet. Okay, so we know that managers are often selfish, but how does that affect their ability to manage a team? After all, you'll have to deal with them if you plan to go into engineering. Well, remember that famous pick two joke from college? The options were sleep, social life, and good grades. The same goes for managers except the three choices are technical knowledge, leadership skills, and emotional intelligence. Now, I have to warn you. Half the time you end up with a pick one sort of manager. To further illustrate how irritating this can be, I've decided to put together a little comic below. The Micromanager In this pick two sort of world, the Micromanager simply chooses technical acumen. After all, the best manager is the one who thinks they know everything. With this manager, you get the excitement of working with someone who doesn't quite understand how to manage a project. Their understanding of delegation is the process of handing out work attached to a short chain. At random, they enjoy pulling that chain in to critique your efforts. In addition, each critique is almost certainly going to spark an argument as this person likely doesn't even know how your work fits into the bigger picture. Instead, they're just going to force their incorrect opinion on you as they feel they're the expert. Of course, if they didn't, how could they say they've done any work. There certainly isn't any hard evidence otherwise. The Staples Manager When the Staples Manager was choosing their top two qualities, they settled on leadership skills only. They figured as long as they could rally the troops they wouldn't need to do any work. As a result, they have an obvious deficiency in emotional intelligence and technical acumen. The result is a leader who never really understands your problems. You're simply another cog in their money-making system. As such, your worth is measured in pure numeric terms: time and money. Perhaps the most irritating part of this manager is how they got their name. Since they don't ever get down in the trenches, everything seems to happen in "that was easy" fashion. You'll certainly catch them saying things like "that shouldn't be too hard" as they have absolutely no basis for comparison. Everything is easy when you're the boss. The Amiable Manager Naturally, the last of the three managers to focus on a single quality is the Amiable Manager. When asked to choose two qualities, this manager felt that all they needed was strong emotional intelligence. These types of leaders excel at including each team member and making sure that everyone is heard. Unfortunately, amiable managers never finalize decisions. This is detrimental in an engineering environment as decisions drive execution. Ironically, this sort of team ends up feeling more stressed despite having an emotionally intelligent leader. The Smart-ass Manager Given the same choice as the rest of the managers, the Smart-ass Manager chose to merge the qualities of the Micromanager and the Staples Manager. As a result, the Smart-ass Manager knows exactly what everyone is capable of and can delegate tasks properly. Unfortunately, this leader still lacks emotional intelligence, so they tend to be pretty insensitive. Instead of "that was easy," you might hear them say "now was that so hard?" The Manipulative Manager The Manipulative Manager takes a mix of qualities from the Staples Manager and the Amiable Manager. With this skill set, the Manipulative Manager is capable of containing and mitigating all team conflict. As an added bonus, these types of managers come equipped with the skills to manipulate individuals and groups to do their bidding. Unfortunately, the lack of technical skills means this leader is unable to appropriately delegate out work. In the end, the Manipulative Manager ends up creating quite a bit more work for themselves in terms of conflict management. The Lackadaisical Manager Naturally, the Lackadaisical Manager chose to mix the qualities of a Staples Manager and an Amiable Manager. As a result, this manager understands your problems first hand and therefore can't even motivate themselves to get work done. On the plus side, they make great teammates. They're just not quite leadership material. The Unicorn Manager Finally, we meet the one leader to rule them all. That's because this type of manager doesn't actually exist. That's right! Finding a good manager is like winning the Powerball. It could happen, but you're more likely to get struck by lightning. Hell, if you have one of the duds above, the lightning option doesn't sound like such a bad deal. Maybe Ben Franklin had the right idea. Now where's my kite? Remembering Miserable Management Obviously, I went a bit overboard with that BuzzFeed-style comic, but you get the point. Working with miserable management is frustrating, yet it seems unavoidable. Personally, I've had managers that picked a different archetype every day. Some days I'd be on a short chain while other days I'd be having a pow wow with the team. This chaos quickly lead to burnout. At any rate, I want to dive into a few personal anecdotes about the four managers I had during my brief engineering career. See if you can tease out some traits from above. The First Manager When I first stepped into the world of corporate engineering, I had one of those lackadaisical managers. They meant well and knew a ton, but they were pretty hands off. After all, they were usually out fighting their own fires which left them very little time to work with me. As a result, I spent my first three months alone working on a project that never amounted to anything. Once a week, I would update the team on the progress of that project. After the update, the team would start their regular reaming process. It was a rough cycle that caused me to really hate Tuesdays. Then one day my manager handed in their resignation letter. The Second Manager At that point, I sort of just handed in my project and went back to school; I was on an internship at the time. I didn't take a literal school bus, but you get the idea. After a year, I found myself back at the same company as a permanent hire. For my first role, my manager was again more of the lackadaisical type. They worked hard, but they never really trusted me to help out. As a result, I spent six months working on projects that never mattered. Sometimes I was lucky enough to get some real work. Unfortunately, that only ever happened near hard deadlines where management would ask everyone to work insane 12-15 hour shifts. Of course, I didn't have any experience with the code base, so I couldn't contribute anything of real value. The Third Manager Eventually I moved on to my third team. In this team, I found myself working on significantly more exciting work, but management was arguably worse. Their Apparent Arrogance For starters, my manager was a typical arrogant engineer. After all, every engineer has an opinion. My manager was no exception. Any time a problem showed up in our system, they had a solution for it. It was incredibly frustrating because these solutions never solved the root cause of the problem. Instead, they served as band-aids for symptoms to larger issues. If you've ever written software, you know that this sort of strategy defeats maintainability. Over time, the system becomes unstable and issues start to pop up at seemingly random times. At that point, the best thing a team can do is start over. Their Lack of Software Comprehension Among the many gripes I had with this manager, the biggest one was their lack of software knowledge. Normally, I wouldn't knock someone for their knowledge gaps, but in this case it had a negative impact on my everyday life. I was forced to rework problems several times because they couldn't articulate their needs. For example, I remember working on a set of tasks that could be chained together in whatever order we needed to accomplish a goal. Each task would just churn out data to a database, and it was up to the rest of the team to find ways to display that data. As a part of that design, I sometimes had the tasks display statuses to the user. To my frustration, these statuses were stored in a single cell in one of our database tables. In other words, there was no way to track state. Because there was no state, if a task ever crashed, the last status would get stuck in the database. The next time we would run a task the old status would pop up. As a solution, I made sure to clean up this status every time we crashed. While that worked for a little while, eventually my manager had some edge case where they wanted a status to show the result of a task through to the next task. Now, this was never the intent of statuses. They existed to simply show task specific runtime information like errors that could be quickly corrected by the user. Displaying task data was a job for the UI developers. Long story short, I ended up going around in circles on this issue with this manager until their eventual resignation. Instead of redesigning the system, they wanted to take shortcuts that caused problems long term. Their Disregard For Process In addition to their lack of software knowledge, my manager also had a blatant disregard for process. To be honest, I don't like process either. In fact, I wrote a whole bit about bureaucracy, but I understand why it exists. After all, we use tools like GitHub and Confluence for a reason. Version control and documentation are critical parts of every team's development process. Unfortunately, this manager would sidestep these tools at every turn just so they didn't have to write anything down. I got so frustrated with this because it offered no traceability. Honestly, I think my manager avoided process on purpose because they knew they knew nothing about software. As a result, they could flip-flop on their ideas and claim the solution as their own. Since nothing was ever written down, there was no way I could call them out on it. Naturally, I started documenting whatever they told me. That eventually drove me to become the team's secret project manager. I wasn't happy about it, but it definitely improved my situation a bit. Regardless, you can probably tell this wasn't a great work environment. Their Incomprehensible Decision Making If everything up to this point wasn't bad enough, this manager had probably the worst decision-making skills I've ever seen. For example, I recall one time I was asked to develop a serial protocol in Python to extract data from a tool. My manager had gone through all the effort to select the tool and design the entire algorithm without once consulting me for help. When it came time for me to develop the protocol, my manager handed me some documentation and told me to get to work. Within fifteen minutes, I had skimmed most of the documentation without finding anything about serial commands. After some more digging, I started to grow a bit worried. What if we can't actually talk to this tool? Luckily, I did find that the tool had a software application which used the serial interface. That's when I figured we probably weren't supposed to be issuing commands to the serial interface. When I reached out to my manager about it, they told me to call customer service to find out more. I assume customer service still uses these in 2018. Yeah, you heard that correctly. They didn't even bother to do their research before buying the tool. Apparently, that was my job. How's that for solid decision-making? Self-Management Unfortunately, I never got the chance to work for another team. I had plans to switch teams for my third role. However, due to several other issues described in this series, my opportunities were denied. As a result, I was forced to spend about nine months with the same manager who never really understood software systems. Luckily, I spent my third rotation remote, so I never really had to deal with their antics. I was also able to work a more comfortable amount of hours because I didn't spend so much time sitting around. That's really the bane of my existence. I can't stand sitting around doing nothing. I need to be productive in some manner, and I'm often more productive when I get to decide where I sit and what I work on. Those just aren't rights that you get in the corporate life. Instead, you're stuck following orders from paycheck to paycheck. The Last Manager The period of self-management only lasted about three months before my manager put in their two weeks. As a result, someone was forced to fill their role. For me, this was a gift and a curse. In terms of gifts, the new manager understood code to some extent, so I at least had someone I could trade ideas with. That was huge for me because I could finally get my ideas reviewed and approved. In addition, they understood important concepts like version control, standards, and documentation which was another major bonus. It was nice because I was finally able to write good code without being under the gun. Despite all the positives, the new manager had a handful of major drawbacks. For one, they had no problem working nights and weekends. This meant work-life balance was gone, and I was stuck sitting on calls late into evenings. In fact, one time I even received a few calls on my one day of vacation for my wedding. They literally couldn't handle themselves for one day without me. Yeah, we went to Dave & Busters after our wedding. Credit: Meaghan Elliot Photography In addition, they were constantly checking up on me. This came in many forms, but I most often found myself trying to fix bugs on camera. In other words, my manager would make me share my screen while I was testing code and tracking down bugs. It was ridiculous. Finding a Unicorn As you can imagine, I've never been fortunate enough to have a manager that makes work enjoyable. Unfortunately, I'm not alone. I've found plenty of others who also struggle to deal with miserable management. Below you can find a few links to gripes from others in the engineering community. What Are the Characteristics of a Bad ManagerWhat is it Like to Have a Bad BossGood Engineering Managers Aren’t just Hard to Find — They Don’t ExistWhat Are the Characteristics of a Bad Engineering Manager When you're finished reading, let's kick off a bit of a dialogue on this topic. I'm interested in learning more about your experiences with engineering management. Was I fair in my assessment? Or did I miss the mark?