Ding! The sound that puts fear into the bones of every engineer; the sound of a new email sitting in your inbox and that could only mean one thing: trouble.
You are invited to a meeting where we will discuss problems that are pestering our department. Blah blah, be there at 10:00.
Yours truly,
Someone
Uh oh, I love the smell of corporate drama early in the morning. Checking out the list of invited people gave me another clue. They were all seasoned engineers which meant it was a serious meeting after all. Yet, one name was missing from the list of invitees; the name of the person that I expected to see at the top of that list. Maybe they forgot to invite him, is what I am thinking while writing an email to the organizer.
The answer to my pondering came right away: “No, it’s not a mistake. I think Joe is too negative to be invited to this meeting, as he would only rant and turn the meeting into an unproductive one. A smaller group will do just fine.”
While a smaller group of people is usually more productive than a larger one, that doesn’t mean cutting out experienced engineers out of important discussions is a great idea. Isn’t the whole point of such crisis meetings to invite the ones who will find flaws in your plan before the plan is carried out?
It turns out that’s often not the case and this problem starts creeping in with the size of the organization. The larger the company, the more likely it is that someone will get in the way of getting things done and start playing the dreaded game of office politics. The kind of a game in which what matters is not your competence, but the strength of your political connections.
Whenever some sort of personality trait is being discussed, such a debate usually spins out of control as the participants start sharing their frustrations with unbearable assholes at work. It’s worth mentioning, however, that Joe wasn’t one of those brilliant jerks. What gave him a target on his back was his ability to point out potential problems and questioning the status quo.
There is an old proverb that claims how “actions speak louder than words,” and according to my ample experience it turns out they really do. Trying to fix broken things often reveals incompetence somewhere along the chain of command and you better not disturb that hornet’s nest or you’ll get the target on your back too.
Whether Joe should be invited to a crisis meeting is up for debate, nevertheless I think we ought to say a few words about the so called negativity that is so common in engineering and increasingly frowned upon.
What is engineering?
In essence, engineering is all about dealing with problems. If there were no problems in this world, we wouldn’t have to employ the aforementioned grumpy Joes since things would just work out naturally. Unfortunately, there are tons of problems that have to be solved in this world and consequently that makes the people who know how to solve them highly sought after.
The process of solving the problem usually consists of first discovering the problem, finding the possible solutions and picking the best solution based on the given set of constraints which are often outside of your control (e.g, time, the cost of materials, people with the necessary set of skills,…).
While having a positive outlook about the things around you is in general beneficial for your health, or so they say, being optimistic when it comes to solving problems is not such a great idea. In a large and complicated system what can go wrong will definitely go wrong, and if this potential problem is not prevented it will in turn add friction to the working of this world 1.
Your blender may broke down at the most inconvenient time, the credit card transactions at the store may not go through leaving you with a cart full of stuff that you have to return and your flight may be delayed due to the broken scheduling software if we name just a few of the problems that you may encounter as a part of your life. Behind every one of the mentioned problems, however, there was a group of engineers involved that didn’t foresee the edge case that caused the breakdown of the system.
Since unnecessary friction is bad for business, the engineers will in general try “to do the right thing” and envision the potential problems and their solutions before they happen and ruin your day 2. From this we can work out that the defining characteristics of a great engineer is to find problems in everything they touch.
In order to sleep well at night, you have to think about what happens when your servers are on fire and you are being attacked by the Somalian web pirates while half of your team is on vacation. You have to think about that “else” statement that is supposedly never going to execute, and handle it appropriately because you know that at some point one of those branches might trigger and silently wreck your day. I’ve seen a fair amount of “this should never happen” logs, notifying us about the bug in our software that would be quite hard to discover and fix if it wasn’t for some scarred programmer who has decided to add a log just in case.
Due to this specific personality trait, an engineer who can “see” things will soon enough become a very valuable and loved member of the team. At the same time they will also become everything that a leadership hates: a grumpy person that can poke hundreds of holes into anything sent their way as if they were genetically modified to see and be the problem.
Yet, every time there is a hard problem to solve, it is consistently pushed over to the same old faces which don’t belong to very optimistic people. What one can see one can also fix, but there is no way to fix the problem that one cannot see.
Notes
Or worse: in some industries sloppiness might even kill someone. ↩︎
While the grunts will often try to do the right thing, their ideas are often overruled by business needs and the quality of products suffers accordingly. Yes, sometimes they get carried away and try to solve the surrounding problems that have nothing to do with the thing they were supposed to work on, thus some adult supervision might be necessary. ↩︎