Ask HN: How have you successfully managed upwards?
21 comments
This shouldn't be your job as a person writing software. This should be primarily on the manager and the PM org.
The first thing I would look at is - what is your request intake process? Are engineers being directly asked to do things? When scope is added, how is it added? There needs to be a handle on that, and depending on who has the "power" in the situation (sometimes product, sometimes engineering), those with the decision making power need to make a tradeoff between the newly requested work and the currently requested work.
Steps to achieve this:
1. Document every request coming in, in an issue tracker of some sort. If work is not tracked, it can't be prioritized. That includes requests from outside, and infrastructure/tech debt work going on within the team.
2. Start rewiring the requests through a TPM, or the person responsible for keeping up to date on the current priorities of the business. This both helps the engineers not get distracted, and provides the TPM an ability to ask about tradeoffs or balance priorities before it gets to the engineers.
3. Have the TPM start maintaining a priority backlog, with all the things that need to be done. Then, when a new high priority task comes in, the TPM can easily explain how this request effects other work. Often times the workload of a team is a black box to any requestor. Making it clear how many things have to be done can turn a "high priority" task into
4. Finally, start making the requesters horse-trade amongst themselves. When someone else's projects start being pushed around by another person's they tend to be able to hash it out between them what is the higher priority.
The first thing I would look at is - what is your request intake process? Are engineers being directly asked to do things? When scope is added, how is it added? There needs to be a handle on that, and depending on who has the "power" in the situation (sometimes product, sometimes engineering), those with the decision making power need to make a tradeoff between the newly requested work and the currently requested work.
Steps to achieve this:
1. Document every request coming in, in an issue tracker of some sort. If work is not tracked, it can't be prioritized. That includes requests from outside, and infrastructure/tech debt work going on within the team.
2. Start rewiring the requests through a TPM, or the person responsible for keeping up to date on the current priorities of the business. This both helps the engineers not get distracted, and provides the TPM an ability to ask about tradeoffs or balance priorities before it gets to the engineers.
3. Have the TPM start maintaining a priority backlog, with all the things that need to be done. Then, when a new high priority task comes in, the TPM can easily explain how this request effects other work. Often times the workload of a team is a black box to any requestor. Making it clear how many things have to be done can turn a "high priority" task into
4. Finally, start making the requesters horse-trade amongst themselves. When someone else's projects start being pushed around by another person's they tend to be able to hash it out between them what is the higher priority.
I think the ultimate issue is a moral one I'm unsure how to approach.
If companies encroached on my paycheck as much as they do on my time it'd be theft, and time is actually more valuable.
Edit: IANAL disclaimer... I'm sure it's not technically theft here... but it's pressure and I think the metaphor still holds.
Companies setting deadlines and not including developers in discussions is asking them to either: - Stand up for themselves, even though they have less power/don't want to risk their job - Spend more of their precious time on the company
I find myself repeatedly being pushed into the second option, and when I bring any of this up no one wants to tackle it at a systems-level... because the system is working as intended. Taking from those who can't or won't defend themselves seems to be how to be successful in business.
What's a good way to push back without looking like a dick or being shunted?
If companies encroached on my paycheck as much as they do on my time it'd be theft, and time is actually more valuable.
Edit: IANAL disclaimer... I'm sure it's not technically theft here... but it's pressure and I think the metaphor still holds.
Companies setting deadlines and not including developers in discussions is asking them to either: - Stand up for themselves, even though they have less power/don't want to risk their job - Spend more of their precious time on the company
I find myself repeatedly being pushed into the second option, and when I bring any of this up no one wants to tackle it at a systems-level... because the system is working as intended. Taking from those who can't or won't defend themselves seems to be how to be successful in business.
What's a good way to push back without looking like a dick or being shunted?
Wow. Really want to hear some answers here. Exact same issues.
Your two self reported flaws deserve some reflection IMO. Ask for help on them, whether from boss, coworker, mentor, or perhaps a therapist if you suspect a deeper issue is driving those. Especially the second one -- saying no and setting boundaries respectfully is paramount.
Regarding testing and tech-debt, those things don't drive business necessarily. Try thinking about what management is really after (it's not those two!) and find a way to deliver.
Related to the paragraph above, talk to the product manager, try to understand the user stories. Once you get a better idea of the forest through the trees, see if you can get yourself staffed on a high impact project. It's not always fair, but the devs who work on high impact projects (again, in the eyes of the business) have more leverage.
Hope this helps, best of luck. Happy to bounce some more ideas off you if you'd like.
Regarding testing and tech-debt, those things don't drive business necessarily. Try thinking about what management is really after (it's not those two!) and find a way to deliver.
Related to the paragraph above, talk to the product manager, try to understand the user stories. Once you get a better idea of the forest through the trees, see if you can get yourself staffed on a high impact project. It's not always fair, but the devs who work on high impact projects (again, in the eyes of the business) have more leverage.
Hope this helps, best of luck. Happy to bounce some more ideas off you if you'd like.
I agree.
I also hate that system though. Often the business can't see the forest through the trees and push back against tech or infrastructure upgrades until something breaks. I feel like it's better to fix the problem than kick it down the road.
I also hate that system though. Often the business can't see the forest through the trees and push back against tech or infrastructure upgrades until something breaks. I feel like it's better to fix the problem than kick it down the road.
I agree. I plan to solve them by prepping for tasks more (doing some of my own PM/BA work ahead of time, so I'm more aware of the roadmap), then being sure to pad the estimates more but also back it up because I will have thought the stories through more.
One thing that seems really strange to me, and I think will seem really strange to future generations... is the paternal tone of just about everyone regarding tech these days. The cherry-picking and bad faith arguments are almost insane sometimes.
One thing that seems really strange to me, and I think will seem really strange to future generations... is the paternal tone of just about everyone regarding tech these days. The cherry-picking and bad faith arguments are almost insane sometimes.
In my admittedly limited experience, I feel confident that my work is valuable enough for a company to not drop me, and choose not to question my self worth. I work at a startup, I always feel behind since there's always a lot of work - but I also know that if I burn both ends of the candle, I'll still feel that way, so I choose not to.
Whenever you do something at a company you're not just doing that thing, you're communicating to others what they can expect from you. So if you don't want others to expect that you'll work long hours - don't work long hours! See if it actually, really materializes into bad performance reviews; if it does, work on your efficiency, not the number of hours spent; if it doesn't, you just won yourself work-life balance.
Whenever you do something at a company you're not just doing that thing, you're communicating to others what they can expect from you. So if you don't want others to expect that you'll work long hours - don't work long hours! See if it actually, really materializes into bad performance reviews; if it does, work on your efficiency, not the number of hours spent; if it doesn't, you just won yourself work-life balance.
I agree with this comment. The single best thing you can do for you career is to learn how and when to say no.
What’s helped me feel comfortable saying no to project scope creep or decisions that will result in overtime is the fact that if projects run over time then it is a failure on managements side; they are responsible for the resources provided and the end deliverables.
Managers will (often) not tell you to work less, they will always find work to fill the time you’re willing to work so it’s very important you place boundaries.
You can place boundaries in two ways, explicit and implicit. 1) An example of an explicit boundaries would be informing the PO during a standup that their feature request will result in you working weekends which you won’t do. 2) An implicate boundary would be not responding to emails, slack messages or PR outside office hours.
What’s helped me feel comfortable saying no to project scope creep or decisions that will result in overtime is the fact that if projects run over time then it is a failure on managements side; they are responsible for the resources provided and the end deliverables.
Managers will (often) not tell you to work less, they will always find work to fill the time you’re willing to work so it’s very important you place boundaries.
You can place boundaries in two ways, explicit and implicit. 1) An example of an explicit boundaries would be informing the PO during a standup that their feature request will result in you working weekends which you won’t do. 2) An implicate boundary would be not responding to emails, slack messages or PR outside office hours.
> The single best thing you can do for you career is to learn how and when to say no.
The hard part is turning off the voice of "What do you mean you don't know? I just want want a rough estimate! What is your fucking problem?" in your head. There are a lot of people who simply do not understand the concept of someone else not knowing how to find the answer to a question. Sometimes, those people ask for software estimates.
It can be nausea-inducing to do, but if you do not know how to estimate software tasks, there is no healthier option than telling these folks the honest truth.
The hard part is turning off the voice of "What do you mean you don't know? I just want want a rough estimate! What is your fucking problem?" in your head. There are a lot of people who simply do not understand the concept of someone else not knowing how to find the answer to a question. Sometimes, those people ask for software estimates.
It can be nausea-inducing to do, but if you do not know how to estimate software tasks, there is no healthier option than telling these folks the honest truth.
This is definitely a problem. I'm also beginning to believe I should pad the estimate and also tell them "I padded it in case something goes wrong".
Another hard thing to say is 20% of my time is meetings, and those aren't all in 1 block, so I have less time and I'm less efficient.
Finally, I'm beginning to believe you should do your own sprint planning as a dev quick before sprint planning with the group. Otherwise you get talked into half-baked stories with no acceptance criteria and a terribly short estimate.
They want you to keep them honest when it's all theoretical... but not when you're actually doing the work.
Another hard thing to say is 20% of my time is meetings, and those aren't all in 1 block, so I have less time and I'm less efficient.
Finally, I'm beginning to believe you should do your own sprint planning as a dev quick before sprint planning with the group. Otherwise you get talked into half-baked stories with no acceptance criteria and a terribly short estimate.
They want you to keep them honest when it's all theoretical... but not when you're actually doing the work.
Late but - often what I do is, if a task is big enough that I don't feel I can really estimate it, I decline scheduling that task in a sprint, and instead schedule a research task to explicitly spend time scoping/speccing out a complex task. During that time I try to make smaller, stepping stone tasks that I think I can reasonably estimate. I intentionally pad those a bit, and also say that I gave some buffer to account for unknown unknowns, which is a reasonable thing to do.
Also, asking other people on your team to talk it through with you is a good idea as well - they can help you see some unknowns you might have missed that would have blown up your estimates, and also give their take on effort required. If you're uncomfortable with saying you want to work with someone because you don't feel confident in designing a solid solution, you can still couch it in other terms, like that you want to bounce ideas off of someone else on the team, parallelize your work by delegating subtasks, or make sure others on your team are familiar with the design and implementation - all legitimate reasons to work with others, but also that deflect a feeling of just "not knowing".
Also, asking other people on your team to talk it through with you is a good idea as well - they can help you see some unknowns you might have missed that would have blown up your estimates, and also give their take on effort required. If you're uncomfortable with saying you want to work with someone because you don't feel confident in designing a solid solution, you can still couch it in other terms, like that you want to bounce ideas off of someone else on the team, parallelize your work by delegating subtasks, or make sure others on your team are familiar with the design and implementation - all legitimate reasons to work with others, but also that deflect a feeling of just "not knowing".
> scope constantly added, never time for anything
I thought I could solve this problem at my last job by finding enough efficiencies in our workflow to make all our jobs easier. I accomplished my goal, but it didn't have the intended effect. What it meant was that management could then hire more people and give everyone even more work to do, so we ended up back in the same situation, or maybe even a worse situation, than we were originally.
I thought I could solve this problem at my last job by finding enough efficiencies in our workflow to make all our jobs easier. I accomplished my goal, but it didn't have the intended effect. What it meant was that management could then hire more people and give everyone even more work to do, so we ended up back in the same situation, or maybe even a worse situation, than we were originally.
The repeated pattern that I have observed is that companies want to hire talent. They screen for this in all the ways they can think of. Once hired though they really wanted mediocrity and trend followers, people reliant upon popular tools that do a measurably significant part of their job. This pattern seems common and repeatable for jobs dedicated to product development and not jobs focused on research or experimentation.
The described pattern is most explicit when the work performance expectations and means of execution directly contradict points and values expressed during the interview. These interview discussion points aren’t some slight hints, but are things raised intentionally by the candidate to avoid poor practice and these are things that win the candidate points during hiring selection.
I suppose the cause of this repeated pattern isn’t the management, at least not usually. The company really sincerely wanted to hire talent but cannot apply the talent they want and selected without raising some concern and insecurity from other employees. For this particular pattern of failure there is nowhere to mentor up, because typically management is not the problem and sympathize with the concerns. When management is the problem mentoring up is counter productive in that their insecurity increases. Typically the people experiencing this problem are less concerned with job security and more concerned with walking a tightrope between burning bridges and building products that resemble dumpster fires.
The described pattern is most explicit when the work performance expectations and means of execution directly contradict points and values expressed during the interview. These interview discussion points aren’t some slight hints, but are things raised intentionally by the candidate to avoid poor practice and these are things that win the candidate points during hiring selection.
I suppose the cause of this repeated pattern isn’t the management, at least not usually. The company really sincerely wanted to hire talent but cannot apply the talent they want and selected without raising some concern and insecurity from other employees. For this particular pattern of failure there is nowhere to mentor up, because typically management is not the problem and sympathize with the concerns. When management is the problem mentoring up is counter productive in that their insecurity increases. Typically the people experiencing this problem are less concerned with job security and more concerned with walking a tightrope between burning bridges and building products that resemble dumpster fires.
There was a similar thread few weeks ago, my take was along these lines:
In this day and age the only way for most companies to beat the market is to deliver fast, what engineers perceive as quality doesn't make sense from a business perspective.
If you want to work on high quality software you can either work in open source projects which have high quality code or avoid highly paying startups and move to an industry that cannot afford low quality software. These industries are usually boring, in the sense that they use old programming languages and frameworks that "just work". They have policies and amounts of bureaucracy/paperwork to go along with it and ensure quality, security and compliance at all levels.
There might be a sweet spot between the extremes, but I never came across one to be honest. My experience is mostly with the first group, which I must say that for all the whining "about quality" and "developers <...>" I most definitely enjoy and to a large extend accept the flaws because I understand the reasoning that goes with it. I'm putting a fight ofc as you do, when I believe quality must improve, but that's about it.
In this day and age the only way for most companies to beat the market is to deliver fast, what engineers perceive as quality doesn't make sense from a business perspective.
If you want to work on high quality software you can either work in open source projects which have high quality code or avoid highly paying startups and move to an industry that cannot afford low quality software. These industries are usually boring, in the sense that they use old programming languages and frameworks that "just work". They have policies and amounts of bureaucracy/paperwork to go along with it and ensure quality, security and compliance at all levels.
There might be a sweet spot between the extremes, but I never came across one to be honest. My experience is mostly with the first group, which I must say that for all the whining "about quality" and "developers <...>" I most definitely enjoy and to a large extend accept the flaws because I understand the reasoning that goes with it. I'm putting a fight ofc as you do, when I believe quality must improve, but that's about it.
Yeah I think poor use of logic is most of the problem. No one's 100% logical... but you get pulled into these discussions asking just how quickly you can get this out... and it just repeats. At the start of the project they'll talk tech debt/spikes/whatever... but as you keep going it's just churn and burn and you really have to do extra/free work if you want to inject more quality.
There's definitely a spectrum from trash to gold plating... but most web shops are in 0 danger of wasting time or gold plating.
I understand the need to go faster from a business perspective... what I don't understand is the lying. Why not just tell us what the plan is so we can plan accordingly?
There's definitely a spectrum from trash to gold plating... but most web shops are in 0 danger of wasting time or gold plating.
I understand the need to go faster from a business perspective... what I don't understand is the lying. Why not just tell us what the plan is so we can plan accordingly?
I kind of do though still learning to get better at it.
The dev process at our company is mixture of Agile and Waterfall. Management wants to know when a large project with several unknowns will be done. There is no way to give a realistic estimate. The management says that it is just an estimate and they won't hold it against us. And we can revise it as we learn more.
In past, I gave rough estimate with some padding but that bit us, because, actual work was more than my rough estimate. And my manager completely forgot that it was supposed to be rough estimate. Product owner started whining about all the marketing they had done, some higher ups got involved. We start having daily meetings to discuss exactly what we did yesterday in addition to daily standup. Some late nights and weekend work. Overall, horrible experience.
Then I decided I will not give estimates no matter what. My manager scheduled a meeting with me and a her director. Where they kind of used police interrogation tactics, asking same thing again and again. They were supposed to help me break down overall project in smaller pieces and then estimate each piece. BTW, I am tech lead but not project manager. I tried my best but broke down and worked with them to come up with an estimate with a lot of padding. That was not good, so in further meetings they cut out some features and asked me to lower the estimate. They repeated same thing that it was just a rough estimate, we would not be held to it. Of course, when deadline got closer, they started to panic and told me that I chose this deadline and our team needed to meet it.
This just pushed me to not give a fuck. I started interviewing and got a few job offers. These offers were not great but I still was willing to move. I told my manager that I was failing in lead position, so I need to resign and go back to dev. She told me that after this project, I can go back. But when she found out that I already had a job offer with more money as a dev. Management panicked and they countered and extended deadline.
I took the counter offer because I was not excited about other company but they liked me enough and said I have a standing job offer any time.
After going through that I learned a few things about managing upwards.
1. Be willing to walk away. 2. Raise dev issues as early as possible. If you had estimate that something will take 2 days but it took 3 days, bring it up in scrum. Make a big deal. Tell management that this probably will impact deadline. Same if you get sick. 3. When they ask you to estimate unknown work, ask the about unknown work. They will connect with you might five you some insight but usually not. Just repeat to manager that was not useful. 4. Always talk about how good industry and how you are networking all the time. This sends the message that you can walk away at if they try to push you. 5. Never ever work more than 40 hours a week. Even if you are bored at home and want to work, do your own project. Once you agree to work one of your weekend, management will consider you pushover and you will work a lot of weekends. At my large company, my team and I have not worked weekend for almost 2 years. But it is very common for other teams to work a few weekend every quarter.
The dev process at our company is mixture of Agile and Waterfall. Management wants to know when a large project with several unknowns will be done. There is no way to give a realistic estimate. The management says that it is just an estimate and they won't hold it against us. And we can revise it as we learn more.
In past, I gave rough estimate with some padding but that bit us, because, actual work was more than my rough estimate. And my manager completely forgot that it was supposed to be rough estimate. Product owner started whining about all the marketing they had done, some higher ups got involved. We start having daily meetings to discuss exactly what we did yesterday in addition to daily standup. Some late nights and weekend work. Overall, horrible experience.
Then I decided I will not give estimates no matter what. My manager scheduled a meeting with me and a her director. Where they kind of used police interrogation tactics, asking same thing again and again. They were supposed to help me break down overall project in smaller pieces and then estimate each piece. BTW, I am tech lead but not project manager. I tried my best but broke down and worked with them to come up with an estimate with a lot of padding. That was not good, so in further meetings they cut out some features and asked me to lower the estimate. They repeated same thing that it was just a rough estimate, we would not be held to it. Of course, when deadline got closer, they started to panic and told me that I chose this deadline and our team needed to meet it.
This just pushed me to not give a fuck. I started interviewing and got a few job offers. These offers were not great but I still was willing to move. I told my manager that I was failing in lead position, so I need to resign and go back to dev. She told me that after this project, I can go back. But when she found out that I already had a job offer with more money as a dev. Management panicked and they countered and extended deadline.
I took the counter offer because I was not excited about other company but they liked me enough and said I have a standing job offer any time.
After going through that I learned a few things about managing upwards.
1. Be willing to walk away. 2. Raise dev issues as early as possible. If you had estimate that something will take 2 days but it took 3 days, bring it up in scrum. Make a big deal. Tell management that this probably will impact deadline. Same if you get sick. 3. When they ask you to estimate unknown work, ask the about unknown work. They will connect with you might five you some insight but usually not. Just repeat to manager that was not useful. 4. Always talk about how good industry and how you are networking all the time. This sends the message that you can walk away at if they try to push you. 5. Never ever work more than 40 hours a week. Even if you are bored at home and want to work, do your own project. Once you agree to work one of your weekend, management will consider you pushover and you will work a lot of weekends. At my large company, my team and I have not worked weekend for almost 2 years. But it is very common for other teams to work a few weekend every quarter.
>I'm tired, HN. I'd like to make at-least-ok software in 40h/week and have a life outside of my work laptop.
I didn't go that route because I'm probably not in your situation.
We build custom data products for enterprise. I wanted the CEO to find clients, close deals, and network. I wanted the CTO to make technical decisions and pick from a collection of implementations. I wanted our machine learning practitioners to dive deep in our clients' data and build models. I wanted to leverage their comparative advantage. I wanted people to do what they're good at, be successful, and deliver value for our clients effectively, efficiently, consistently, and repeatably.
Whenever I caught our CTO, CEO, or data scientists doing something I could do, I would push them to do something I could not yet do and take care of whatever they were doing. If they were doing something I knew I could stretch a bit and be able to do, I would go for it and ask for corrections, but the bulk would have been done.
That meant owning everything as an individual contributor. The code to do something, the docs, the deployment scripts, the issue templates, the design of the product, working on modularity, focusing on "the job to be done", improving development workflows, documenting findings in a knowledge base that became a seed of our knowledge base, working on onboarding. The business side, better communication and marketing strategies, improving ways to help our clients pinpoint the problems, interfacing with domain experts in different functions, proof reading emails and reports, even making LaTeX templates for our reports and invoices because I wanted them to be beautiful. Later documenting how to operate the company in an "Operator's handbook", finding better abstractions. Post mortems and root cause analyses on failures. Why did a project fail, why did another succeed, why did someone quit, are there patterns. Everything is dissected to amortize the experience. We had paid the price, we definitely ought to keep the learnings. [that meant going over email exchanges of past projects and decisions and "replay" them]
It required a lot of comparative reading about a lot of subjects and leveraging past learnings from a period I read voraciously.
I wanted us to become more efficient and effective in delivering value to those who trusted us.
I'm not smart enough to pull that off in 40 hours/week, as that's basically two work days. I worked everywhere, while commuting, during the week-end. I'm not in your situation so that might not be possible, but the core message is to increase the likelihood of people succeeding at their job in a repeatable manner that doesn't need my presence. Increasing the likelihood of success for projects. Helping clients be successful. "Institutionalizing knowledge" for every single part of the company.
I didn't go that route because I'm probably not in your situation.
We build custom data products for enterprise. I wanted the CEO to find clients, close deals, and network. I wanted the CTO to make technical decisions and pick from a collection of implementations. I wanted our machine learning practitioners to dive deep in our clients' data and build models. I wanted to leverage their comparative advantage. I wanted people to do what they're good at, be successful, and deliver value for our clients effectively, efficiently, consistently, and repeatably.
Whenever I caught our CTO, CEO, or data scientists doing something I could do, I would push them to do something I could not yet do and take care of whatever they were doing. If they were doing something I knew I could stretch a bit and be able to do, I would go for it and ask for corrections, but the bulk would have been done.
That meant owning everything as an individual contributor. The code to do something, the docs, the deployment scripts, the issue templates, the design of the product, working on modularity, focusing on "the job to be done", improving development workflows, documenting findings in a knowledge base that became a seed of our knowledge base, working on onboarding. The business side, better communication and marketing strategies, improving ways to help our clients pinpoint the problems, interfacing with domain experts in different functions, proof reading emails and reports, even making LaTeX templates for our reports and invoices because I wanted them to be beautiful. Later documenting how to operate the company in an "Operator's handbook", finding better abstractions. Post mortems and root cause analyses on failures. Why did a project fail, why did another succeed, why did someone quit, are there patterns. Everything is dissected to amortize the experience. We had paid the price, we definitely ought to keep the learnings. [that meant going over email exchanges of past projects and decisions and "replay" them]
It required a lot of comparative reading about a lot of subjects and leveraging past learnings from a period I read voraciously.
I wanted us to become more efficient and effective in delivering value to those who trusted us.
I'm not smart enough to pull that off in 40 hours/week, as that's basically two work days. I worked everywhere, while commuting, during the week-end. I'm not in your situation so that might not be possible, but the core message is to increase the likelihood of people succeeding at their job in a repeatable manner that doesn't need my presence. Increasing the likelihood of success for projects. Helping clients be successful. "Institutionalizing knowledge" for every single part of the company.
Some of my flaws: - Not padding estimates enough - Agreeing to to much (and too wide a variety of work)
Pattern: 1. Place says all the right things (we work on tech debt, testing, etc) 2. I start working there 3. I do the things in the flaws list above 4. (1) was a lie, scope constantly added, never time for anything 5. Leave for new place
Some of this is definitely my fault, but some of it seems to stem from:
- It's hard to push back when the power dynamic isn't in your favor - Our industry is young - Management seems to want to "churn and burn", even at small companies. Deadlines over everything, even when times are good
This leads me to my question:
How have you successfully "managed up" when you were an individual contributor and didn't want to lose your job, but management politely patted you on the head and acted like they knew better. Do you build relationships? Get them to like you? Work lots of overtime? Keep quitting until you find a place that isn't about churn and burn?
I'm tired, HN. I'd like to make at-least-ok software in 40h/week and have a life outside of my work laptop.
Thanks for your time.