Junior engineer needing help growing
August 1, 2020 11:04 PM Subscribe
I'm a junior engineer trying to grow into a senior engineer. There are non-technical aspects of this process that I'm not handling well. I don't have anyone in my life to discuss this with, I'm hoping folks from the green can give me some advice.
Some background (not sure if relevant but wanted to be complete): I'm a woman, POC. I work as a junior engineer at a large well-known tech company.
My goal for this question is to understand better what it means for a junior engineer to grow into a senior engineer, to assess where I am lacking, and to find some resources to help me get there.
I apologize in advance for the rambling question, I guess it's quite clear I'm lost and not sure what I'm doing wrong.
I've worked at my current company for 3.5 years, and throughout that time I've gotten above average reviews for my technical work. My manager has consistently given me feedback that I'm technically strong, can find good solutions to hard problems, and am a valued member of the team. He has also consistently told me that my "vision" is not enough, that I need to think longer term, and that I need to have more direction for my work if I'm to grow to be a senior engineer.
The problem is that I don't know what he means, and many meetings with him have only confused me further. My understanding (and it could very well be wrong) is that he wants me to align better my projects with the team, and to ask more questions about why we do things instead of simply planning a technical execution to the things we are being asked to deliver.
I have asked for growth opportunities and I think my manager is trying to help. I am being put into meetings with more senior people, but I don't know the point of these meetings. These are typically meetings with senior technical people and some non-technical people. They seem to have context that I lack because I am always confused and can never predict where the conversation will go. As a result I'm not comfortable speaking up and stay silent the whole meeting. It feels pointless and frustrating for me to be there, I don't think I'm adding value and I don't get much out of these meetings. I suppose the information is useful, to see what everyone else is thinking, but I don't know what I'm expected to do with this information. I suspect I'm being put into these meetings to push the "agenda" of our team forward, and to "play the politics game" as it were, but it's really not clear to me how I'm suppose to do this and when to speak up and when to push back. I guess some people naturally "get" things like this but this is not me and I find it an incredibly confusing experience. During these meetings whenever I do speak up what I say are barely addressed (or are politely acknowledged and not engaged with) and the conversation moves forward. I can't tell if I'm saying something uninteresting or not appropriate for the context. Moreover someone more senior from our team is usually there, so I feel like I'm just a redundant person at these meetings. And what time I'm spending at these meetings I'm not spending doing actual work, and is causing me to be behind and stressed.
Another aspect that I think is related, is that I'm being asked to put forth plans for my work (perhaps an encouragement to think more "long term"?). The nature of my work is such that there are dependencies and earlier steps will hugely influence the later steps (I don't think this is unusual in any substantial long term project?). So from my point of view any planning with either be stating the obvious (phase 1, we do X) or so vague as to be useless (if in phase 1 the result is X and in phase 2 the result is Y, ..., then in phase 10 we do Z). My boss's advice was "think what state we want to be in in 2 years and work backwards" - which makes sense to me, but if any number of the 10 things from now until then can go wrong, then why bother? Is the point to just put forth something reasonable, that people won't argue with?
I am here asking for help on how to improve on all of this *waves hands*. If say there is a technical matter that I don't understand, it's simple for me to look up the relevant information, or documentation, or find the SME and ask the right questions. On that aspect I can get up to speed quite fast. But the non-technical aspect is really tripping me up. I feel like I'm stuck and can't move forward. I can tell that my boss is expecting more from me, but he is not able to articulate any concrete feedback and is telling me that part of growing to a senior engineer is figuring this all out myself.
I'm hoping someone else has been where I am, and "got it" and is now on the other side, and can explain to me what I'm doing wrong. Do I have the wrong mindset? Are there skills I'm lacking? Am I not asking the right questions? How do I get better at this and grow to be a senior engineer?
Thanks for your help, appreciate any perspective you can give on this.
Some background (not sure if relevant but wanted to be complete): I'm a woman, POC. I work as a junior engineer at a large well-known tech company.
My goal for this question is to understand better what it means for a junior engineer to grow into a senior engineer, to assess where I am lacking, and to find some resources to help me get there.
I apologize in advance for the rambling question, I guess it's quite clear I'm lost and not sure what I'm doing wrong.
I've worked at my current company for 3.5 years, and throughout that time I've gotten above average reviews for my technical work. My manager has consistently given me feedback that I'm technically strong, can find good solutions to hard problems, and am a valued member of the team. He has also consistently told me that my "vision" is not enough, that I need to think longer term, and that I need to have more direction for my work if I'm to grow to be a senior engineer.
The problem is that I don't know what he means, and many meetings with him have only confused me further. My understanding (and it could very well be wrong) is that he wants me to align better my projects with the team, and to ask more questions about why we do things instead of simply planning a technical execution to the things we are being asked to deliver.
I have asked for growth opportunities and I think my manager is trying to help. I am being put into meetings with more senior people, but I don't know the point of these meetings. These are typically meetings with senior technical people and some non-technical people. They seem to have context that I lack because I am always confused and can never predict where the conversation will go. As a result I'm not comfortable speaking up and stay silent the whole meeting. It feels pointless and frustrating for me to be there, I don't think I'm adding value and I don't get much out of these meetings. I suppose the information is useful, to see what everyone else is thinking, but I don't know what I'm expected to do with this information. I suspect I'm being put into these meetings to push the "agenda" of our team forward, and to "play the politics game" as it were, but it's really not clear to me how I'm suppose to do this and when to speak up and when to push back. I guess some people naturally "get" things like this but this is not me and I find it an incredibly confusing experience. During these meetings whenever I do speak up what I say are barely addressed (or are politely acknowledged and not engaged with) and the conversation moves forward. I can't tell if I'm saying something uninteresting or not appropriate for the context. Moreover someone more senior from our team is usually there, so I feel like I'm just a redundant person at these meetings. And what time I'm spending at these meetings I'm not spending doing actual work, and is causing me to be behind and stressed.
Another aspect that I think is related, is that I'm being asked to put forth plans for my work (perhaps an encouragement to think more "long term"?). The nature of my work is such that there are dependencies and earlier steps will hugely influence the later steps (I don't think this is unusual in any substantial long term project?). So from my point of view any planning with either be stating the obvious (phase 1, we do X) or so vague as to be useless (if in phase 1 the result is X and in phase 2 the result is Y, ..., then in phase 10 we do Z). My boss's advice was "think what state we want to be in in 2 years and work backwards" - which makes sense to me, but if any number of the 10 things from now until then can go wrong, then why bother? Is the point to just put forth something reasonable, that people won't argue with?
I am here asking for help on how to improve on all of this *waves hands*. If say there is a technical matter that I don't understand, it's simple for me to look up the relevant information, or documentation, or find the SME and ask the right questions. On that aspect I can get up to speed quite fast. But the non-technical aspect is really tripping me up. I feel like I'm stuck and can't move forward. I can tell that my boss is expecting more from me, but he is not able to articulate any concrete feedback and is telling me that part of growing to a senior engineer is figuring this all out myself.
I'm hoping someone else has been where I am, and "got it" and is now on the other side, and can explain to me what I'm doing wrong. Do I have the wrong mindset? Are there skills I'm lacking? Am I not asking the right questions? How do I get better at this and grow to be a senior engineer?
Thanks for your help, appreciate any perspective you can give on this.
At a very high level, there are a couple of things it took me a while to realize about the transition from junior to mid-level to senior. The first is: junior people implement solutions, mid-level people come up with solutions, and senior people identify problems worth solving. You can see a version of this in this blog post.
The second is related to the idea that, as you progress, your job involves problems more than solutions: they're not kidding when they say "comfort with ambiguity" is a trait that senior engineers possess. I don't have a trick for acquiring this, but it's clear from some of the specifics of your question that you would benefit from it. It's different than mere confidence, but it's related. It includes things like thinking about long term prioritization and evaluating big risks, interaction with other teams, the marketplace/product context, etc. Making peace with imposter syndrome is also part of it.
Here are a couple of more concrete suggestions: first, have you looked at your company's engineering ladder? This is a document that describes, in very clear detail, the exact criteria used to assess whether you should move up to the next title. The one complication with this is that, typically, at the junior end, your promotion is handled by your own manager (or their manager), and they have a lot of discretion about how they interpret the ladder. At the higher end, promotions are handled by larger committees which (in theory at least) makes things fair (although in practice also makes things more political). My point is: tell your manager that you want to move up a level, and ask them to go through the ladder with you.
My other concrete suggestion is to take a look at the resources at StaffEng.com. "Staff" is a level above senior. It's useful to think about where you're headed in the longer term, and the resources there describe earlier stages of people's careers. Also take a look at What's a Senior Engineer's Job by Julia Evans and On Being A Senior Engineer by John Allspaw (both of which are in the resource links of StaffEng.com). And, since you're a woman and a POC, I want to flag up a failure mode that you unfortunately may find yourself pushed toward by *waves hands*: please watch the talk Being Glue.
On preview: the point that being a "team/tech lead" is difficult because you have no authority is absolutely correct. For that specific issue (which is in many ways a special case of the entire challenge of becoming more senior), I highly recommend that Team Lead chapter in The Manager's Path (if you don't want to be a manager you can stop after reading that chapter!)
posted by caek at 11:55 PM on August 1, 2020 [19 favorites]
The second is related to the idea that, as you progress, your job involves problems more than solutions: they're not kidding when they say "comfort with ambiguity" is a trait that senior engineers possess. I don't have a trick for acquiring this, but it's clear from some of the specifics of your question that you would benefit from it. It's different than mere confidence, but it's related. It includes things like thinking about long term prioritization and evaluating big risks, interaction with other teams, the marketplace/product context, etc. Making peace with imposter syndrome is also part of it.
Here are a couple of more concrete suggestions: first, have you looked at your company's engineering ladder? This is a document that describes, in very clear detail, the exact criteria used to assess whether you should move up to the next title. The one complication with this is that, typically, at the junior end, your promotion is handled by your own manager (or their manager), and they have a lot of discretion about how they interpret the ladder. At the higher end, promotions are handled by larger committees which (in theory at least) makes things fair (although in practice also makes things more political). My point is: tell your manager that you want to move up a level, and ask them to go through the ladder with you.
My other concrete suggestion is to take a look at the resources at StaffEng.com. "Staff" is a level above senior. It's useful to think about where you're headed in the longer term, and the resources there describe earlier stages of people's careers. Also take a look at What's a Senior Engineer's Job by Julia Evans and On Being A Senior Engineer by John Allspaw (both of which are in the resource links of StaffEng.com). And, since you're a woman and a POC, I want to flag up a failure mode that you unfortunately may find yourself pushed toward by *waves hands*: please watch the talk Being Glue.
On preview: the point that being a "team/tech lead" is difficult because you have no authority is absolutely correct. For that specific issue (which is in many ways a special case of the entire challenge of becoming more senior), I highly recommend that Team Lead chapter in The Manager's Path (if you don't want to be a manager you can stop after reading that chapter!)
posted by caek at 11:55 PM on August 1, 2020 [19 favorites]
As an IC you don't get to tell people to do as much as persuade them what the right thing to do is, or at least that's my interpretation as a senior IC.
One part of this is questioning, when you find that what you're doing is valuable but inefficient, what you did wrong. Not the 'here's a bug' sort of wrong, the 'why are we having so many bugs and is there a common thread here' sort of wrong. Also, come with a solution to hand. It doesn't have to be a perfect solution, and it's generally best to be open to alternatives, but it's the difference between being negative and being positive.
Another is questioning what you're doing. You have customers. What do they want? Have you talked to them? Can you see people doing things that are precisely what was asked for but not what is needed? Measure your solutions against the problem.
A third is sharing your skills. What can you do better than other people and what makes you wince every time you see it? Can you do anything about that? It might be training, it might be advocating, it might be changing processes (but to be honest people follow processes they see value in and curse processes that are seen as roadblocks, so even then it comes back to learning and advocating).
Finally, if you can't contribute, listen. Ask the occasional dumb question if you can get away with it. Everyone who learns starts out with no knowledge; the skill is in learning, not in already knowing.
Do those suggestions measure up against your role?
posted by How much is that froggie in the window at 12:34 AM on August 2, 2020 [5 favorites]
One part of this is questioning, when you find that what you're doing is valuable but inefficient, what you did wrong. Not the 'here's a bug' sort of wrong, the 'why are we having so many bugs and is there a common thread here' sort of wrong. Also, come with a solution to hand. It doesn't have to be a perfect solution, and it's generally best to be open to alternatives, but it's the difference between being negative and being positive.
Another is questioning what you're doing. You have customers. What do they want? Have you talked to them? Can you see people doing things that are precisely what was asked for but not what is needed? Measure your solutions against the problem.
A third is sharing your skills. What can you do better than other people and what makes you wince every time you see it? Can you do anything about that? It might be training, it might be advocating, it might be changing processes (but to be honest people follow processes they see value in and curse processes that are seen as roadblocks, so even then it comes back to learning and advocating).
Finally, if you can't contribute, listen. Ask the occasional dumb question if you can get away with it. Everyone who learns starts out with no knowledge; the skill is in learning, not in already knowing.
Do those suggestions measure up against your role?
posted by How much is that froggie in the window at 12:34 AM on August 2, 2020 [5 favorites]
I would definitely look hard for any coworkers you can find who are "senior" and are women or POC or both, because their perspective could be important.
Erasing the gender and racial effects, I think it is generally true that "senior" = "discovers what need to be done". "but I don't know the point of these meetings" -> does anyone really? What actually, for whatever your company does, should happen?
(What I see, actually, is that a perhaps-surprisingly large number of people can accurately tell you what the company ought to be doing, but most of them for reasons of hierarchy or sex or race or any other reason are not being heard. It's remarkable how much efficiency our prevailing system is willing to sacrifice to maintain the status quo. Navigating this for your own career is deeply tricky and you need local advice.)
posted by away for regrooving at 1:09 AM on August 2, 2020 [2 favorites]
Erasing the gender and racial effects, I think it is generally true that "senior" = "discovers what need to be done". "but I don't know the point of these meetings" -> does anyone really? What actually, for whatever your company does, should happen?
(What I see, actually, is that a perhaps-surprisingly large number of people can accurately tell you what the company ought to be doing, but most of them for reasons of hierarchy or sex or race or any other reason are not being heard. It's remarkable how much efficiency our prevailing system is willing to sacrifice to maintain the status quo. Navigating this for your own career is deeply tricky and you need local advice.)
posted by away for regrooving at 1:09 AM on August 2, 2020 [2 favorites]
On the meetings that you are at with another person in your team, are you being included there in a kind of apprenticeship model, to learn to do what that person does in those meetings? Can you debrief with them after?
posted by freethefeet at 1:38 AM on August 2, 2020 [4 favorites]
posted by freethefeet at 1:38 AM on August 2, 2020 [4 favorites]
My boss's advice was "think what state we want to be in in 2 years and work backwards" - which makes sense to me, but if any number of the 10 things from now until then can go wrong, then why bother?
This hugely jumped out at me.
Think of it this way: what if no one in the entire organization was thinking about where you all wanted to be in two years? How would anything at all get done? How would anything even get planned? What would you even be working on, if the very notion of planning wasn’t anybody’s job?
If any number of things could go wrong - well, what are those things? How might they go wrong? How might you address it if they did? You have to ask those questions - but the fact that those questions exist doesn’t mean “why bother.”
I am not an engineer but I used to be a grant manager, and “planning for where we want to be in two years despite massive uncertainty” is the entire job. It’s also the reason I no longer do that job, because personally I don’t thrive in environments like that. But many of my coworkers did.
posted by showbiz_liz at 5:05 AM on August 2, 2020 [7 favorites]
This hugely jumped out at me.
Think of it this way: what if no one in the entire organization was thinking about where you all wanted to be in two years? How would anything at all get done? How would anything even get planned? What would you even be working on, if the very notion of planning wasn’t anybody’s job?
If any number of things could go wrong - well, what are those things? How might they go wrong? How might you address it if they did? You have to ask those questions - but the fact that those questions exist doesn’t mean “why bother.”
I am not an engineer but I used to be a grant manager, and “planning for where we want to be in two years despite massive uncertainty” is the entire job. It’s also the reason I no longer do that job, because personally I don’t thrive in environments like that. But many of my coworkers did.
posted by showbiz_liz at 5:05 AM on August 2, 2020 [7 favorites]
Just to address one tiny element of this:
I'm a woman, POC.
...
During these meetings whenever I do speak up what I say are barely addressed (or are politely acknowledged and not engaged with) and the conversation moves forward.
These two things may be related, in a way that is totally not your fault. If you’re in a predominantly white, male profession, and you’re also younger than the rest of them, there’s a more-than-zero chance that they’re unconsciously in the habit of dismissing the things you say as lightweight, irrelevant, not giving you due attention, because you don’t fit their mould of what a serious, accomplished engineer looks and sounds like.
There can also be something viscerally difficult about inserting your voice into a soundscape where everybody else’s voice sounds different to yours, IME (ie. deeper and louder, if they’re mostly men). It’s like you’re literally on different wavelengths and connecting effortlessly with the flow of the meeting is hard.
Sounds like you’re aware of other, wider problems that also exist, but I just wanted to flag up that some of this may be structural and entirely not your fault/not because you’re failing to understand or contribute appropriately. People who know they’re being taken seriously and have a voice have a huge advantage in confidence, which in turn makes others take them more seriously, and so on. It’s a vicious circle if you’re shut out of that.
The idea of a female, POC mentor floated above sounds like a good one.
posted by penguin pie at 5:30 AM on August 2, 2020 [2 favorites]
I'm a woman, POC.
...
During these meetings whenever I do speak up what I say are barely addressed (or are politely acknowledged and not engaged with) and the conversation moves forward.
These two things may be related, in a way that is totally not your fault. If you’re in a predominantly white, male profession, and you’re also younger than the rest of them, there’s a more-than-zero chance that they’re unconsciously in the habit of dismissing the things you say as lightweight, irrelevant, not giving you due attention, because you don’t fit their mould of what a serious, accomplished engineer looks and sounds like.
There can also be something viscerally difficult about inserting your voice into a soundscape where everybody else’s voice sounds different to yours, IME (ie. deeper and louder, if they’re mostly men). It’s like you’re literally on different wavelengths and connecting effortlessly with the flow of the meeting is hard.
Sounds like you’re aware of other, wider problems that also exist, but I just wanted to flag up that some of this may be structural and entirely not your fault/not because you’re failing to understand or contribute appropriately. People who know they’re being taken seriously and have a voice have a huge advantage in confidence, which in turn makes others take them more seriously, and so on. It’s a vicious circle if you’re shut out of that.
The idea of a female, POC mentor floated above sounds like a good one.
posted by penguin pie at 5:30 AM on August 2, 2020 [2 favorites]
Like showbiz_liz this jumped out at me:
My boss's advice was "think what state we want to be in in 2 years and work backwards" - which makes sense to me, but if any number of the 10 things from now until then can go wrong, then why bother?
In the last few years of my career (I am an engineer, though do mostly PowerPoint engineering these days), I have realized that there are people who seem psychologically less secure when there is a plan. And there are people who have the opposite feeling. Here and here are a couple HBR articles about the phenomenon. You may want to take a look at those articles and see if those resonate. And think about the Eisenhower quote, to emphasize showbiz_liz's comments: Plans are worthless, but planning is everything.
Very often the point of a technical plan is to put something forward as a projection: this is where I think things will go. By thinking through that, you also identify the areas of risk: here is what I think will go wrong. And develop ways to mitigate the risk: here is what I can do if this does go wrong. This gives the higher-ups confidence that you understand the situation and can handle the unexpected.
There are entire disciplines in both hardware and software that focus on this sort of analysis, and tools to help with these processes. I'd suggest asking about risk assessment on projects as a way to start, and doing some reading on technical project planning. Your professional society of choice (IEEE, ASME, SME, etc.) should have some resources and courses available on this. Find them, tell your boss you would like to get better and get the company to pay. (Also, professional societies can be good places to find mentors!)
Second:
I suspect I'm being put into these meetings to push the "agenda" of our team forward, and to "play the politics game" as it were, but it's really not clear to me how I'm suppose to do this and when to speak up and when to push back.
Yeah. I was crap at this too. Best advice I can offer: find the people who are good at this, especially people like you (female, POC) and pay attention to what they do. You might not be able to do exactly what they do based on their personality, seniority, etc., but you'll start to notice patterns. Test these things on your own projects.
It is hard to give political advice that is universal other than this, as each company is different on what they value in politics. Some places all the real work happens behind the scenes, with nothing really happening in meetings. Other places it is about visible arguments. Other places it is two or three collaborators who really run the place. You'll need to pay close attention to get that context and understand what is really going on.
Finally:
EQ training. I know. You are saying yeah, yeah, yeah, whatever (I said that early in my career as well). But, seriously. I've done a selection of different programs and reading that are fundamentally this, starting early in my career. It has been soaking in slowly over the last 20 years. I wish I had taken it more seriously earlier on. A couple things I can recommend as a starting point are:
- How to Win Friends and Influence People -- A classic and my first introduction to what I was doing wrong. It is old and a bit hokey, but fundamentally looks at the right things.
- This Course on LinkedIn -- Part of a training we did at work on EQ recently. It gives good coverage and tools.
If you want to get to the next level and far beyond, getting good at these skills will have the biggest bang for the buck.
Finally, finally: feel free to MeMail me. I'd be happy to talk through more of my experience, answer questions, and point you toward other resources.
posted by chiefthe at 7:51 AM on August 2, 2020 [5 favorites]
My boss's advice was "think what state we want to be in in 2 years and work backwards" - which makes sense to me, but if any number of the 10 things from now until then can go wrong, then why bother?
In the last few years of my career (I am an engineer, though do mostly PowerPoint engineering these days), I have realized that there are people who seem psychologically less secure when there is a plan. And there are people who have the opposite feeling. Here and here are a couple HBR articles about the phenomenon. You may want to take a look at those articles and see if those resonate. And think about the Eisenhower quote, to emphasize showbiz_liz's comments: Plans are worthless, but planning is everything.
Very often the point of a technical plan is to put something forward as a projection: this is where I think things will go. By thinking through that, you also identify the areas of risk: here is what I think will go wrong. And develop ways to mitigate the risk: here is what I can do if this does go wrong. This gives the higher-ups confidence that you understand the situation and can handle the unexpected.
There are entire disciplines in both hardware and software that focus on this sort of analysis, and tools to help with these processes. I'd suggest asking about risk assessment on projects as a way to start, and doing some reading on technical project planning. Your professional society of choice (IEEE, ASME, SME, etc.) should have some resources and courses available on this. Find them, tell your boss you would like to get better and get the company to pay. (Also, professional societies can be good places to find mentors!)
Second:
I suspect I'm being put into these meetings to push the "agenda" of our team forward, and to "play the politics game" as it were, but it's really not clear to me how I'm suppose to do this and when to speak up and when to push back.
Yeah. I was crap at this too. Best advice I can offer: find the people who are good at this, especially people like you (female, POC) and pay attention to what they do. You might not be able to do exactly what they do based on their personality, seniority, etc., but you'll start to notice patterns. Test these things on your own projects.
It is hard to give political advice that is universal other than this, as each company is different on what they value in politics. Some places all the real work happens behind the scenes, with nothing really happening in meetings. Other places it is about visible arguments. Other places it is two or three collaborators who really run the place. You'll need to pay close attention to get that context and understand what is really going on.
Finally:
EQ training. I know. You are saying yeah, yeah, yeah, whatever (I said that early in my career as well). But, seriously. I've done a selection of different programs and reading that are fundamentally this, starting early in my career. It has been soaking in slowly over the last 20 years. I wish I had taken it more seriously earlier on. A couple things I can recommend as a starting point are:
- How to Win Friends and Influence People -- A classic and my first introduction to what I was doing wrong. It is old and a bit hokey, but fundamentally looks at the right things.
- This Course on LinkedIn -- Part of a training we did at work on EQ recently. It gives good coverage and tools.
If you want to get to the next level and far beyond, getting good at these skills will have the biggest bang for the buck.
Finally, finally: feel free to MeMail me. I'd be happy to talk through more of my experience, answer questions, and point you toward other resources.
posted by chiefthe at 7:51 AM on August 2, 2020 [5 favorites]
One thing I’ve frequently had to help junior engineers with is to understand the business that the company is in. It can be non-intuitive; for example a surprisingly large number of engineers at the tech-heavy Google don’t recognize that they are working for an advertising company. 70% of Google income comes from connecting eyeballs with people who want their message to be seen, but engineers are so deep in the technical stack it’s easy to forget that.
Next, why do people give money to your company instead of another? What makes a good product in your industry and more specifically for your company? Hopefully customers are telling you what they want; ask someone in Marketing for the master list of requested features and start thinking about what resources they would require from engineering.
Note that this is still above the technical level. A project might need one engineer for two months or six engineers for eight months. Making that guess is tough, which is why it is relegated to people with a lot of experience. The executives only have a certain amount of resources and need your informed opinion (guess) about allocating them, so you might want to focus less on how hard it is to predict the future and more on how you’re going to do it anyway.
At long last at the end of the chain, informed by everything that has come before, the technical work begins. Functional specs are hashed out not based solely on that feature, but on all the other features that are coming down the pipe. Approaches are suggested that don’t make all that much sense for the current feature but that will fit in nicely with what is to come.
Design specs are equally affected. What libraries are you going to create that will be as useful down the road as they are for what you’re doing right now? What are you doing such that you don’t have to re-architect the whole system six months from now?
This may seem like a lot but this is the vision that you are being asked to have. You don’t need to have soaring new technology ideas, you just need to be able to plan and execute technical projects based on the whole picture from customers giving the company money to you writing for-loops.
(On top of all that there are politics to consider. Functional and design specs are both affected by what teams will work well together, who in lower level management is hoarding their resources, etc, etc.)
But wait, you say, none of this is what I was hired to do! Exactly. Junior engineers are hired to focus on their own bit of code and make it work well.
All of this of course ignores the technical part, but you already know what you need to do there. Go find the people who understand what was talked about in the meeting and get enough context that you can do your own research. Create libraries for your project that will be useful for other projects, and in general consider how to contribute to more of the engineering organization.
TL;DR. Figure out how the company makes money and drive your decisions based on it. Technically, ask people for the breadcrumbs you need to understand what is being said in those meetings.
posted by Tell Me No Lies at 8:07 AM on August 2, 2020 [4 favorites]
Next, why do people give money to your company instead of another? What makes a good product in your industry and more specifically for your company? Hopefully customers are telling you what they want; ask someone in Marketing for the master list of requested features and start thinking about what resources they would require from engineering.
Note that this is still above the technical level. A project might need one engineer for two months or six engineers for eight months. Making that guess is tough, which is why it is relegated to people with a lot of experience. The executives only have a certain amount of resources and need your informed opinion (guess) about allocating them, so you might want to focus less on how hard it is to predict the future and more on how you’re going to do it anyway.
At long last at the end of the chain, informed by everything that has come before, the technical work begins. Functional specs are hashed out not based solely on that feature, but on all the other features that are coming down the pipe. Approaches are suggested that don’t make all that much sense for the current feature but that will fit in nicely with what is to come.
Design specs are equally affected. What libraries are you going to create that will be as useful down the road as they are for what you’re doing right now? What are you doing such that you don’t have to re-architect the whole system six months from now?
This may seem like a lot but this is the vision that you are being asked to have. You don’t need to have soaring new technology ideas, you just need to be able to plan and execute technical projects based on the whole picture from customers giving the company money to you writing for-loops.
(On top of all that there are politics to consider. Functional and design specs are both affected by what teams will work well together, who in lower level management is hoarding their resources, etc, etc.)
But wait, you say, none of this is what I was hired to do! Exactly. Junior engineers are hired to focus on their own bit of code and make it work well.
All of this of course ignores the technical part, but you already know what you need to do there. Go find the people who understand what was talked about in the meeting and get enough context that you can do your own research. Create libraries for your project that will be useful for other projects, and in general consider how to contribute to more of the engineering organization.
TL;DR. Figure out how the company makes money and drive your decisions based on it. Technically, ask people for the breadcrumbs you need to understand what is being said in those meetings.
posted by Tell Me No Lies at 8:07 AM on August 2, 2020 [4 favorites]
My transition to senior engineer was probably 50% confident white guy privilege but the number one difference I'd say in my engineering practice was thinking about two interrelated factors in software: first, what's the return on investment on building this feature or doing this refactor etc, is it actually worth it? Does it improve customer experience enough to make a difference in the bottom line, and, closely relatedly, how will this affect our engineering experience in 3, 6, 18 months from now. So thinking about the balance between product improvement and technical debt for all new code. This means: ok it would be great to have full test coverage, but we also need to build this fast enough to get a win for our customers, how do we build it so we can be confident it won't break and we won't hate our past selves but also move fast.
Move fast, don't break things, that's the perfect senior engineer mindset
posted by dis_integration at 9:08 AM on August 2, 2020 [2 favorites]
Move fast, don't break things, that's the perfect senior engineer mindset
posted by dis_integration at 9:08 AM on August 2, 2020 [2 favorites]
Just to add some spot answers to my wall of text:
>>I have asked for growth opportunities and I think my manager is trying to help. I am being put into meetings with more senior people, but I don't know the point of these meetings.
>>And what time I'm spending at these meetings I'm not spending doing actual work
Get used to that feeling. Attending meetings is very much the actual work of senior engineers. If you are like me and really enjoy the nitty-gritty they are simply a necessary evil.
>>I guess some people naturally "get" things like this but this is not me and I find it an incredibly confusing experience.
Your boss has probably put you in these meetings as an observer. Don't feel like you have to speak up at this point. He's put you there because they *are* confusing and it's something you're going to have to figure out to be a successful senior engineer. I think you may find some clarity by understanding the jobs of the non-technical people who are present. Frequently these meetings are negotiations between the non-technical and technical people.
>>o I suppose the information is useful, to see what everyone else is thinking, but I don't know what I'm expected to do with this information.
>>o he wants me to align better my projects with the team
These two go together. As a software engineer I tend to think in terms of libraries, but in general how is the work on your project improving your whole team's lives? Is there overlapping work? Can you redesign so there *is* overlapping work? Less work for everyone is always good, but you can't make these decisions without context.
>> but if any number of the 10 things from now until then can go wrong, then why bother?
"Plans are worthless, but planning is everything."
A good walkthrough of your basic plan:
posted by Tell Me No Lies at 9:17 AM on August 2, 2020 [3 favorites]
>>I have asked for growth opportunities and I think my manager is trying to help. I am being put into meetings with more senior people, but I don't know the point of these meetings.
>>And what time I'm spending at these meetings I'm not spending doing actual work
Get used to that feeling. Attending meetings is very much the actual work of senior engineers. If you are like me and really enjoy the nitty-gritty they are simply a necessary evil.
>>I guess some people naturally "get" things like this but this is not me and I find it an incredibly confusing experience.
Your boss has probably put you in these meetings as an observer. Don't feel like you have to speak up at this point. He's put you there because they *are* confusing and it's something you're going to have to figure out to be a successful senior engineer. I think you may find some clarity by understanding the jobs of the non-technical people who are present. Frequently these meetings are negotiations between the non-technical and technical people.
>>o I suppose the information is useful, to see what everyone else is thinking, but I don't know what I'm expected to do with this information.
>>o he wants me to align better my projects with the team
These two go together. As a software engineer I tend to think in terms of libraries, but in general how is the work on your project improving your whole team's lives? Is there overlapping work? Can you redesign so there *is* overlapping work? Less work for everyone is always good, but you can't make these decisions without context.
>> but if any number of the 10 things from now until then can go wrong, then why bother?
"Plans are worthless, but planning is everything."
A good walkthrough of your basic plan:
- Reveals flaws you hadn't considered at first glance
- Lets you enumerate your dependencies on other people/projects
- Lets you list the risks, their probabilities and how to minimize them
- Provides a chance to create contingency plans so that you reach your destination even if things go wrong.
posted by Tell Me No Lies at 9:17 AM on August 2, 2020 [3 favorites]
I've found it weirdly, terribly reassuring to have upper management tell me, as we're going through the planning process and I'm stressing out about the unknowability of the future and the % bullshit content in the plan, that "The one thing we KNOW about this forecast is that it will be wrong."
Like, of course it will be wrong! There are too many variables for us to say exactly what will happen. And yet, we still need to make decisions about where we will invest, which projects we will fund, what features we will implement and which ones will end up below the cut line.
So that's the comfort with ambiguity and risk piece.
The other things I would say have been really key distinguishing marks between senior engineers and junior engineers (and some "senior engineers" stay junior their whole careers, as far as this goes):
1. Do you understand how to set the "cut line" on your team's work? What is the real impact of the features you are making and what do the people above you actually value about your work - is it customer satisfaction, measurable productivity improvements, server load... What is core functionality and what is nice to have? How do those decisions get made and on what basis?
2. Expand your scope of thinking. Say you're asked about how a product is coming along. A junior engineer might say, it's awful, look at all these bugs we have. A senior engineer might see it totally differently - maybe we can tolerate those bugs as long as the core functionality works. Maybe we have time to get them in to a day 1 patch. Or maybe they already expected we'd need to push out the schedule by 6 weeks and the bug fixes will fit in there just fine. But in order to know if that's possible you have to know things about the business and where those scheduling deadlines came from.
The question my mentor kept asking me when I was growing from a junior to a senior engineer was, "is it a ship stopper?" I'd be complaining to our program manager about some UNACCEPTABLY lazy work some other team had done and he would ask me that... You say this is a serious problem. Do we have to call our customers and tell them we're delaying the release to fix it? And I'd go, oh, no, we can fix it in the first patch and most people won't even notice it. Calling the customers hadn't even been on my radar as a possibility. But for someone who actually has that authority, the scale for "big deal" includes, like, "it turns out our DRM package is siphoning people's passwords and we are going to get sued for $everything if this goes out the door" or "maybe our biggest customer will go out of business".
posted by Lady Li at 1:43 PM on August 2, 2020 [1 favorite]
Like, of course it will be wrong! There are too many variables for us to say exactly what will happen. And yet, we still need to make decisions about where we will invest, which projects we will fund, what features we will implement and which ones will end up below the cut line.
So that's the comfort with ambiguity and risk piece.
The other things I would say have been really key distinguishing marks between senior engineers and junior engineers (and some "senior engineers" stay junior their whole careers, as far as this goes):
1. Do you understand how to set the "cut line" on your team's work? What is the real impact of the features you are making and what do the people above you actually value about your work - is it customer satisfaction, measurable productivity improvements, server load... What is core functionality and what is nice to have? How do those decisions get made and on what basis?
2. Expand your scope of thinking. Say you're asked about how a product is coming along. A junior engineer might say, it's awful, look at all these bugs we have. A senior engineer might see it totally differently - maybe we can tolerate those bugs as long as the core functionality works. Maybe we have time to get them in to a day 1 patch. Or maybe they already expected we'd need to push out the schedule by 6 weeks and the bug fixes will fit in there just fine. But in order to know if that's possible you have to know things about the business and where those scheduling deadlines came from.
The question my mentor kept asking me when I was growing from a junior to a senior engineer was, "is it a ship stopper?" I'd be complaining to our program manager about some UNACCEPTABLY lazy work some other team had done and he would ask me that... You say this is a serious problem. Do we have to call our customers and tell them we're delaying the release to fix it? And I'd go, oh, no, we can fix it in the first patch and most people won't even notice it. Calling the customers hadn't even been on my radar as a possibility. But for someone who actually has that authority, the scale for "big deal" includes, like, "it turns out our DRM package is siphoning people's passwords and we are going to get sued for $everything if this goes out the door" or "maybe our biggest customer will go out of business".
posted by Lady Li at 1:43 PM on August 2, 2020 [1 favorite]
As for what you need. You need a mentor who can help you with the thought process. Is there anyone in one of those senior meetings who is asking what seem to be really good thoughtful questions, who you could ask some questions about their thought process?
Maybe there is a high level requirements document for the product that was created before you ever started work, that would help you understand how more senior people on your team conceptualize your team goals. But I'd recommend you start by interviewing someone. Asking someone respected and senior for help to have a mentoring conversation, and then asking them questions (NOT presenting them with your problems to solve or telling them all about your gaps in understanding, but asking them for THEIR understanding) is a good way to (a) make allies who want you to succeed and (b) actually see their thought process in work.
You can also see if there is a question you see come up a lot that would be a helpful framing for you to start applying independently. Something like, "what are the key requirements here?" or "Is this a ship stopper?" or "who is the customer for this feature, and how important is it to the overall success of our product?"
posted by Lady Li at 1:57 PM on August 2, 2020 [1 favorite]
Maybe there is a high level requirements document for the product that was created before you ever started work, that would help you understand how more senior people on your team conceptualize your team goals. But I'd recommend you start by interviewing someone. Asking someone respected and senior for help to have a mentoring conversation, and then asking them questions (NOT presenting them with your problems to solve or telling them all about your gaps in understanding, but asking them for THEIR understanding) is a good way to (a) make allies who want you to succeed and (b) actually see their thought process in work.
You can also see if there is a question you see come up a lot that would be a helpful framing for you to start applying independently. Something like, "what are the key requirements here?" or "Is this a ship stopper?" or "who is the customer for this feature, and how important is it to the overall success of our product?"
posted by Lady Li at 1:57 PM on August 2, 2020 [1 favorite]
Nice ask. Item zero is a mentor, and may you be visited with kindness in finding someone who's a good match to you.
The options at your hand are broadening. It's tough to go from being told to stay in your lane to choosing lanes which affect the direction available to your business. That's one part: Expectation you will, not permission needed to, raise the game of your colleagues, products and organisation.
Pairing with, mentoring so it's learn-by-doing also helps bring up the skills of colleagues.
Bring in some new toys to show that your current toolset might gain from some innovative approaches (and in contrast, get money for old rope by reusing an older platform in ways people say can't be done).
Asking Socratic questions that help tease out the knowledge in the team about which patterns to invoke as you design and implement your products. Go-see where your customers are and use that to feed into what people imagine they should make and why it's right for your customers.
posted by k3ninho at 2:00 PM on August 2, 2020
The options at your hand are broadening. It's tough to go from being told to stay in your lane to choosing lanes which affect the direction available to your business. That's one part: Expectation you will, not permission needed to, raise the game of your colleagues, products and organisation.
Pairing with, mentoring so it's learn-by-doing also helps bring up the skills of colleagues.
Bring in some new toys to show that your current toolset might gain from some innovative approaches (and in contrast, get money for old rope by reusing an older platform in ways people say can't be done).
Asking Socratic questions that help tease out the knowledge in the team about which patterns to invoke as you design and implement your products. Go-see where your customers are and use that to feed into what people imagine they should make and why it's right for your customers.
posted by k3ninho at 2:00 PM on August 2, 2020
There’s so much good advice in this thread!
I have not climbed the ladder within a single institution, so take this with a grain of salt, but here’s what I’d add:
Many times I’ve observed and experienced that the fastest way to get taken seriously within an organization is to have some success elsewhere. This can take a lot of forms.
posted by sixswitch at 2:12 PM on August 2, 2020
I have not climbed the ladder within a single institution, so take this with a grain of salt, but here’s what I’d add:
Many times I’ve observed and experienced that the fastest way to get taken seriously within an organization is to have some success elsewhere. This can take a lot of forms.
posted by sixswitch at 2:12 PM on August 2, 2020
This thread is seriously an amazing resource.
A few small ideas I didn't see represented elsewhere:
posted by heresiarch at 3:38 PM on August 2, 2020 [1 favorite]
A few small ideas I didn't see represented elsewhere:
- Takes notes in the big confusing meetings and find someone senior who can answer your "why?" questions who was in the room. Drill down as many levels as it takes. "Why did we have this meeting?" "Why did the exec ask XYZ?" "Why do you think tech lead rejected that idea?" "Why did this meeting end without a decision?" "Why did that idea cause an argument?"
- In your meeting notes, try writing down the names of all the participants and what you think their role and goal for the meeting might be.
- Leaders set the tone for rooms and teams. Focus on them in particular (in meetings or otherwise) and ask "what motivates them?" It might be on-time delivery, it might be gaining scope, it might be satisfying a key customer, it might be cutting down on risk, it might be feeling important or respected, it might be doing something innovative, it might be saving money. (And then there's a meta version here -- why are they motivated by that? That often comes from the company situation. If a company or division is not profitable, that trickles down into the motivational framework for leaders who are trying to change that with whatever tools they have.)
posted by heresiarch at 3:38 PM on August 2, 2020 [1 favorite]
I'd like to echo dis_integration's description as describing my experience and attitude in becoming a senior, including the part about unearned white guy privilege.
posted by Kwine at 5:35 PM on August 2, 2020 [1 favorite]
posted by Kwine at 5:35 PM on August 2, 2020 [1 favorite]
I am being put into meetings with more senior people, but I don't know the point of these meetings.
This would be one of the major starting points. Find someone who can tell you what the point of the meetings are. The stereotype of higher-level meetings is that they are pointless. That might be from a certain perspective, but I guarantee that from some other perspective there *is* a point. Get more than one opinion on this. The answer will lead you to other questions. Repeat.
Who's at these meetings? What are their roles and functions? Why are *they* there? Again if it's not clear, poke around and get some opinions.
But first of all, try to get more information from your manager. The next time such a meeting comes up, ask him specifically: "What would you like me to get out of X meeting?" Not in high-level terms but specifically to do with the project that is being discussed.
The feelings of awkwardness brings back memories for me. Looking back, I should have seen them for what they were - signals that I was in a learning situation.
I'm POC and went from junior to senior engineer and then into management. The transition from Junior to Senior for me came from mostly becoming an SME in my area (it was operating systems software). Once you achieve that, your voice *will* be heard. I recommend SME as a top career priority. I've seen people advance who weren't SMEs but it seemed to me that they were taken less seriously in general.
When you are an SME you can be a valuable trainer for new hires. That's one mark of the senior hand. To accomplish the crossover you will also need to know who your group's main interfaces are. What teams are you working with? What do those teams do? What do they need from your team?
How comfortable are you in making presentations and speaking before a group? This is another critical skill for seniors. I was very nervous. I joined Toastmasters and worked on my public speakng. It doesn't take a lot of work (maybe 2-3hrs a week regularly). As a force multiplier on top of SME, speaking skills is right up there.
posted by storybored at 6:21 PM on August 2, 2020 [2 favorites]
This would be one of the major starting points. Find someone who can tell you what the point of the meetings are. The stereotype of higher-level meetings is that they are pointless. That might be from a certain perspective, but I guarantee that from some other perspective there *is* a point. Get more than one opinion on this. The answer will lead you to other questions. Repeat.
Who's at these meetings? What are their roles and functions? Why are *they* there? Again if it's not clear, poke around and get some opinions.
But first of all, try to get more information from your manager. The next time such a meeting comes up, ask him specifically: "What would you like me to get out of X meeting?" Not in high-level terms but specifically to do with the project that is being discussed.
The feelings of awkwardness brings back memories for me. Looking back, I should have seen them for what they were - signals that I was in a learning situation.
I'm POC and went from junior to senior engineer and then into management. The transition from Junior to Senior for me came from mostly becoming an SME in my area (it was operating systems software). Once you achieve that, your voice *will* be heard. I recommend SME as a top career priority. I've seen people advance who weren't SMEs but it seemed to me that they were taken less seriously in general.
When you are an SME you can be a valuable trainer for new hires. That's one mark of the senior hand. To accomplish the crossover you will also need to know who your group's main interfaces are. What teams are you working with? What do those teams do? What do they need from your team?
How comfortable are you in making presentations and speaking before a group? This is another critical skill for seniors. I was very nervous. I joined Toastmasters and worked on my public speakng. It doesn't take a lot of work (maybe 2-3hrs a week regularly). As a force multiplier on top of SME, speaking skills is right up there.
posted by storybored at 6:21 PM on August 2, 2020 [2 favorites]
There is a lot of useful information about business, technology, and people skills in this thread. In fact I find myself overwhelmed just reading it and I used to do all this for a living.
So I'd like to say: Nobody learns all of this in six months or a year. Too much of it is experiential -- for example, you need to watch a few projects go down in flames before you get a feeling for when to bail out. Many things you do as a senior engineer require making guesses with limited information and that takes experience.
There are concrete steps that you can take right now, but overall you should consider yourself as doing well if you start to feel comfortable somewhere in the 3-5 year range.
posted by Tell Me No Lies at 6:40 PM on August 2, 2020
So I'd like to say: Nobody learns all of this in six months or a year. Too much of it is experiential -- for example, you need to watch a few projects go down in flames before you get a feeling for when to bail out. Many things you do as a senior engineer require making guesses with limited information and that takes experience.
There are concrete steps that you can take right now, but overall you should consider yourself as doing well if you start to feel comfortable somewhere in the 3-5 year range.
posted by Tell Me No Lies at 6:40 PM on August 2, 2020
One last bit and I'll stop, I promise. Just heard back from the most impressive technical woman I know (who is also a POC. And a lesbian). She said I should point you to Women Who Code, a very active group which is about half Coding and half Women In Technology content. It might help you feel not so alone.
posted by Tell Me No Lies at 6:59 PM on August 2, 2020
posted by Tell Me No Lies at 6:59 PM on August 2, 2020
I have kind of a diagnostic question: why do you want to become a senior engineer? You can message the moderators to put an answer in the thread. I feel like I need to know that to help suggest a course of action.
posted by brainwane at 8:35 PM on August 2, 2020 [2 favorites]
posted by brainwane at 8:35 PM on August 2, 2020 [2 favorites]
Oh, one other last idea -- You've mastered many difficult skills to get where you are now. This set is hard too. It takes practice and study and people who are good at it make it look effortless. And just like a technical domain where you don't have any expertise, it is disorienting at the start. Even worse, it looks easy because it's just people talking. But there's a lot of depth here and it will take a lot of work to understand it all.
posted by heresiarch at 10:58 PM on August 2, 2020
posted by heresiarch at 10:58 PM on August 2, 2020
If the meetings have a name and agenda, you can take that as a starting point to find out what their purpose is. You can also take notes and reverse-engineer the agenda to find out what problem the meeting is supposed to solve.
The more senior you get, the more strategic (i.e., where should we be headed in the longer term) the tasks and meetings will be. The tasks a junior engineer completes have to come from somewhere. One way is to go down the organization, time, and abstraction levels together, from top (we are the company that achieves X by decade Y to address societal problem/need Z), over senior (we do project I by year J with features K to address need L for target group M), to junior (I do task R today for subproject S that’s due in T months), probably with levels in between.
Lack of response to your input can be because it’s not quite relevant (you don’t seem to have enough context), but being a POC and woman certainly adds a non-negligible probability of being ignored for no legitimate reason.
posted by meijusa at 5:04 AM on August 3, 2020
The more senior you get, the more strategic (i.e., where should we be headed in the longer term) the tasks and meetings will be. The tasks a junior engineer completes have to come from somewhere. One way is to go down the organization, time, and abstraction levels together, from top (we are the company that achieves X by decade Y to address societal problem/need Z), over senior (we do project I by year J with features K to address need L for target group M), to junior (I do task R today for subproject S that’s due in T months), probably with levels in between.
Lack of response to your input can be because it’s not quite relevant (you don’t seem to have enough context), but being a POC and woman certainly adds a non-negligible probability of being ignored for no legitimate reason.
posted by meijusa at 5:04 AM on August 3, 2020
Echoing everyone else, being a senior engineer is about seeing longer term, and having a wider impact. A lot of that is politics, and not in the derogatory sense -- literally the professional relationships you have across your team, group and org at large.
Participate in those meetings you get invited to. Ask dumb questions, they're usually not dumb at all -- not having a bunch of inbuilt context on why things are happening allows you to ask "hey why are we doing this instead of this other thing?" and almost without fail someone will pause and say "...you know, that's a great question". And either there's a good reason, or there isn't -- but it's always worth asking. Think about the projects you discuss with a multiple year horizon in mind, think about where the group and org are moving towards, and suss out what aligns and what doesn't.
Moving into a more senior role involves a lot more questioning, not more knowing. You'll develop a sense of knowing and a sense of direction over time only when you ask "why this" "why now" "why this way" etc.
posted by so fucking future at 7:48 AM on August 3, 2020
Participate in those meetings you get invited to. Ask dumb questions, they're usually not dumb at all -- not having a bunch of inbuilt context on why things are happening allows you to ask "hey why are we doing this instead of this other thing?" and almost without fail someone will pause and say "...you know, that's a great question". And either there's a good reason, or there isn't -- but it's always worth asking. Think about the projects you discuss with a multiple year horizon in mind, think about where the group and org are moving towards, and suss out what aligns and what doesn't.
Moving into a more senior role involves a lot more questioning, not more knowing. You'll develop a sense of knowing and a sense of direction over time only when you ask "why this" "why now" "why this way" etc.
posted by so fucking future at 7:48 AM on August 3, 2020
Mod note: From the OP:
Thank you so SO much everyone for your thoughts - it has given me a lot to think about and I am digesting and reading all the resources you all have posted, and trying out the suggestions you all have given.posted by loup (staff) at 1:55 PM on August 3, 2020 [2 favorites]
Regarding brainwane's question "why do you want to become a senior engineer?":
I think three inter-related motivations:
1) this seems like the natural progression if I want to move forward with my career, as dictated by the company promotion ladder.
2) I want to have the opportunity to tackle harder problems and think about more interesting questions. I feel that I have "mastered" the problems that junior engineers work on, my projects are starting to feel predictable (in the sense that I know that I _can_ solve them and I know _how_ to solve them), and I am looking for new, more technically challenging problems and it feels like I need to be more senior to have the opportunity to work on those.
3) I admire a lot of the senior engineers I see, they often provide thoughtful input on industry wide trends and can generate predictive insights. It seems that they can apply their knowledge even to tangentially related domains and I want to also be able to do that.
I'm a product manager, not an engineer, but I have been in tech for 15 years and I have seen a lot of engineers grow through the transition that you are trying to make.
On the plus side, it sounds like your leadership is giving you good advice and opportunities, and wants to see you succeed. From your latest update, it also sounds like you are ready for the next step. These are the most important factors.
The challenge will be to make the leap from a problem-focused to a product-focused mindset. As a senior engineer, you need to be able to make architecture and design decisions that take maintainability and extensibility into account, and communicate clearly and confidently about why you're making those decisions. The customer (or the higher-ups) will always be pushing you for easier answers and faster timelines, but they have no choice but to be reasonable when your rationales are clear.
I agree so hard with your manager that told you to focus on the "why." Think about the last feature your team worked on. Do you know who will use it? When? What small thing in their life that will be easier because this feature exists? I do a 5-Whys exercise with new product managers I'm training where the prompt is "build a fence" --- Why? It normally goes something like:
* "I want to build a fence to enclose my yard" --- Why?
*"Because deer are getting in there and eating my veggie garden" --- Why do you have a garden?
* "I wanted to grow my own food" --- Why?
* "I thought I could save money on groceries"
"Save money on groceries" (or "eat more healthily," or whatever else the group comes up with in the end) is a VERY different problem to solve than "Build a fence." You might indeed end up building a fence in the end, and that's fine! But you might also find some other cheaper, better options to solve the problem, and even if not, the investigation and process will help you be more sure that the fence is the right answer. It will also pull out more requirements, like how tall or strong the fence needs to be.
Anyway. These are the kinds of things I would advise you to think about. For certain personalities, like mine, and presumably yours, it is always going to be hard to speak up in meetings when you're the most junior person in the room, especially as a woman. That doesn't change --- the meeting rooms just get more and more expensive, and the men have better and better haircuts. One thing that helped me push through those nerves when I was in the same phase of my career was to take time after each meeting to think about what I would have said if I had been braver, and then either consult with a trusted colleague who was also in the meeting, or just reply-all to the meeting with my feedback over email. I always find that people forget what people say in meetings pretty quickly, but an email that they can search later? Gospel.
posted by slenderloris at 4:21 PM on August 5, 2020
On the plus side, it sounds like your leadership is giving you good advice and opportunities, and wants to see you succeed. From your latest update, it also sounds like you are ready for the next step. These are the most important factors.
The challenge will be to make the leap from a problem-focused to a product-focused mindset. As a senior engineer, you need to be able to make architecture and design decisions that take maintainability and extensibility into account, and communicate clearly and confidently about why you're making those decisions. The customer (or the higher-ups) will always be pushing you for easier answers and faster timelines, but they have no choice but to be reasonable when your rationales are clear.
I agree so hard with your manager that told you to focus on the "why." Think about the last feature your team worked on. Do you know who will use it? When? What small thing in their life that will be easier because this feature exists? I do a 5-Whys exercise with new product managers I'm training where the prompt is "build a fence" --- Why? It normally goes something like:
* "I want to build a fence to enclose my yard" --- Why?
*"Because deer are getting in there and eating my veggie garden" --- Why do you have a garden?
* "I wanted to grow my own food" --- Why?
* "I thought I could save money on groceries"
"Save money on groceries" (or "eat more healthily," or whatever else the group comes up with in the end) is a VERY different problem to solve than "Build a fence." You might indeed end up building a fence in the end, and that's fine! But you might also find some other cheaper, better options to solve the problem, and even if not, the investigation and process will help you be more sure that the fence is the right answer. It will also pull out more requirements, like how tall or strong the fence needs to be.
Anyway. These are the kinds of things I would advise you to think about. For certain personalities, like mine, and presumably yours, it is always going to be hard to speak up in meetings when you're the most junior person in the room, especially as a woman. That doesn't change --- the meeting rooms just get more and more expensive, and the men have better and better haircuts. One thing that helped me push through those nerves when I was in the same phase of my career was to take time after each meeting to think about what I would have said if I had been braver, and then either consult with a trusted colleague who was also in the meeting, or just reply-all to the meeting with my feedback over email. I always find that people forget what people say in meetings pretty quickly, but an email that they can search later? Gospel.
posted by slenderloris at 4:21 PM on August 5, 2020
Anonymous, thank you for that further info on why you want to be a senior engineer.
So, from that plus your original post, I think you find it really frustrating when you can't predict what causes lead to which outcomes, and you are goal-oriented and prefer to work through explicit structures rather than discover ambient meaning and bootstrap that into fluid, iterative action. You want to get and solve interesting technical problems and be able to make useful insights about new domains. And you want to advance in your career, which is to say, you want to not get fired/laid off, and you would like more money and prestige.
I think you have a few different paths that might suit you. One is to try to climb the career ladder where you are. This will probably require you to work on your people and listening skills -- you would become an amateur ethnographer and sociologist, so that when you hear people saying things that don't make sense or you feel like you're being asked to make useless plans, you can find ways to use those facts as clues. And you would work on your understanding of industry economics and trends, and read your company's financial statements and internal team reports to understand how they affect the decisions your colleagues are making. Here's a writeup of a speech I gave that might help you.
Another approach is more of a self-study/spare-time/hobby project approach: You could start a company or a research project or an open source project in your spare time. This would ensure that you get to work on technically interesting questions and problems of your own choice, and could provide some perspective to help you understand different choices that your employer has made or is making. And you can learn from engineering history, like the Architecture of Open Source Books, to help you understand why senior engineers make the decisions they do.
(Also: You might find it useful to watch the 4-season AMC series Halt and Catch Fire. It's about engineers, including engineers who go from individual contributors to team leads, and start companies.)
But a third approach -- and I think you should strongly consider this -- is going into research as a career, or at least for a short period. If you have not already attended graduate school, then you should consider getting a paid research apprenticeship, which is (at least in the US) how it works to get a research-focused master's or PhD in engineering/CS. The structure of the coursework would help you, and your advisor and peers would help you work through the more fluid bits. The coursework and your research would help you develop broader and more imaginative vision, find and apply yourself to novel technical questions, and help you gain a kind of prestige, whether you choose to go back to industry afterward or not. If you have never considered graduate school in computer science, Lindsey Kuper's blog and Phil Guo's blog are helpful resources.
posted by brainwane at 10:26 AM on August 24, 2020
So, from that plus your original post, I think you find it really frustrating when you can't predict what causes lead to which outcomes, and you are goal-oriented and prefer to work through explicit structures rather than discover ambient meaning and bootstrap that into fluid, iterative action. You want to get and solve interesting technical problems and be able to make useful insights about new domains. And you want to advance in your career, which is to say, you want to not get fired/laid off, and you would like more money and prestige.
I think you have a few different paths that might suit you. One is to try to climb the career ladder where you are. This will probably require you to work on your people and listening skills -- you would become an amateur ethnographer and sociologist, so that when you hear people saying things that don't make sense or you feel like you're being asked to make useless plans, you can find ways to use those facts as clues. And you would work on your understanding of industry economics and trends, and read your company's financial statements and internal team reports to understand how they affect the decisions your colleagues are making. Here's a writeup of a speech I gave that might help you.
Another approach is more of a self-study/spare-time/hobby project approach: You could start a company or a research project or an open source project in your spare time. This would ensure that you get to work on technically interesting questions and problems of your own choice, and could provide some perspective to help you understand different choices that your employer has made or is making. And you can learn from engineering history, like the Architecture of Open Source Books, to help you understand why senior engineers make the decisions they do.
(Also: You might find it useful to watch the 4-season AMC series Halt and Catch Fire. It's about engineers, including engineers who go from individual contributors to team leads, and start companies.)
But a third approach -- and I think you should strongly consider this -- is going into research as a career, or at least for a short period. If you have not already attended graduate school, then you should consider getting a paid research apprenticeship, which is (at least in the US) how it works to get a research-focused master's or PhD in engineering/CS. The structure of the coursework would help you, and your advisor and peers would help you work through the more fluid bits. The coursework and your research would help you develop broader and more imaginative vision, find and apply yourself to novel technical questions, and help you gain a kind of prestige, whether you choose to go back to industry afterward or not. If you have never considered graduate school in computer science, Lindsey Kuper's blog and Phil Guo's blog are helpful resources.
posted by brainwane at 10:26 AM on August 24, 2020
This thread is closed to new comments.
I spent my career in software development as an "individual contributor". At my peak, I worked at Google, as a level 5 (same level as Brian Kernighan... if that doesn't give you impostor syndrome, nothing will). When pushed to get to "senior" levels, the main thing seemed to be the ability to use other people as a force multiplier. That is to say, there's only so far you can go being the "elite coder", that can code up whatever insanely amazing thing there is to code up all by yourself. After a certain point, it doesn't matter what you can code up by yourself. It matters what you can get other people to code up for you -- how you can be a leader, a manager, how you can get other people to execute a plan you envision which is too big for a single person to take on.
I found this transition from individual contributor to a sort of "team lead" to be *very* difficult. Part of this was the lack of any explicit authority. I'm expected to be a "team lead", but, I have no authority over the people I'm supposedly leading. I'm supposed to lead them by sheer force of personality and the merit of my ideas alone. I found it to be so difficult that it seemed to me that I was being required to be a different person than what I actually was, a requirement so severe that it lead me to exit the scene entirely.
You may be running into something similar. If so, the people that thrive in such environments are people with strong personalities who are "natural" leaders, whatever that means (kinda one of those "you know it when you see it" situations), If you're a kind of shy, thoughtful person, rather than a grab-the-bull-by-the-horns-without-thinking because 'my-way-or-the-highway' type of person,... well, it may not go well.
I don't think I have the answer you're looking for, I think I probably serve more as an example of someone in a similar situation who wasn't really up to the task of advancing into a leadershop role, and who would have been better off remaining in an "individual contributor" role. But maybe you're different than me. I think the main thing to take in is that you need to think less about what you can directly contribute yourself and think more about what you can do to get an army of people to do for you -- which if you can do that is really its own kind of contribution.
And it's possible I'm mis-reading the situation entirely and mapping your situation onto my own situation in a way that is not really helpful.
Good luck.
edit:
"He has also consistently told me that my "vision" is not enough, that I need to think longer term, and that I need to have more direction for my work if I'm to grow to be a senior engineer."
Yeah, this seems familiar. To some extent (at google anyway), the idea is that you push people regardless. You are not allowed to be comfortable. If you are comfortable (i.e. feel like you have a solid handle on your job and can do it without sweating), you are by definition not being pushed hard enough, and there is more juice that may be squeezed out of you. Consequently, you are never comfortable, and are always in discomfort, because your manager sees to it that this is the case.
posted by smcameron at 11:53 PM on August 1, 2020 [10 favorites]