Yet again, I can almost hear you screaming through the very cabling that makes up the internet: “Dave…seriously…have you nothing better to do than sit around and write these things?”
1. Depending on the day…”no, not really”.
2. More importantly, this one’s not mine. This one comes to us courtesy of Chris Martello, who some of you may know from his attendance at a few of our events.
And he’s got some good points to raise up. It’s not just about networking with people at our events, or even at events at all…what you do day to day around the office is equally important.
Wanna know why? Read on…
Intro
With much of the focus of IT Networking being an external activity, I thought I’d bring to light some of the internal aspects of IT Networking. You never know when you may need a referral from a current colleague, or when you will run into that colleague again at another gig. Having good relationships with your current colleagues could lead to the next job, or could prevent a future opportunity based on the relationships that you build each day at your workplace. So it seems fitting that we turn our attention to some of the personalities that you come across INSIDE organizations that you have probably experienced at places where you’ve been. You know these people; they exist in every IT organization in one form or another, to one extreme or another. You may find yourself nodding your head at these descriptions in agreement, much like you laugh at a Dilbert cartoon, but you’ll have your own personal examples that have much more meaning to you. Here are a few of my favorites.
Project Manager – a.k.a. “The Task Master”
The Project Manager has a difficult job herding cats, keeping the children in line, or whatever metaphor you wish to use. They are doing their best to work towards a plan, goal, and deadline to ensure on-time delivery of the product. They are checking, double-checking and re-checking again the status on all their tasks and list items in order to make sure that everything is still on target. They hound you for status, updates, and invite you to endless meetings that waste your time. They are a task master and it is their job to hold team members to the agreed upon deliverables and deadlines that are set forth for the project. I once heard a project manager say, “I didn’t say it was your fault, I said I was blaming you.” That’s not a great way to build rapport. Nobody likes being held accountable for factors outside their control and being constantly reminded of their responsibility, yet there he is. The Task Master is just the messenger, right? Well, as my mother used to say; “It’s not what you say, it’s how you say it.” There are ways to be tactful about communicating with colleagues and collecting status, and there are ways of being a complete (asshole) jerk about it. When the development team manager stops by your desk and wants to talk about your ‘performance’, you know the project manager talked to him on the sly, and WITH malice. It’s that one time that you are slightly delayed or blocked by process or bureaucracy and the project manager raises red-flags, turns on the sirens, sounds the alarms, and cries wolf that the project is going to be DELAYED (gasp) because THE DEVELOPER isn’t getting stuff completed according to the wonderfully crafted, carefully managed, master-sacred project plan. This is usually the point where I want to take the laptop running Microsoft Project and throw it out the window. Planning tools are great, but they always leave out one factor; the human factor. That’s also what the Task Master fails to realize when running the project; that projects aren’t run by computers, they are run by people. In order to accomplish a team goal with people on the team you need to use good people skills to lead a team.
Lead Developer – a.k.a. “The Elitist”
The lead developer is an important part of the development team as he sets the technical direction for the team. He may choose the platform, development tools, and even design the development process. He enjoys the order and ‘elegance’ of the technology and raves about all the wonderful things you can do with it. His tool selection is really the key here; the platform, coding language, hardware preference, software choices, operating system; they are all ‘the best’ and there is nothing else that can even come close to being as good as this one. He looks down upon lower operating systems with disgust and scoffs at programming languages that can’t compile code in less than 0.25 milliseconds. When presented with alternatives the defenses are raised and the attack is on. “It’s just better,” with little justification as to the reasoning behind the statement. This person may be labeled as a ‘fan-boy’ or an ‘evangelist’, extolling the virtues of their favorite technology and dismissing all others categorically. In extreme variations of this character, he may even be combative when the project falls out of process in favor of a slight turn in direction. When clarifying requirements his responses are less than timely and he can throw up roadblocks like, ‘it’s a data issue’ or ‘that’s how the system was designed.’ Then there’s my personal favorite response when inquiring why feature xyz doesn’t work properly in the TEST environment; Developer: “I don’t know, it works on my box.” At this point, you are left wondering how the (hell) heck this guy got to his position with the clear lack of people skills?
Quality Assurance Tester – a.k.a. “The Gatekeeper”
The Quality Assurance Tester is a very important part of the team, ensuring a level of quality in the developed applications. They make sure that the user experience is good and that there are no bugs in the software. They have a tough job reporting defects and issues to both the project manager and the lead developer. The developer writes all sorts of code to build software features that meet the requirements. The developer spends days and weeks of constantly clarifying requirements and showing their customer what was built. They put their heart and soul into coding functions elegantly to the specification. The tester goes through the application with a test plan and some test tools and comes out with a list of issues and defects. This basically amounts to the tester telling the developer that ‘his baby is ugly.’ Who wants that job? It’s a tough one to be sure of, but the tester can be your best friend, or your worst enemy, and that perspective can change in the span of five minutes when attending a status meeting. If the tester is doing his/her job right, they are actually protecting the developer from releasing bad code. Without knowing all the issues present, the developer would be on the hook to fix it in a hurry after release to production, which is never a good situation. The readiness of an application should be determined by the team, but really it’s the tester on the project which gives the blessing. Being the gatekeeper is a tough job because the first question when someone finds issues in the production environment is “Why didn’t QA catch that?” This question usually has the side-effect of causing the tester to go (ape-shit) ballistic over every little issue or defect in subsequent projects and becoming difficult to work with. Finding a happy medium on testing issues and application functionality is a working balance and partnership that the developer and the tester need to find together by communicating better and being reasonable about expectations.
System Administrator – a.k.a. “Angry SysAdmin”
It is human nature to take the path of least resistance, so when ridged standards and bureaucracy stand in the way, people find the easiest path around them. Such is the case when dealing with System Administrators. The system administrator’s job is to maintain not only the production environment and applications, but all the other systems in lower environments as well as tools for the organization that support the development OF those applications. They maintain an environment built on standards, naming conventions and organization with minute detail. Those details at the networking level are important too, because one improperly flipped ‘bit’ on the network switch and production is hozed. Perhaps this is why the SysAdmin is so touchy about changes in the environment, as he should be. Yet again, we find the most important System Administrator is the one with the least tact and grace when it comes to interacting with colleagues.
The Angry SysAdmin finds creative ways to say ‘no’ to any requests that come across his desk so he only has to do minimal work or none at all. Getting a request filled is like pulling teeth some days. Simple requests like this: “I’d like PHP upgraded to version 5.2 on the build server for application XYZ.” are responded to with obstacles and denials along the lines of: “Can’t. Application ABC relies on version 4.6, and that’s on the build server too.” So we ask differently; “Ok, fine with me. Can you put my application on a DIFFERENT server that CAN have PHP 5.2 on it?” We don’t ask too much, and we are even willing to wait a little bit before the environment is ready, but no, we get the blockage: “PHP 4.6 is our standard. Sorry.” Where’s the creative problem solving? Where is the customer service that we come to (hope for) expect from our service teams? It gets mired up in process and bureaucracy for the sake of laziness. So when something complex comes up like a big architecture question that didn’t include the Angry SysAdmin, he turns into a phase three werewolf complete with hairy-scary arms, fangs and drool about being left out of the loop. All this from a team leader whose motto is: “The beatings will continue until the morale improves around here.” And he wonders WHY folks try to go around him. Honestly.
Conclusion
Networking with colleagues in your current position can be just as important as networking with outsiders for your next position. So when you recognize these personalities in your organization, take the time to communicate well with your colleagues and don’t be that guy.
Until next time…
Make sure you check out our other Don’t Be That Guy entries…