It should be no secret that software engineering in the professional workplace is done in teams. And when you’re working in teams, that means collaboration. It’s not rocket science, right? But unfortunately, when stress is high and we all have looming deadlines and deliverables, it’s easy to falter in collaboration. This is especially true when it comes to individuals or teams fielding answers from others. In this article, I’ll explain what this looks like and why it’s detrimental to not only a healthy engineering organization… but to your career. So if you don’t care about everyone else around you, at least care about your career. Problem-Solving + Collaboration = Software Engineering As was already mentioned, software engineering is heavily reliant on collaboration. And what are we collaborating on? Generally, these will be technical problems that require solutions based on software. And that means that you’re building software solutions together. But what kinds of problem-solving are typical within engineering organizations? Which problems to solve – Often handled by collaboration with Product-based roles. How to solve problems – Generally when engineers are working together (same team or cross-team) The priorities of which things to work on – Working with Product, Project, and Engineering Management roles Fixing live-site issues and technical support requests – Collaboration with other engineers, service engineers, and potentially Tech Support or Sales roles. … What else comes to mind? But the reality is if each team is doing this sort of problem-solving, it means that when some questions or opportunities span teams, we have another intersection to introduce into all of this. How To Kill Collaboration When Problem-Solving Problem-solving in software engineering is often like pulling on a piece of thread. We start breaking down complex problems into smaller ones and then realize we have more and more to unwind. Another metaphor we could slap onto this is like following a trail of breadcrumbs, which feels more analogous to when we’re debugging. But the common theme here is that we need to continue taking steps to move forward. And the number one thing that stops someone from taking steps forward is when you put up a wall. People aren’t great at walking through walls — nor is it convenient to climb them. What Killing the Breadcrumb Trail Looks Like So what does it look like to kill things off? I’ve explained this in the following video: https://www.youtube.com/watch?v=lB4qjyRYOzk&embedable=true These are factors that can stop progress in their tracks or otherwise make it difficult for someone to move forward: Saying no to an idea or proposed path forward without explanation or follow-up “That won’t work” “We’ve tried it before” “That’s not right” Not taking the time to understand what someone is trying to accomplish Not providing an alternative solution if you disagree Not providing an alternate person/team/resource if you are not the right person to field it And the sad part is that these are all things you can improve with very little effort. Being Stuck Sucks – Here’s How You Can Help Nobody wants to be on the receiving end of those situations. You feel helpless because you’re trying to solve a problem and you’re met with a wall. But now that you know what that can look like, how can we make it better: If you disagree with the proposal, take some time to ask and genuinely understand. Especially when through written communication, there are so many opportunities to miss context and valuable data points. Explain why you disagree or why something isn’t correct. Providing this context might be new information to the person you’re talking to. Provide alternatives. I watch people shut down ideas ALL of the time and leave it there. And they’re smart people — they likely have one or two alternatives they could suggest. Give the additional breadcrumbs out! Help redirect without deflecting! Take the time to understand the challenge and see if you can redirect the person accordingly with more context than when they showed up to you. None of these involve an incredible amount of effort. Your Career Depends On It I’ll leave you with this parting thought… As you become more senior in your software engineering role, some things are almost guaranteed: You’ll be working on more important areas You’ll be working on broader areas of impact You’ll be working with more people As soon as you get in the habit of blocking forward progress, your NEGATIVE impact is multiplied across all of these. That’s right. Instead of being a multiplier within your engineering organization, you’re now putting up barriers across all of these things which have a higher impact across the board. It’s not only a missed opportunity for a great positive impact, but it’s a net negative to the organization. Do yourself and your software engineering colleagues a favor: Prioritize collaboration. If you’re interested in more learning opportunities, and ! subscribe to my free weekly newsletter check out my YouTube channel Also published here.

How to Create Custom Middleware in ASP.NET Core

Memento Pattern in C# - Undo & Redo

Newsletter

Collaboration Killers in Software Engineering

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

3 Beginner Tips You Need to Know for async await in C#

What No One Told Me About Being a Product Manager at an Early Stage Startup

10x10: Ten Life Lessons from a Developer After Ten Years in the Industry

10 Things Every New Developer Should Know

10 Steps for Landing a Job at a Startup

10 Skills You Need For Your Post-Pandemic Career

3 Beginner Tips You Need to Know for async await in C#

What No One Told Me About Being a Product Manager at an Early Stage Startup

10x10: Ten Life Lessons from a Developer After Ten Years in the Industry

10 Things Every New Developer Should Know

10 Steps for Landing a Job at a Startup

10 Skills You Need For Your Post-Pandemic Career

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps