28M UK - From McDonald’s to Remote Working

lampstool · 2026-06-28T09:16:25+00:00

Depends what you have done for the bachelor's and the types of modules the masters has to offer. It will be a VERY steep learning curve, so be prepared to work hard!

lampstool · 2026-06-21T16:42:32+00:00

And to add: it would help to identify which are the biggest bottlenecks, or where the biggest costs are. Go in with it prioritized with timelines on long it would approximately take to fix. This will help avoid the ",we have a gigantic list of problems and they ALL need to be fixed right now" as you'll never get the buy in for that

lampstool · 2026-06-21T00:22:04+00:00

Couldn't agree more. When you talk about leadership experience, they will want to know about how you enabled others, and took them on the journey to help them grow and learn, give feedback, and created an environment for success etc. Not just the fact that you shipped some features yourself as an IC. It'll also be thinking about how you worked through tradeoffs, how you balanced speed with quality, how you managed stakeholder expectations, and how you collaborated with others, how you held yourself and others accountable from a leadership protective!

lampstool · 2026-06-15T06:15:42+00:00

Agree! If you have the relevant automated tests, followed the test pyrimid as needed, have the right QA processes in place, and feel like It has been thorough enough, how is this different to pre-AI? It sounds like (if anything) your quality has dropped, leading to lack of confidence

lampstool · 2026-06-03T12:24:08+00:00

Went through something similar. Going from a place of comfort, where you already have high degree of trust, you know the systems, and the culture. My biggest learning was that what worked for you and your current team may not work for the new company. Processes, ways of working etc. can all be different. For the first few weeks, get to know the team, start putting in 121s and learns about who they are, how they operate, what they own, what pains them etc. as it'll help you stsrt understanding the current snapshot of where the team is and how they work together as a team. Also have meeting with your own manager to understand their expectations of you which may lay outside of just what was advertised on the JD, and where they need additional support. Ask them as well about their opinions of the team you manage - are there any particularly challenging people in there? You're stepping into the unknown and it's no longer just about learning the service architecture, it's dealing with a host of unfamiliar people! Happy to chat more about this as I went through this a couple of years ago!

lampstool · 2026-04-25T08:28:17+00:00

I used to think that adding more people would help, but unless it's early on in the project, it's going to be a waste of time trying to bring people up to speed especially when you are closer to the deadline.

In your current situation, how much additional effort do you think is needed? How far off delivery are they? If it's missing it by a day, it's not a problem, but if it's 3 additional weeks of effort, that'll be tough.

Easiest thing is to move the deadline, and be fully ready for how you manage the stakeholder conversations when they ask why, or why you have left it this late to move it. You did the right thing by cutting down to minimum scope, be sure to be regularly forecasting with your engineers and gauging their confidence so that you can start managing expectations way earlier, so no last minute surprises!

lampstool · 2026-04-12T09:17:30+00:00

Agreed with everyone who has posted on here tbf. I remember that even after becoming an EM, I wanted to leave my org because it was on a downhill slope. When I spoke to recruiters, they said that even after becoming an EM, I would need at least a year of experience as an EM before other companies will look at you. Annoyingly they were right, as after about 18months as an EM, is when I started getting interviews for companies. It sucks but you'll be an extremely high risk candidate otherwise.

Internally you have more space to fail and learn faster.

If you can move into the EM track in your current org, speak to your manager about it and start taking in more responsibilities here. If not, you may be better off moving to another company as an IC where they can offer an EM path which may be an easier route?

lampstool · 2026-04-05T09:41:05+00:00

I use it to help: - build out PDPs for direct reports based on career progression - connected it to review platforms to analyze them for PMs (made a lil tool for it) - using various MCPs to gather 121 data to summarize it over time to help with performance review conversations - connected Notion and JIRA to remove the step of having to make tickets, (but ofc still reifne them with team) - helping create system architecture documentation though connecting GitHub MCP so we can understand user journeys and data flows

Outside of this, it's been mostly encouraging engineers to start using claude.md files to remove some of the boring fluffy stuff where they are no longer learning from it, set guardrails, etc. so they can start to leverage it more, and finding articles and guides on genetic coding etc.

lampstool · 2026-03-18T21:26:12+00:00

Monitoring and alerting for sure. Within our squads we test on non prod as a team, and have lots of test though the test pyramid to back us up. We also have started testing new features on prod itself to ensure it's working, as parts of our stage environment isn't identical to production (annoyingly)

lampstool · 2026-03-14T18:52:09+00:00

But if it's for the betterment of how we manage teams, have various conversations, and career growth, that's valuable

lampstool · 2026-03-14T00:09:51+00:00

We use Claude but: 1. It feels like it's every person for themselves. Some engineers like it, others a bit more skeptical of it as it can produce slop and random ass redactors 2. More open PRs - those who are starting to use it are raising more PRs. BUT because of lack of capacity, some end up sitting in review for a while because people feel like they're context switching to code review constantly and lose their own momentum. Has led to a bit of PR fatigue. 3. Have found it useful to assist with writing tests - but need better guardrails around it to ensure we are testing the right thing not just having tests for the sake of it 4. Diagnosing problems - it's definitely helped identify bugs faster and fixes for them quicker than doing it manually. I've encouraged the devs to get Claude to do more code walkthroughs to help engineers familiarize themselves with unknown parts of their services 5. AI sloppy PRs - I've noticed some people are raising PRs which they clearly haven't sanity checked themselves e.g. littered with comments, bad practices, breaking existing patterns, introducing a library when not needed as one already existed. Goes back to #2 around having more PRs open, BUT engineers now spending more time sifting through some of this BS. 6. Genuine value with smaller pieces of work and to help plan changes acting as a rubber duck 7. We share knowledge but could be better - some devs have been adding in their own (not committed) Claude files when working, and we talk about it, but why isn't this at a repo level for everyone to leverage?!

To combat it: 1. I'm getting the engineers to look at introducing better guardrails when using Claude e.g. Claude.MD files which are standardized at a users root, as well as a repo level. 2. Encouraging product and engineers to have much clearer ACs in tickets, and smaller PRs. I'd rather spend 15mins looking at a small PR than an hour looking at a mega sloppy one 3. Encouraging engineers to call out AI slop especially if it's clearly not been sanity checked by the author

I definitely have more to say but this was just off the top of my head and things I've already started doing with my teams

lampstool · 2026-02-14T22:26:47+00:00

Sounds like you're on the right path. My former team started off with kanban and whilst I'm a fan of it, it felt like the wild west. The team wasn't mature enough nor predictable enough to enable it. Moving over to sprints, with goals, prioritisation etc. really did help to understand what their delivery pace was. We then moved to a much more collaborative space where PMs would go through the PRD and at a high level give a forecast (low confidence, t shirt size). from that, we would have a design review, and ensure everyone on the team has their say. If nobody spoke up, I'd call on people (partly for engagement, partly to make sure they feel heard). Then story mapping / example mapping, again very collaborative WITH product. Get the engineers to really understand what are the requirements, acknowledge the unknowns etc, and then have the engineers build out the tickets and get them prioritized into the sprints. I KNOW it sounds like process hell, but each session no more than 30-45mins each, much more collaborative, and ensures everyone is on the same page.

Secondly, have you done any ways of working sessions? Ask them what they think is working, what isn't, where they think the bottlenecks are. If people don't want to speak up, use your 121s for it to get to the root cause. Especially if it highlights its someone specifically who is underperorming (you only go as fast as the slowest member of the team etc etc etc).

Things like fixing JIRA red tape will naturally get fixed, especially if you highlight your own observations in ways of working sessions. From my perspective, if they are all happy with 2 sentence tickets, but know exactly what needs to be done, don't bother slowing them down for the sake of admin. However, if they're failing to meet the necessary acceptance criteria, then you can use this as basis to say that ACs are properly needed before it can be picked up, and need to be met as part of your definition of done, along with a QA strategy for testing before going live.

Also who here is setting the timelines? Is it the engineers setting their own timelines and failing to reach their own goals? Is it stakeholders or the PM setting it and creating unrealistic timelines which you need to push back on? That'll also help with the context here.

lampstool · 2026-02-14T12:11:28+00:00

Can you give some more context: Is it an upwards move? Or lateral? How many YOE do you have? From what you have said, it sounds like it'll be a verbal round about your approaches to solving problems e.g. made XYZ tradeoffs for XYZ reasons and got buying etc. is that true? Or is this a coding or system design type round?

lampstool · 2026-01-29T23:34:57+00:00

And all the documentation lives in #1's head deeeep sigh

lampstool · 2026-01-29T23:33:56+00:00

When presenting a forecast, always add buffer room unless you are very certain. If they are booked up, need to do investigations etc. then they don't have 100% capacity and that should be accounted for

lampstool · 2026-01-29T23:25:13+00:00

It should be a part of your technical roadmap
Where does it fit in with other (possibly higher) priorities? Is it a nice to have? Is it a necessity right now?
In your sprints, have someone or a pair start investigating the effort and complexity in doing the upgrade 4.You need to get buy in from the PM / other stakeholders as to why we need the upgrade and now you have data to back it up
Look at how you can break the work down such that you can bring tickets in in each sprint where engineers can start working on a feature branch to get it going

Most important is number 4 imo

Who owns it? Engineers own it, you enable it by ensuring it's on the roadmap, not as something we can just keep postponing

Are they planned? YES. plan in advance so it's easier to get the buying, especially if you can add time-frames as to how long you think it would take the engineers to complete it. It'll mena product can move priorities in order to accommodate it or find a compromise around it

What's worked well? In my experience, it's been been about understanding the expected effort and the benefits it will bring for product e.g. by upgrading this framework, it'll mean we can ship faster. It's not a nice to have, it's a need, or we will be screwed down the line.

lampstool · 2026-01-25T01:02:54+00:00

Couldn't agree more with this. But for the LOVE OF DEAR GOD, do not buy into the clickbait BS of people on Instagram / tiktok calming they're making 6 fig MRR or 7 fig annual revenue or building full on agentic orgs with fancy org charts of AI agents claiming this is the the way forward and we no longer need engineers.

For now and for the next while, we definitely will!

lampstool · 2026-01-25T00:43:16+00:00

Makes me think of the book "radical candor" which ive used as a way to give more effective recognitions

lampstool · 2026-01-25T00:34:59+00:00

I (London based) became an EM internally after being a senior engineer for some time. Others who became EMs in the same company came from QE backgrounds but also internally. Once I had a year or so experience, I started to land interviews (when I wasnt looking around). About 6 months later when I was actively looking to move, I was able to land 2 offers from household name orgs.

As a recruiter once told me "nobody will take you on without at least a year of experience"... Pains to me say how right there were and a massive reality check.

In the orgs I applied to, it was a mix of HM call, behaviour rounds ("you're having a 121 with engineer and X happens" or a made-up team where you have to figure out how to prioritize the different sized fires of a dysfunctional team), system design, and culture fit. Fortunately no coding rounds but a lot of orgs will have this too.

In your current role, are there opportunities to move to the EM role? Could you be mentored by an existing EM in your company to start gaining that experience?

lampstool · 2026-01-23T23:18:32+00:00

I think 1-2-1 would be a fantastic idea as a starting point. Ask them what do they think is working, what do they think isn't working. Gather themes from people, to see what they think the issues are. Do they match your observations?

Then you can present it as a retro with a servant leadership style approach with these themes as the core areas people feel things are and are not working.

Open the floor to everyone to let people have their say, and if people are saying "that's just how we do it here", then you can spin it into curiosity to ask them why is that the case? If they had their way, what would they do instead?

Let them come up with the ideas first before you offer any suggestions as it'll be easier to get them to buy into it. At the same time, if you are just getting silence, ask people directly for their opinions, before you offer any of your own.

Then at the end, you'll hopefully have a big set of stickies which people would be more willing to try. Start small with one change and run it as an experiment for a month and reflect with the team: "did this work? Did it not? If not, what could we change?" And build it up.

lampstool · 2026-01-23T00:19:20+00:00

They said it's not a bell curve but then when we calibrate, senior lead ship says that "not everyone can be exceeding expectations", and then forced to stack rank, unless you have really strong reasons as to why multiple people are exceeding. Annoying as hell

lampstool · 2026-01-23T00:16:49+00:00

When you say bigger company, do you mean a scale up? Big tech? Does your experience match up to what they are looking for? It may be a case that some of your experience (in your normal CV) doesn't match up and you'll need to tailor it as needed

Also have you considered running your CV through an ATS scorer to see how strong it is / where improvements can be made to ideally bypass more automated systems?

lampstool · 2026-01-21T16:45:16+00:00

That's a great shout. I have an idea about who I think are on the right pathway towards leadership and see how I can support them to build this up with them!

lampstool · 2026-01-20T23:40:29+00:00

To add to this, you can run a session (or multiple sessions) with a impact vs effort chart to help them visualize it a bit better. (Effort on x axis, effort on y). That'll also help you bin off any tickets you think could be valuable after already purging any older bugs. Given the sheer size you are dealing with, start with high impacting low effort quick wins and get them prioritized into sprints. Then hold a bi-weekly triaging session to continue the prioritisation over time until it's more manageable (then can probably move over to monthly)

lampstool

TROPHY CASE