We’ve all had them. Colleagues that fight you at every turn and then get upset when you have legitimate concerns about a project they lead. As an individual contributor, what do you do about this? As a manager, how do you foster peace and harmony while maintaining forward progress? I’m going to break this into a couple sections; first, individuals have an obligation to their managers to let them know when things are hostile. Second, managers have an obligation to their staff, especially the strong performers that are raising concerns, to take care of barriers. I’ve experienced the individual contributor and managerial tension; it’s difficult and both sides need some grace and humility.
Let’s get going…
Individual contributors. Let me provide a scenario. You work with a dude, heck, maybe this is you, who thinks any suggested proof of concept (POC) should immediately become production. For the guy suggesting the product, he wraps his identity in approval from his peers and managers. Any technical or business rejection is a rejection of HIM (or her).
I can’t tell you how many POCs I’ve had rejected over the span of a 20 year career. Back in the frame-relay days, I did a 6 week study on how to do Voice over Frame Relay. Piles of documentation, sketches, phone calls, and code changes to support the argument that it would be good to retire the PBX. At the time we used an old Rolm that barely supported digital phones and was wicked expensive to support. We burned more analog phones because techs connected them to a digital port than I could shake a stick at! The end result is that the business didn’t want to spend the money to move in that direction.
That sucked. I shrugged. I moved on. You see, many times the business isn’t exactly certain how the technology can help their problem, let alone, put a finger on what their problem is. They rely on us technologists to do not only tech, but determine how it benefits them. More recently I was working for a bio-manufacturer in Warsaw, IN. We had Nexus 7000’s in the core and I thought it may be a good idea to converge data and storage. Nope. Technically it was possible, but the personnel wasn’t able to support converged storage. All the documentation and research suggested it was good to move in that direction, but, the people on the team couldn’t support it. It’s just one of those things. I recommended we not take advantage of that functionality and continue leveraging Brocade, plus, train the network and storage staff. This recommendation helped the business recognize new technologies and limitations for growth. It also helped identify a deficiency in training that could be addressed.
Years ago I read an article from a techie that suggested that business be more communicative and elaborate their needs. It seems the business expected “us” techies to know business requirements, but shouldn’t expect the accountant in cube HQ1356 to understand IT functions. Part of me agrees with the sentiment; the “business” is our customer. I don’t care how Target or Walmart works in the back office as long as services are provided. Business units should operate with a similar understanding. If I went to Target and said I need a widget that does some function, I don’t care how they do it, just provide it or I go look somewhere else. But I also expect the business to be able to define to IT what they see their own customers needing.
Hey nerds! We provide a service. If the customer isn’t ready to spend six-figures for the latest and greatest technological solution. Guess what? They get to make that decision. You—techie—didn’t help them understand the need, define the need/benefit, or miscalculated how the spend helps your customer. In the end, we’re salesmen. If our product doesn’t work for the business it’s just wrong. Don’t take a PoC failure as a personal affront.
What do you do when you can’t move on?
The important thing is to not let business rejection be personal. If you find yourself grumbling over a
management decision, you’ve derailed and lost sight of the objective. Over the years I’ve learned that if you want to get stuff done that you think is important, you need to do a couple of things.
- Clearly identify the problem.
- Explain how the proposed solution will economically benefit your customer.
- Illustrate the cost differential.
- Have a good-better-best plan.
Of those four, remember you can still be shot down. Just say’n. If you’re following this approach and continually get told “no”, at that point you may consider looking for other employment opportunities. That’s not your first option, but certainly something to consider. Technologists, generally speaking, want to do things that are a) challenging, and b) beneficial to their customers. When we think through technical solutions to a business problem, but the business decides not do take the advice you only have a couple ways to deal with that. Move on, or grumble.
You can understand there are certain things above your pay grade that you don’t know or understand. Sometimes it’s a budget issue, business unit direction issue, or misunderstanding of a business problem. If you think the tech is really that important, dust yourself off and try again. Take a smaller approach to make the idea more palatable…but you better be correct. You’re putting your technical reputation on the line if you push hard. That’s something you’ll need to judge.
The bigger problem is if it’s always an attack from your own team member. You have an interpersonal issue or you suck as a technologist. Most often, it’s not the latter…but what if? Take stock.
What If It’s Personnel?
Should you take objections personally? Maybe. Maybe you work for someone who is a total jerk and doesn’t like you or your ideas because they’re not theirs! Or, maybe it’s a perceived slight in your own mind. Maybe you’ve misread a text or email and have taken offense without the backstory. What do you do if the person is just hostile and toxic? Basically, put your big-boy pants on.
First, remember that it didn’t happen if it’s not written down. If you’re having a huge issue with boss or colleague, write it down. Write everything down so that if an HR issue arises, you can defend yourself. That also means don’t get drawn into a pissing match. You have to be above the fray! The world is hard and it’s not always about you. That’s a tough lesson the first time you learn it. If it’s the fifth issue, well, you may want to stop reading because you’re hopeless. The best thing to do is always maintain a professional attitude.
What if you’re the boss?
I’ve worked for a lot of folks and the best ones were always the ones that could set clear expectations. Most individual contributors have no idea what’s happening two layers above them. I always tried to extend this courtesy to my bosses and my directs:
- Have regularly scheduled one-on-one meetings and come prepared. What is being worked on? What is new or coming down the pike? What is the status of deadlines?
- What issues are being raised from the “higher ups”? Are these things that can be solved with process, technology, or both?
- What technology or process can be improved on? What ideas can be shared with the team to make life better? Are there barriers to success?
If you’re the boss and your direct report screws up enough courage to tell you there are issues, especially with others on the team, pay attention. If the offender leaves your organization, you win. If you address the issue with the offender, and they adjust, the team wins. As hard as it is, if you need to fire someone, you still win because the guys that report to you will know you have their back. Hopefully you know the good workers and can get a feel for personalities.
Problems Galore
Okay business and IT geeks, ultimately, what are you trying to solve? In my organization I work with a guy that thought Riverbed WAN optimization would solve a problem. The way data was being transferred to remote sites was causing high utilization on the MPLS port, which caused network monitoring alerts, which caused a flurry of activity. My colleague did a full fledged proof of concept (POC), but didn’t establish success/failure criteria, statistics validation, or let end users know they needed to monitor their experience.
What is the problem we’re trying to solve? How do we know Riverbed—in this example—is a successful player? How do we know the product succeeds at what we’re solving? What are the other benefits? SD-WAN? Client compression? SSL off-loading? Does the POC plan include those functions? If not, why not?
See how this works? We’re supposed to give analytical information to the business so they can evaluate the cost-effectiveness of the proposal. Anything less is, well, sub-par engineering and if you’re blaming colleagues, well, that’s on you.
The real problem is when you hold the POC so close, that you’ve emotionally integrated before anything has been approved, let alone vetted by peers and customers. You see, a POC is just that…a concept. You want to be certain it solves a need; but if you’ve neither effectively solved a need, convinced others of the need, or designed a solution for a defined need this “solution” is a fart in the wind. Another example of IT vapor-ware. As an IT professional, I’m sick of that from my colleagues and we should all be held accountable for such nonesense.
It isn’t personal, it’s professional.