Listen to your engineers.

Hello. You've most likely stumbled upon this page for one of two simple reasons:

1. You're an engineer who saw the title or URL of this article and thought, "well, I'm an engineer, and I like being listened to. Let's see what this is."
2. You're a manager, not an engineer—but an engineer sent you a link to this and told you to read it.

I apologize in advance to those of you who have been involved in the engineering side of corporate technology projects; the remainder of this note is likely to temporarily raise your blood pressure while it triggers chilling memories of the pain and suffering you've incurred at the hands of the antagonist we've come to know as "The Management." I am truly sorry for those of you that know such pains.

If, however, you fall into the second category listed above, then I do not apologize to you; I will, however, warn you that the remainder of this article is not going to be friendly to you. Why? Because you are part of the problem. But fear not, for I shall guide you back towards the path you need to be taking.

Let's begin.

When The Management asks one of their engineers how long a project of any scope will take, one of exactly two things is bound to happen:

1. The engineer will provide an estimate, which The Management will undoubtably reduce by a factor of no less than two.
2. The engineer will tell The Management that the project can't yet be estimated (due to necessary research and/or project elaboration) and The Management will simply make up a date that aims to please the involved stakeholders.

"But," you interrupt, "The Management must also cater to business priorities other than the engineering departments! Surely they have reasons for needing this project completed sooner."

That makes total sense. It's also the reason why I can walk down to the Lamborghini dealership and, after explaining to the salesperson that I don't have much money because I must cater to other financial priorities (such as alimony, gambling debts, and the three mortgages on my house) I can leave said dealership with a brand new Lamborghini Veneno for half its MSRP.

No, wait, I actually can't do that. That's not how the real world works.

The Management, when involved in technology projects, exists in some bubble, isolated from the rest of reality, that makes them believe they can control the delivery date of a successful project by simply uttering a deadline and sending an email. This behavior, while initially baffling, can be explained as having three root causes:

1. The Management has literally no idea what work is necessary to implement the project or how that work is done. (In many fields, it's necessary for The Management to have a working knowledge of the work they're Managing. Engineering is, apparently, not one of those fields.)
2. The Contractors have bid the project to fit exactly within the budget and timeline The Management is demanding. (This, like The Management's deadline decision behavior, is also not rooted in reality. More on this later.)
3. (Unfortunately, this one seems to be our fault.) The engineers have simply given up on the idea that anybody above their pay grade even fathoms taking their opinion of the project seriously, and thusly agree to The Management's demands knowing full well that the project is destined to fail.

The first point, unfortunately, has become a fact of life. My least favorite phrase that comes from The Management during any sort of meeting is "that shouldn't be hard to do." It takes every fiber of my being not to stand up and scream "YOU HAVE NO IDEA HOW HARD THAT IS" or, worse, tell them "if it isn't that hard, then you can do it." Unfortunately, comments like that tend to end in job termination. (And I rather enjoy having a paycheck.)

The third point is an unfortunate one, because it shows that the skilled practitioners of the engineering trades often feel hopeless when faced with The Management's view being imposed upon their work. This observation makes sense, though, when considering that The Management often view engineers as replaceable resources that can simply be "swapped out" when they start to push back on unrealistic expectations. This leads me into the second point from above, which is the most infuriating of them all.

I have a fiery, burning hatred for contracted engineers. (Full disclosure: I used to be one. I've been on every side of this table, and I have the horror stories to prove it.) Firms that contract out teams of engineers are the kinds of companies that will promise to sell you oceanfront property in a landlocked state. The reason for this? Plain and simple: capitalism! (Don't get me wrong, I love capitalism. But it's well-known that there are many groups of people that abuse it, and these firms are among them.) The process the contractors go through is very much the same as what hired engineers have to deal with when estimating a project; the contracted engineers will be asked what they think will be necessary to complete the project, and they will be ignored in favor of some other arbitrary constraints. The only difference is that the contractors' The Management derive their time and budget bid from what your The Management is demanding. So why do I have such hate for the contracted engineers themselves? Because they willingly choose to be a party to the scams that the firms' The Management and sales teams are pitching to companies that don't know better.

(That, by the way, is why I left contracting and will never go back. The way contractors operate, as I will explain below, is very much against my code of ethics.)

Imagine, for a moment, that you have hired a contract vendor for a year-long, five million dollar project.

If they finish your project in a year, it costs you five million dollars, and it's built correctly, I will eat my shoe. (Afterwards, I will send you my résumé, because I want to be a part of this utopia you've discovered. I'm still not convinced it exists.)

You may have heard of The Project Management Triangle: it's often expressed as the phrase "good, cheap, fast; pick two." Guess what? When you hire contractors to build your project, you get to pick none of those things. The project won't be cheap, because contractors are, by nature, more expensive than in-house developers. The project won't be fast, because there is an insane amount of overhead in actually explaining what you want the contractors to build, as well as validating the results of the process. And, of course, the project won't be good, because contractors are trained to do just enough to meet the requirements before moving on to the next thing.

I want to interrupt this line of thought to remind you of the title of this note, but I want you to pay close attention to the emphasized word.

Listen to your engineers.

Why? Because, at the end of the day, contractors are not stakeholders in your project. They are not your end users, they will not be maintaining the project long-term, and (most importantly) their employment does not find any risk if they choose to deliver a solution that's held together by duct tape and chewing gum. Their job is to pump out a project that vaguely resembles the requirements, polish a rough edge or two when the client sends their negative feedback, and then disappear into the night once they've delivered.

This may be a novel idea to some of you reading, but true engineers take serious pride in their work. They don't exist in the realm of employment simply to punch a clock and do the bare minimum required to receive their paycheck. The most talented and dedicated engineers spend more of their lives learning than they do sleeping, and they see work projects as opportunities to hone, expand, and showcase their skills. Their crafts, in fact, are as much art as they are science. Your engineers aren't construction workers, they're designers, composers, sculptors—and their purpose in life is to make masterpieces.

Of course, if you're of the managerial persuasion, you probably want to ask me “who cares about art? I'm responsible for a project and my only concern is whether or not it does what it's supposed to do.”

…

You're the kind of person that hides a hole in your pants by drawing on yourself with a marker, aren't you?

What The Management consistently fails to understand about engineers is that they're not replaceable parts. They cannot be endlessly shuffled around from project to project, and tossing a bunch of extra ones into a room will not make a project go any faster. You know what they say about nine women who are all cooks, right? Same goes for engineers. Every single one of them has their own set of experiences to draw from and their own skills to contribute. Also, every project on their plate is a work of art—functional art that serves a purpose, albeit, but art nonetheless. Your engineers want nothing more to deliver to you a project that serves above and beyond its purpose, and does so in a way that represents the skills that were put into its creation. Unfortunately, they can't do that effectively if they're subjected to the stresses caused by The Management not fundamentally understanding how engineers think and work… and nothing puts more stress on an engineer than unrealistic demands and deadlines, constant interruptions, and the fear of being replaced by a team of outsourced contractors.

Oh yeah, I was complaining about contractors, wasn't I? I should get back to that.

If you don't know what the phrase "technical debt" means, go look it up now. Then, understand that bringing in a contracted team to build a project in this way is the fastest way to incur technical debt known to man, short of hiring a team of high school students instead. And guess who has to deal with the technical debt that the contractors bring?

First, your engineers.

(And you wonder why they crack jokes about The Management, hang signs that say "to avoid injury, don't tell me how to do my job," and punch out at 4:55 PM on the dot every day.)

Second, your company itself.

Ever have a project that has to be rebuilt every three years because, for one reason or another, it starts failing to perform it's task? That's because of technical debt. When your engineers are falling on their knees and begging you for more support and maintenance employees, that's because of technical debt. When your engineers start fleeing the company in droves because the project to which they're assigned is "unmaintainable" and "a nightmare to work on," that is because of technical debt. But guess what: there is a way to avoid almost all potential technical debt!

You'll never guess what it is:

Listen to your engineers.

When they tell you how long a project is going to take, what they're really telling you is how long it'll take for the project to be built correctly. When they tell you what technologies to use for the project, what they're really telling you is which technologies make the most sense for the project, and what technologies will support it long-term. (They, unlike contracting firms, are not just listing off some technologies that they're "certified" in or get paid to push on their clients.) When an engineer tells you that they need more resources, what they're really telling you is that they give enough of a damn about your project to ask for what's necessary to complete and deliver it properly. They are your true stakeholders, because they take as much pride in truly good work as anybody else in your organization possibly could. Engineers are not cogs in a machine that should be replaced when they become squeaky; they are, when treated correctly, some of the best assets a company can have when working with technology. Their ideas could move your company into the top position in its market, or develop something completely new that nobody has though of before. But they can't do that if they're imposed with unrealistic restrictions or The Management threatens to outsource their projects to contractors.

Remember that the next time you hear some suit and tie telling an engineer that something "shouldn't be that hard."