3 ms·

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

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.

closeparen 9y ago
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.
- rowyourboat 9y ago
  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.
  - closeparen 9y ago
    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?
    - rowyourboat 9y ago
      Task. But a three-month project is, at the abstract level, also a task. I misunderstood you, that is all that is happening here.

closeparen 9y ago

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.

rowyourboat 9y ago
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.
- closeparen 9y ago
  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?
  - rowyourboat 9y ago
    Task. But a three-month project is, at the abstract level, also a task. I misunderstood you, that is all that is happening here.