A Day at Made Tech: What It’s Really Like

A typical day at Made Tech starts with a calm but focused atmosphere. I’d arrive, settle in, and check my tasks for the day. The team always made space for me, and even though I was a student, I felt like a real contributor. Mornings often began with stand‑ups — short meetings where everyone shared what they were working on. This was one of the first surprises for me: how much communication matters in tech. It’s not just coding in silence; it’s constant collaboration.

After stand‑up, I’d dive into my tasks. Some days I was writing Python code for the login system. Other days I was testing endpoints, fixing bugs, or improving the database. I learned quickly that real‑world coding is less about writing perfect code the first time and more about iterating, testing, and refining. The team encouraged me to ask questions, and every answer helped me understand not just what to do, but why it mattered.

One of the most surprising things I learned was how much consultants think about users. Even when building something simple, the question was always: “How will this help the user?” That mindset changed how I approached my work. Instead of just making features function, I started thinking about clarity, security, and long‑term maintainability. Lunch breaks were relaxed and social — a chance to talk about tech, career paths, or even completely unrelated topics. These conversations helped me understand the culture of tech teams: supportive, curious, and always learning.

Afternoons were usually focused work time. I’d continue building features, updating documentation, or reviewing feedback. I learned how to manage my time, how to stay organised, and how to keep track of tasks using tools like GitHub. Seeing my code pushed to a real repository was a moment of pride — it made everything feel real.By the end of the day, I’d reflect on what I learned. Every day brought something new: a concept, a tool, a technique, or a piece of advice. That constant learning is what makes tech exciting.

🎓 Advice for Future T‑Level Students

If I could give one piece of advice, it would be this: don’t be afraid to ask questions. Tech is a team sport, and learning from others is part of the job. Be curious, be open, and take every opportunity to try something new. Your placement is not just about completing tasks — it’s about discovering how you work, how you learn, and how you fit into the world of digital consultancy.

The post A day in the life of a T-level student – Goodluck appeared first on Made Tech.

What does a typical morning look like? 

As a student, it’s important to gain a variety of skills during your college years to help prepare for adulthood. Being part of the Made Tech team has allowed me to experience so much and every working day is different, where I am consistently learning something new. Starting a work placement as a student can feel both exciting and nerve-wracking, but each day brings new opportunities to learn and grow. 

I typically start my day at 9:30am, whether I am working online or in person. I begin by checking my emails and Slack for any updates, which helps me stay organised and prepared for the day ahead. We usually start our morning with a catch-up session, where we talk about what we’ve done over the week. At the end of each week, we complete a journal and an evaluation reflecting on the skills we develop.

What was the most surprising thing you learned about working in tech? 

One of the most surprising things I learned about tech is how much teamwork is involved. Teamwork and collaboration are essential to share ideas, fix problems and meet deadlines. 

What advice would you give to the next group of students?  

For the next group of students, I would advise them to be confident and ask questions. At first, it can feel intimidating being in a professional environment; however, everyone understands that you’re here to learn. At MadeTech, one of the key values is continuous learning, whether it is a personal skill or a technical one. I would also advise staying organised and managing your time well. At first, it may feel overwhelming balancing work, college, and personal life, but remember you can always speak to your manager and teachers for support. 

Overall, my experience here has been extremely valuable. I have developed many personal and technical skills through programming projects such as the NASA Space Apps Challenge, which gave me a better understanding of how collaboration works in a real programming environment. The skills I’ve developed through those projects have helped me perform better in my end-of-year exam and will continue to support me in my future career.

The post A day in the life of a T-level student – Laura appeared first on Made Tech.

What does a typical morning look like? 

There is never really a typical morning for us, each week there’s a new exciting project, whether it’s with the DfE, coding alongside apprentices or even writing blogs like this one! But even with the change in tasks, most mornings start with a quick meeting with our supervisor, Dom.  Before we jump straight into work, we usually play a short game together to get settled and make the rest of the day feel a bit lighter. It’s a nice way to ease into the work. 

After the game, we have a catch-up session on what we did the previous week and what awaits us in the following week. It is also recommended to take lots of breaks throughout the day. I then spend some time writing in my journal. This is where we reflect on what we did that week, what we learned, what we want to learn next, and any worries or concerns we may have. This helps me keep track of my progress and reflect on it as part of my development. 

What was the most surprising thing you learned about working in tech? 

The most surprising thing for me was how collaborative everything is, not just sitting at a chair doing independent work that drains the life out of you, but instead, I find myself constantly pairing up on code and discussing ideas. This opened my eyes to how much I misunderstood what tech is; it isn’t just about writing a bunch of code, it’s communicating with others and solving problems together. 

Whilst working on my project of designing and building a simple assessment system for teachers, I realised I wasn’t just learning HTML, CSS, Flask or SQL, I was learning what it’s really like in a junior product designer’s shoes. I was able to pick up on what the user wants/needs to ensure a smoother user experience for a non-technical audience.  

What advice would you give to the next group of students? 

My advice is to find a routine that works best for you. Both college work and  your responsibilities tend to pile up quickly, making you feel overwhelmed.  If you can’t manage your time well, then try different ways to see what fits you. And honestly, if u end up doing things last minute (not recommended,  but we’ve all been there), make sure you still try your best.

The post A day in the life of a T-level student – Taybah appeared first on Made Tech.

Recently, I found myself in an unfamiliar position. I’d done thorough research, validated the findings, and used AI appropriately to synthesise a large volume of data. And yet, when I presented the work, it didn’t land in the way I expected.

The issue wasn’t the quality of the insights. It was the story I told with them, and how subtly that story had been shaped by the tools I used along the way.

This is a reflection on using AI in research storytelling: where it helped, where it quietly constrained my thinking, and what I’ll do differently next time.

The context: lots of data, sensible intentions

I’m currently working on a programme integrating a new off-the-shelf online data management system. As part of this work, I conducted research with two different internal stakeholder teams, as well as external users of the existing process/system.

The aim was to understand the “as-is” experience in full detail: the challenges, how they showed up across teams, and how they played out across the end-to-end journey.

The interviews returned a lot of data. Rich, nuanced, and detailed. The kind of dataset that’s incredibly valuable and slightly intimidating.

Where AI genuinely helped

This is where AI did exactly what it promised.

I used it to help:

• Synthesise large volumes of qualitative data
• Identify recurring themes and patterns
• Surface challenges across the end-to-end journey

It gave me speed, confidence, and reassurance that key insights weren’t being missed. I mapped the findings out across the “as-is” journey on a MIRO board and structured a report that presented challenges by each stage of the process.

At the outset, this felt entirely reasonable. Logical, even. If the team could clearly see where the pain was occurring, they could start to address it.

The problem I realised too late

As I moved into report writing – and later, presenting the findings – I could feel something wasn’t quite right.

The work was thorough.
The insights were accurate.
The facts were checked.

And yet, the findings felt repetitive. The narrative felt flat. Instead of a clear articulation of the big issues, the audience was being taken through a long list of challenges without a strong sense of what really mattered or how it all connected.

This was unusual for me. I’ve always considered storytelling a strength when presenting research. Normally, I move from synthesis on a MIRO or Mural board into a deck with relative ease, shaping insights into a narrative that helps teams think and act differently.

This time, that flow wasn’t there.

The subtle trap of AI-assisted structure

After the session, I spent time reflecting on what I’d done differently.

The key difference wasn’t the project or the complexity of the work; it was my starting point.

This time, I began with two detailed word reports that AI had helped me generate, outlining challenges by process stage. That’s not how I usually work. In the past, I’ve tended to move straight from visual synthesis into storytelling, shaping the narrative myself as I go.

Instead, I found myself reacting to a structure that already existed.

The structure made sense. It was coherent and comprehensive. But it wasn’t necessarily the story that needed to be told.

This is where AI can quietly lead you down a path you didn’t consciously choose:

• It produces a logical, complete structure
• That structure feels “right,” so it goes largely unquestioned
• You start optimising within it, rather than stepping back and reframing

Fact-checking didn’t solve this, because the problem wasn’t accuracy – it was meaning.

Why checking the facts isn’t enough

Everything in the report was correct.
That didn’t make it effective.

Good research storytelling isn’t just about describing what’s happening at each step of a journey. It’s about:

• What really matters
• What connects issues together
• What explains why things are breaking down
• What decision-makers actually need to understand

AI is excellent at surfacing what.
It’s far less capable of deciding so what.

That still requires human judgement, context, and a point of view.

Going back (and reframing the story)

I went back to the findings and reworked them into a shorter report with a very different structure. Instead of following the process end to end, it focused on a clear narrative about the core issues shaping the experience overall.

The result was:

• Shorter
• Clearer
• Easier to follow
• More actionable

In the process, I created two detailed Word reports, a needlessly long deck, and finally the report I should have produced at the outset.

That’s not time I’ll get back, but it is a lesson I’ll take forward.

What I’ve taken away

A few reflections I’ll be carrying with me:

1. AI is extremely helpful in making sense of complexity
   Especially when working with large volumes of qualitative data and needing confidence that key themes haven’t been missed.
2. The biggest risk isn’t over-reliance, it’s unexamined influence
   I didn’t outsource my thinking to AI, but I did allow an AI-generated structure to become the default frame for the story. That influence was subtle, logical, and easy to accept, which is exactly why it’s worth paying attention to.
3. Accuracy alone doesn’t create insight
   Everything in the report was correct. That didn’t make it coherent, compelling, or easy to act on.
4. Storytelling requires conscious human framing
   I was using my judgement throughout, but I wasn’t always aware of how my framing had been shaped upstream. The lesson wasn’t to “use my brain more,” but to pause earlier and ask whether this was truly the story I wanted to tell.

AI didn’t weaken this work, but it did make it easier to follow a path I wouldn’t have consciously chosen.

What I’ll do differently next time

• Use AI heavily for synthesis, but pause before locking in any AI-generated structure
• Sense-check the narrative before writing detailed reports or decks
• Ask: “If I had to explain this in three slides, what’s the story?”
• Separate process mapping from insight storytelling more deliberately
• Treat AI outputs as prompts, not starting points

AI can help you find the insights, but it’s still up to you to decide which story is worth telling.

The post When AI gets in the way of the story appeared first on Made Tech.

I’ve always been taught to use the Testing Pyramid¹.

The basic idea is to write the most unit tests, as they are the smallest in scope and fastest to run. Then you write fewer integration tests, which are larger in scope and slower to run, before you finally write an even smaller number of end-to-end tests, which are the largest in scope and slowest to run.

I’ve always been taught to use Test Driven Development²³ (TDD).

The basic idea of this is that you should write your tests before you write any code. Your tests codify the required behaviours of the software you then write, giving you an easy way to know when the feature you’re working on is complete. This should also document the context of the code you’ve written, making future changes theoretically easier.

But I keep observing common issues with unit testing on the digital delivery teams I’ve worked with over the past several years.

Recognise either of these from projects you’ve worked on?

Problem 1: Lack of test confidence – Your application fails when you deploy it, despite all the unit tests you’ve written for the change you’re making and high test coverage.

Problem 2: Testing stalls change – You make a simple change to your code, but you then need to totally restructure lots of unit tests in order to do it.

Problem 3: High cognitive load – You want to understand the behaviour of a section of your codebase, but reading the unit tests provides little help.

I’ve observed these problems dozens of times and they’ve always frustrated me because they seem to directly oppose the entire point of testing!

I believe good testing provides several significant benefits in software delivery:

1. Good tests should give us confidence in the correctness of our changes
2. Good tests should allow us to make changes more quickly
3. Good tests should document how our system behaves

Introducing the Testing Trophy

The culprit is the Testing Pyramid. It’s outdated and obsolete.

I’d like to introduce you to the Testing Trophy⁴⁵⁶ as a replacement. This is also sometimes known as the Testing Vase or Testing Honeycomb, but it’s essentially the same thing.

Integration tests are now the widest layer

The goal of these tests is to codify business logic. This typically means each test maps to either an individual acceptance criterion or an obvious, easy-to-understand part of a user journey.

For example, if your user journey is “to allow users to log in and check their health records”, you might have an integration test to check they can log in, another to check that a logged-in user can access their health records, and a third to check that a person’s health record displays the correct information.

Integration tests shouldn’t really care about the internals of your code. In theory, if you re-wrote your codebase in a new language, you should still be able to run the existing integration tests with minimal change needed.

Integration testing also avoids some of the common problems attributed to end-to-end testing – extremely long, brittle tests which fail intermittently. By splitting these long journeys up, integration tests are more reliable.

To address the three problems described above (lack of test confidence, testing stalls, and high cognitive load), I recommend migrating the bulk of your unit tests to integration tests.

End-to-end tests stay very thin

The goal of end-to-end testing is to ensure your application works as expected in an environment that closely replicates the production environment. In other words, they’re infrastructure tests. Only a few of these tests are needed, and they should cover complete user journeys.

To keep your end-to-end testbench manageable, it needs to rely on the presence of your integration testbench. This means you can keep the number of expensive end-to-end tests to a minimum.

Unit testing is now also a very thin layer

There are two goals for unit testing now: exhaustive testing and complex-subsystem testing. Both of these rely on your integration testbench to assert that your codebase actually works in a general sense, and only test very specific functionality that would otherwise slip through the cracks.

Exhaustive testing is for when you want to test all possible values or combinations within a feature. You could integration test the “common” combinations to check that the code works overall, but you could then add a unit test that would loop through every possible single value or combination of values to ensure they all still work.

For example, imagine you’re building an online shop, and you have integration tests that verify that users can successfully purchase green paint. Exhaustive unit tests could build on this to ensure the paint is also available in the 100s of other colours your shop offers.

Complex-subsystem testing is for when you have an isolated nugget of complexity in your codebase that you want to test in isolation. Because it has many edge cases and is complex, highly focused unit testing is important to ensure it works correctly. In essence, this pattern uses the same philosophy as integration testing our services as opaque boxes – just zoomed in to treat a specific class, module, or function as an opaque box instead.

For example, I once wrote a set of complex-subsystem unit tests for a smart rate limiter I was working on. You could integration test that the rate limiter works for several examples in the wider context of the application it lived within, but then add unit tests on top of this for every edge case you can think of for just the rate limiting logic.

Linting/Static analysis is the new base layer of the model

The goal of this layer is simply to speed up our ability to write quality code and tests. By using automated tools, we can catch more careless errors without having to test for them specifically.

And that’s the Testing Trophy!

What does this look like in practice though?

But what about the real world? It’s all well and good to evangelise a theoretical testing model, but how would you go about applying this to a real project you’re working on?

Below are some examples of common queries, and how I’d approach addressing them.

“I’m on a project with an OO codebase and lots of unit tests for each class. How can I introduce integration testing?”

• You can probably use your existing test runner (jest, junit, pytest, etc.) and extend it with tools like Localstack, Wiremock, or Test Containers.
• You can then write integration tests which read like chunks of a user journey or individual acceptance criteria. Something like “I want to allow users with an existing account to log in” or “I want to reject users who log in with the wrong password”. This is often referred to as Behavior Driven Development (BDD).
• You can convince your team with working code examples to back up what you’re saying. Hopefully, it shouldn’t take them long to see that writing a handful of integration tests with very few mocks saves them considerable time and effort!

“I’m working on a frontend using a modern JS framework. What does the testing trophy even look like for this codebase?”

• Render the entire app (and spin up any backend services) and use tools like Cypress or Playwright to end-to-end test full user journeys (e.g., logging in, adding a product to the basket, checking out, and requesting a refund).
• Render each page and click through multiple components to integration test. These tests should naturally make sense as parts of a user journey (i.e, a login flow).
• Render each significant visual component and verify that it renders correctly on screen during unit testing (exhaustive unit testing). You can also use tools such as Storybook or Chromatic to help with this.
• Render each complex (think lots of gnarly state logic, etc.) component and run through edge cases (complex subsystem unit testing).

“Our team has an end-to-end testbench which has all of our user stories in but is flakey, expensive to run, and breaks all the time. How do we fix this?”

• Is your entire end-to-end test stack running in a production-like environment? If not, fix this first! Even if it means you’re no longer able to run these tests locally, that’s an acceptable tradeoff.
• Are your tests actually written as full user journeys? Or do they try to do much more, testing edge cases or individual chunks of a user journey? If the test isn’t a full user journey through your system (e.g, I want to buy new shoes → my new shoes are on my feet), it probably belongs as an integration test.

“What’s the problem with just having lots of integration and lots of unit tests?”

• It’s fine to have partially overlapping tests! This is often a good pattern: an exhaustive unit test (the login button renders), an integration test (I can log in), and a larger e2e test (I can log in, buy something, and pay for it).
• If your integration tests are easy to run, can be run locally and debugged, having equivalent unit tests that try to do exactly the same thing is unnecessary, increases cognitive load, and runs the risk of rotting over time.

“My manager/boss says that we should aim for X% code coverage”

• Code coverage has diminishing returns (beyond 70%)⁷. It’s often good at revealing which chunks of a codebase haven’t been tested, but it’s bad at revealing which lines of code you should/shouldn’t be hitting.
• If their focus is on overall system performance, you could consider trialling DORA metrics⁸ within your team or organisation instead.
• They might start to trust you more when your new testbench starts automatically catching issues that the existing unit tests miss. I added a simple end-to-end testbench to a service our team owned, which had previously been very heavily unit-tested. It caught 5 bugs in the first month that would’ve otherwise gone to production without being spotted by the existing testbench.

“Our team has dedicated testers/SDETs, I don’t want to upset them by changing how we test”

• Most organisations employ testers to be test experts, not human computers. Most organisations and testers welcome automation and the increased confidence it brings through better testing.
• Bring them into the conversation early if you can. They’re likely to be highly in favour of new testbenches and better automation! After all, these tools make their jobs easier, freeing them up to focus on more important work like paying down test technical debt or activities like user acceptance testing (putting new stuff in front of actual users).

Annex – The types of tests

I want to take the time to define exactly what I mean when referring to all the different types of tests. In my experience, everyone has a subtly different definition of them – so for the sake of my sanity and your understanding, here are the definitions I’m using⁹¹⁰:

End-To-End (E2E) testing

Sometimes referred to as Functional, Integrated, System, or Smoke testing.

End-to-end tests are typically scoped to Level 1 (Software System) of the C4 model. Of all the tests, end-to-end tests are as realistic as you’re able to get and often need to be run in a production-like environment. These tests typically read like fully complete user-journeys.

External software systems are mocked as needed and pragmatic infrastructure changes are made (for example, running with fewer replicas than the production instance to save on server costs).

End-to-end tests are meant to be wide-reaching and realistic, at the expense of speed and ease of being run.

Integration testing

Sometimes referred to  as Functional, Component or Service testing.

Integration tests are typically scoped to Level 2 (Containers) of the C4 model. Integration tests are the middle child between end-to-end and unit tests, carefully balancing scope, speed, ease of running, and realism. These tests typically read like chunks of a user-journey, or specific acceptance criteria.

Other major components of your software system are mocked out, and tightly-coupled parts aren’t. For example, integration tests for a login API might mock everything except the API, a database storing login credentials, and a queue which login requests are read from. Infrastructure is also often mocked, with tools such as docker, localstack, or lightweight kubernetes clusters being popular choices to only stand up a small handful of tightly-coupled services.

Integration tests are a balance between being closer to reality, treating your software as an opaque box unlike unit testing; and fast and simple to write/run, unlike slower and more brittle end-to-end tests.

Unit testing

Unit tests don’t really go by any other names, but there are a million competing definitions of what constitutes a “unit” of software!

Unit tests are typically scoped to either Level 3 (Components) or Level 4 (Code) of the C4 model. Due to the limited scope of these tests, other classes/modules/functions/objects within the same codebase are mocked as needed.

Unit tests are meant to be quick to write and run, at the expense of scope and realism.

Static analysis

Sometimes also known as linting. Static analysis covers a vast array of tools and automations and can often be found in places like pre-commit hooks, continuous integration pipelines, and even your code editor. This bundles together linters, formatters, type checkers,

Static analysis tools are typically scoped to Level 4 (Code) of the C4 model. They aren’t really “tests” in the traditional sense, but enforce things like code styling and good practices.

Ideally, they should be run as close to code being written as possible for the shortest feedback loop possible.

1. Mark Cohn – Succeeding with Agile: Software Development Using Scrum, 2009 ↩︎
2. https://martinfowler.com/bliki/TestDrivenDevelopment.html ↩︎
3. https://www.madetech.com/blog/messy-software-projects/ ↩︎
4. https://www.wiremock.io/post/rethinking-the-testing-pyramid ↩︎
5. https://kentcdodds.com/blog/the-testing-trophy-and-testing-classifications ↩︎
6. https://kentcdodds.com/blog/write-tests ↩︎
7. https://kentcdodds.com/blog/write-tests#not-too-many ↩︎
8. https://www.thoughtworks.com/en-gb/insights/articles/improving-your-bottom-line-with-four-key-metrics ↩︎
9. https://martinfowler.com/bliki/UnitTest.html#SolitaryOrSociable ↩︎
10. https://martinfowler.com/articles/practical-test-pyramid.html ↩︎

The post A pyramid scheme! Have we been unit testing wrong? appeared first on Made Tech.

We launched our apprenticeship programme as part of our long-standing commitment to grow digital capability and deliver social value through our work. Since founding Made Tech, we’ve invested heavily in early career pathways, including our engineering academy. Apprenticeships were a natural next step, combining learning with real-world delivery experience. 

The goals of our apprenticeship programme are simple but ambitious:

• Develop future-ready digital talent
  
• Create accessible entry routes into tech careers
  
• Build long-term capability for public sector delivery
  
• Raise standards in practical, work-based technical training
  
• Support business and client outcomes through a strong talent pipeline

Innovation is at the heart of the technology sector, and our apprenticeship programmes are no different. Our Learning & Development team has worked hard to integrate several innovative approaches into our programme delivery to ensure that our apprentices expand their consultancy skills alongside their technical training. 

A blended model built around delivery

We use a blended learning model that combines traditional classroom-based learning with hands-on, client-facing work. Apprentices balance their time between structured learning sessions and practical project delivery, allowing them to apply their learning in real-life scenarios. This approach helps consolidate their understanding and keeps learning grounded in the realities of modern digital delivery. Instead of learning theory first and practice later, apprentices build confidence by doing both simultaneously.

Developing consultants, not just engineers

Great public sector digital delivery relies on more than technical skills alone. It requires collaboration, communication, and sound judgment too. That’s why our apprentices work on cross-functional teams, which allows them to interact with other specialisms and gain a deeper understanding of how Made Tech operates. This helps them develop strong communication, collaboration and problem-solving skills – consulting skills that matter just as much as technical capability. 

Learning through gamification

To further enhance apprentice engagement, we have incorporated gamification elements into our curriculum to make learning more interactive. These practical exercises give apprentices a chance to test their thinking, strengthen their technical skills and tackle problems in a more dynamic format.

Competitions and events

We encourage apprentices to test their skills beyond their day-to-day work whenever possible. Recent cohorts have participated in external competitions such as the NASA Space Challenge, which provided them with the opportunity to showcase their talents and challenge their abilities, whilst also engaging with individuals outside of Made Tech. We believe that these competitions and external events will foster healthy competition and drive excellence, enabling apprentices to benchmark their skills against peers across the industry whilst gaining confidence and experience under pressure. 

Assessments that mirror real work

Our assessments are not abstract tasks. They are designed around real-life challenges that we encounter at Made Tech and the work we do for our clients. To make the experience as authentic as possible, we involve relevant stakeholders and, at times, clients throughout the project milestones so the work feels authentic and outcome-focused. By doing this, we aim to give apprentices a clear understanding of the impact of their work and how their contributions can make a meaningful difference for our clients and the broader community. 

Continuous feedback

Feedback shouldn’t be something that only happens at the end of a module. At Made Tech, we implement a continuous feedback system built into the rhythm of the programme. Through regular check-ins, learning reviews, and weekly journals, apprentices receive ongoing feedback, enabling them to adjust quickly, build self-awareness and keep progressing steadily. This approach ensures learning remains ongoing and helps our apprentices stay on track, with support provided where required. 

Career guidance from day one 

Starting a career in tech can feel exciting – and overwhelming. We support our apprentices with structured career information, advice, and guidance throughout their apprenticeship. Our CIAG (Careers Information, Advice and Guidance) programme is a dedicated initiative that supports our apprentices as they build a confident, informed pathway to their future careers. The transition into the workforce is both exciting and daunting, and our programme is designed to provide clear, consistent, and high-quality guidance every step of the way.

Looking ahead

National Apprenticeship Week is a celebration, but it’s also a reminder that workforce development is long-term work. Strong programmes are built through iteration, feedback and partnership.

We’re proud of what our apprentices have already achieved, not just in qualifications gained, but in services improved and teams strengthened. As we grow the programme, our focus remains the same: high-quality learning, real delivery impact and genuine career progression.

If you’re interested in starting a career in digital and technology, we’d love to hear from you.

The post How our innovative apprenticeship programme is building the next generation of public sector technologists appeared first on Made Tech.

I came into tech as a career changer. After seven years working in the NHS as a Physiotherapist, I took a leap into coding through a bootcamp, which led me to a role as an Apprentice Software Engineer at Made Tech. 

The Made Tech apprenticeship programme

From the very start, it was clear that this apprenticeship was about far more than just learning to code. While technical skills are essential, the programme takes a holistic approach to development. Early on, we explored topics such as Equality, Diversity & Inclusion, British Values, Power, Privilege & Responsibility, and Non-Violent Communication, among many others. Learning about these subjects showed me that this apprenticeship isn’t just about becoming a better engineer, but it’s about becoming a more well-rounded, capable professional. 

You might think that, after years in healthcare, I would have already honed my communication and teamwork skills, and, to some extent, I thought I had too. Yet, this apprenticeship has shown me that learning never stops, and there are always new ways to grow both professionally and personally. 

Turning learning into practical experience

A highlight for me has been joining a delivery team where I get hands-on experience every day, not just with coding, but with collaboration, communication, and teamwork. Pairing with senior engineers allows me to learn in real time, gaining practical insights and guidance that you simply can’t get from textbooks alone. It also inspires me to see the career path I hope to follow one day. 

Having completed a university degree in the past, I can honestly say that this apprenticeship offers a different and incredibly valuable way of learning. Being immersed in ‘on-the-job’ experience has given me confidence, practical skills, and a sense of contribution from day one. While it can feel like being thrown into the deep end initially, that challenge quickly becomes an opportunity for rapid growth. Moments of discomfort or imposter syndrome are normal, but learning to navigate them is part of the process, and it’s what enables true development. 

The value of apprenticeships

Apprenticeships don’t just fill skills gaps for businesses; they transform lives, opening doors to careers and personal growth that might once have felt out of reach. My journey is proof of that, and I am proud to celebrate National Apprenticeship Week by sharing it.

Since 2023, our apprenticeship programme has been part of our long-standing commitment to broaden access to digital and tech careers while strengthening the skills base that public sector delivery depends on. To find out more about building a career in tech through the Made Tech apprenticeship programme.

The post Celebrating Growth and Opportunity: My Apprenticeship Journey appeared first on Made Tech.

Masood Khalid

Masood’s pivot to data engineering began during his Actuarial Science degree, where he discovered a keen interest in data analysis. He realised his passion for data and joined a graduate scheme that trained him as a data engineer, ultimately leading him to his current role at Made Tech.

What would you say to anyone looking to work in tech?

From my experience, certifications don’t cut it. You need to have experience. Find ways to implement your interests into your own personal projects. I have upskilled a lot and frankly if there was a leaderboard for how many certifications you could do within a short amount of time I’d be up there.

At the end of the day there’s no replacement for real experience and the only way to avoid the slow grindy feeling of doing those projects is to bring in your own interests. The more you do that, the more motivated you’ll be, the more inspired you‘ll be and the easier it will be for you to keep getting that experience whilst not having a job within the industry.

If you’re looking to get in, that’s my best advice. It is a bit daunting. You just have to keep chipping away at it until you get to the point where you can tie all these different fields together and you can build products and new projects on the whim whenever it takes your fancy.

What do you enjoy most about your role?

I love the variety. Thanks to the varied nature of the work here, I’ve been able to get some of my own interests involved in some of the tools I use day-to-day. I’ve got a good amount of personal projects going on. It really helps that you learn a lot of this stuff while you’re doing the work. There’s a lot of support for that here at Made Tech. We have a learning budget to use which really helps too. 

There’s a lot of different people you work with. We’re hugely cross-functional. I work with software engineers quite a bit and so we have meetings to make sure we’re not clashing or butting heads over shared infrastructure. A lot of their work flows downstream into what we do, and so a lot of our work is built upon what they’ve built in the frontend application. There’s lots to do and there’s a lot of people from different fields to work with.

Do you have any advice for anyone looking to join the team?

Out of all the places I’ve interviewed for, Made Tech does a really good job of keeping the job descriptions up to date and relevant. Read that job description because it is updated frequently. 

If you’re more junior, you stand a better chance if you can show how passionate you are. There’s a lot of projects and learning you can do to bolster your portfolio and CV if you don’t have experience yet.

Sophie Wenban

Sophie moved from video production to data engineering. She self-studied Python and completed the AWS re/Start programme. Starting at Made Tech as an associate software engineer, a databases module and a love for pipeline work inspired her shift to data engineering.

What’s a typical day in your life as a Made Tech data engineer?

My day typically kicks off with a coffee as I catch up on Slack messages and emails. My first priority is always checking our dedicated Slack channel for pipeline failure alerts, ensuring our overnight data ingestion and transformation jobs ran smoothly. I then review my to-do list, which helps me quickly re-engage with my tasks and ensures a smooth start to the day.

At 10am my team gathers for our daily stand-up. I provide a quick update on my progress and flag any blockers. If I’m stuck on a ticket, we’ll quickly agree on who can help, often jumping straight onto a call after stand-up to work through the problem together.

If there are no immediate issues, I dive back into my current ticket or pick up the next high-priority item. Collaboration is a big part of our day. We often jump on calls to discuss tickets and sometimes we’ll use pair programming to tackle challenges together.

In the afternoon I’ll jump back into my ticket or carry out a peer review if another engineer has completed a piece of work.

Towards the end of the day, I consolidate my notes and prepare my to-do list for tomorrow. This ensures I can hit the ground running, picking up exactly where I left off, ready for the next day’s challenges.

Can you tell us a little bit about the data community?

The data and AI community at Made Tech is truly a fantastic group of people. I’ve found everyone to be incredibly welcoming since joining.

We foster our community through regular events. Every week, we hold a Community of Practice (CoP) session. These are great opportunities for individuals or groups to share their work, discuss interesting technologies they’ve explored or talk about their experiences working in data. It’s a brilliant way for us to learn from each other and stay connected.

Beyond our CoP sessions, we also have a monthly remote lunch. These are more informal gatherings with no set agenda, which is perfect for getting to know colleagues better, especially since many of us work on different teams. It’s a really nice way to build connections and reinforce the welcoming atmosphere of our community.

What do you enjoy most about your role?

The direct impact my work has. I love helping organisations leverage the valuable data they hold. We partner with government departments and arm’s-length bodies and the insights we help them glean from their data can lead to real, positive change for the public. 

It’s incredibly rewarding to know that the technical work I do contributes to better public services and informed decisions that can benefit many.

Do you have any tips for anyone interviewing at Made Tech?

Pay close attention to the interview calendar invites you’re sent. They include really helpful information about what format the interviews will take, the type of activities you’ll be asked to do and some of the questions and topics you’ll be asked about.

Use these to help yourself prepare, think of experiences you can share when answering these questions and be prepared for follow-up questions.

Lee Broadhurst

Lee moved into tech after 8 years at Lloyds Banking Group. He self-taught coding for a year and completed the Northcoders bootcamp in 2022. In early 2023, he joined the Made Tech Academy as an associate software engineer, gaining 2 years of experience. A project building a client’s data platform gave him hands-on data engineering experience, leading to his transition into a data engineer role after 6 months.

If someone were to shadow you for a day, what kind of tasks would they see?

I start at 9:00am and usually spend the first 30 mins making sure that I’m up to speed with any Made Tech announcements and admins tasks. I also use this time to reflect on my previous day’s work and plans for the day ahead.

At 9:30am my project team has a daily stand up where we each provide an update on our assigned tasks. From 10:00am my day can vary quite a lot but it will often involve working on my assigned tickets, attending meetings and planning sessions or preparing to present the progress of my work to the client in Show and Tells.

Currently, I’m working on building data pipelines in a data lakehouse architecture using Databricks and Azure. I’ll often be collaborating with other data engineers and analysts to understand and implement the requirements of the client. 

Are there any areas you’re focusing on in your development right now?

I’m lucky to be working on a project where the work itself aligns with my development goals. So I get to learn whilst also being an impactful member of the team. In the last couple of months I’ve gained a lot of experience working with Databricks, Terraform and Azure so I’ll be using my learning days and annual learning budget to work through courses relating to these.

What’s your #1 tip for people who want to work in tech?

Find a learning resource that interests you and complements your learning style. Learn the foundational skills required for the role you’re working towards and try not to get distracted by all the different technologies. 

Whilst technical ability is important, it’s not the most important skill to have to work in tech. Especially at a consultancy like Made Tech. The softer skills are equally important. You may already have a lot of what’s required, especially if you’re coming from another career that requires a similar skill set.

What type of workplace culture is most important to you?

A lot of my job satisfaction comes from feeling valued by the data community and the teams I work in. Everyone is encouraging and this has helped a lot with my career progression and confidence in my ability. 

How do data engineers at Made Tech typically collaborate and share knowledge?

The data community at Made Tech is great. Everyone is friendly, supportive and keen to help each other grow. We have a Data Community of Practice call every couple of weeks. A member of the community will present something they’ve been learning or working on, or we’ll have a guest speaker attend the session.

Recently, we all got together at a venue in London for a strategy and alignment day, focusing on the future vision of Data and AI Made Tech. We had talks from members of the data community and plenty of opportunities to get to know each other more.

If hearing from our data engineers has piqued your interest in working with us, great news – we’re hiring! 

The post Meet the Data Engineers of Made Tech appeared first on Made Tech.

***

I was delighted to be making my third speaking appearance at UX Scotland. It’s a great conference with a diverse range of talks, workshops and lightning talks by designers in the public and private sectors. 

This year there were representations from private-sector organisations such as Pinterest, Netflix, Monzo and Natwest. From the public sector side of things in attendance were the Government Digital Service, the Ministry of Justice, Home Office and the NHS. 

My talk was called Being the Grown Up: The One Habit of Highly Effective Leadership. With 25 years’ experience in user-centred design I’ve learned a lot about why adopting a grown-up mindset is key to the trickiest parts of leadership.

The essence of my talk was a simple but important approach to leaning into leadership challenges. Ask yourself “what would a grown up do?” By channeling your inner grown-up and embracing maturity, responsibility and focusing on others you get this amazing lens to tackle almost any leadership challenge.

Key takeaways for effective design leadership

People who came along to my talk said that they left with a clearer idea of what leadership really is, along with practical strategies and useful frameworks. I shared real-world examples of how I’ve handled tough leadership situations, showing how an “allocentric” (other-focused) approach can be a leadership superpower.

Tackling tough situations: my real-world examples

I went into specific examples of where asking “what would a grown up do?” was a game-changer for me. Here’s a snapshot of what they looked like. 

Designing conversations for intended outcomes

This means planning out difficult conversations like performance reviews that might lead to someone leaving your organisation. For example, it’s essential to make sure as a leader, you’re aware of how dropping someone a simple ‘do you have a minute?’ message could fill them with terror!

Visible leadership in remote contexts

In today’s now often remote world, I’ve found that a grown-up leader proactively connects, communicates clearly and makes sure everyone feels like they belong. During COVID-19, I made intentional efforts like daily virtual rituals, to keep my team connected and feeling safe, even when we were apart.

Becoming an accidental leader of organisational change

Sometimes you find yourself leading big organisational shifts. My grown-up response involved taking ownership of cultural transformation through design leadership.

Strategies, tips and frameworks

Beyond those examples, I offered some big-picture strategies for adopting a grown-up mindset that include:

• focusing on the outcome, not just the emotion by acknowledging your feelings, but don’t let them run the show
• practicing active listening and empathy and really trying to understand others points of view
• communicating clearly and respectfully by being straightforward and treating everyone with dignity
• taking responsibility and own your decisions and actions, the good and the bad
• being proactive, not reactive and try to anticipate problems and deal with them before they blow up
• being accountable, that means owning it, even when it’s uncomfortable or a bit scary

Leadership and thinking beyond titles

Throughout my talk I made it clear that true leadership isn’t about having all the answers or just telling people what to do. Instead, for me it’s about:

• empowering others and helping them grow
• taking responsibility for all actions without ego
• having a positive influence and serving a bigger purpose

On the flip side, micromanaging, dictating and looking for personal glory are definitely not leadership.

The power of allocentric design leadership

My grown-up approach to leadership is fundamentally allocentric, which means it’s focused on others, not on me. I believe allocentric leaders put their team’s needs and growth first. Understanding the wider impact of their decisions and aiming for collective success. This is how you build truly effective and sustainable teams.

I also shared some practical tools, like the Rock, Tree, Heart, Star framework for personal reflection on strengths and areas to grow. Don’t forget the Accountability Ladder to help foster discussions about accountability within teams.

Ultimately my presentation at UX Scotland was a reminder that embracing your inner grown-up with maturity, responsibility, empathy and an other-focused view is the habit that builds a strong foundation for truly effective leadership.

By consistently asking myself “what would a grown-up do?” I find I can navigate challenges with intention, build connections, make thoughtful decisions and lead with a much greater impact.

If you’d like to stay up to date with insights like these from Dan, sign up to our newsletter.

The post A grown-up approach to design leadership appeared first on Made Tech.

In 2017 we launched our first Made Tech Academy and since then we’ve trained and employed over 100 aspiring software engineers. We strive to create pathways for career growth that empower individuals to create change in society.

To amplify our social value, in 2023 we made the move into offering a Level 4 DevOps apprenticeship programme.

Shaping tech careers through apprenticeships

Apprenticeships open doors for people from all backgrounds, particularly those who may not have followed the traditional university route. Nurturing early career talent through apprenticeship programmes allows the tech sector to equip individuals with the technical, professional and soft skills needed to thrive – while creating tangible social value through a more diverse, skilled and equitable workforce.

UK digital skills and economic growth

The UK government sees apprenticeships as a key part of its strategy to boost productivity, increase employment and close the digital skills gap – all of which are core to improving social value.

Initiatives like the apprenticeship levy reflect a national push to promote alternative routes into high-skilled careers, especially in technology. Apprenticeship programmes like ours align with the government’s strategic goals by:

• offering high-quality apprenticeships aligned to Level 4 digital standards
• supporting career changers and underrepresented groups into tech
• promoting regional growth and levelling up by offering opportunities across England, not just in London

Apprenticeships play an important role in contributing to a stronger, more inclusive digital economy that helps shape the future of tech talent in the UK.

An apprenticeship designed for social value

Wanting to offer our apprentices something different, we take an industry-first approach. This means apprentices work on real-life, impactful client projects early in their journey, gaining hands-on experience alongside senior engineers.

By delivering real software to communities, apprentices not only gain a better understanding of users but also help increase social value by having a positive impact on real-world problems. Programmes like these shouldn’t just be about learning to code, they should always aim to deliver value into society.

When backed by structured support, mentors and a tailored progression framework, apprentices can create a positive impact in the public sector while they learn. It’s about developing the person, not just the skillset.

Increasing opportunities for underrepresented groups

Apprenticeship programmes should always be designed to create meaningful employment opportunities, for all. By actively encouraging applicants from underrepresented backgrounds the tech sector can play an important part in making sure the services and products we design are shaped by people from all areas of society. This can include women in tech, ethnic minority groups, career changers and those without university degrees.

Traditional tech roles often require prior experience or formal education. This can disadvantage capable people who don’t have access to those opportunities. Removing that barrier to instead focus on potential, curiosity and drive is central to reaching many more aspiring individuals, while creating social value through the promotion of equal opportunity.

By creating inclusive access to tech careers and supporting people throughout their journey, apprenticeship programmes like this contribute to reducing inequality and promoting equal opportunity, delivering lasting social value in every sense.

Real impact in local communities

From week 12 of the programme, our apprentices are placed on real client projects. This is where they contribute to essential public sector digital initiatives.

So far that has included projects such as digitising patient records with NHS England and enhancing the consistency of energy compliance checks for building regulations with the Ministry of Housing, Communities and Local Government.

Embedding apprentices in socially impactful projects and supporting their growth within the sector not only invests in them but also strengthens the digital infrastructure of the public services that communities rely on every day.

This approach delivers local impact and long-term wellbeing outcomes for people, places and the public sector – a significant and important driver of social value.

Social good beyond company walls

Following a successful Ofsted inspection, we’re welcoming our next 2 cohorts of apprentices. Our first group joined this week and the next cohort will be joining us in October 2025. We’re incredibly excited to support them as they begin their careers in tech.

We believe investments in apprenticeships like this go well beyond developing internal talent. They reflect broader commitments to driving long-term, positive impact and social value across the public sector, local communities and the wider technology industry.

Stay up to date with Made Tech apprenticeship news.

The post Tech for good: how apprenticeships can drive social value appeared first on Made Tech.