Guys in my position are generally pretty busy people. We're usually outnumbered by requests, situations, questions, tasks and people to help, manage or get back to.
Not to blow our collective horns for those of us who identify with this space, but we're pretty scarce and in high demand.
Not because we're rockstars (far from it).
But we possess a cross-section of skills and experience, not deliberately acquired (in my case anyway), but that has been built up due to the need for them at various times in our careers.
The term we used for people like us was 'RSG' or 'Random Sh*t Guys'. Because anything that landed in the "too hard", "who's job is that?", "what the? where did that come from?" and "look, we're in a bind, we really need someone to figure this out!" basket, it was usually us who ended up sorting it.
And this could mean anything. Network (issue, design, troubleshooting), Design (architectural as in draw something, or figure out what's wrong with this design), Scripting ("here's this whacky ruby scripted monstrosity - please un-monster it and make it work"), Security Appliance (nobody knows how this works, please learn how it works and make it do the things we need it to do).
There's no qualification for this type of role. You learn by doing, and you do because you like learning or figuring things out. Otherwise, like most people, you think "that's not my job and I don't get paid to do that" and find your nearest RSG to hand it over to.
Now. Why am I talking about this? I guess because it occurred to me that because I can't really advise how you would get into this type of role (there's no straightforward path to here), I can definitely advise on particular set of skills you will definitely need to survive in this role.
What role are we talking about exactly?
Good question. I may have lost you down RSG memory lane aka 'nam flashbacks in the previous paragraphs.
The role, is the Project Delivery Systems Engineer or IT Consultant (which sounds like it makes way more sense). The guy who does the systems/infrastructure stuff but understands enough about everyone else's' jobs to help everything come together.
Job Specific Skills
This one is pretty obvious, and sort of goes against what I just said in the last few paragraphs if you don't keep reading.
Job specific in this context is learning exactly what they need you for on this contract possibly based on something similar you've done before.
For example. I worked at a place that needed me to configure mulesoft ESB's and Citrix NetScaler Load Balancers. Never worked with either before but I knew Weblogic/OSB/SOA platforms. So I downloaded NetScaler onto my lab, learned the syntax, the ups & downs. And now I had the job specific skills.
It's not a cert. Or a qualification. They didn't have time for me to go away and do a 3 week course on it. I just had to know how to do they things they needed it to do.
So I got me a 'job specific skill'. And you keep doing this with this type of role. And accumulate the experience to continue doing this kind of work (sorry, like I said its not an exact science.)
Problem Solving Ability
Now this might sound technical, and a great deal of the problems you'll solve will be technical. But I think what makes people stand out in these roles isn't the technical problem solving - but the WHOLE PROBLEM problem-solving skills.
What do I mean by this?
Let's say for example the project is in trouble. What aspects of the entire project can you make an impact on to alleviate the issues?
Can you provide your Project Manager with several solution options with risk, assumptions and expectations to help the client?
Can you see where the delivery bottle-neck is and do a deal with the Change/Release managers?
Can you see an issue on the vendor side and anticipate any information requirements, skills shortages or uncertainties to speak to, which will help the project out?
If you understand the everyone's roles, motivations and drivers, you stand a good chance at finding solutions to a wide range of problems.
And if it happens to a technical one, sweet, now you can get your hands dirty.
People Skills
This one could almost fall under problem solving as well. But I didn't want to frame people as "problems" necessarily (lol).
People skills, to me, is being a good listener. Not telling people how to do their jobs (PM's I'm always kidding when I do this with you guys, you know I love you guys). Not telling people what they did wrong or how something was their fault (what does that achieve exactly?)
This is easier said than done, especially when people come gunning for you. But if you listen closely enough you'll see its not about you. They're frustrated because the system broke down, or someone didn't follow a procedure that tends to make their work more difficult, or their boss is pressuring them for something that's outside their control.
People skills is being able to hear what the real need is under the distress, and then being big enough to calmly help them out.
Communication (again)
This should be a no-brainer.
After its established that you've got enough RSG experience to hang in this role; and that you can see problem-solving involves more than just technical issues; and you've learned that people skills is about seeing the actual needs of people...
Well, then you're just left with communication skills.
"But Ron, isn't this just people skills?"
You would think so wouldn't you?
It's not. Otherwise this would be a pretty short(er) post.
Communication is not just doing it - but also knowing how to do it well.
What do I mean by this?
When your project is hit by something out of left-field and the 12 hour estimate for something you were supposed to deliver by tomorrow is now looking unlikely.
You need to communicate this to the team.
And no "hey, you won't be getting X tomorrow" isn't going to cut it.
Getting into a hissy fit about the thing that came out of left-field is also equally useless to everyone.
And no, I'm not suggesting saying "everything's fine, will have it by tomorrow" and then working through the night until you're a mess, either.
Communicate what's happening, why it's happening, and what can be done about it. Your communications should help manage expectations.
At the very least it'll help your project manager set the expectations with the client.
So not only do you have to a) communicate something (don't just go to ground, turning your phone off etc) but also b) communicate it in a helpful way with lots of info and other answers which might help keep the client calm(ish).
Conclusions
Not that you need one, but these points are the areas of skills I think are not only very useful for anyone thinking of getting into this field (the RSG one), but for your office life in general to set you apart from everyone else.