
Ask HN: How have you successfully managed upwards? - throw4238
I&#x27;ve noticed a pattern in my professional life I&#x27;d like to break:<p>Some of my flaws:
- Not padding estimates enough
- Agreeing to to much (and too wide a variety of work)<p>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<p>Some of this is definitely my fault, but some of it seems to stem from:<p>- It&#x27;s hard to push back when the power dynamic isn&#x27;t in your favor
- Our industry is young
- Management seems to want to &quot;churn and burn&quot;, even at small companies. Deadlines over everything, even when times are good<p>This leads me to my question:<p>How have you successfully &quot;managed up&quot; when you were an individual contributor and didn&#x27;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&#x27;t about churn and burn?<p>I&#x27;m tired, HN. I&#x27;d like to make at-least-ok software in 40h&#x2F;week and have a life outside of my work laptop.<p>Thanks for your time.
======
presentation
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.

~~~
rusty-rust
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.

~~~
afarrell
> 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.

~~~
throw4238
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.

~~~
presentation
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".

------
austincheney
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.

------
atmosx
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.

~~~
throw4238
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?

------
taurath
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.

~~~
afarrell
> steps to achieve this

To clarify, you mean this as hypothetical advice for a Tech Lead, right?

~~~
taurath
Yes - if you're not a lead in any sense its unlikely you'll get buy-in.

------
dorkwood
> 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.

------
syndacks
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.

~~~
throw4238
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.

------
blitz_skull
Wow. Really want to hear some answers here. Exact same issues.

------
Jugurtha
> _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.

------
ddeFWEFE
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.

