A few months ago, I lost my job as an engineering manager. I was officially told that I was being let go because my team didn’t think I gave good enough feedback and because they didn’t think I had enough technical understanding of the team’s work. Ironically, I got no feedback on this until the day I was being let go, and my performance review from 6 months before had mostly positive. I have told myself that most of the real reason that I was let go was probably the company trying to save money. There was a general push within the company to raise expectations and to not let good enough be good enough, and two engineering teams (neither mine) had recently been combined, leaving an extra manager. But, my confidence still took a big hit, because I’d been under the impression that my team thought well of me and my management. I got mixed messages on the way out the door with my own manager harping on all my shortcomings and my team telling me how much I'd helped them.
In my job search, I could have afforded to take time finding a new job. But, I threw myself into doing it quickly, both to eliminate the uncertainty and to prove to myself that I wasn’t useless. That was probably a mistake. After two months of searching, I got an offer and decided to take it. I wasn’t super excited about the company. The hiring process felt impersonal. But, the recruiter said they were excited about me, the pay was good, and I wanted to be done looking.
A brief history on me: I spent 16 years as an individual contributor. I started out in full stack web dev, moved to iOS dev for a few years, and moved back to web dev for a few years before moving to management. I've never had much interest in designing large systems or introducing new technologies. I like to build stuff and solve problems, and I care less than some engineers about how elegantly it's built. Before moving to management, I held scrum master roles on teams, but never tech lead roles. Shortly before moving to management, I got a promotion to staff engineer, but that was mostly in recognition of my non-technical leadership work. I was told I couldn't be a manager at that company because I wasn't technical enough. I've been a manager for 3 years total. My first management job was leading a team of front end engineers, my second (the one I lost) was leading a team of full stack engineers with a strong focus on the front end.
It's probably worth noting that I am female, and I have heard a few times that I am not technically strong enough to do certain things. Despite believing that I'm smart and good at understanding complex topics, I believe I internalized the idea that others are better at me at architecture without seeing potential bias behind it. But, at this point, I don't know what I'm unskilled at from lack of exposure and genuine lack of interest and what I'm unskilled at out of fear of being bad at something.
My current company does a lot of backend work and uses a serverless architecture. I have a decent understanding of backend, but I've never worked at a place with a serverless architecture and I barely understand the term. In the hiring process, there was a screen that consisted of multiple choice questions about AWS, which I don't really know. I felt like I was taking a test in a foreign language. But, when I later told the recruiter that I found that section tough, the recruiter told me that I got a top score. There was also a system design question that I think I did well with simply because I've studied system design questions. I've never actually designed systems a distributed system. All of this makes me think I may have interviewed well above my actual abilities. I've always been very good at taking tests. I recently saw a hiring panel where people chose to reject an engineering manager candidate because they're technical skills weren't strong enough. Someone made the comment that they wanted all of their engineers to be capable of acting as staff level engineers. I don't think I'm at that level.
To make matters worth, there's a lot of pressure on my technical leadership skills right now. I have a team that does a lot of manual work to make up for the fact that the systems it supports were never fully built out. Before I joined, the team had 4 people, but two had been lent to other teams for other projects. So, it was essentially 2 engineers, and one of those was beyond burnt out. One of the engineers who was supposed to rejoin the team was fired right after I started because he was stubborn and hard to work with. The other engineer was brought back to the team at that point. But, when the burnt out guy quit a couple weeks later, I was back down to 2 engineers. The two remaining engineers are a junior engineer who has been at the company (and in the working world) for about a year and a senior engineer who has been at the company for less than 6 months. We clearly need to build systems to replace the manual work, and people are looking to me to start planning what those systems are going to look like. But, I've been here for about a month, and I don't think I have the skills or the context to do that.
I have tried asking if I can get an engineer from another team. But, everyone is stretched thin. We're getting some help from a principal engineer, but it's only temporary, and he's on vacation. We're hiring for my team, and there are two offers out to senior engineers. But, it's going to take some time to onboard them. I've also yet to meet them, because that's not how our hiring process works. I have seen the interview notes, and they're positive. But, I'm uneasy about not knowing these people.
I don't think anyone would blame me if I just quit. But, I don't really want to go back to job searching right now. I also wonder if this might be a chance to build skills I've been lacking.
But, I really worry about doing a terrible job of it and getting fired. I've seen two people fired in my first month. One was the aforementioned engineer. In the brief time I knew him, I saw enough to think letting him go might have been a good decision. But, I am fairly certain the firing took him by surprise, and I don't know if that was his arrogance or poor communication from his previous management. I also saw someone in product who'd been supporting my team let go. I didn't know the person well, but all of my interactions with them were positive and they seemed like a good ally. I have no idea why they were let go, and I worry that the things I saw them doing that seemed positive were things others thought were a problem.
One of the interview questions the company asks managers is about handling a very productive, but toxic engineer who refuses to change. I've seen the rubric, and the only acceptable answer is to let him go. I wouldn't be here had I not expressed a willingness to let go of someone who was being toxic. But, it leaves me wondering if this is a company that is a little too trigger happy. The rubric doesn't cover whether or not a manager can judge if someone is really a problem or give them feedback to help them improve. My manager hasn't given me feedback, good or bad. I could be next and not know it yet. I know I should probably ask my manager for feedback, but I'm afraid that if I have a frank conversation with him, I'll let on how unprepared I feel and get myself fired sooner rather than later.
I'm having a hard time caring about this job and summoning the motivation to try to do what I need to help turn things around. Do I need to just get back out there and find something else, or do I need to find the motivation to lean in and give it my best shot? Any other suggestions?
First of all, thank you for sharing all of this. If more people shared difficult management challenges like this, we would all feel a little bit less like imposters.
The situation you describe isn't uncommon. I think most of us have had a stint in a shop or at least a period where we are asked to perform miracles. We are tasked with this with such confidence that it feels like we aren't up to it. This isn't true. The reason we are asked to perform miracles is because technology is miraculous for most people and the difference between an easy and an impossible project is completely opaque.
Now let me be clear. If you are having a bad time at your job, you should leave. Life is too short to stay with places and people of torture if you can afford not to.
But, if you are willing to give it a shot here's my assessment. The story you're sketching sounds like a turbulent time where the business is growing rapidly and/or has lost Engineering leadership. Engineering leadership is needed to to have realistic projects. If your job is to perform miracles, you will fail every time. What you can do is able to communicate realistic limitations to your stakeholders and negotiate consensus on what can be achieved. You need to create a situation where the business can sacrifice a 20% chance of taking 5 steps forward this quarter for a guarantee of taking a single step. A business that can't see the value in that is dead in the water anyway.
The engineers on the other side, need to have their priorities cleared and set. You need to recognise premature optimisation, hobby projects and resume fluff and put an end to them.
This has nothing to do with Amazon lambda and everything to do with communicating arguments effectively, creating relationships of trust with stakeholders and developers.
I won't lie. This role will cause alot of friction, but it sounds like the business has no one to tap on the breaks. In the end the real miracle would be to turn the boat around and have some predictability in the workplace.
I really appreciate your thoughts on this.
I am having trouble deciding if this place is a bad fit for me or if I just came in at a terrible time and it will eventually be an okay job. I expect jobs to come with a honeymoon period where I can be excited about what's going, and this one did not. I was given almost no onboarding direction for the first few days, then it just started being one new setback after another. I'm feeling very alone. Technically, people have offered to help however they can. But, it's all on me to figure out what to ask for and about.
This is definitely a turbulent time where the company is trying to grow rapidly. As far as I know, there's been no loss of engineering leadership company-wide. But, there's been a lot of shifting people around to fill holes as new teams are created, and I'm dealing with some of the holes that left.
I am really unclear the specific expectations of me and my team. The product owner who joined my team a month before me was in the middle of planning for Q3 when my team started losing people. She readily agreed that most of the work we had planned would need to be slashed in light of the changes, and she was supportive of prioritizing work that can reduce the team's manual workload. But, I'm less sure of the stakeholders beyond her. Her boss was supportive, but he was one of the folks who's been fired. I think we'll be able to hit our Q3 goals if we don't lose another engineer. But, I don't know the systems well enough to be confident on that, and I can't say we won't lose another engineer.
As far as I can tell, the big thing that steals time from my engineers is a constant stream of client requests. Some are requests for data. Some are trouble shooting requests. Some are questions about how the system works. Some are setup requests. I've been working to make sure all of this work gets captured into tickets and triaged by myself or the product person to reduce interrupts. A lot of this happened via DMs for too long, so we need time collecting data to figure out the biggest time sinks to figure out where to focus our improvement efforts. Then, the challenge is going to be estimating the time it takes to do the work that will take us out of the loop. At a high level, the path forward seems pretty clear. But, I definitely worry about the part where I need to figure out how much effort the work that cuts my team out of the loop is. In past management jobs, I've been able to lean on a tech lead to help me figure out what to build and how much work it's going to take. This time, it's looking like that's going to be my job, and that scares me a lot.
I totally understand. It sounds like you've been put in a frightening spot. These transitions really hard enough to do for established managers that have worked at a company for a while, let alone for a fresh hire. It sounds to me like you are doing all the right things: putting tasks into systems and managing expectations.
A growing organization is used to moving fast and when you reach a certain size, you start spinning wheels. Very rarely do companies stay ahead of the curve and setup systems before they hit that wall. You are in the unfortunate position of having to slam the breaks.
Often a company needs an outsider influence to be able to do that. The old guard is used to going fast and haven't developed the tools to go far yet. To me, it sounds like you are doing exactly that. Accept that there will be friction. The new company will work for different personalities. The people that take you from 5-50 are going to be completely different that take you from 50-500. You will lose people in this transition and all you can do is keep a steady course and communicate realistic expectations to stakeholders.
Something that helped me a ton during a turbulent time was implementing patrols. Now, I was lucky to be granted a lot of freedom to implement process changes. But it did really help us to minimize all the small tasks and distractions that kept coming up. Regardless of what tools you use, those little in-betweeners are by far the cause of most overhead. They never really take less than an hour to complete and they are constantly taking an engineer out of the working memory for a complicated task. Also, people love doing them, because you get a small accomplishment every few hours. It's much more difficult to sit with a long project for weeks without much progress, but it's easy to pickup low-hanging fruit. You're doing well to eliminate those.
When it comes to a billion client requests, a bit of requirement engineering goes a long way. Go through the requests and try to understand the root of the problem they are trying to solve. Propose a projects around solving that problem and eliminate all the chatter while your team can focus. If the requirements for that project change too much, then that means the chatter is even more wasteful and needs to be eliminated. A smart business will recognize this.
As for expectations. Yeah, it sounds like it's up to you te set expectations for you and your team. Stakeholders don't have preset expectations and often look at you to set the standard. You want to bring clarity to the table. You want to have the difficult conversation about responsibility and accountability. Again, none of that has much to do with databases and virtual machines.
Ooh, patrols look like an interesting idea. I'll have to keep that approach in mind. There are some expectations that my team use sprints in the sense that I need to report on what we've accomplished every 2 weeks and what we're planning to do in the next 2 weeks on a regular cadence. But, until someone tells me different, I'm assuming that I can run things however I like so long as I keep up the reporting.
I appreciate all the ideas in general, it gives me a lot to think on and provides a reminder that there are plenty of things that I can work on improving that have nothing to do with the tech specifics like databases and such.
But, I've got to admit that I'm still worried about missing technical details. When he was letting me go, my last manager recalled every time my team had failed to consider a non-functional technical requirement and put the blame for that on me. When those things had been missed, I had taken ownership and resolved to make checklists that would catch similar things in the future, and I had thought that was as much as I could do. All I ask of software engineers on my team is that they do their best and work to avoid making the same mistakes twice. But, I'm learning that even if a company hires me for espousing that view, that doesn't mean they'll treat me the same way. I worry that managers are expected to do something more and that I'm just not cut out for that.
It sounds like you are already doing a great job and taking the right steps. The challenges you are facing aren't uncommon.
When it comes to non-functionals (response times, scaling, security, cost, update speed), you need to quantify them. Bring the stakeholders and your team together and set standards. If stakeholders have unrealistic requirements, this gives the team a chance to negotiate. If your team repeatedly fails to meet the standards they agreed upon, you have a more difficult conversation.
As an engineering manager, your job shouldn't be to know everything and predict the future. Your job is to use your technical intuition to create clarity and keep people accountable. Manage expectations and filter out the bunk between business and technology.
I hope you are doing well, it sounds like you are in a tough spot, but you can recognize it :) It's important to remember that it's possible your employer has unrealistic expectations of your role. Then you should talk to them about it. Expectations can be managed. If that is also not possible, it's okay to look for a better place. We don't have the time on this earth to take the heat for things we can't control.