You may have seen all the hype around ES6 and hopefully are already taking advantage of some of the cool syntactic sugar that ES6 has to offer. But, you don’t need to be satisfied with just doing the next cool thing. With Babel, we can already start using ESNext features in our code. read here
Nothing is sure to sink a project more than fighting between the project team and all the other groups in the organization that it may impact. We have all seen this happen before, the project team needs something from infrastructure, security, or qa (although they should be on your project team…) and for whatever reason, they can’t or won’t help.
Now, I say “for whatever reason” to be inclusive but it is amazing to me how often we don’t take time to ask what the reason is. So it really turns into “for some reason they won’t concede to our demands….” Let me ask you a question, if an infrastructure team member came to you and started telling you how to write your app, would you listen? really? Yet for some reason as developers we tend to expect other teams to just do what we say or take our suggestions as gospel.
So, if you want to smooth the path with your neighbors, you need to do three things.
1) Get their input on your project early. Buy them donuts or coffee early in the project and tell them what you are doing and why you are doing it. Real reasons, not just that it is “the most important thing”
2) When they throw up a road block (and they will) take an honest interest in why they are doing it. Just because it is not important to you does not mean it is not important to them. Take the time to sit and understand their position. Not so you can convince them to change, but so you can find a solution that will work for everyone.
3) Make their life easier. Ask your project team what they can do to help ease the burden of these other teams. If qa is buried, can you do more pre testing? If infrastructure is busy, can you try automated deployments? Be creative.
Now, making their life easier only works if you took the time to understand their issues. Once you start treating these other groups like they are actual people with real issues and goals, you will be amazed how much easier it is to work with them.
tl;dr All the other people in your org are actual people, treat them like they are important and they know what they are doing…..
OK, I know one thing for certain about whatever project you are working on right now. At some point, something will change. There is no doubt about it. You know it is true. Once the business owner or the user see something, they will want it be be different. Now, the question is, when that happens, what person are you going to be?
What do I mean by that? When something changes, there are generally 2 types of people that respond. There are helpful people who anticipate the change and work through what it means for the project. Or, there is “that” guy. “That” guy for whatever reason refuses to acknowledge that change is coming and when it does gets really mad about it. Generally the first response from “that” guy is “No! we can’t change it, why didn’t you plan?” or “It’s not possible to do that.”
Sometimes “that” guy takes the opposite stance. He will answer with something like “Sure we can change it, if you are willing to shut down everything and start over!” He will agree with a change with some overblown response in hopes that if he overstates what it will take the business side will back down.
These types of obstructionist people do nothing but add conflict to a project. So, don’t be “that” guy. But be careful, the pendulum can’t swing too far in the other direction. Some teams take whatever changes come there way and just go do them. Thats when you get into trouble with the business side not understanding why you keep missing the deadlines. They suggest changes, but are never told how that will impact their timeline.
So, what is the right way to handle this situation? You need to do three things with every change request.
Thats all there is to it. Every change, every time work these three steps. Following these steps in a helpful constructive way will add tons of credibility to you and the project team. It will amaze you how often a change is killed once the business side understands what a change will really take. It may also surprise you how many changes just are not that hard to do.
tl;dr Things will change, be a voice of reason and calm in your organization. Don’t be the one who is looking to cause conflict.