Effective Software Teams: Islands and Autonomy - Dev Leader Weekly 76

TL; DR:

• Every team will be different!
• Autonomy is a driving force for effectiveness!
• Join the live stream on Monday, December 30th at 7:00 PM Pacific!

I owe my ability to post content across social media to BrandGhost . If you're interested in content creation, you can get started today 100% for FREE.

Effective Software Teams: Islands and Autonomy

It's Story Time!

I've been fortunate enough to manage engineering teams for roughly 12 years or so now. I've spent roughly 8 of those years as a startup being a technical manager not only leading the team but acting as an individual contributor in the team, and 4.5 years leading teams in Big Tech.

Being in early at a startup without strong software engineering leadership meant that we had to figure stuff out on our own. And I mean like... all of it. But we had an amazing founder/CTO and CEO who both gave us a lot of autonomy. They trusted us to get things done, and we did.

But it wasn't always easy (read: it was never easy) and we weren't always right (read: we were mostly wrong). But we constantly reflected on what was and wasn't working and the organization continued to evolve to drive towards improvements.

In the beginning, there wasn't a lot of variation across teams. We were just trying to get our footing. Over time, we'd come to learn that software engineering teams aren't one-size-fits-all.

We'd also learn that there were some common things that worked well and didn't work well for many teams.

Every Team Is Different

As with everything in software engineering, when we're trying to figure out the best path forward we can answer with this: "It depends".

And that's because we always have a scenario with some context to think through. We have to consider the pros and cons. We have to understand what we're optimizing for and what we're trading off as a result.

When it comes to engineering teams, there will always be variance:

• The product or service being created
• The maturity / lifecycle of that product or service
• The users of that product or service
• The release cadence
• The number of people on the team
• The experience of the people on the team
• How long that team has been working together
• The roles on the team
• ...

I could go on (almost) forever, but I think you get the point. We have many factors to consider when optimizing for team effectiveness. That means that as I walk through some of these scenarios that didn't work so well, my goal is not to suggest to you that they cannot work. Instead, I'm just sharing my experience so that you have some things to consider when you're reflecting on your current (or future) scenario.

And with that, let's jump into some things that didn't work so well!

Islands

In my experience, I've found that creating islands in software engineering teams is not ideal. In this context, when I refer to "islands" I am referring to putting a group of roles together but isolated from a product / service team.

Examples of this include:

• Dedicated team of testers
• Grouping all of the product managers into a team
• Making teams of project managers
• Putting all of the documentation writers on one team

From my experience, we often think of doing this because we're aligning functional areas. If we group the testers together, then they can focus on testing together. If we put the project managers together, they can focus on coordinating. Documentation writers? They can crank out all the technical docs together.

If you'd like to hear about my experience with this and QA / testing roles, you can hear more about it in this Code Commute vlog:

Despite the good intentions of grouping roles like this together, I think there are two negative consequences:

• We start to create silos between the core team and one of the individuals with a role that's on the "island" (or "satellite" team).
• We create opportunity for priority gaps between the core team and the individual with the role on the "island".

With respect to silos, I lived through examples where development teams would toss features and bug fixes over the metaphorical wall to the QA team. Could we have done a better job communicating and collaborating? You bet. But the separated organization of teams really enabled us to... ignore that. It made it easy to "finish" coding something, add it to the testing team's backlog, and then move onto something else. We essentially tried to optimize the work of two different roles and created huge inefficiencies by siloing this way.

With respect to priority gaps, I've experienced the roles on the "island" teams having different priorities than the core development teams for the products & services. The side effect is that the core development teams either:

1. move in a direction that's not aligned with the other roles
2. or they feel blocked/inhibited by the other roles

If the documentation writers are focused on creating and organizing documentation in a particular way but not closely collaborating with the product teams, things get misaligned. If the testers are focused on a new testing infrastructure but not working closely within the product teams, things get misaligned. If the UI designers are coming up with the perfect UX but not working alongside the product teams, things get misaligned.

This type of problem can come up though even without an entire "island" team of a particular role. Sometimes it can happen with just ONE person.

Single Points of Failure

Let's talk about single points of failure next, and we'll start by clearing up what I hope is a misconception these days: Becoming a single point of failure should not be what you consider as "job security". This is a career death sentence.

Single points of failure can make entire teams grind to a halt. This can happen not only with some of these "island" teams that I discussed, but even with individuals on the team. Let's walk through a couple of examples:

1. I've worked where the software architects weren't embedded in the teams. Instead, they operated in more of an ivory tower mode. But this means they were responsible for the architecture of features or the code bases of other teams even though they weren't on those teams directly. How effective do you think that felt for the architect? How effective do you think that felt for the team that had to wait for the architect to tell them the direction of their code base?
2. What about situations where the one senior person on the team needs to sign off on all the pull requests? I'm sure many people reading this have been in this kind of situation. What happens when that one person is busy with other things and they can't keep up with the PRs? They're now gating any and all work from making progress.
3. Or my (least) favorite example: The Intelligent @sshole. This person is actually very smart and very capable -- but they have a tendency to steamroll conversations and decisions. Their way is the only way. They end up interjecting themselves into everything and as a result, they become a bottleneck for anything getting done. It's extra crappy because they are very difficult to work with and often the only way is their way.

When we're thinking about trying to make teams more effective, we want to reduce barriers and blockers as much as possible. We want to improve collaboration. We want to improve communication. But we need to make sure things can keep moving as much as possible.

Some homework for you is to think about whether your team has a single point of failure on it. That could be the one senior that needs to sign off on everything. That could be that you have one documentation writer who gates all of your releases on whether or not they get documentation done on time. That could be your product owner, manager, or even YOU. What could you do to try and ensure there's not just ONE point of failure?

Autonomy

All of these things we've discussed lead us to autonomy. And while autonomy isn't the ONLY thing that makes teams effective, it's the one I wanted to touch on for this article.

When I reflect on the most effective times in my career, autonomy was at the center of it. This also meant that I was given a lot of trust and respect, but these things enabled autonomy. Things that stand out to me include:

• My most effective days writing and shipping code meant I had autonomy to design and implement the feature. I didn't do it in isolation, but I didn't have someone dictating what I needed to do every step of the way.
• The most effective teams I've led were given autonomy. I worked with the product owner to ensure the business goals were clear, we knew which features to focus on, and developers were given autonomy to get things done. They didn't ignore their team or other stakeholders. They were empowered to make effective decisions and supported when doing so.
• The most effective I have felt as an engineering manager is when my manager and/or leaders trust in me and give me autonomy. They don't micromanage me or question everything I do. They make the vision clear, elaborate on business goals, and allow me to focus on how I enable the team to do their best work.

I've hinted at this, but autonomy isn't just something that comes for free. There's an inherent requirement of trust that goes along with it, because we need to be able to trust an individual to carry out their responsibilities. On the flip side, individuals need to have an environment that promotes psychological safety so that they know that if they fail, they will be given the opportunity to learn and grow from it.

I have found that when we focus on the inputs that enable individuals to have autonomy and teams to act as autonomous units, we get incredibly effective teams. Individuals feel empowered to do good work -- they're engaged and they're excited because they get decision-making power. Teams do good work because teams with more autonomy have fewer blocking dependencies -- and that might mean taking some of those other roles on island teams and bringing them directly into the team!

We reduce the single points of failure by bringing roles that are responsible for the product or service area all into one spot. That becomes the team. That team can tackle their challenges together.

• Join me and other software engineers in the private Discord community!
• All of my weekly vlogs are on YouTube!!
• My Code Commute vlogs are on YouTube!!
• Remember to check out my courses, including this awesome discounted bundle for C# developers:

Weekly Recap

WRONG Software Engineers Are Throwing Me Under The Bus!

Have you been in a situation where you're in a meeting and someone tries to belittle you or throw you under the bus? How much worse is it when they're factually incorrect?

This Software Engineer SUCKS With Customers (Or Do They?)

A Redditor reports that their manager had to give them negative feedback from a client regarding their attitude... How should software developers approach this?

SHUT UP And Take The Money! - Principal Software Engineering Manager AMA

They say the grass isn't always greener on the other side... But is it true? How can we tell?

When it comes to making team, organization, or role changes as software engineers, we have a lot of things to consider!

In this stream we'll look at:

- Team dynamics

- Career and technical growth

- Comfort, complacency, and permanency

- ... and of course, MONEY

As with all livestreams, I'm looking forward to answering YOUR questions! So join me live and ask in the chat, or you can comment now and I can try to get it answered while I stream.

HELP! My Technical Writing SUCKS As A Software Developer

Technical writing (if it isn't already) will be a part of your software engineering career. I can guarantee it! So... How can we do it effectively?

Users DO NOT CARE About Clean Code! (But Maybe You Should)

Find me a user who's decided to use a product based on clean code, and I'd love to interview you on my main channel! Until then, it remains something software developers care about -- and probably for good reasons!

Communication Is FAILING Your Development Team

Inspired by a topic from Reddit, this video is about a reflection on software engineering teams and where communication can be improved. These are reflections from my own experience -- enjoy!

As always, thanks so much for your support! I hope you enjoyed this issue, and I'll see you next week.

Nick “Dev Leader” Cosentino

[email protected]

Socials:

– Blog

– Dev Leader YouTube

– Follow on LinkedIn

– Dev Leader Instagram

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!