If you need to lobby for permission to work on something broadly within the scope of what you're paid to work on, you aren't being treated like a professional.

An issue tracker is a communication tool for use in the context of a largely self-directed activity. The only role at my company where your day-to-day activity is dictated to you by the tickets on your screen is customer support.

On my team, if you're only working the asks handed down from above and not proactively taking initiative to make things better, you're barely pulling your weight.

> On my team, if you're only working the asks handed down from above and not proactively taking initiative to make things better, you're barely pulling your weight.

The problem with a lot of engineers is that "make things better" often doesn't translate into "keeps customers happy and money coming in".

I could work on making our internal software "better" for the next two years but it wouldn't bring in enough money from customers to justify paying me to do it. And I'm smart enough to know that I have zero idea about what will make things "better" for the actual customers.

The customers will eventually suffer a death of a thousand cuts through quality and reliability issues if direct attribution to revenue / customer requests is a requirement to work on anything. But of course you can't rewrite ever time you hear about a new language. Obviously there's a balance, and striking that balance correctly is a huge part of the job.

If engineers really ran a company, progress will often slow down. For example, if you're surrounded but a lot of young talent, the phrase that you just constantly hear is "refactor". Not as many developers enjoy bug hunting as they do new feature development. I suspect that those of us who've been in the field long enough end up growing a much greater appreciation for PMs and they decisions they make make than when they first start out. Or maybe I've been fortunate to work with really great PMs?

It is important to strike a good balance. One should neither ignore input by the engineers, nor give them a completely free hand. Refactoring can be a benefit for the future, but it should not grind progress to a halt. Senior engineers should give valuable input there. And of course, sometimes a seemingly crazy idea by a young talent is actually a good one :).

So, you guys are all developers and product managers rolled into one? How do you decided what gets worked on?

By broadening your vision. As an engineer, it's easy for me to focus only on technical details. So I make an effort to see beyond that -- what is our org's broader goal; what are our industry's issues? It's not always easy, and sometimes I'm overwhelmed, but it helps build a common vision, which can be the foundation for teamwork across disciplines.

What I meant was: How do other parts of the organization know what's being worked on? How do marketing, sales, product management influence the decision making process? GP made it sound as if engineering on its own decides what improvement to work on next. How does that work in the context of the larger organization?

Taking the bigger picture into account when designing a solution is simply good engineering practice. I don't think that's what the GP was talking about.

The organization communicates extensively to select a set of projects (at a fairly abstract level of definition) each quarter. Engineering managers assign projects to engineers. As a project lead, you design an architecture and implementation, circulate an RFC, break down the work, write much of the implementation, and maybe delegate components to 1-2 more junior colleagues, mentoring them in the process.

The EM and PM are often in the room with you to support conversations with stakeholders/dependencies, absorb the brunt of cross-team communication, make tough prioritization calls, and to monitor the progress you report via the bug tracker and in weekly sprint planning sessions. The engineer is responsible for determining what part of the project to work on next, and how to spend each hour/day/week in the service of its completion. PMs/EMs are only going to challenge your plans if they're egregious, and it would be unwise to create a sprint plan that would require 100% of your time.

Most people have interviewing and mentoring to do, several previous projects that occasionally need their attention, code reviews to give, operational incidents to attend to, etc. even before you consider the undocumented tech debt fixes, refactors, and productivity investments that aren't necessarily even mentioned to PMs.

If you spend too much time on that, of course, you'll fail to complete your projects, stop getting interesting assignments, and have no hope of promotion. If you spend too little, however, your projects will turn out to be operational/maintenance nightmares that may even be worse for your reputation and prospects than vaporware.

Each engineer is their own architect and project manager, with the scale of the project tailored to the engineer's level. (You advance by earning and then succeeding at increasingly complex project assignments). Product managers help determine the vision of what the product ought to be; engineers get it there.

That sounds like a normal organization to me...

> Engineering managers assign projects to engineers

So engineers do only work on tasks handed down to them. We just did not agree on what "task" means.

Well ok. If "task" to you means a months-long initiative with hundreds of constituent parts, what do you call the items that take a few hours to a few days?

Task. But a three-month project is, at the abstract level, also a task. I misunderstood you, that is all that is happening here.