Best Practices of the Application Engineer
That balancing of convenience and security has never been so important or so difficult than it is today. Between bring your own device (BYOD), savvy users, and increasing security threats from both inside and outside the enterprise, Apps and all of IT are making adjustments in both practice and additional software safeguards
The goal of course is to reduce the amount of interaction with employees because the computer system should be as invisible as possible. It’s a measure of how well the system is running. Interacting with employees is a cyclical problem because escalated calls interrupt the engineer, forcing them to deal with immediate and emergency issues rather working on upcoming projects and solutions. The better something is tested, the less likely it will generate a call from an employee.
Testing is the most important practice for an application engineer. The application engineer tests and retests every change or piece of software that will eventually be deployed. The testing involves anticipating and planning for nearly every practical circumstance. Testing is more important than ever because one change has a more immediate and farther reach which could disrupt employee productivity. A corrupt Microsoft patch or a conflict in group policy could lock the entire office out of their PCs
I’ve worked in IT shops where documentation was not a requirement and though it sped up a lot of tasks, it eventually added unnecessary overhead because invariably a problem would happen when the only tech who knew the architecture was on vacation creating a difficult learning curve. And when the person leaves they take all the product knowledge with them.
Documentation does not require the application engineer to be a great writer. But it helps. When we are trying to communicate a message, the choice of words has an impact even when it’s about password policy. Documentation can include a generous amount of screen captures and video.
Documentation contributes to communication skills and as a part-time writer I’ve found that improving those skills improves my ability to persuade.
An adjunct of documentation is adding notes to the knowledgebase. While documentation records how something was built, it’s location, license information, application version and history, adding to the knowledgebase improves troubleshooting for both the applications team and help desk.
Don’t answer questions; solve problems. I’ve working in environments where information was horded and used as leverage to solve problems that others couldn’t. You might be stumped with a problem, but a piece of the puzzle was missing and someone comes in with the missing piece to save the day. That kind of approach is borne from the adage that knowledge is power. And it is. But some of those guys that horded what they knew are in the same place 10 years later with the same job titles. They got what they gave. They also didn’t learn anything new because people learned not to share with them. They are no better. They also haven’t made a lot of tight friends.
Communication is more than answering a question freely and openly. While that’s great, the communication that essential is to understand what colleagues need to know and providing it before they ask. Because people don’t know what they don’t know and will spend too much time searching for it. If ever you’ve worked in a branch office, you know what I mean. They are often the last to know what is happening and yet mocked for not knowing what is going on.
The result is a smoother process for IT and building trust with colleagues. This comes in handy when you decide to work elsewhere. You have a network of colleagues that you’ve helped
This is good advice for any profession, but it’s especially important advice for IT where the information keeps changing and we’re all a couple of years away from not knowing how the new stuff works.