How have you successfully managed upwards?

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.

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.

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.

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.

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

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.

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

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