Unhappy Engineer

What makes an unhappy engineer? As of late, I've been trying to answer this question. Recent events have made be think more and more about this topic. Work used to give me pleasure, now it's a chore.

I remember a time, not long ago, where I could start and finish a day within a blink of an eye. Time flew by, at the speed of light. A sense of accomplishment was always there. Now a days, I look at the time and see the minutes and seconds crawl at a snail's pace. Something is very wrong!

My enthusiasm has left the building, leaving an empty shell behind. Work used to be fun. Problems waited to be solved, solution to be written. The World of Dilbert has arrived at my company.

Retrospection

calendar-1024x928Over the past year my workplace has changed completely. Usually change is for the better, in this case it's not. As I look at my colleagues, I see great turmoil in their eyes. Chaos and disorder rampage the once peaceful place.  Stress is rising, and everybody feels helpless.

This all started, when our boss left. That's when the floodgates started opening. Our filter with upper management was gone, a void was left in his place. The once quiet workplace is flooded by waves of unfiltered noise.

Fortunately a person stepped in, to fill our bosses shoes. Bringing back a sense of stability. But the damage was already done, there was no stopping the inevitable. Disorder crept in, inch by inch. We where being consumed by Dilbert.

Ultimately that person also chose to leave, and I now completely understand why. Me and my team were shielded from what goes on upstairs. Now, since there's no proxy, we can see everything. The worst part of it all, we now have to interact with the other side.

Nowadays our team can be classified as a virtual team, meaning we are managed remotely. This would be fine, if not for the substantial timezone difference and the ocean that separates us. Everything happens in slow motion, and instead of being proactive we are reactive.

Management

Our problems started from the top. Management got a hold of us, our every move was now being steered from overseas. Instead of order we got chaos.

Engineering in general is a very structured discipline, software development is no exception. It requires planning for it to succeed. You cannot change your mind every step you take. What happens when you don't have a clear plan, keep changing the goals? You get a lot of frustrated engineers, not able to create something you asked them to build.

When management can't tell you precisely what they want, and then complains that something is missing. What do you do? Requirements that appear out of nowhere pile up fast. They break the flow, and soon everything is being duct taped together. This drives an engineer nuts.

It is the management's job to fully define what should be built and for when. And take into account all the engineer's input. Communicate with the architects and developers, as they know where the limits are. This was definitely being ignored at my workplace.

I would be terrified if managers from the software industry started constructing buildings. In this industry it's the "Wild Wild West", anyone can be a manager. In the construction industry, managers have to be builders, it's required by law.  It's critical to talk and communicate with the engineers about requirements and plans. As they will be building it, and they know how to do it best.

dilbert-on-project-management

Communication

Effective transfer of information is key in large teams. There is a fine balance between too much and not enough. Move too far away from the center and productivity is lost. If too many people participate, you get the same effect. Balance is everything and it's no easy task.

This problem recently started to effect our team. Too many meetings, and everyone was invited to join. Imagine the amount of "man hours" wasted when 30 people sit in 1 hour meeting. That's 4 days lost!

Lack of focus was also another problem. People attended the gatherings, but nothing came out of them. Discussions veered off course in a short amount of time. While other communication channels, such as email, where not being used effectively.

Information dissemination and proper delegation would solve a lot of these problems. Generally meetings should be an exception, a last resort. Less is better in this case. And worst part of it all, we were separated by a 8 hour time difference. Expecting people to stay before or after work on a regular basis is unacceptable.

The Unhappy Engineer

The engineer is a simple creature, he loves to work. There is nothing more satisfying than being able to solve a problem. Being idle is not something he enjoys. I for one can attest to that.

When a engineer's time is wasted by other tasks, such as constantly being in meetings or writing emails, he gets frustrated. Do this consistently and you will have a riot on your hands. The ship will start sinking, people will start leaving. This is exactly what is happening at my company.

Clarity and order is vital in his environment. So is shielding and proper information control. The engineer should focus on solving the puzzles, not on the bureaucracies of managing a large project. He is a critical asset, he builds what the company can sell. Don't discount what he says, as he knows where the problems may lie down the road.

My Verdict

leaving_the_forest_by_andreasrocha-d6lk4zlI think it's time for me to get a fresh perspective, a change of scenery. Follow in the footsteps of my now departed colleagues. The once tranquil workplace I enjoyed, does not exists anymore. Everything was fine, until the dominoes started falling.

When work does not give you joy anymore, it's time to put in the towel. Find something new to do.

Tomasz Bogdal

Engineer by day, hacker at night. I take the road less traveled, dissect the unknown. Give me something new, and I'll master it by the dusk of dawn.

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">