Archive
My Path To Engineering Manager
Often, a manager role is a “reward” for competency or natural leadership ability. Some will actively seek it out; others actively avoid it; and others just organically end up there, often by business need or an absence of leadership in their space. I fall in the latter category; I’ve never been one to seek out promotion or differing roles, as my goal is always to make the best decisions I can at the time they need to be made. One might say I could have pressed my career further, but I am fairly self-aware and have a pretty solid handle on what I need to be the best version of my professional self regardless of the role I happen to inhabit at any particular time.
My initial management role was in retail. At the age of 19 I was promoted to an Area Manager at the local Bradlees department store in Keene, New Hampshire, where I was working after graduating high school. I’d been there almost three years at that point, having joined just before my junior year. That experience informs a lot more of my viewpoint than you might expect. I was young, not the most mature, and was promoted over several of my peers. That was the most difficult part, to be honest…trying to lead people who the day before had been people you treated as peers and friends. That led to a lot of difficult conversations, a tough adjustment period, and changes to my social circle, including changes in the dynamic of my larger friend group. It often put my role as a friend and young adult in direct conflict with my new professional responsibilities. Not something I’d recommend, even to this day, although I did help transition a direct report from IC to manager in that exact situation. Eventually I left that position and role.
Several years into my technical career I was a Chief Architect for Marketplace Verticals at LoopNet. We were a small team of about six. My manager, who I had a great relationship with, decided that we should try out the new Scrum and Agile methodologies and strongly suggested the role of Scrum Master should fall to me. Little did I know he was positioning me to take on more leadership for the team, as he was considering taken other roles within LoopNet. Eventually he did decide to move on to a different role, and I was given a probationary period to lead the team ahead of a role shift to Technical Manager.
I refer to this as “being dragged into management against my will.” I didn’t choose this path; I didn’t seek out management roles; yes, I was a natural technical leader, but that’s definitely not the same thing. Later in my career, many Individual Contributors (ICs) came to me to ask my advice on whether they should move into management or not. The Kindle teams frequently shifted engineers to manager roles in the same way that I had, at times with little regard for the engineer’s best interests. Each time I would ask the IC why they wanted to become a manager, as often in cases like this, the person changing roles doesn’t know why, and doesn’t understand the depth of the difference in the roles. The most common answer I got was that the person shifting wanted to have more control over outcomes and more say so on what was happening on the team. I would often tell them that that was not a good reason, as managers don’t have any control; they can really only influence the quality of the behavior and decision making. Yes they can give “direction”, but at the end of the day the key to successful managers is their ability to look around corners, properly manage technical decisions and disagreements, earn a high degree of trust, become excellent communicators, effectively set expectations, and effectively coach their team. Control tends to not be a thing.
My role at LoopNet eventually ended at Senior Technical Manager with a team of 13. I then took a bit of a break to determine next steps, and ended up at Amazon as a Software Engineering Manager. Much of what I learned about being an effective manager came from that experience; at the time, Amazon’s Leadership Principles were still a primary input into culture, and they blended well with my natural leadership abilities. In particular, Ownership and Customer Obsession resonated with me, and without having to code in addition to my management responsibilities, I was able to develop to the level that I was part of the group training new SEMs as they joined Amazon.
Occasionally I wonder what would have happened if I’d stayed an IC. I’ve never lost the drive to create; I still leverage it in my music projects and at times my own technical projects at home. But I do think that my experiences since LoopNet, at Amazon and now at Atlassian, have shown me that I have much to offer in the way of guidance to the teams that I manage, so in a sense, I’m now building people rather than software, and many days that’s just as rewarding if not more.
Emotional Reflections – Job Search 2025
In March of 2025 I decided to switch teams at Amazon. I had been successful on both the Kindle and Partner Network teams, spending more than three years in each organization. I wanted to see what I could do if I had the chance to build something from the ground up. It was risky, to be sure, a new organization, a new manager, a new director, and a new team focus. Sadly, for various reasons, reorganizations led to the new director departing, and business challenges stifled our engineering plans. With no clear team charter as a result, I was impacted as part of the Amazon layoffs in October 2025.
I mention the circumstances because it’s important context for the emotions that follow. I was definitely not surprised it happened, and I had in fact cleaned out my desk the Friday before. Amazon has changed over the last several years, and not in a good way. It’s very Day 2 now, and in many cases toxic leadership-driven organizational cultures are rewarded even as those leaders poorly model Amazon’s Leadership Principles. I’ve learned a lot and enjoyed my time as an Amazonian, and am grateful for all of the colleagues I worked with. But in my opinion, the company culture has drifted off course internally. I’m sure that’s not a surprise to anyone paying attention to prevailing public opinion as of today.
So, while I was not surprised at the outcome, I was unhappy that a proven track record of success at such a challenging tech company could be pushed aside because of circumstances. I would still have made the same decisions at the time I made them, because they were the right ones when they were made. But I do admit I was very frustrated that despite my time of successful delivery and execution I still found myself in this situation for reasons outside of my control. And I did wonder what would have happened if I had not decided to change teams, even apologizing to my wife at one point for the outcome of that decision.
It was difficult telling my children it had happened. Even though they are both near adulthood, at 18 and 17, it’s still hard for them to understand the magnitude of the situation, especially when I am a rational thinker and I very rarely let my concerns show. I told them my full time job was now finding my next opportunity, and that that was what they would be seeing me do until I was successful. It’s important to model the right mental approach, and one of my strengths has always been clarity during a crisis. And this qualified, even if to them it felt like it was just “Dad needs to find a new job.”
All that said, I wanted to reflect on my reactions to these experiences as I’ve navigated my job search to what is a satisfactory conclusion, as I’ve happily joined Atlassian.
Initial Reactions
There is a general consensus that someone shouldn’t “spray resumes” out at any job postings once a layoff occurs. I’m going to disagree. From a tactical standpoint, this makes some sense. But from an emotional standpoint, I felt the act of doing something was cathartic and helped me maintain my focus during a difficult time. Emotionally, I wanted to take action. Emotionally, I didn’t want to miss out on a potentially great opportunity that maybe didn’t entirely align with my overall background. And from a “well let’s see what the world thinks of me” standpoint at a time where I was basically being told I was no longer needed, I did a lot of applying above my current level, for director positions and even some executive positions.
I got two positives out of this “spray resumes” strategy. The first is, I was able to feel like I was making progress as a few applications garnered interviews. The second is, I was able to take time and figure out how I wanted to rebuild my resume, but not feel like I was being forced to do that rebuilding under duress. Eventually I did cut back on the amount of resumes I was submitting, but I still took some shots at positions above my level, and still would apply to places that looked interesting even if I wasn’t a perfect fit.
I think cutting back entirely to only applying for very specific positions risks missing out on positions that might not have been the best fit, but that I would be excited about. It’s difficult to predict at any time how my resume might be received by a hiring manager.
The other thing that I did, and it was a mixture of tactical and emotional response, was to investigate the possibility of going back and getting my Master’s degree at my alma mater, WGU. There was one prerequisite class I needed to enroll in a Master’s program, so I took time to complete that course in between job searches. At times I regretted taking the class as it consumed time, but I wasn’t sure if I was going to find a new role and wanted to set the stage for alternative options, even if those were long term options.
Amazing Support
The outpouring of support was unexpected and humbling. As a manager, often you don’t see the impact you have on people even if you have established a solid relationship. And a lot of times, your team members don’t have the context or the awareness to recognize what you do. I remember one time someone I had promoted to Senior Engineer two years prior messaged me to thank me for all the work I had put into their promotion; they had recently sat on a promotion panel for the first time and realized how much work went into it.
Several people wrote heart-felt recommendations on LinkedIn, and people who I hadn’t spoken to for years reached out to offer support, links to open positions, and referrals, one of which led to my offer at Atlassian. I sometimes have difficulty asking for support or putting myself out there online, but the overwhelming amount of people reaching out to check in on me was amazing, and gave me the confidence to reach out more than I might. Ordinarily I’m the one helping others. I am humbled to be receiving similar help myself from my colleagues and friends.
Maintaining Confidence
One thing a layoff does, is it messes with your confidence. An overloaded, fractured job market simply piles on. My success rate in getting an interview was about 7%. I consider that high based on public anecdotes, but to be honest, my experience is pretty lengthy and pretty deep. The number of positions I was perfectly qualified for and didn’t get a chance to interview with was high, and those rejections pile up.
I knew enough about the public discourse to know I needed to buckle down and concentrate on the successes, but it’s always in the back of your mind that this situation might not end well. I come from a non-traditional background; I was 15 years into my technical career before I got my degree. The imposter syndrome is real. And it undermines you. I’ve delivered at every stage of my career, and delivered projects at Amazon. Surely I can succeed elsewhere?
I made a number of choices to keep my confidence. One, I ignored the negativity and shrugged off automated rejections as mostly unimportant. Two, as I’ve mentioned in other posts, I doubled down on having my resume and cover letter reflect who I am way more than reflect what an ATS wants to see. That alone helped reestablish my confidence as I went through all of my accomplishments, and reminded myself of all the good things, and then saw my application responses increase. And three, I didn’t abandon my instincts or my principles.
Trusting My Instincts and Principles
Once the interviews started happening, and I was able to handle those conversations mostly well, I was able to rely on my instincts and principles as I continued through my search. I’ve already spoken about the poor phone screen experience that led me to withdraw from a position. In another case, which ended on a very friendly note, a company had decided that they were not going to move forward after the first of two coding interviews. When I asked for feedback on where I could improve, the company actually backtracked and decided they were willing to go forward as I was “close enough” to code competency for a management role. I spoke to the recruiter at length and realized that it was unlikely that the next step, a front-end focused second coding interview, would go any better. We’d be having the same “close enough” conversation again after that one. I really liked the company and felt I would be a good fit, but they have their technical bar, and that’s their prerogative. So I withdrew from that interview loop as well.
In another case, I could tell from instincts and conversations that one company wasn’t sure what they were after as far as role, but that I could have a big impact if I came in. I’d been through a full loop and then two conversations with a senior leader, and they were still undecided. I would likely have accepted an offer at that time, so I drew a bit of a line in the sand and sent a polite email to the recruiter asking what remained in the process because I’d be happy to accept an offer if they extended one. They removed me from consideration the next day.
The one thing I did not want to do was make a bad situation worse by accepting an offer for a role I could tell might not be the right outcome. So I trusted myself and tried to not make any sudden decisions.
The Coding Interviews
The coding interviews varied quite a bit. I recognized that I would need to try my hand at LeetCode style challenges, and started working through those while familiarizing myself with the new AI tools and reorienting myself within Visual Studio. Eventually as the interviews started to come up I abandoned my LeetCode experiment, as I only had so many hours in the day and had no idea what questions I was going to get, and so no way to prioritize problem types.
One thing I noticed is that while companies say they aren’t doing LeetCode style questions, they still are, they are just hiding them better. One company’s task was to finish implementations of a preexisting feature that was essentially building upon a depth first search algorithm, even though it was more of a game-like presentation.
While these were the more fear-inducing parts of the process, I feel I did well in each one. I never felt like I was truly failing any of them, and after making it through the first one reasonably well, I was able to put the fear and uncertainty aside and ground myself in putting forth my best effort, trusting my ability to problem-solve, and leveraging my communication as much as possible. In particular, I felt that talking out loud at every step of the process in a coding interview, including articulating why I would stop to think, helped to keep me calm, while also allowing the interviewer a bit of a look into my thought process around trade-offs and other factors.
I am grateful my ability to focus enabled me to present myself in a reasonably confident way as I kicked off 7 years of programmer rust.
The System Design Interviews
The system design interviews also varied, but I felt I did better with these. In one case, an interview for a team that owned centralized product APIs, I basically sketched out a design that matched what their general plan was to coalesce their APIs. Historically back-end and systems has been my strength; when I interviewed for Amazon the design question I was asked revolved around being able to predict when an order of bananas could be delivered, and at the end of my walk-through of that plan, involving ordering systems, delivery scheduling, and a bunch of other things, the interviewer basically acknowledged that I had nailed what they did already.
Surprisingly, the toughest interview ended up being one of the system design interviews. It’s the only one I came out of feeling like I did not do well. I’ll own the fact that I probably didn’t do a good enough job at the time of getting deeper into requirements. That said, this question was another LeetCode problem dressed up as a design, where the only correct answer was implementation of a breadth search data structure. In addition, I think linearly and holistically; often when I draw out component structures I intend to go back and make adjustments as I think through the larger problem. The interviewer interrupted at every step of the way if one of my components wasn’t completely done before moving on to the next one, and threw my thinking off. I can see the point, each component should stand on its own. But if I’m building a system looking at it from a high level first before digging into details should be a reasonable approach if I want to make sure I am thinking about the problem correctly. This interview was a clear misalignment between my perspective of the level of the question and the depth the interviewer was seeking, and was the only time I felt myself start to overthink and lose my focus.
Final Thoughts
This was a challenging time, with a lot of uncertainty and a lot of uneasiness. It can be hard to remember who you are, and it can be very isolating. Control is illusory, usually in a negative way. In this case, though, things I had no control over ended up having a positive impact on my search. Anger and self-doubt do creep in, but they aren’t productive except maybe as motivation. I was able to wrangle those emotions and put my best foot forward in the face of difficult circumstances.
The Importance Of Mentorship
Mentorship has been a key part my ability to influence beyond my team, in particular during my time at Amazon. I spent a lot of my time at Amazon giving back, either through coaching peers in document writing, helping to train inbound engineering managers, or helping new Amazonians navigate getting things done. I’ve developed a perspective about mentorship, both from being a mentor, as well as finding a mentor. When I was an engineer, I always found time to help others, including spending lunch breaks helping a QA engineer learn how to automate testing. I think there’s always value in learning as well as teaching.
Finding a Mentor
I have a distinct perspective on the timing of finding a mentor, and what I seek to gain from the relationship. For a person to gain value from having a mentor, that person needs to have some level of clarity around what they are looking to learn. Finding a mentor without having some purpose for the relationship, in my opinion, is non-productive and will ultimately not succeed if a purpose is not defined. In addition to that clarity, the mentee needs to own the topics, the conversations, and the choice to continue or not. It’s important to choose the right mentor for the topics at hand, and without that clarity, choosing a mentor can be difficult, and runs the risk of finding a less than suitable collaborator.
I’ve sought mentors a few times in my career. At each point, I had very specific things I wanted to work on. To my point above, it didn’t make much sense for me to sit in a conversation with a mentor without some idea of what I wanted to accomplish. Early in my time at Amazon, I felt that I needed to improve some of my leadership skills as my teams grew larger in size. When I decided I needed someone to talk to about this, I could have sought out another engineering manager, but that wasn’t what I was really after. I didn’t necessarily want to talk to someone in the same role I was.
Instead, I sought out a leader one level up from me who had experience managing associates in Amazon fulfillment centers. I was very specific about the types of issues I wanted to talk through, and felt that the team scale this person had experienced would have a better perspective than someone in a similar role as myself. I spent close to 5 months working with this mentor until I felt like I had absorbed and internalized what they could teach me. At the end of that time period I moved on.
And that’s another important point. Mentors are not forever. They can be, but they don’t have to be, and mentors won’t take it personally if a mentee decides it’s time to move on. I’ve encountered people who don’t want to commit to a mentor because they feel it’s a one-way door. That’s not typically how it works; either of those involved can choose to stop, and it won’t be taken personally.
And if I don’t have anything specific I am working on, I am fine not having a mentor for a while.
Being A Mentor
I played golf in on my high school golf team and quite often in my early 20s. I wasn’t bad; I could shoot low 90s consistently if I played often and putted well. I was able to play well enough that playing was more fun than frustrating. One summer, though, a friend of mine wanted to learn how to play but was having trouble making consistent contact. Over a couple of weeks, I took his swing apart and helped him put it back together, getting his weight back in his stance, making sure his head was still, and keeping his right elbow tucked in.
I shot in the high 80s the rest of that summer and into the next year. By teaching him how to get his swing together, I inadvertently fixed a few flaws in mine and my game improved dramatically.
And that’s one of the hidden powers of mentorship. You learn so much yourself by teaching someone else.
I once managed an engineer trying to get promoted to the next level. They were on a team surrounded by more senior engineers, and had reached a point where they were starting to level off, despite being a very effective front end engineer while steadily improving on back end work. At around this time, I inherited a team that was entirely back end engineers, facing a project with a lot of front end work. I moved my aspiring engineer to the back end team, and instructed them that they were now the subject matter expert, and their job was to teach this back end team how to become effective, if not excellent, front end engineers. That engineer thrived being put in a position to advise more senior engineers on unfamiliar technology, helped to deliver a complex project, and secured their promotion later that year.
Often people are concerned that they are not skilled enough to be a mentor, or don’t know enough to give advice. But in deciding not to be a mentor, they actually miss opportunities to learn so much themselves, and miss opportunities to improve a lot of non technical skills like communication and listening.
Anyone can be a mentor. All you need is a perspective, a willingness to listen, and a willingness to share.
Final Thoughts
Don’t discount the benefits of being a mentor in whatever capacity you can be. It’s a great way to learn, to teach, and to have an impact beyond just what you yourself produce. It’s a great first step to becoming a force multiplier, someone who makes the team around them better.
From there, you can take steps like I did, where I took on several different Bar Raiser roles at Amazon, and look for ways to generate impact well beyond your normal day to day.
And whenever you feel like you want to improve something, take the step and find the right mentor to help you with that particular challenge. It’s worth the effort.
Be welcome and true.
Rob Hope 