UI Lead Developer

Why I joined

Sky was a company I’d wanted to work for for a while. I’d talked about its engineering culture for years and met different teams there, and the role on offer was a clear step up: not the TV side I knew from Accedo, but the network side, as a React lead. I’d be leading the front end of a platform that brought many microservices together for engineers, with exposure to lots of teams and real involvement in back-end work.

That lined up with the career plan I’d written at Accedo: more breadth, more full-stack experience, and a senior role where I could drive change rather than just deliver tickets. Like each of my moves, it was more responsibility with a title to match.

The role

I was UI Lead Developer on a low-code network automation platform used by multiple Sky teams and external business partners. Engineers designed automation workflows as diagrams, ran them, and tracked each run to completion.

The job was broad. I set the front-end architecture, roadmapped UI work, directed and mentored UI developers, and worked closely with network engineers, business analysts and product managers. I also crossed into the back end: OpenAPI contracts with back-end teams, Python endpoints, API gateway configuration and security scanning in merge pipelines. Later I chaired UI/UX across the wider Telecoms Management department.

What I built and led

• The workflow platform itself. Model-driven editing on top of BPMN, server-side permissions, JSON Schema forms and a catalogue of reusable building blocks, so a new automation became mostly configuration (Building a Low-Code BPMN Workflow Platform).
• A network-graph component library to replace a commercial one: benchmarked first, headless and compound by design, with Storybook as the contract (Building a Graph Component Library).
• A testing strategy teams actually adopted: network-level mocks instead of brittle ones, features shipped test-first, faster lint, coverage in every merge request, and Playwright adopted across departments (A Testing Strategy Teams Actually Adopted).
• TypeScript errors to zero, through months of small merge requests, then type checks enforced in the build (Driving a TypeScript Codebase to Zero Errors).
• An API gateway in front of the platform’s services, with versioned routes and one owner per cross-cutting concern (Rolling Out an API Gateway).
• A cross-team UI guild, after making the case in writing that UI engineers scattered across backend-shaped teams were under-used and invisible (Chairing a Cross-Team UI Guild).

Results

At CV level: the platform let the team offer its network automation tooling as a service to other teams and partners, and cut the technical resources needed for routine work. Playwright was adopted for end-to-end testing across departments. The graph library’s first phase was delivered by its deadline and gave clients clearer insight into their networks. The codebase ended up with enforced type checks, much stronger test coverage and a single, secured API surface.

Before I left, I automated a lot of the team’s tooling, so routine work no longer depended on anyone remembering the steps:

• CI and merge-request checks: faster linting, test-coverage indicators shown on every merge request, and branch protection rules, so quality gates ran on every change rather than relying on review alone.
• Secret scanning: a scanner to catch leaked credentials before they reached the repository, after a clean-up of an old repo’s history (Removing Secrets from Git History).
• Automated end-to-end testing: Playwright suites that ran in the pipeline (Playwright).
• Reusable workflow building blocks: the low-code platform itself, where common network-automation steps became configurable blocks rather than one-off scripts (Building a Low-Code BPMN Workflow Platform).

What I learned

• Let the domain library own the domain state. Fighting a mature modelling library with your own store is a losing battle.
• Security belongs on the server from day one. The UI can only reflect permissions, never enforce them.
• Influence without authority. The guild happened because I wrote the problem down clearly, not because I had the power to reorganise anyone.
• Platform thinking. Templates, building blocks and self-service were the parts that scaled. Reading Platform Strategy later gave me words for what had worked.

Why I moved on

My time at Sky ended with an unfortunate redundancy. The team’s responsibilities were moving to a new team in Chennai.

I wanted to leave the platform in the best shape I could. I ran structured knowledge-transfer sessions, each backed by written documentation, and helped train the people stepping into the roles in the new team, so they could own the platform confidently from day one (Knowledge Transfer Before Moving On). Alongside that I finished automating the tooling the team relied on and left a reuse strategy and a clean backlog behind.

Looking for what came next, I wanted another step up: faster-paced work, people who’d stretch me, and the kind of place where you can own a lot. That led me to a fintech building real-time crypto trading UIs.