“People often accept something that works “fine” without realizing that maintaining such code is costly and time consuming. As developers, we have to remember that product owners are not programmers and that we need to clearly explain the changes we want to make.” – Mateusz Spiewak, X-Team
When we make suggestions for improvements in a traditional office environment, we have a lot of methods to help us convince people to move forward with our ideas. We can stop people in the hallways, gather leadership in a conference room and show a presentation, walk into offices, bring up ideas at the pub at Happy Hour, and various other ways of using personal relationships and in-person trust to sway superiors to bring about change.
Being remote removes those options from our toolbox, and introduces its own challenges as well as benefits. But a unique trait of every X-Teamer is how proactive they are in doing whatever it takes to present clear, strong recommendations for improvement (remotely or not).
So we spoke with X-Teamers about what they’ve found are the best ways to have success as a remote developer who wants to help drive their team forward and make improvements.
Take advantage of remote’s necessity for clarity
Ryan Chartrand: One of the benefits of being remote is how it forces us to make our messages to our team as clear as humanly possible. This, of course, translates to when we make suggestions for improvement as well.
Whether you approach someone with a suggestion via Skype/Slack/Hipchat, e-mail or while on a call, your message will have to be incredibly clear and brief in order to both grab their attention and get them to move forward with your idea.
Let’s say you wanted to recommend starting to do automated tests. That’s a broad topic, right? Trying to pitch such a big concept remotely isn’t going to be easy. If the people you are pitching this idea to are going to be reading it via a chat message or via e-mail, you have a very small amount of time to get that concept across.
So rather than start by trying to explain the entire world of automated testing, start small. Start with something small, very relevant to current needs/challenges, and easily achievable within one or two sprints from now.
For example, perhaps there was a bug discovered last week that brought down the entire homepage for hours. That’s the kind of bug that should never happen again (especially if people want to keep their jobs). On your next sprint planning meeting, suggest that it’s worth setting up an automated test that checks before every deploy to make sure that specific bug hasn’t regressed.
Rather than starting with a very vague, broad topic like automated testing, you instead started small, with a very specific use case that solved a very relevant challenge that has clear value to people (ensures they won’t lose their jobs). These are the kinds of recommendations that are clear, valuable and will set you on a path to achieving larger improvements you have in mind.
Oftentimes in a traditional office environment, we go for the big, showy, conference room presentation approach in order to influence change. Being remote forces you to be more specific, clear and to the point, which ultimately results in a better chance of success.
So remember: start small, clear and focus on value for the whole team in order to work toward making the improvements you envision. Rome wasn’t built in a day, but with persistence, clarity and focus, you can build anything.
Suggestions depend on an understanding of empathy
Josh Johnston: I think one of the biggest things here is: before you tell somebody to change, you have to understand how they got there. If you look at someone’s product and spot an area that needs improvement, it’s most likely not because you are smarter than them. The product has been born out of a complex system of competing demands, and limited resources.
We all want our products to be perfect, but remember that perfection is not always found in the individual parts. The perfect product is one that ships on time, within a budget, and makes people happy to use it. So anything that you can do to understand the context and the product owner’s priorities will help you to phrase the question.
Once you have a bit of this understanding, you can start asking yourself questions like “Why would they care if we are missing a few semicolons?” Just because something is right, doesn’t mean it has value for this particular product (I’m deliberately trolling here, but hopefully you see the point I’m trying to make).
Maybe you will observe that the team’s productivity is hampered by having to fix a lot of bugs. So instead of coming in babbling about semicolons and linters you could start with the more relevant topic: “I’d like to discuss with you some productivity / quality challenges we face, and some simple ways we can address them“.
Use improvements as an opportunity to unify your team
Mateusz Spiewak: Unlearn the words “you” and “me” and start using the word “we.” Instead of “I want to improve,” instead use, “We should improve,” or even “Let’s work together on a solution,” or, “Our lives would be simpler if we did _______.”
Using the word “we” delivers a feeling of teamwork and inspires a sense of unity, which although difficult for remote teams to achieve, all starts with using the right language to get there.
Don’t be a constant complainer; make the effort to present a clear argument
Wojtek Zając: Go the extra mile. You don’t have any excuses when suggesting an improvement: focus on the ideal scenario. When you’re sending a code gist, follow good practices and design patterns. Focus on good documentation.
Back it up with links. There should be good evidence that what you’re saying is actually proven. Bonus points for research, tech talks, and blog articles.
Being negative will get you ignored real quick
Wojtek Zając: Avoid negativity. Put an effort on wording your suggestion carefully. In a remote team, the other person won’t see you and could read your intentions improperly.
Never make your recommendation personal. By all means, avoid name–calling and always stay away from blaming other people for faults.
Your suggestion was approved! Now, don’t let it die
Wojtek Zając: Monitor the progress once your suggestion is approved. Imagine that you proposed adding schema.org data to the site; it was accepted, but it turns out that other developers are not familiar with it and they didn’t validate results before signing off the task. Subscribe to the github issue. Follow up. Add further advice if needed.
Or…knowing when it’s time to accept defeat
Wojtek Zając: Know when to stop. Sometimes when you feel that further discussions won’t lead to anything constructive, just leave. The saying “pick your battles” has been around a while for a reason.
And finally, it’s worth hearing some advice about the inevitable day when someone will present *you *with a suggestion for improvement.
How you receive is just as important as how you give
Kuba Dobranowski: When you don’t see someone else’s face, or hear their voice, or feel their emotions vibrating in their hearts, it’s quite easy to misread their intentions.
If you have a bad day, don’t let it affect what others are trying to recommend to you, because suggestions mean they want to help – and this, in turn, serves the purpose of you getting better and better. Learning from criticism is a proof of wisdom.
Always try to approach a suggestion you receive via text assuming the most positive emotions from them.
