I was recently answering a couple questions about this for someone and I found I had a lot to say about it, so I'm going to try to encapsulate those thoughts in a blog post.
I've realized it's much more important to encourage people to solve their own problems. It's what most people want, anyway. Your job is to listen to them and to give them tools and encouragement they need. My first answer to 'Professional Conflict in the Workplace' - is that youneed to help people help themselves. It took me a long time to figure that out, but with help from a good mentor and from this book I've really tried to shift away from getting involved directly, as hard as that is sometimes.
To begin with, you need to understand what help you're being asked for. For any professional disagreements what's really being said is, "Please help me get better at working with this person." This can be true, even if they don't phrase it this way.
If someone is venting, you need to listen and ask why they're venting. Questions like - "What's really bothering you?" or "How do you think the situation could be resolved?" Can help them move away from their vent and focus on what they can actually do about it.
Once they begin to focus on problem solving for themselves, you can coach them through that - again questions are useful. "What else?" or "Do you want to rehearse what you will say?" are valuable here.
If they plan to talk to the person they're having a disagreement with, you should state your expectations for the interaction, “You’re going to speak to Ted this week? Let me know on Monday how it went.”, “Please listen to the other side of the argument and seek out a win/win.” Only get involved further if the sides seem unwilling or unable to reach a decision.
One other possible resolution strategy that I have used is to simply invite the other party to the meeting where the venting or other discussion is occurring. If someone is complaining or struggling with a workplace conflict, simply ask to bring the other party in. Then pick up the phone and say to the other party, "Can you come down here? I need your help resolving something."
Once both people are together I usually speak first and try to characterize the issue as I see it. Then the parties need to work together resolving a solution. This has the advantage of bringing both sides to the table and drawing forth quick resolutions.
You should be careful about when and how you employ this strategy and the different profession and emotional levels of the parties involved. It's effective if you feel the parties need supervision or if you simply want to make it clear that you want an answer now. It avoids all he said she said aspects. For manager-to-manager disputes or director-to-director level professional disagreements it can be an effective tool.
Most of the time, the two sides, when brought to the table in this fashion will see the expedience in working together to find the right solution.
There may be situations where you need to make the final decision. In that case, you make the decision.
In general I would still characterize this as a win/win to both sides if you can reasonably do so. But the 'loser' may not feel that way. Avoid overselling it. You can come across as dishonest if you don't realize that one of your employees just lost an argument.
Above all, you should make sure they know that you listened and that you appreciate their cooperation, you know they're a professional and will abide by the decision. Do your best to explain the business rationale of why you chose the way that you did. Avoid the urge to let them feel like they are owed one. In the future you need the latitude to continue to make the right business decision, based on who has made the best case.
By forever, I mean it took me almost an hour. That says something about our access to information and my own expectations, but that's another blog post entirely.
The trouble happened because of the nature of my question - which the StackOverflow post does a good job of explaining - I'm trying to call one integration from another. This leads to a semantic overlap of the parts question I'm trying to ask.
I like to envision this as the question collapsing on itself, inside of Google, but I probably don't really understand that as well as I think I do, and I did just watch Tron recently.
Plus many variations of 'call a slash command from web hook on Slack' leads me to Slack's own documentation where they don't answer this question (as of this writing 3/1/2016).
In the end the answer is obvious - you can't call one integration from another. This prevents a lot of attacks or spamming that could probably happen if you had a wide open gateway to push data through Slack.
How did I find it in the end? Brute force querying google until I found a result that didn't look like all the other slash command/web hook posts and documentation that are out there.
Final Google query - 'pass giphy to slack api' which removes the confusion by specifically naming the thing I'm trying to do - 'giphy' - instead of just asking more generally about slash commands.
It was the 4th result.
I have to teach my kids all this some day. Maybe they will just grow up knowing how to do it.
I have heard from some parties that the cloud technology offerings that are gaining traction now (Google Cloud, Microsoft Azure, Amazon Web Services) are going to bring about the "death of IT".
First of all this is a big overstatement. Next, I also think these technologies are actually going to be net job creators, and not just for developers.
This is true because more small companies can afford to build-out infrastructure and therefore we will have more technology startups, which will create more jobs.
I also think that existing IT jobs likely aren't going anywhere either. These environments (Azure, Google Cloud, AWS) are complicated and it takes a good IT professional to learn them, set them up correctly, and manage them. There is a lot to learn here, so A) people need to go learn it and B) smart people need to be in charge of managing it in the long run.
And, interestingly where there were basically two flavors of IT in the past (Windows and Linux) now you have 3 - Microsoft, Amazon, and Google. Even though Amazon and Google are based largely on Linux, the two service offerings are not the same thing. They have different services, different UI, different structures. To be an expert in one is not to be an expert in the other.
To me this is nothing but good news from a competitive standpoint (3 options vs. 2 options) but also from a job creation and economic perspective.
The other good news? Since these platforms actually run VMs in a lot of cases, your existing IT expertise will still be applicable as well.
Virtualization probably has had a negative effect on jobs thus far, but the next stage will almost certainly create jobs, and opportunity, for those willing to learn and pick up new skills.
I recently rebuilt our employee recognition tool using AngularJS.
The old tool had been built as an add-on to our case management tool, which we are migrating away from.
Since Angular is our preferred web direction, I believed it beneficial for me to dabble a bit and rebuild it using a modern, strategic technology.
Once I was able to do that, it was relatively simple to get done what I needed. My app was about 6 pages with 2 input forms, 3 grids, and a port of an old jquery-centric billboard form with some basic fade-in/fade-out animation.
This was no enterprise system mind you, but it had enough moving parts for me to learn the basics and prove to myself how hard it was going to be for others to learn.
The Amadeus Innovation Team has already developed a lot of our AngularJS best practices so that portion of the transition process is covered. There's a fair amount to think about in terms of project structure and approach, but I have left that to the more expert development minds.