[Aurornis]

> 1. If your manager has something in particular they want you to do, you should do it.

This point seems obvious, but it's one topics I've had to coach many early career people on over and over again.

Many of the people who were having difficulties or heading toward PIP could be turned around by implementing a simple loop where they:

1. Ask their manager for the top priority, explicitly. Re-confirm the top priority every time you encounter a question about what to work on or new information that might change the situation.

2. Write it down. Put it somewhere visible. Check it every morning. Remind yourself about the top priority.

3. Do the top priority until it's done. Confirm that your manager agrees that it's done when you think it's done.

It sounds simple to those of us who internalized these loops early in our careers, but some people don't see it so clearly until it's laid out for them. They get distracted, go on side quests, take too many tasks from people who aren't their manager, or avoid their manager's requests in favor of a task they find more interesting.

[maccard]

I completely agree. I've foudn that skill never goes away no matter how far you get. The trick is as you go higher up, spotting what comes next and knowing how to solve it faster.

> They get distracted, go on side quests, take too many tasks from people who aren't their manager, or avoid their manager's requests in favor of a task they find more interesting.

I had a great manager when I was fresh and I watched someone else on the team go down this path and succeed. I know now that the difference was that they knew what was going to bite us in 2 weeks/2 months, and that it was partially experience and partially they had info on where the project was going that I didn't. But had I looked at what they were doing and mimic'ed it, I would have failed.

[spdionis]

You can go on sidequests but first you need to accumulate sufficient credibility.

[rcxdude]

This is it, pretty much. If you do your own thing and it works, then you'll come out well. If you do your own thing and it fails, you'll look bad, while if you do what yiu're asked you're going to be much safer. So if you go off-piste you should have some confidence it'll work.

[maccard]

> if you go off-piste you should have some confidence it’ll work

Just remember that the definition of “working” is in the eyes of your manager. Assuming they’re competent and not pointy haired boss, then they might have different goals and priorities to you. I’d you end up diverging from them, even if what you did is technically good and a good fit for the project, you’ll probably have a bad time.

[rcxdude]

Yes, you do still need to solve a problem that is considered a problem and at least around the same level of importance of whatever you were supposed to be working on, preferably greater.

[monkeyelite]

> spotting what comes next and knowing how to solve it faster

This is such a strange mindset to me. Part of staff engineer is learning you don't need to solve tomorrow's problems. You solve it with the constraints you understand and leave room for expansion if needed.

Why do we have the opposite belief organizationally? And why as a manager would you want your top workers to be speculating about things you might want rather than achieving at the tasks you gave them?

(This is a genuine question.)

[maccard]

It’s obviously way more nuanced than 2/3/5 lines of text on both sides but;

It’s not about speculating vs achieving what I’ve assigned them. It’s an over simplified example but if an engineer has two tasks to be completed that are dependent, it’s poor engineering for task A have to be re-done for task B to work (imagine an API that has ambiguity in the definition of done). A good engineer thinks just a little bit farther ahead.

At a staff+ level, 8: expect them to not only consider that but to consider “how likely is it what I’m going to have to re do this work” and scope accordingly, or to come to me and say “hey, every feature we add to service Alpha, we end up having to do XYZ to it, but with Beta we don’t”. They spend 10x more time than me writing code so they know that better than I do.

My team know my priorities, know what I value and know the areas I’m keeping an eye on. If one person is continually going on unhelpful tangents then that’s a single person issue to be handled with them directly.

YMMV with team sizes, team maturity, and where you are with your product dev.

[monkeyelite]

That makes sense. I guess seeing the full lifecycle is always how I think about software I work on. I can do a better job of communicating that’s what I’m doing and why the approach I’m using (of doing less) actually helps us to be able to make changes.

[alchemism]

In certain tribal societies, there is no "chieftan" per se, there is just the guy who happens to be correct about things more than everyone else, so his opinion gets the most weight.

[notyourwork]

As a former engineer who recently transitioned to management, this is precisely how engineers who are competent are perceived as underachieving. Focus on the right problems, put side quests on the back burner.

[smcin]

But how do you know what the management perception is of whiat is currently considered to be 'the right problem' vs 'side-quest'? To what extent is that subjective and manipulable? Or that everyone in the management chain is fighting to maximize their perceived contribution to the former and minize their perceived contribution to the latter?

Without knowing the context, it's impossible to tell whether the key word in your sentence is 'perceived' or 'achieving' or 'focus'. Or what set of people shape the perceptions. Or on what KPI. Or what if there aren't even clear metrics. Most engineers like working on designing things, not executive palace coups.

(Corollary: have you never seen a group or entire dept get sidelined by being assigned something that they're officially told is important but at some point is publicly/secretly determined not to be, at some murky point up their management chain? What happens when the Director, VP, CXO are changed, perhaps multiple times, in a project?)

[Aurornis]

> But how do you know what the management perception is of whiat is currently considered to be 'the right problem' vs 'side-quest'?

You ask.

A large number of the problems I helped people work through while mentoring came down to engineers get stuck in their own head instead of communicating.

Whenever it's not clear, you communicate. Many companies have this as a daily update ritual in standup, but some engineers treat standup like a game where they have to say the right thing to get it over with as quickly as possible before going back to their computer and forgetting what they said they were going to work on.

If ambiguity persists, it's a good idea to write a short e-mail to your manager saying you're working on X instead of Y or Z because you think that's what's best, but then finish by asking them to let you know quickly if you got it wrong.

> Corollary: have you never seen a group or entire dept get sidelined by being assigned something that they're officially told is important but at some point is publicly/secretly determined not to be

No, I have never worked at a company so dysfunctional that management will make secret decisions but forget to inform the company, or make public decisions and an entire department will ignore them.

I don't get it. What's the incentive for anyone to do this?

Though I have worked with some people who would go off on their own tangents, then when the consequences caught up with them they'd concoct excuses about how it was never communicated to them (despite us pointing to records in Slack where they acknowledged) or elaborate conspiracies about management coming up with secret changes or something.

[jzig]

They are the one in a position of power. Why do I have to ask?

[submerge]

You don't have to do anything. But as you say, they are the one in the position of power. If you are working on some side quest they don't see as valuable, it may not end well for you. Doubly so if you are shirking what they see as a high value task for your side quest.

It's not about what is right or who "should" do what, it's about securing the best outcome by making sure you and your manager have the same understanding, even if your manager isn't doing a good job of making sure you have the same understanding. (Also known as "managing upwards.")

[smcin]

Obviously the context is after you and other people have asked; multiple times. You should interpret my comment with that reasonable preamble. And obviously as you say when people are being ambiguous or not communicating well, you memo what was communicated in writing. But that doesn't cure all organizational ills, not by a country mile.

It's nice if in your sample size you've personally only ever come across management chains that were trustworthy, competent and aligned. It's nice if you've only ever seen one unambiguous flow of truthful information from the bottom to the top and vice versa, and everyone's aligned to cooperate. But the alternatives abound.

I've seen (or been told of) directors battling other directors on organizational priorities, senior managers quietly undermining and deposing VPs so they could take their jobs, EVPs of sales selling capabilities that their own engineering had been telling them could never ship, the sales-side of an organization having a totally different roadmap than engineering and feeding it to a (nontechnical) CEO who couldn't tell which was accurate; CEOs putting out press releases about fictitious component their engineering was telling them they would not be available. Managers cheerily suppressing showstopper issue reports to send "mostly green/96% done"-type status reports up the pipe, on a project they knew to be doomed, before they completed their company-sponsored MBA then promptly jumped ship to a rival, and the company failed. Board members hyping underwater stock internally, only to quietly step down and immediately dump all their stock now they were no longer designated as privileged insiders. (Remember: once you go public, there are disclosure requirements and possibly shareholder class-actions, so even when something's universally known internally to be an issue, often executives can't acknowledge that, even internally (think "audit trail"); although you can infer a lot from their actions.)

Also you're presumably aware of some company cultures where internal secrecy and internal competition are fostered, pitting departments against each other (or at absolute minimum, where cooperation between departments is heavily discouraged, or punished). Or, in the middle of a product development cycle suddenly launching a "partner collaboration" or "strategic acquisition", where that is misaligned or competes with internal groups. Fear, intentional ambiguity, conflicting priorities as a management tool. Often this stuff is indirect evidence of conflicts at VP-level or higher; sometimes it's culture or force-of-habit.

Nobody said "forget" to inform the company or "departments ignoring clear and unambiguous directives". I implied misinforming or misleading groups/depts, or maintaining strategic ambiguity about what priorities were.

> What's the incentive for anyone to do this?

All of the above happen regularly, and it's pretty obvious what size and structure or organizations, and what individual metrics for compensation, and in particular when metrics are intentionally designed to be in conflict. For example, in a large company once you define separate "business units", people are overtly now working to differing metrics.

"conspiracies" and "go off on tangents" is a pretty disparaging way to misinterpret my question. You've never heard of any of the above ever being intentionally deployed? And "dysfunctional" might be our shared opinion, but I've heard from board members that passionately believe companies should be incentivized like that.

There's a reason Software Anti-Patterns (both technical and management) were recognized to exist several decades ago. [0] I think you're merely saying you haven't personally encountered them much.

For sure there are some engineers who treat standup like an annoying interruption to real work, or can't be articulate; equally there are scrum meetings where people play points hero or points olympics in inflating their perceived velocity. I've seen some adept operators nurse a weak spot in their part of the product so it could get closed then quickly reopened multiple times for multiple different customers, making them look great, but no mention of refactoring or adding testcases, or explanations of whether the thing was incorrectly closed or underestimated previously. Agile is only as good as the people overseeing it and measuring; it's easily gamed.

Communication does not happen merely because you mandate a 15-minute daily(/weekly) team meeting and tell people to do it; it only happens when people's official or unofficial incentives are generally roughly aligned to facilitate it. It's much easier to do that in a 10-person shop all working on the same product than 10,000 people, multiple teams, multisite, multiple products, dendritic orgchart, etc. You haven't really focused on the "managing perceptions" aspect of my question at all. There are certain breeds of middle-manager whose careers thrive on going into problem depts of large companies and cultivating the perception of them as firefighters/powerpoint-warriors, whether that's decoupled from reality or not, before they move on before the success/fail outcome becomes apparent. Again, misaligned incentives, and works best at the interface above which management stops being technical. If you're inside the dept in question, you can actually see how much of the perceived performance is objective verifiable fact vs managed perception. Or to put it another way to you, you've never seen people who are roughly as good as each other, yet one is more adept at managing perceptions?

It helps us gauge your personal experience if you tell us what size of team and organization and company stage (early starup/late-stage startup/small/large public company/etc.) you're anecdotally referring to.

[0]: https://en.wikipedia.org/wiki/Anti-pattern#In_software_engin...

[vineyardmike]

> But how do you know what the management perception is of whiat is currently considered to be 'the right problem'

Ask! Literally. But also listen.

Many people in management will repeat over and over that feature X is the thing they wake up thinking about, even though feature Y is important to the PM or director or whatever. Especially if you’re young enough that promotions and performance reviewed are really important for career growth, work on X not Y.

If your manager doesn’t start every meeting with some passive remark that project X is consuming their time, ask them what is important. Ask them what project they’re worried about.

Example:

“Hey Boss, I’ve been working on ProjY, but I also have tasks from ProjX pulled into this sprint. Which one is a bigger priority for the team, because I have 10 days of tasks, but only 1 week left in the sprint?”

… “hi boss, a week ago you told me to prioritize finishing X and not Y. Should I just allocate all of this sprint to the next set of tasks for X?”

… “hi boss. It’s me again asking this question every week “

If you want a good performance review/promotion/etc, usually that starts with your direct manager, so do what they think is important and ignore the rest. You need their trust first, so get it by working on their priorities. With their trust, you can get flashier or more fun work, or you can get them to trust you when you suggest alternative priorities, and you can earn the gossip/news they hear in management meetings from up the chain.

Your corollary is just rage-bait FUD or dysfunctional behavior. Any you can’t control it anyways so ignore it and focus on what matters that you can control. If your CXO doesn’t like what you’re working on, but your manager does, pick your manager, they actually write your performance review.

[roenxi]

Although we should notice the other side of that - managers that don't have an explicit onboarding where they lay that algorithm out for their reports are doing a terrible job. It is literally 3 lines. Lay it out at least once. Maybe go through it in a standup once a year. They are letting people slip through the cracks to the point where we have junior and even mid software engineers that don't realise there are priorities and that they should be working on them. Wow.

One of the reasons companies get dysfunctional is low- & mid-tier managers seem to be allergic to the idea of laying out what the priorities are and provide feedback on whether people are working on them or not.

[latchup]

> One of the reasons companies get dysfunctional is low- & mid-tier managers seem to be allergic to the idea of laying out what the priorities are and provide feedback on whether people are working on them or not.

Have you considered the possibility this is not a result of incompetence, but intentional? If these things are never clearly communicated and, more importantly, put in writing, management can just reframe what was agreed upon as best suits them later to deflect any blame if things go sideways. This is a perfectly rational move, since they hold all the power to do so.

I think a lot of what is wrong with this discussion is that people implicitly assume management is honest and communicates openly and sincerely. This is sadly only true in a small fraction of cases, likely because the incentives point squarely in the opposite direction: those who judge the game are always better off cheating.

[apwell23]

exactly. my last job the project i was working on suddenly became "my project" where manager wanted to "give me a win" by shipping. it became my project when we discovered all the way in the end that what he had come up with isn't viable at all. thing i was telling from the get go but he didn't listen and adamant that it would be fine.

we even had it in writing the i had objected to his scheme and that he overrode it but that document was completely hidden from upper managment.

[gmfawcett]

Very well expressed. That's great early-career guidance, but also a good refresher for many senior staff.

[Aurornis]

The simpler version is "Actually deliver on what you're asked to do".

It sounds so simple that people get offended when you say that. Yet it's at the root of a lot of employee performance problems where the employee is doing a lot of activity, but not delivering on expectations.

I've worked with some brilliant engineers who failed because they were always off trying to reinvent the wheel with their own completely unnecessary framework or rewriting some code that didn't need to be touched. In each case their managers were practically begging them to just focus on delivering the tasks they were assigned, but they were still surprised when the performance management actions came along.

[charlie0]

What do you do if your manager sends you on boondoggles of a project?