This week
The theme of these week notes so far has been waiting. My first couple of weeks in my new role have been all about getting my feet on the ground and figuring out how this company works, and where I fit in. The reality of that has been fewer client-facing tasks and more internal work to get acclimated. For the first time in my career, I am a smaller cog in a much bigger machine. I think the largest workplace I’d been in prior to this role was ~70 people, most of whom were based in Newcastle. Now I’m one of 4000+ people, with the Newcastle office being a much smaller component in a fully global machine.
There’s very little I can control about being between projects, or “on the bench”. There are commercial factors at play in levels far above mine, so it’s a waiting game. Personally, I place a lot of my value on being busy. Not busy for busy’s sake, but in the sense of earning my keep and adding value. If you end up on the Instagram and TikTok side of grind and hustle culture, it can be really easy to fall into the not-enough trap: “If I’m not actively working on a client project, I’m not adding value”. Reminding myself that quiet periods do not equal unproductive has been a tough pill to swallow. This quieter period has been a fantastic opportunity for getting hands-on with the kind of work a “Design Engineer” role would involve. For the first time I’m digging into code and APIs, and building working concepts for problems that even a few months ago I could only have dreamt of…
One thought
In my experience, the difference between artists and designers is that designers tend to be problem solvers. I found myself saying this when I was interviewing for jobs: I’m a problem solver. I just tend to use design as my medium to solve the problems, but not always.
A few years ago, I had a non-profit client who had won some funding to do a discovery with a design agency to solve a problem. As per the brief, we uncovered the problem and came up with a custom solution that would cost multiple hundreds of thousands of pounds to design and build. The actual outcome we ended up implementing with them was to give some of our time pro bono and set them up a Trello Kanban board. At the end of that day (and in a pre-AI-enabled workflow era), a gigantic custom product was the furthest thing this client needed. They needed a way to collaborate with team members and track progress for their clients. The off-the-shelf solution solved 80% of this with little setup. The final 20% was awkwardly covered by making sure they made use of the inbuilt comments feature.
With the kind of emerging roles we’re seeing across the industry in 2026, such as design engineers and forward deployed developers, a custom solution for that client that solved 99.9% of their problems could be done at a fraction of the cost.
And that’s the exciting bit for me: previous solutions were inaccessible to me. I could come up with the idea, but I still needed a developer pal to make it a reality. Now I can hook up Google APIs and spin up a working solution for a personal problem, or a proof of concept for a bigger problem. A prime example of this was a custom job tracking web app I built when job searching.
I was losing emails from recruiters, losing track of auto rejections and missing potential opportunities. I built a small application that scanned my Gmail for job search related emails and tracked them against a Kanban board. It kept note of the initial job spec, salary, date applied. And ultimately meant I could manage all my applications in one place. Building these little custom solutions for small problems has been a game changer in understanding collaboration with AI and with developers.