Recently, we launched a new frontend for a client. The build went live, everything looked fine on the surface, but someone on our team spotted an unusual technical issue. It wasn’t obvious. You had to look into the data to see it. What stood out most wasn’t the bug. It was that no one had taken ownership of it. The person doing most of the work on that project hadn’t picked it up. And when we asked why, it turned out he didn’t even know he was expected to. He thought he was just a developer. The rest of us had been treating him like the technical lead.
That moment sparked a much-needed internal shift. It forced us to confront a blind spot in how we assign responsibility. And it’s been one of the most important cultural improvements we’ve made in a long time.
It was nobody’s fault, really. The project ran smoothly, communication was decent, and the issue didn’t affect the client directly. But it revealed something critical. We had never made responsibilities explicit.
Because this person handled most of the implementation, we assumed he saw himself as the technical lead. But we’d never said it out loud. There was no clear role assignment. No shared understanding of ownership.
And in a growing team, that’s a dangerous way to work.
Our first instinct was to create checklists. Maybe we just needed a framework to make sure every box got ticked.
But the more we talked, the more we realised that checklists can become a crutch. They encourage compliance but not ownership. People start doing tasks just to complete them, without stepping back to think critically or ask better questions.
What we needed wasn’t process. It was clarity. And confidence.
We wanted people to understand their role fully. To feel empowered to take responsibility. To speak up if something looked wrong, even if it wasn’t written down on a list.
We made a deliberate decision. From now on, every project would have a clearly assigned technical lead. And that person would understand what the role involves.
You are in charge of quality. You are responsible for the technical health of the project. And that means you get to make decisions, not just execute tasks.
It also means you have the right to push back. If a client asks for something unreasonable, like a 120 megabyte animated splash screen, your job is to say, “That’s not a good idea, and here’s why.”
You still execute the client's vision, but not without input. Your job is to care. To guide. To protect the long-term quality of the work
In our internal meetings, we talked a lot about the word "no." Not everyone liked it. Some people found it too harsh. But I wasn’t trying to teach the team how to reject clients. I was trying to show them that they have permission to challenge ideas, and a responsibility to speak up when something feels wrong.
That can sound simple, but it isn’t.
One of our developers came to me after the meeting with a scheduling conflict. He was torn between two overlapping project demands. So I asked him, “After everything we just discussed, what do you think you should do?”
I could see he wasn’t fully confident yet. He understood the logic, but he wasn’t used to stepping into that leadership role. So I told him, “This is the chair. You can sit in it now. You’ve earned that responsibility.”
We also realised that we needed to shift how we see our team members. Not as resources. As people.
It sounds obvious, but in a fast-paced technical agency, it’s easy to lose sight of this. People get reduced to their role, their ticket queue, their velocity. But behind the keyboard is a human being, with thoughts, frustrations, and ideas.
Just because a decision makes sense on paper doesn’t mean everyone understands it the same way. Good leadership means explaining the why, not just assigning the what.
You have to bring people along with you. And for that, emotional intelligence is essential.
Alongside assigning technical leads, we also made it clear that every lead has a strategic partner. Someone who deals with client communication at a higher level, who can help remove roadblocks and bring perspective.
That layer of support makes a big difference. It reassures the technical lead that they are not alone. It gives them a point of contact when the task list feels overwhelming. And it helps protect the balance between technical integrity and client demands.
Since making these changes, we’re seeing big improvements.
Team members are more aware of what’s happening in their projects. Communication has improved. And there’s a noticeable lift in confidence.
People understand that it’s not just okay to speak up. It’s expected. And they know they have backup if they need help navigating that conversation.
Even more importantly, our project quality is improving. There’s more proactive planning. More accountability. Fewer avoidable issues slipping through the cracks.
For clients, this cultural shift means better outcomes. Their projects are managed with more care and technical insight. Potential issues are spotted earlier. Solutions are challenged and refined before they become problems.
It also creates stronger relationships. When our team feels confident, our communication with clients becomes more open, transparent, and strategic.
This kind of trust builds better software.
Make things explicit. Never assume someone knows what their role is if you haven’t told them.
Expectation management is one of the most underrated skills in a company. Especially in smaller teams, where job titles blur and people wear multiple hats, it’s easy to assume everyone knows what’s expected. But they don’t.
Clarity creates confidence. And confidence creates better work.
You don’t need massive task lists or rigid checkboxes. You need defined responsibilities, emotional intelligence, and a company culture that encourages people to speak up.
We’ve missed this in the past. But now, we’re fixing it. And it’s already paying off, for our people and for our clients.
Image from John Lockwood on Unsplash
Strong teams don’t run on assumptions. Tell me how your team assigns ownership — or let’s sharpen your technical roles so problems get solved before they escalate.
03.06.25
