Collaboration as a Developer: Finding Shared Goals and Reframing Conflict
Unsurprisingly, software developers spend a lot of time writing, discussing, reviewing, rewriting, testing, and deploying code. I know I’ve sometimes felt like my working life is focused on going heads down and writing the fastest, most-precise code in the smallest amount of time. Often, it feels easiest to achieve this goal working by yourself.
But the truth of the matter is that we don’t work in isolation. Companies are never composed entirely of developers. At the end of the day, the support, instruction, and collaboration of our teammates and peers in other roles aren’t just helpful, they are mandatory for making exceptional work that best serves our students. For me, working to make these interactions more helpful, efficient, and mutually respectful has been a valuable part of becoming a better developer.
For this post, I’ve identified a few common roles we’re likely to encounter in our day-to-day interactions as software developers, and I’ve listed some thoughts and experiences on my work with these groups in the past. From the resounding successes to the awkward silences and near-fistfight shouting matches, I hope to reinforce the idea that software engineering is not a solo act.
In general interactions, one of the most common ways I see developers instantly lose the good will of their audience is to bring an inflated ego around their work. I believe this is a negative side effect of working in a field with such low unemployment; it’s easy to assume that if developers are difficult to find, your role is very important. However, I would suggest maintaining constant awareness of these feelings. One friend and former colleague told me she thought I was one of the most obnoxious people she had ever met after an early interaction where I intended to be funny and self-deprecating but came off as self-important. I’m very glad I was able to salvage that relationship, but I absolutely stay more aware of how I come off now, so as not to repeat this same mistake again.
In more specific interactions, let’s take a look at how we engage with experience designers. Not all of us necessarily work with one (or a team of many), but chances are that if you produce or maintain a website or user-facing service, you interact with a designer on a near-daily basis. I believe one of the most common friction points in our industry appears at the developer/designer border, due to how interconnected these roles tend to be. If you’re a developer, you may have had more than a few tense conversations while collaborating with designers. I can think of no shortage of interactions I’ve had, around everything from new product inceptions and entire navigation redesigns, down to padding changes on text. Oftentimes these rousing conversations can feel accusatory, but I believe that if you step back and consider some realities about both roles, you can easily help these relationships become productive and respectful.
One area where I’ve felt frustrated is trying to understand specifications around additions and changes of products. The mistake of changing something in a way that my designer never intended is one I’ve made more times than I’d like to admit. And, unfortunately, it’s pretty easy to respond defensively when you’ve made a mistake.
As an example, consider collaborating on reworking a modal button. The focus of the designers you’re working with shouldn’t be ensuring that the mock-ups they give you include a pixel-perfect example of the entire screen on all resolutions, since you’re just tweaking the button. As a developer, it would be easy to assume that the designer was asking for a change to something like the sidebar navigation component, if the design made it look different from production. I’ve learned that I’m prone to making this mistake, after making changes numerous times that ended up being unintended and undesired.
Sometimes, my natural response has been to look for ways that my mistake was someone else’s. But it’s always much more productive to acknowledge that my first instinct can be defensive, and then take responsibility for the mistake instead, regardless of whether I feel that the change could have been communicated more clearly. In addition, asking better questions to confirm that my assumptions were correct in the first place has often saved me from getting to the point where I make the mistake at all. I’m yet to have a coworker become even a little annoyed at being asked questions that might seem obvious; they always seem relieved to hear that I understood what they were asking for.
Another common frustration I hear (and have certainly felt myself) is feeling micromanaged over the in-progress details of the work. It can definitely be frustrating to solicit feedback about something specific and have collaborators focus on other unfinished or non-functional parts of a project instead.
I believe that a solution to this unpleasant feeling actually has less to do with the outward interactions we have as developers, and more with the way we think about and empathize with the job reality of our designer coworkers. As trivial as it sounds, I think it is fundamental to understand that a majority of what designers make depends on the execution of the developers they work with.
If a designer hands the clearest, most brilliant wireframes to a developer who doesn’t pay enough attention to them, the end result is going to be something that no one is proud of. As developers, I think it can be difficult to appreciate that the work we do often goes directly into the hands of our end users, without anyone else getting the chance to muck with it. This, of course, means the bugs get tied back to us as well. But when we write great code, we almost always get to appreciate it working in the wild the way we intended.
Realizing that this isn’t always the case for other roles really helped change my perception. It would be a whole different level of uncertainty to hand your work to someone and not know whether they would faithfully translate it into code. At the end of the day, getting to see your great work out in the world is something everyone wants to feel, and I’ve found it helpful to understand that the designer I’m working with wants that same feeling of accomplishment and success. Where previously I had found myself feeling micromanaged, I now realize I had been completely misinterpreting the intentions and motivations of those I worked with. At Guild, we share the same goal of wanting to create the most effective and meaningful experience for our students. The least I can do is listen and make sure I’m doing my part to ensure we achieve that goal.
Another common interaction we face in our role is with coworkers who interface directly with users or customers. Guild is a little unique in that students are a majority of our users, which means that they represent the core of our business. As such, we have a wide variety of roles that focus on helping our students succeed throughout their educational journey, from signup all the way to graduation.
I believe one of the most common struggles when collaborating with student-facing teams is creating accurate schedules and estimations. I think we’re all familiar with the trope that developers are notoriously bad estimators — the idea that the estimates we provide should secretly be doubled for feature changes, and then tripled for testing, and quadrupled when the end product turns out completely different from what was asked for in the first place. I haven’t figured out how to do perfect estimation yet myself, so I’ll leave that for someone else’s article.
Instead, I’d love to consider estimation communication, or how to interact with your colleagues who depend on the timeline of your work in order to do theirs. For starters, I recommend letting them peek behind the curtain a little more. Instead of “this is gonna take four weeks,” go against your intuition a bit and be more specific: “this is going to take four weeks, but the first week will be exploratory work to find out if the third-party API we connect to is going to handle the load we’re expecting.” It may seem like oversharing, but giving your coworkers a sense of what you know and what’s in-flux will help them set expectations appropriately, for everyone’s sake.
I’d also encourage you to be more proactive around unexpected delays when they invariably come up. I think we could all do with a reminder to check with ourselves when we’re getting those uneasy deadline-slipping feelings. There are times when it doesn’t “just work” quite as much as you were sure it would; when even you don’t understand the code you wrote yesterday, and even the “happy” path isn’t very happy. While determination is one of many characteristics of a great developer, so are great communication skills. Taking the time to let those user-facing teams know things aren’t going as smoothly as I hoped gives them time to do better damage control, and it shows them that I respect and understand the work they do. One tip that has served me well is to set reminder check-ins for myself at regular intervals, even when things are on or ahead of schedule, to let stakeholders know what the status is. There’s a lot more that goes into being an effective estimation communicator, but these are some great mindset changes I have made to see improvement.
The goal of this blog post isn’t that you approach your profession every day in a completely new light. But I encourage you to spend a little time thinking about your relationships with cross-functional team members and how you empathize with their roles.
If I could leave you with a single suggestion to try out when collaborating with others, it would be to challenge yourself to shift your focus beyond your own motivations and pressures, and really try to imagine what they look and feel like for your non-developer colleagues. Putting in this effort has helped me take some cross-functional relationships from “challenging” or “fine” to not only rewarding, but necessary to my success in my role.
