When was the last time you walked on water or turned water in to wine? You haven’t? Are you sure? Because that “holier than thou” attitude you just gave the Product Owner over why that task couldn’t be done said otherwise.
Why do so many engineers insist on thinking that they’re better than their non-technical counterparts on the team? I’ve seen it time and time again (and quite honestly back in the day was a little guilty of it myself).
There’s nothing wrong with being proud of the knowledge and skills you have as an engineer. It’s true that not everyone has them. At the same time though, it’s not acceptable to hide behind the curtain of knowledge and give some hokey answer as to why something can’t be done. I don’t know how many times I’ve heard one of the following:
- The system can’t do that
- That’s a major undertaking that will take too long
- The user is doing it wrong
- It’s not my problem
- It can’t be done
You know, with the right explanation, any one of those could be a valid reason. Yes, even the “It’s not my problem” one is valid. You just need to have a very formal process and clearly defined division of roles and responsibilities to be able to get away with using it. Even then, you should always offer up what individual or department is responsible.
If you’re pushing back because the user is doing something wrong with your perfect code it’s time to reevaluate your test cases and edge scenarios. It’s possible that the issue could be resolved with a little UX help to make things more obvious to the end user, but even then, they obviously did something that you didn’t expect them to do. It’s time to suck it up and admit that your code wasn’t as perfect as you thought it was. Now go write some unit tests to cover this new scenario and write some code make those tests pass. While you’re at it, talk to the QA team and your Product Owner and see if you can come up with a few other potential edge cases to handle. If your users found one, odds are they’ll find another.
Claiming the system can’t do something or that the change will take way too much work to do are similar in nature and can be handled the same without coming across too high and mighty. Let’s face it, some requests really can’t be done easily with the current code base and language or the current system architecture. If that’s truly the case, than come out and explain why it’s the case.
As a manager, there’s nothing I liked more than having an engineer tell me that something would take too long to do or that it would break the current system with no better explanation than that. I’d have lunch at my desk, or do a little work that night, and turn around and send a branch of code to the developer with the solution the next day. Please, don’t tell me something will take weeks to complete when I can solve it in two hours while watching a bad movie.
The worst offender in that list is “It can’t be done.” Odds are you’re not being asked to do quantum computing on an old 386 desktop computer, which would truly qualify for that statement. I’ve heard “It can’t be done” more often than not when it’s something that can be done, but the engineer doesn’t know how to right away, or has never done it before. If you hear “it can’t be done,” push back and ask if it can’t be done or if they just don’t know how to do it. Chances are they’ve never done it or don’t know how to do it and are afraid to come out and admit that hole in their knowledge and lose the mystique surrounding what they do.
Of course, sometimes the entire reason behind any one of the “excuses” is really just that; an excuse used to try and hide the engineer’s laziness. If they’re just being lazy and don’t want to do it, that’s a whole different issue…
As engineers, we need to stop trying to cover up our short comings with cocky attitudes. We need to admit where we are lacking and seek the knowledge (and assistance) whenever possible. We need to give sound reasons to back up our statements, especially when they are deemed negative by the rest of the organization. If we want to be the gods of the organization, we need to do it with humility and helpfulness and have others bestow the title on us. We cannot do it just because we think we’re good enough or, worse still, better than everyone else.