Driving innovation by increasing developer collaboration

Working together to achieve company goals can often be one of the biggest challenges while writing software

collaboration at a table with people and tools

Think about the last time you had to collaborate with another team at your company—does it bring back feelings of anxiety and stress?

I remember a time at a previous company where I found a bug that was catastrophic to our software release. I reported it to the team who seemed most responsible for it, and the ticket bounced around between two development teams and myself as the reporter. No one taking ownership or caring to talk to each other one on one led to a game I call “ticket ping pong.”

This game of ticket ping pong went on for three months and delayed the release of our new product by well over a quarter, costing the company significant amounts of money. I’m sure you have a similar story; developer collaboration is one of the most difficult yet important parts of technological innovation. This is especially true when you have to work across different organizational boundaries that are siloed.

There’s an old saying that goes “The only people who like collaborating are the ones that don’t need to do it,” and, unfortunately, this often feels too true with developer collaboration.

The complexity of problems engineers are trying to solve increases every year. Most engineers used to work purely on software, but today’s challenges cut across domains and require working with other experts to create truly innovative products. When done the right way, collaboration promotes innovation and improves the speed and quality of decisions. At LinkedIn, effective collaboration across organizations and between teams is a requirement of the business. It’s not always easy, but here are three tactics we use to make working together less stressful and more positive.

Assume positive intent and think about the larger software ecosystem

When a colleague on another team makes a decision that negatively impacts your own code, it’s easy to dismiss him or her as being incompetent or indifferent. But chances are, he or she simply didn’t realize how that change would affect you—just like you might not realize why the change was necessary for his or her code in the first place. When you find yourself in a situation like this, it’s important that you approach the problem assuming positive intent.

By taking the time to understand the full context of the situation, instead of looking at the problem from only your own perspective, you’ll be able to work together to build a better solution. It’s important to create opportunities for these conversations and to brainstorm solutions across boundaries that solve both teams’ challenges, rather than focusing only on your needs.

As an example, recently our ownership software was negatively impacted by a new feature implemented for the LDAP server. My gut reaction was to get frustrated with the other team. However, instead of reacting instantly, I took a step back from the situation to remind myself that it was trying to make improvements, too. I sat down with the team and discussed the issue, keeping in mind their requirements. We discussed the new feature and why it was needed, as well as our requirements on performance, and brainstormed solutions. Having this larger context, we were able to propose solutions that would help us both do our jobs better. My team didn’t need the new feature, so we added a flag to bypass it, and the other team got better tracking metrics and an understanding of how its data was being used by its customers. We walked away with a stronger relationship, a better product, improvements to our business metrics, and improved reliability for our software ecosystem. If I had approached the team in an emotional state, it likely would have gotten emotional and pushed bac,k and we would have not come to the same net positive outcome.

Celebrate your failures

Fear of repercussions when mistakes are inevitably made keeps a lot of people from collaborating. If something goes wrong, it’s easy to lapse into finger-pointing, hurting long-term working relationships and making future collaboration even more difficult. To help combat this tendency, it’s important to create a safe place to make mistakes. At LinkedIn, when something goes wrong, we talk about what happened and think about ways to fix the situation so that it doesn’t happen again in blameless incident post-mortems. In other words, we focus on attacking the problem, not the person.

My team once had an outage, with our software down for several hours. The root cause was that an email server we talked to had started to hang, which stopped our application from doing its job. Once you know the root cause, it’s easy to just blame the other server or the other server’s team. Instead, we conducted a post-mortem to evaluate how the situation could have been prevented. As a result, we realized that we didn’t need the email server as a hard dependency, so we added timeouts and skipped emails in the event the system was down. This helped us to improve the overall reliability of our ecosystem and will keep our system running in the future if this ever occurs again. If we had just blamed the email server, we would have had that team fix its application and done nothing ourselves, but in a culture that values finding the best solution over assigning blame, we ended up with improvements that made our own application stronger.  

Reward people for helping each other

Doing what’s right for the company is often in conflict with what’s right for ourselves—incentive schemes and promotions are often tied to how we do individually, rather than as a team. A previous manager of mine once said that the difference between school and the workplace is that in school you’re judged for how you do by yourself, but at work it’s how you do as a team that matters.

Someone who is able to amplify the performance of his or her teammates and promote collaboration is likely to benefit your company more than someone who just gets his or her own work done. Managers need to recruit and retain these hidden gems in their organization. At LinkedIn, we look for the people who choose to do the right thing for our members and the company.

These people come in many different types, but one of the most common is what I’ll refer to as the mentor. Most teams have someone who acts as the mentor for the rest of the team. He or she encourages the team to ask for help when it’s struggling to find an answer or debug a piece of code.

When I joined my first team at LinkedIn, a colleague acted in this role for me. I would get stuck with a compilation error and ask for help; it could be a missing semicolon, or a large complicated build issue, and he’d help me take the time to find a solution. If he hadn’t helped me in these situations, I would likely have spent several hours or days debugging the problem, but instead, he’d drop by for five to ten minutes and help me find a solution. This took him away from his regular job, and the context switching probably had a larger impact than five to ten minutes on his productivity, but it had a significant boost for mine. The result of us collaborating was a more productive team overall, with a small sacrifice in the mentor’s personal productivity.

A key to fostering a collaborative environment is recognizing that sometimes individual sacrifices like these are repaid many times over in the form of larger team productivity.

Games like ticket ping pong can easily be solved by working together in a more collaborative manner. In my case, we could have saved millions of dollars if we had taken the time to set up a meeting and understand the issue in a more collaborative way.

Working together to achieve our company goals can often be one of the biggest challenges while writing software. We have focused goals to help us better break down the monumental tasks of creating our company’s software, and it’s easy for emotions to get heated when things don’t go well. Moving past emotional reactions to think about how to work across teams and improve collaboration can pay dividends on your company’s and your success. Next time you find yourself in one of these situations, think about how you can lend a helping hand to your colleague, better understand your software ecosystem, and land a bigger win together.

Copyright © 2018 IDG Communications, Inc.

How to choose a low-code development platform