Is it normal to be expected to set “ambitious” business goals as a software engineer?
Posted by tokyonian@reddit | ExperiencedDevs | View on Reddit | 71 comments
Hi everyone,
I recently joined a pretty big and well known tech company (not FAANG, but still quite prominent in the industry), and I was asked to set three personal business-related objectives based on my ambitions. These goals are supposed to align with the company’s direction and include a plan for how I’ll achieve them and what kind of impact they’ll have etc.
For example, I’m expected to come up with something like: “Build and launch feature X that improves user engagement by Y%,” and then actually drive that initiative myself.
Is this kind of expectation common in the industry? I assumed the main responsibility of a software engineer was to build the features we’re assigned, not necessarily to define product goals or business impact. I’m finding it a bit overwhelming and was curious how others have dealt with similar expectations.
FYI, I am a middle level
Party-Lingonberry592@reddit
My personal opinion is that the Product Managers should have the pulse of the customer and set the vision to stimulate growth. Engineers should build that vision to scale keeping in mind how the customer will use the product. I was at a big company that bought a product that didn't align to the company's primary business. They sent a directive to all engineers to come up with ideas on how to make it fit into our business model. Complete failure. Ended up selling the product to someone else years later. They did make a profit though...
gingimli@reddit
I've had to do this at one tech company before (also well known but not FAANG).
We promptly threw all my goals out the window once we got busy with the actual company goals for the year, never revisited them. I'm not sure what the point was.
ScriptingInJava@reddit
The middle management special; aggressively set objectives (with threats of bonuses not awarded if they aren't met) and then entirely ignore them because the product is on fire 11 months of the year.
stevefuzz@reddit
Can we please just replace middle management with AI and let developers be productive?
skg1979@reddit
If you’ve seen how stupidly Claude ai works when doing its diagnostic attempt of a build error you wouldn’t want this at a management level. We allow the agents to inefficiently diagnose issues because at the code level it’s cheap.
SituationSoap@reddit
Man, if you think you get a lot of BS from middle management, wait until you have to understand everything they need to do their jobs and you still have to do your own job, too.
stevefuzz@reddit
Why would I do their job lol? I don't have time to sit in meetings all day.
SituationSoap@reddit
If middle management doesn't exist, someone needs to do that job. Businesses don't all have middle managers because they think the idea is neat. If that person doesn't exist in your management chain, you're going to have to go do it yourself. Or someone on your team will.
stevefuzz@reddit
Yes .. ai
SituationSoap@reddit
This is roughly as useful as saying that writing software is just typing.
You're giving a bad take based on your bad understanding of how someone else's job works. Stop being that guy.
stevefuzz@reddit
I'm not. I think, for example, you could replace multiple project managers with one using a software solution using AI. I literally have pitched the idea. Hey, people keep saying that developers can easily be replaced, and our job is much more complicated. You don't think an LLM could handle managing tickets, communication, time estimation coordination, and reporting for developers? For perspective, I've been a developer for 25 years. I'm not some punk kid trying to annoy you. Like, people say, let's replace doctors, and that's fine... Bring management into it and the entire vibe changes.
SituationSoap@reddit
Mate, you literally just said that you think a project manager's job is simple while trying to tell me you didn't.
But no, a LLM cannot do those things well. It also cannot replace a doctor or a developer. All of those takes are stupid takes that are based on people not understanding the jobs that other people do, and assuming that because you only see a small slice of it, you must understand the whole thing.
stevefuzz@reddit
Honestly I kind of find the entire state of LLMs angling to replace junior developers really depressing. Like, what happens if you only cut down the young trees. However, for automated tasks that require interfacing with humans, LLMs are far better. At least as a huge productivity boost. I don't even know why I went down the rabbit hole here with this thread. It's not really my style. I apologize if I came off as crass or jaded.
canadian_webdev@reddit
Seriously.
My boss:
That's it. That's literally it. You're telling me AI can't replace him? Give me a break.
SituationSoap@reddit
Do you want to go sit in those meetings yourself and then still get out and do that work?
stevefuzz@reddit
It's way more suited for basic human interaction than coding. I actually pitched creating a PM replacement with LLMs for interfacing. He was afraid that it might ruffle some feathers. I was like, ok, ummmm... Wouldn't want to ruffle project managers feathers, you know, as a dev constantly reading we are getting replaced by exactly that (we aren't).
internetgoober@reddit
I've been there so many times that I don't take these goal talks seriously. Just go through the motions to tick a box for my manager.
The times I've gotten a raise or promotion has always aligned with me being buddies with the c-suite or some higher level director or when an organization is growing fast.
gingimli@reddit
Yep, that's exactly what happened 😂. Thankfully I had a good manager at that the time so when we looked at my goals a second time (12 months later during annual review) they were more apologetic than anything.
0dev0100@reddit
This is my favorite question in the annual performance reviews everyone goes through at my company.
Manager: "What do you want to achieve in the next year?"
Me: "what are the company goals for the next year"
Manager: ""
Me: ""
Manager: "sounds good"
Works every time.
Global_Rooster8561@reddit
Good managers should have the team goals listed somewhere, go and ask. Could me much easier that doing the same thing but on a company level
UnkleRinkus@reddit
I remember snarking at my boss about something like this 20 years ago: "I've learned our esoteric product, as well as Java and Perl to support the product, on my own, with no prompting from you, or any of these stupid goals. Do you want me to look into the future to invent an irrelevant target, or shall I just continue being the fire and forget engineer that you love me being?"
ProfBeaker@reddit
No, never. And honestly I'm surprised by how many comments here seem to think this is normal. It's enough to make me think I'm the weird one.
But look, figuring out what to build is the job of a whole other job function - Product Management. Asking individual devs to do that is taking "Full Stack Developer" into the territory of being an entire company yourself.
Are you supposed to be looking at usage data, talking to clients, and attending the product planning meetings too? If so, where do you find time for all the actual dev work? If not, you're going to a shitty job of being a product manager.
Also, measuring individual devs on whether a feature works, when that is probably the outcome of work from multiple teams and even entire other parts of the business is just crazy, and a terrible yardstick.
tl;dr, If someone asked me to write goals of this type, I'd tell them to go hire a product manager, and also read a book on setting reasonable goals.
Financial_Anything43@reddit
No one “exceeds expectations “
AManHere@reddit
I have had that at a company similar to Dell. At FAANG that was not present, which I thought was interesting
light-triad@reddit
Your org should have a strategy roadmap and OKRs defined (hopefully). Try to understand what those are and define your projects based on that.
julirocks@reddit
I can’t speak to how it’s implemented, but what’s most likely is happening is leadership wants engineering to be more outcome driven then output driven.
Ideally, but having outcome driven results, you are now empowered to have more say in a product and it’s not entirely driven by a PM.
nicolas_06@reddit
It's boit the job of engineering to know what feature to add and what benefit it bring to the business. That for the business people to determine and then engineering make that happen.
I agree that engineering can have interesting discussion with business on proposals and brain storming things but ultimately the business decide the features using the engineering cost and timeline estimate from engineering. And then engineering makes that happen.
abe_mussa@reddit
I think it’s typical, and a good thing
Having technical skills alone isn’t enough - success is using them to drive impact and deliver value to the business
Are there any data / product analysts at your org? If so, I’d focus on building relationships and chatting to them. Having a solid understanding of the metrics important to your team (and which levers to pull to impact them) is essential IMO if you want to succeed here.
nicolas_06@reddit
To be honest this isn't the job of software engineers to decide what the business/client need. And they would have no clue as newcomers in the company on top.
As engineer our job is to design solution to implement some functionality to solve people problem. Our job isn't to discover what people problem are and what they want/need (and especially not to guess it from nowhere when we are onboarding). Usually there whole departments/teams that focus on that.
They would say we are discussing with client X that like to pay for feature Y. Or they would say we think we could increase sale by 25% if we implemented feature 1, 2 and 3. Then it would be the dev department job to provide the cost and timeline to do X as well as 1, 2 and 3. Project manager would prioritize and decide what will be done or not and we would build together a roadmap and implement it.
tomqmasters@reddit
It is common in industry to bully people into overpromising so they feel obligated to work themselves to death. I only every feel obligated to put in an honest days works and they get what they get.
nicolas_06@reddit
Usually with XP you understand that nobody care actually.
serpentdrive@reddit
Lets make you set goals for products you do not know yet, then we will keep you in sprints where you do not pick what you work on, and after that lets talk about how you did not meet your goals.
nicolas_06@reddit
With decent managers, the goals are changed/ignored and in the end you get raises/promotions based on how well you did overall (or at least what you manager think of it).
effectivescarequotes@reddit
I've worked for a few companies that did stuff like that. Every year we would have to set goals that were never discussed again. During review time we'd retroactively change them to reflect the work I actually did.
I personally think the exercise is a waste of time. There's a pattern to pay increases. During the first round that I was eligible, I'd get a small increase. Then right around the time that I cross the "not a job hopper if I leave" threshold, I get a bigger one, usually around 10%. Then it's two to three percent increases until I get poached for a 20% increase.
nicolas_06@reddit
I agree that objectives like that are bullshit especially as you won't be given the necessary resources and time to do it.
What make sense with a good manager is still what you need to improve, like what skills you need to acquires or issues that need to be fixed and to setup a plan and expectations.
But a bullshit like I will implement feature ABC that nobody asked and it will improve some bullshit KPI by 50% is useless.
Atagor@reddit
Many engineers fake these goals.. The "10x engineer" myth is mostly luck. The real high-impact moments come from being in the right place at the right time. Anyway, play the game
nicolas_06@reddit
+1 you have to play the game.
Aromatic-Pizza-4782@reddit
The 10x engineer is just a coder who does a huge amount of coding compared to what management expects for the price of a 1x engineer.
ScriptingInJava@reddit
As a principal engineer that's part of what my job is, being able to align the business interests and product development to drive growth etc.
As a mid-level I wouldn't expect that frankly, however there's a chance they've recognised you may be on the boarder of senior and want to use this as a springboard for a promotion. Have you discussed it with any colleagues? Have they had the same requirements set?
nicolas_06@reddit
Realistically you can't provide any commitment like that as a newbie in the company has you don't know the business, the product, the codebase, what the users want or need.
What I would expect more is that the project manager together with commercials and potentially some data analyst would say that from the data, from the client feedback and all they think that the next feature that will add the most value will be X, Y, Z, that the development team come back with the cost/feasibility of each of them and that we will prioritize all this and that as dev I might be involved in the cost/feasibility + development of the features.
Once I have some knowledge of the company/code base/project I might be able to propose improvements and working with the data I may be able to get an idea of how much it would improve this or that metric. such improvements but as I don't work for free, and don't have infinite time, it will only happen if we have the budget, resources and it get actually planified.
That being said, like everybody else I can say whatever bullshit is necessary and even make effort to max any bullshit KPI.
tokyonian@reddit (OP)
I should have added it in the post but this is expected for everyone, regardless of the title. Meaning, even junior level members are supposed to set the goals.
Esper_18@reddit
Its just letting managers see you report your own value so its super easy to fire you.
Probably based on Elon Musk's "name three things you did last week"
Flyodice@reddit
I dont think there is enough information to come to this conclusion. We often do this for platform work where the business wants to see some productivitybor reliability gains and defer to the teams to suggest ideas to best achieve those goals.
ScriptingInJava@reddit
That's fair, I just edited my original comment with some more info regarding the why. It's a great skill to have that you'll need in the not-too-distant future, being able to hone it now while the stakes are lower (as a mid-level) is a great place to start.
You don't want to hit the top end of senior and have ambitions for more, but also no people skills nor business acumen.
stevefuzz@reddit
Same. I usually get looped in to discuss and plan the technical side of things, architecture (my job), cost, goals, etc. Not so much roadmapping the company vision, but, making sure it's possible.
UpgrayeddShepard@reddit
Shows a company with a poor separation between product and development teams.
ramenAtMidnight@reddit
No this sounds ridiculous. That’s a product wide biz KR. It should be on multiple teams: Engineering, Product, and Business. You do have to make your own tech KR though. SLAs and such are reasonable. Your tech lead should work it out with the other teams, so that the tech KR still aligns with the biz KR
marmot1101@reddit
Fairly common to set goals, but not to drive product. Working alongside product to improve usability and leading the charge is sane though.
The best goal setting has 2 parts: leading and lagging indicators. What you’re describing is a lagging indicator. It’s an outcome rather than a behavior. You can fail for reasons completely out of your hands. Leading indicators would be something you do. “A pr a day” or whatever.
It’s also important to know if the company wants you to set ambitious goals for real, or “ambitious goals”. Truly ambitious goals are ones that you have a reasonable chance of failure. “Ambitious goals” in quotes are ones that sound big, but you have little chances of failing. I’m going to make 25 commits a week sounds impressive, but is entirely gameable.
sessamekesh@reddit
Depends on your career goals. Do you want to climb the ladder and take on technical and/or business leadership roles? Or are you happy staying at the strong IC level and leaving it at that?
All businesses I've seen expect career advancement up to a point, some expect that point to be much later than others.
No_Quit_5301@reddit
Don’t do it. You will literally never be asked nor evaluated on those kinds of metrics. You will get nothing but blow back from your teammates and superiors when there’s inevitably a bug, if you get it shipped at all
Keep your head down. Do what’s assigned. Then dip for the next best thing
makonde@reddit
Don't know how common this is but honestly whenever I am asked to deal too closely with the business side I always feel like this is a failure of some other part of the company, like what is the business and product side doing if engineering is now supposed to come up with business goals, especially given how much data in terms of all sort of analytics and costumer contact and user research they do.
noonemustknowmysecre@reddit
Yeah. It's just a "hey, how do we know if you're doing your job?"
It's managers having you do their job for them. Which is fine, really.
Looooots of variance there. If you make up something here and then just blow it off, your manager may poke you on it. Usually it's just "I'm on project X. I'll work on project X. Project X will launch by Y". And of course, that's what they pay you to do so come review time, you can point and say "I worked on project X".
Empanatacion@reddit
Be good at your job, build relationships, and be pleasant to work with. Say whatever plausible blather sounds good for these rain dances.
When it is time for promotion or review, your boss is going to do a gut check on a few things.
1) What your productivity has been
2) How inconvenient it would be if you left
3) How likely he thinks it is that you might leave
4) How much he likes you
5) How often he hears good things from others about you.
He'll work backwards from that gut check when reporting on how well your performance matched with meeting your goals.
It's actually not a terrible set of criteria. The only problem I have with the whole dynamic is that we're not honest about how it works.
BobRab@reddit
I would imagine that this is an effort to get engineers to think strategically. Writing code is a tool to do stuff for the business. Do you have insights from writing code that could help the business? Do you have ideas about how you can align the kind of code you want to write with helpful directions for the business?
Or another way to look at it is to think about what you want to be able to put your promo doc and start working towards it.
thatguygreg@reddit
Look at it this way: should this be your job? No; this is Project/Program Manager work. However, when a PM does this, you wind up having to work on someone else's goals.
With this, in theory, you're in the driver's seat. You are being asked to determine what success will mean for you and then figure out how to get there. Make sure the code you're writing has the telemetry in place to report on user engagement with whatever feature or the product as a whole, and write goals that are a logical level above that.
Objective: Increase monthly active users, and enable those new users to be successful
Stuff like that. Now, your company, your manager, your skip-level manager might just throw all this out the window as soon as you've turned it all in, but they might also not be expecting actually useful OKRs with plans behind them.
SmokingPuffin@reddit
It is routine for staff and principal engineers to set such targets. Not very common below staff level.
You should view such an ask as an opportunity to call your own shots. Figure out what you personally want to make and draft a plan to go make it. Doing so successfully likely opens up doors, because hardly anyone at your level is going to succeed at this.
stevefuzz@reddit
This seems like a bullshit onboarding task that nobody actually cares about.
ewhim@reddit
We set annual top down goals where leadership defines goals, and we align our goals supporting management's goals.
Just make sure you set relatable goals that add value to your company's strategic objectived, otherwise you're chasing windmills.
DeterminedQuokka@reddit
It depends on the company and the level of impact you have. I personally don’t like them to have the second part unless you actually have full control of what gets released. My job does have stuff like that like X people will use feature. And because of that I tell engineers to ignore them because you can’t do anything other than build the backend endpoints so you can’t control who uses it.
Other places I’ve definitely had those kind of goals and they have been fine. I think for a goal to be meaningful you have to have control over if it is achieved. I had some goals around feature usage at my first job in teach but my team also had 100% control over that page.
Running an initiative is a lot for mid level unless it’s a smaller initiative. But it definitely happens. I was doing it at the last company I was at which was similar in size to yours.
liquidpele@reddit
No, it's normal to set 2 easily attainable goals and make them sound hard and ambitious, and then one hail mary goal that makes it look like you're actually challenging the status quo.
agherschon@reddit
Typical of a big corporate company.
Once I understood that I didn't fit there, I left to a small company at a much earlier phase in its life and I went from feeling very overwhelmed, stressed and depressed to calm and 1000% happier about my job, all for the same role on paper.
cran@reddit
What I love is when you spend the entire year being told that Product sets the roadmap for everything we do, then sitting down once and being asked to write up everything I plan to accomplish next year. Get out of here with that nonsense please.
nighhawkrr@reddit
You should talk to the business and listen to their biggest problems. Often the thing that would help the most is something they don’t ever ask for because they think it would be too much.
tom-smykowski-dev@reddit
It depends how it's carried out. In fact it may be a sign that company wants you to grow in that role, because business alignment is something skilled senior developers seek for. You move from thinking about code and implementation torwards thinking about product, business, operations and how your work improves these. I'd take it as a good sign
the300bros@reddit
Everything you do - if you’re good at it - becomes part of your toolbox and second nature. Then one day you realize you’re qualified for something way bigger than your title (at a lot of places) says. Sounds like your company is pushing you to be proactive about coming up with something valuable. Most places just wait for individuals who have that natural ability feel like pushing something.
ALAS_POOR_YORICK_LOL@reddit
Sometimes these goals are just a way to set you up for failure
d3nnska1337@reddit
It is normal and expected from a mid Level engineer. If you wanna BE a codemonkey who Just Push Tickets from left to right in JIRA you wont make it further than that.
Blue-Phoenix23@reddit
Stretch goals are very common, but are these on top of your existing duties and really feasible with the hours you have? If this is extra then you should figure out a way to set goals that are things you would have done anyway, that way you can actually accomplish them and not get penalized later for failing. Ask some of your co-workers what types of goals they set for ideas.
IProgramSoftware@reddit
Typical. Your idea but the ceo and the shareholders take most of the money you generate
fued@reddit
I've seen it a few times at bigger companies, although your example would be considered a bigger goal where there's a lot of history behind the relationship
It's usually something smaller, like contribute to a blog, run a lunch and learn, trial a few code reviewer tools to upgrade quality etc.
It's just professional development usually
drnullpointer@reddit
I don't find it strange at all.
Usually, I try to give ambitious projects to people who seem to be able to handle them. The level doesn't matter, what matters is that they seem to want / need an ambitious project and that they seem to be capable of completing it, meaning it is not too far from their comfort level.
I observed that good devs tend to grow up to the level of expectation put on them.
The only problem would be if the project is actually too ambitious for you. But this would not be your fault, it would be fault of whoever decided you should do it.