Team turnaround
The team behind the field technician app: how design, dev and ops at a Fortune 100 US telecom provider went from contested handoffs to one delivery team.
From separate groups to one delivery team, in four steps
- Me
- Design
- Dev & architects
- Ops
- Product & execs
- Project role
- Design lead on the engagement
- Team
- a team of 8 client UX professionals, including 2 UX directors
- Timeline
- Client
- a Fortune 100 US telecom provider
- Outcome
- Engagement extended by about 6 months
My part in this
- Decision I influenced
- How product leaders and executives set the program’s strategy, through conversations, demos and presentations.
- What I pushed back on
- Ops managers who opposed our early decisions. I answered with technicians’ own words from testing instead of arguments.
- Trade-off I made
- Bringing developers and architects into design sessions made early work slower, and saved that time many times over in handoffs.
- What I noticed
- The friction wasn’t about people. Teams were handed decisions instead of being part of them.
- What changed because I was there
- The team turned around within 3 months, sprints hit their targets, and the client extended the engagement by about 6 months.
The problem
Design, dev and ops worked against each other. Handoffs were contested, work came back for rework, and trust between the teams was low. Ops managers were strongly against the decisions we made early on. As design lead for a team of 8 client UX professionals, including 2 UX directors, I couldn’t fix it by authority alone. It had to change how the teams worked together.
What I did
Key insight The friction wasn’t about people. It was about process: teams were handed decisions instead of being part of them, and old ways of working went unquestioned.
- 01
Developers in the room
I brought developers into design sessions, instead of handing finished work over to them. Architects and designers worked out feasible approaches together, before anything was final.
Trade-off: More voices made early sessions slower. That time came back many times over in handoffs nobody had to fight about.
- 02
Turning critics into partners
Instead of defending our decisions to the ops managers who opposed them, I invited them into the conversation and showed them what technicians said before and after usability testing. Hearing frustrated techs get excited about the new tools did more than any presentation could.
Trade-off: Opening unfinished work to its strongest critics risked more pushback. Leading with evidence instead of arguments earned their trust, and it held for the rest of development.
- 03
Question the process, then make the fix simple
I keep asking why things are done the way they are. When I challenged how equipment inventory was tracked, the answer was a simple fix: one digital system, with technicians scanning barcodes using their phone cameras so inventory problems are caught the moment they happen.
Trade-off: Questioning established processes creates tension with leadership. It’s also how we found the systemic issues that had been quietly holding the program back.
Results
- Less rework, on-target sprints. With research, architecture and dev feasibility in the room from the start, design time stopped going to work that couldn’t ship. On 3–4 week sprints, we regularly hit our targets without revisiting the work.
- Designers grew in skill and scope. I taught the designers to work closely with architects and developers: when to compromise, and when to defend a design against pushback.
- Ops on board. Ops teams saw firsthand how technicians who had been frustrated with their tools spoke excitedly about the new features.
- Leadership aligned. Through conversations, demos and presentations, I helped product leaders and executives set the strategy rather than fight over it. User testimonials and executive buy-in proved the value, and the client extended the engagement by about 6 months.
What I’d do differently
I’d look for the trust issues sooner. I didn’t know design, dev and ops had bad blood until I was in the middle of it, and it took time before people trusted me enough to say why.
I’d also start earlier on teaching the client’s designers to work beyond their own team. Their group was close-knit but siloed, which pushed it away from dev and ops. I still see that pattern on other projects: teams work best when everyone sees each other as peers, with strengths and weaknesses, not as separate camps.