My team does networking - architecture, engineering, installation, maintenance, etc. We also manage all the network firewalls in our company. Most firewall requests are generated by other people, and come to us in the form of work tickets. The on-call person from our team has to do these and it's something no one looks forward to doing - which is why it makes a perfect example for demonstrating the order-taking mentality.
In general we tend to think of a firewall rule as a pretty simple set of four things - a source IP address, a destination IP address, a protocol, and a port number - with some obvious exceptions, that set of details makes up the vast majority of the rules we create. It would seem like simplicity itself for the requester to gather these items for us and properly document the request, and that's what we want - we basically want to get a "form" with everything filled out, so we can just go execute the request.
The sad fact is that it's just not that simple in the real world, and a lot of the requests we get can't be executed "as is". Here are just a few of the issues:
- The requester doesn't understand ANYTHING about networking and doesn't know what an address, protocol, or port is
- The requester doesn't know how to use the order tool (in our environment it's a sort of web order form for technical services)
- The requester asks for something impossible (some parts of the network can't talk to one another for technical reasons)
- The requester asks for something inappropriate (we have rules about what we let in and out of the network, you know?)
- The request is rejected by the security department (they have to sign off on these) or the change management department
The question of whether a highly paid professional network engineer is reduced to being an order-taker comes down to the manner in which he/she handles these kinds of challenges. Here are some examples of order-taker behavior I have seen more than once in my career:
- Engineer knows the request can't be worked due to incorrect or impossible combination of items - but instead of contacting the requester proactively so they can correct the issue, just doesn't do the work and allows the change to expire
- Engineer refuses to explain anything to requester who clearly needs a little education (sometimes with a snide comment about how dumb "those people" are)
- Engineer goes ahead and implements an impossible rule (such as a firewall rule that doesn't work because the network routing doesn't ever bring the traffic to the firewall) because hey, they were dumb enough to request it and the security guys were dumb enough to approve it, right?
I absolutely understand on the deepest personal level this kind of behavior. We're all overworked, the firewall changes are already a pain in the ass, and we'd all rather be doing something fun like building out a new network. But those who rise to the level of networking professional (I like that better than salesperson) will do the following, or something like it:
- If the requester clearly doesn't know what something is or how something works, the professional will take the time to explain it
- If the requester asks for something that will never work, the professional will be proactive in pointing this out, will find out what the requester was trying to accomplish, and help them refine the request so that it represents what they actually needed
- The professional will contact the security team if something has been approved which should not have been, because even the security guys can make mistakes, and the company's security is too important to play games
I think the above examples illustrate what I'm talking about. In our work as network engineers, we can be order-takers - waiting for someone to tell us what to do, passive-aggressively carrying out stupid or impossible requests, and refusing to take an interest in our customers....OR, we can try to be more than technicians - we can rise to the level of networking professionals, an integral and indispensable part of making our companies successful.
I know which I'd rather be.