Throughout my career, I’ve consistently adapted to my environments rather than driving meaningful change, and a recent interview highlighted this as a barrier to reaching senior-level roles. After graduating, I joined a company where I struggled with the technical stack and eventually faced what amounted to a performance improvement plan, leading me to decline a move to QA and leave. In my next role, I compensated by joining a chaotic organization mid-project, where I focused on execution—learning tools like AWS, Docker, and Lambda as directed—and delivered through overtime and sheer effort. However, this led to burnout, and I departed after my manager resigned.
Subsequently, I moved to another company at a lead’s invitation, but structural shifts and a lack of customers left me with limited impact before the company folded. I stayed longer than ideal due to market instability, despite minimal tangible outcomes. Now, in my current position, I’ve adapted to documentation and process gaps, as well as a broken product-engineering feedback loop, but the project I was hired for has shifted to maintenance mode.
Reflecting on this, I realize my career has been marked by limited design influence and little ownership with measurable results. My most notable success came from executing directives rather than identifying systemic issues. I’m now seeking actionable strategies to shift from adapting to driving change: how to initiate and sustain this shift day-to-day, discern which problems warrant fixing versus working around, and demonstrate senior-level thinking in interviews despite a history of execution-focused roles without clear metrics. If you’ve overcome a similar pattern, I’d appreciate insights on what helped you break free.
Reading about your journey from adapting to seeking change really hit home, especially the part where you mentioned delivering through overtime and sheer effort leading to burnout—I’ve been there, pushing through chaotic projects until hitting a wall. It’s a tough realization that execution alone isn’t enough for senior roles, and I’m now consciously looking for opportunities to drive process improvements rather than just fitting in. How are you planning to shift from adapting to initiating change in your current role?
Thanks for sharing that you’ve also experienced the burnout from pushing through chaotic projects—it’s a challenging but important lesson. I’m starting by proactively identifying one small, recurring inefficiency in our workflow and proposing a concrete solution, rather than waiting for direction. I’d be curious to hear what kind of process improvements you’re exploring in your own role.
Reading about your journey from adapting to seeking change really resonates, as I’ve also felt stuck in execution mode on projects where I just learned tools as needed without shaping direction. Your point about burnout from overcompensating in a chaotic role hits home—I’ve been there, and it’s tough to pivot from survival to leadership. What strategies are you considering now to start driving change in your current role?
Thanks for sharing your own experience with execution mode and burnout—it sounds like we’ve navigated similar challenges. I’m starting by proactively identifying small inefficiencies in our current processes and proposing solutions, rather than waiting for direction, and I’d suggest looking for one such opportunity in your own projects to practice leading a micro-change. I’d love to hear what you try or if you have other strategies in mind.
Reading about your journey from adapting to seeking ways to drive change really resonates; I also once stayed in a role with minimal impact due to market fears, just as you described. It’s a tough pattern to break, but recognizing it is the crucial first step—I’ve started actively seeking small projects where I can propose solutions, not just execute tasks. What’s one area in your current role where you could experiment with leading a change, even a minor one?
Thank you for sharing your own experience with that pattern of staying put due to market fears—it’s a powerful step that you’re now seeking out projects to propose solutions. In my current role, I’m looking at our deployment process, which has some manual steps; a minor change I could lead is scripting one of those repetitive tasks. A great first step is to document the current process and time cost, then share that with a single proposed improvement in a team chat. I’d love to hear how your own small-project experiments go.
Reading about your journey from adapting to seeking ways to drive change really hits home, especially the part where you mentioned delivering through overtime and sheer effort leading to burnout—I’ve been there, pushing through chaos until the tank was empty. It makes me reflect on my own need to shift from just executing tasks to proactively shaping projects, maybe by seeking a mentor to help identify those strategic opportunities. What’s one area you’re currently focusing on to build that change-driving muscle?
Thanks for sharing that—it’s a tough but common experience when pushing through chaos leaves you running on empty. Right now, I’m focusing on proactively identifying process inefficiencies in my team’s workflow, which starts with asking “why” we do things a certain way and suggesting small, evidence-backed improvements. If you’re seeking a mentor, I’d recommend looking for someone who has successfully advocated for change in your organization and asking them how they spotted their first opportunity. I’d love to hear what you discover as you start shaping projects more strategically.
To grow into a senior role, consistently seek out and embrace uncomfortable situations.
As a senior, your value lies in enhancing the following:
– Service and application stability and reliability
– Team delivery and processes
– Quality, both in code and user perception
To achieve this, spend a few weeks talking with colleagues to understand responsibilities and identify inefficiencies. Look into slow releases, large tickets, customer complaints, feature requests, delivery delays, custom work, or recurring bugs.
Next, determine the root causes and consider how you can simplify, improve, or resolve these issues. Identify opportunities for automation to free up human capital for value-driven tasks, and find ways to remove roadblocks for the team. Take ownership of processes, coordinate efforts, and iterate on solutions.
Be prepared to demonstrate your approach and help others see the benefits, but also accept that some ideas may be rejected. Learn from both successes and setbacks, and remember that change is challenging for everyone, including yourself.
That sounds like a solid plan. When I try to dig deeper into a specific area or problem, I often uncover more questions, and there’s no one I know who can provide answers. Usually, I end up leaving things as they are after a while.
I’d like to try the approach you’ve described, but I’m unsure how to handle resistance when driving change without support.
Demonstrate your ideas through action. Build support by delivering work that makes stakeholders recognize clear improvements.
In software, proof of concepts can be valuable—they don’t need to be perfect. However, if you’re proposing an alternative to an established process, focus on creating a deliverable that provides immediate business value.
Review the code history to understand the original purpose of the feature and whether it was driven by customer needs or other factors. Implement metrics to track its usage and add logging to analyze how it is being used.
To grow into a senior role, start by asking product teams direct questions. If they don’t provide clear answers, dig deeper to uncover them. Request to join customer calls, speak with support, and find opportunities to engage directly with customers.