Low-Maturity Software Teams: Understanding & Survival 🧗🏻‍♂️

Low-maturity team solving a problem in isolation

Hey Everyone 👋🏻

How’s it going? Abdullah here, a product designer with an engineering background. Currently treading the slippery slopes of product management. I am writing after some time. And It’s great to write about another learning.

Some time ago, I was curious to know more about UX maturity. The idea came from an interesting talk I took by Jonathan McFadden at Disco Conf. The talk was about how to be inflexible as a designer. And while it is an interesting take on “why” we need to be inflexible as a designer. And in what situation? Do we have to be one? Early on, I had a wrong understanding of the talk. But it was about what to do as a designer when faced with adversity. The key insight from the talk was that as a designer, we should always:

• Have a personal risk analysis.
• Be strategic and tactful.
• Accept what we cannot control.
• Disengage when necessary.

But as I dove more deeply into this, I got steered in the right direction by the one and only Jeremy Miller! the creator of the Beyond UX design podcast. It is one of the best out there. And that’s maybe my bias here. But Jeremy has been super helpful the past couple of months. His experiences have helped me build my understanding of a lot of stuff on design & beyond. If you already haven’t checked out his podcast. You’re missing a lot. Be sure to give it a look now. Shoutout to Jeremy here! Thanks for making the Beyond UX design podcast and being an awesome silent mentor.

So in one of the weekly LinkedIn threads. Jeremy pointed out that when decisions from above in an organization are not the right ones, it is about having low maturity. And being adaptable and flexible are two essential skills a designer can have. And it’s not about rolling over and building the wrong thing. But to build great software.

And to my surprise, he already had a podcast series. Where he talks about low-maturity teams. “From CHAOS to CLARITY” → sounds a bit too much right, but believe me the name does justice with the insights. While I was listening to it I was like oh, this is what’s happening, okay I have done this and it works, and many more Aha moments. If you want to learn more by yourself, take note of your “Aha moments” You can check out the series here.

Before we get into my learnings from the series and understanding the whole topic. I thought I’d break it down so that it’s easier to digest. And it’s for me. So when I reflect on it later, I can do so with ease. Hoping the breakdown helps you too. There were lots of things in there.

But I wanted to understand it from different perspectives. So I divided the findings and my thoughts into three parts, understanding it from:

→ A general understanding 👈🏻

→ A designer’s battle

→ A PM’s responsibilities

So let’s start with understanding what is low maturity. And to do that let’s understand another term first that I found the most appropriate. “Software Maturity”. I liked the term, and like you, I thought it had to do with software right? But it’s not with software with a context here it’s about the software maturity of teams.

We can say that the PM/UX/design/engineering team’s maturities are a subset of this big term. So let’s understand it.

Software maturity is how a team operates together as a whole. It’s how they collaborate, understand, and build software. As simple as that. So what’s the crack here?

Teams with low software maturity tend to be pretty dysfunctional. And the chance of growth is low in such a place. And most of the time we don’t know if we’re doing things right.

People in low software maturity teams:

• Have short-term vision
• Are super reactive
• Build silos
• Have few super-heroes

All these characteristics can lead to:

• Burnout
• Loss of interest in work
• Low growth

Now let’s pivot to “Operational Maturity” which is how things work. It relates to the software maturity. It includes:

• Day-to-day operations
• Team allocation
• Team leaders → PMs and Managers
• Team players → Designers, Engineering, Product

And why this was important? because in low software maturity teams, none of these things are present. The team’s functions as a whole are not defined. And that impacts how they work and reach their goals. In a low operational maturity team, there are no clear:

• Goals & Objectives
• Roadmaps
• Clear communication
• Strategic Vision
• Metric for success

And what happens is that when there are no clear goals and vision. There is chaos. Management says yes to all the stakeholder needs. And this leads to a dysfunctional product vision. This affects all the teams from designers to engineers. Believe me when I say it’s real chaos and it takes a lot of time and effort to make sense of things.

Contrary to this is high operational maturity, and while it’s not the focus here let’s talk about it. In an operational software team, we have realistic:

• Deadlines
• Milestones
• Research

A team like this operates like a well-oiled machine.

Understanding of the concept of software team’s maturity. We have discussed low maturity and connected that with a team’s operational maturity. Compared to what’s it like to be in a high operational team.

Let's discuss strategies for collaborating effectively with a software team that has a low level of maturity.

“Work with what we have”

It’s not our responsibility to change the whole company/org or a team. Especially if we’re at a junior level. And even as seniors we can’t have that big of an impact. In a small company, we can change things with time but in a larger org, it’s not possible.

So what to do? Work with the team you have and see how you can improve things together.

To quote the BUX creator here “And while it may sound odd, it’s quite alright to get the hell out of there. If you can afford to quit then quit. Don’t ruin your mental health trying to make an impossible situation.” For all the suckers like me, emphasis on if you can, don’t quit. In today’s world, everybody has some sort of responsibility. Some have more than one. So think it through. And this I think could be another story → Extent of planning ahead, for life, a job, or anything. Going to write about it soon.

Coming back to how to work well in a low-maturity software team. We have to understand that everybody wants to do great work. Understand your team, and who you work well with and start from there. Foster relationships and build trust. See how you can help each other out. Doing this can inspire other teammates around you to do the same. This can help bring a change in the way things should be. And like everything, nothing is a sure shot. There still be people that are going to be a pain for you.

Communication plays a critical role here, as it does everywhere. But in a low-maturity team if the communication is clear and done. We can salvage a lot. If something is missing we should not wait for others to tell us. We have to put in the effort and connect the dots. Why is this important? because low maturity does not mean that the team can’t operate well it’s that they do not know how to. But with good communication, we can work on the “how” together and find a system that works.

Plugging in one of the key resonating points from the series. The concept of Practice followership. It’s the idea, that we do not follow everybody but a particular leader. That tries to take initiative, support, and raise concerns when needed. And this way we emulate a behavior that can be good for us and help people around us. If you’re interested, the idea is from Dr. David Lightner, you can check him out on LinkedIn.

Asking the right way. Is also one way that helps to navigate in a low-maturity team. But the trick here is to expect things, and not ask. Phrase it in a way that you expect that. What happens here is that it brings clarity that to go from A to C, we need to have B. Talking about it in a way that makes it normal is the right way to ask.

And a very obvious one, showing more is always better than telling more. When we have tangible things to present, we have better conversations. They lead to insights based on actual work rather than talking in the air on the fly.

Even with all this understanding. And ways to work in a low-maturity software team. Things might only sometimes go your way. So we have to remember that it’s a long game and change takes time. We can try to do our best and work with what we have. And most importantly build “great relationships to build great software”.

I hope you liked the story and my learning. If it was helpful, I’d appreciate you share it with others who can learn from it. Thanks for reading till the end. 🙇🏻‍♂️

More learnings are on their way! 🚀

Want to level up your design knowledge?

Some resources for you to peak at. They will surely help you out in your UX journey. They focus on more than just design:

• https://www.beyonduxdesign.com/
• https://www.dive.club/
• https://danmall.com/

Creating your first design portfolio?

You can use Framer to do that, it can be a great choice:

• It’s easy to set up and start with.
• Is very similar to Figma, so there is a minimal learning curve.
• And there are a ton of free templates & resources to get you started.

I made my portfolio on Framer. You can check it out here.

If you’re ready, use my link to get started. It’s a referral link. So if you use that. I might make some quick bucks. No extra charges from you. And if you use the promo code: partner25proyearly for the yearly subscription. You get 3 free months on the Pro annual subscription.