The post You’re Killing Collaboration (And How To Fix It) appeared first on Dev Leader.
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 surgery, right?
But unfortunately, when stress is high and we all have looming deadlines and deliverables, it’s easy to cut short the 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? The easiest way to explain this is by watching me talk about it in this video:
These are factors 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, subscribe to my free weekly newsletter and check out my YouTube channel!
Want More Dev Leader Content?
- Follow along on this platform if you haven’t already!
- Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos: SUBSCRIBE FOR FREE
- Looking for courses? Check out my offerings: VIEW COURSES
- E-Books & other resources: VIEW RESOURCES
- Watch hundreds of full-length videos on my YouTube channel: VISIT CHANNEL
- Visit my website for hundreds of articles on various software engineering topics (including code snippets): VISIT WEBSITE
- Check out the repository with many code examples from my articles and videos on GitHub: VIEW REPOSITORY
Top comments (0)