Recently, a post on the CIO advice and opinion forum posed the question about working your way up the IT food chain. This made me think more about advice for IT, developers, and general “tech” people and how they can break the mold of IT and advance up the department ladder. Some developers or engineers find themselves working for managers who “have no clue.” What they don’t realize is the managers have the ability to work with internal stakeholders effectively and translate business problems into requirements for the technical team to implement.
Here are some examples of how you can position yourself more effectively with other departments in your organization so they look at you as the “go to” person not by just the title on your business card, but by the value you bring to their business functions.
The title on your business card defines what you do, not how you do it
The title on your business card does not always mean you are viewed as the “go to” person for your functional area — I have experienced plenty of people in business who are avoided at all costs due to lack of strategic and/or big picture thinking within an organization or on a project. Your title defines what you do, but how you go about doing it is another game completely.
In IT, understanding the needs of another department is extremely important when they come to you with a question or request. Nobody likes feeling stupid, and this is one area where IT typically falls short — fail to understand the problem, provide short, non-descriptive answers to questions, and allow the uneducated business person to craft the design requirements for a (web) project that makes little sense. This then results in an application or solution that underdelivers due to poor planning and creates a customer (the employee in the other department) who is unhappy.
Picture yourself bringing your car to a mechanic for service…how do you want to be treated?
(This is often times an easy analogy to make, so if you already understand cars, then pick another area where you are not as knowledgeable in and put yourself in the position of that customer.) You drive your car into the shop — it’s vibrating whenever you “drive it” and you obviously want it fixed because A.) it’s annoying and B.) it seems very unsafe!
Now, there are two ways to approach this: probe deeper, ask questions to help you navigate the troubleshooting process with the customer face-to-face, or take the car and run a series of tests that run the risk of looking at an area of the car that is not broken (and in the end not be able to find anything wrong — we’ve all experienced this, and it’s frustrating!). Vibration in a car can be a number of things — bad brakes, unbalanced tires, unbalanced driveshaft — the list goes on, and can be varying degrees of technical explanation depending on the customer’s expertise on the matter. A “go to” person asks questions because they genuinely want to help.
Sometimes the problem described is not the source of the problem at all
Odds are the customer doesn’t know exactly what the problem is, but they may suggest a fix because they don’t want to appear stupid in front of you. This happens countless times in business! They could say “the tires feel out of balance” but in reality, it could be that the vibration only occurs during braking, which generally points to warped brake rotors (among other things). Being the responsible businessperson you are, you would always start this process by going back a step or two to understand the customer’s needs and a description of the problem.
This will ultimately lead to a more accurate and timely resolution to a problem and a solution that hits the nail on the head. Part of being the “go to” person is providing that guidance that other departments lack — knowing they can come to you with an idea and you can help them make the most of it without making them look incompetent is critical in business. You will turn them into repeat customers.
Your customers (fellow employees) don’t really care about your deadlines
Another problem area in IT is the ability to turn on a dime or the tendency to paint a dreary picture from a resource standpoint. Just like bringing your car to the shop, you don’t really care to hear about all of the other work the shop has queued up, so spare your own internal customers (fellow employees) the details. Explain that you want to help them, understand their timeline, and fit their project into the mix where you can. If you make other departments feel like you’re doing them a favor for every request they come to you with and that it feels like pulling teeth just to get some time, you will lose your position as the “go to” person. Likely, they will look elsewhere or even outsource — at which point you’re cut out of the process completely.
A “go to” person follows up.
Ever brought your car to a mechanic, the expected due date comes and goes, and you never hear from the service manager? Avoid this situation at all costs. Manage your customer’s expectations, and provide reasons for why you’re going to be later than promised. Things happen, deadlines change, but how you manage the situation will also improve the satisfaction and perceived value you bring to a project and will ultimately paint you as a “go to” person. The “go to” person gets things done and follows up when they have or haven’t been accomplished. It’s just that simple.
Work through the process and/or problem, don’t work around it or point fingers
Many times IT is looked at for solutions to sharing data or information with other internal departments or external customers. This often times means creating a new process for the application or implementation you’re building on behalf of a department. If the success of your project implementation depends on the actions of another person or department, then work with them until their job is finished. Unless explicitly told to do so, don’t “pass the buck” and assume your work is done when another department has to get involved. Part of being a “go to” person is finding the answers to problems that are outside of your current knowledge or your functional area’s expertise.
Your internal customers may not realize the amount of collaboration involved, so don’t hesitate to give them a high-level (notice the phrase “high level” — avoid the technical details!) overview of what’s being done throughout the project. This is what will make them look to you in the future for other projects and view you as a “go to” person.