4 ms·

The amount of meetings need to be cut down for engineers...

• senttoschool 4y ago
  Sure, just have no meetings at all. Just send you tickets with perfect specs. You'll never have to talk to anyone.
  • dev_0 4y ago
    I mean the middle men meeting where someone translate business requirements to technical solutions. Engineers should be treated as problem solver and not code monkey
    • senttoschool 4y ago
      You mean a product manager? You do realize that most engineers would hate to have to do the work of a PM? Talking to users. Analyzing data. Coming up with solutions. Convincing executives. Convincing designers. Convincing dev managers. Convincing devs. Writing specs. Handholding the project through the finish line. You told me you don't want more meetings. But you realize that you'd have to have a ton of meetings to do the above? You think a spec just magically shows up and a ton of work was not done before it ever makes it to your queue? >Engineers should be treated as problem solver and not code monkey Engineers solve technical problems. Some engineers want to solve business problems too. Those might be good candidates to become product managers.
      • icedchai 4y ago
        Based on previous experience at a SV "unicorn", more often than not, a ton of work was not done. The "specs" were vague and poorly written. "Lacks attention to detail" is how I would describe most PMs at that place. I think they had a 1:1 ratio of PMs to engineers.
        • senttoschool 4y ago
          Never heard of a 1:1 PM to engineer ratio. Usually it's 1 PM to 3-6 devs. I was a PM for many years. Now a tech lead dev. My job as a PM was significantly harder and more stressful than being a dev.
          • icedchai 4y ago
            I was only slightly exaggerating. Though I do remember being in my daily standup, and regularly there were 3 engineers, a dev manager, 2 PMs, the product directory, and a designer of some sort.
    • jerf 4y ago
      The translation is a legitimate skill that should not be underestimated. Especially when you add in that there ought to be flow the other way as well. As an engineer, I want to be involved early in the business processes, because as we all know sometimes business people assume that very hard things are easy, but sometimes there is something I can offer them that they don't have any idea is easy. It's best to work through the cost/benefit process together, rather than the business people huddling in a corner before flinging over a set of requirements to engineering as Holy Writ. (Kinda struggling with that now; I'm peripherally involved in a project with big monetary implications. The "solution" is to build a big system as quickly as possible and run around making super-high-priority requests across a whole lot of teams, almost all of which need to be in place before any value is obtained, and which consequently is behind schedule and dragging out. On the other hand, a week, some database queries, and a reasonable amount of manual labor could get about 50-75% of the value now. But none of the project managers are interested in that fact, which frankly boggles my mind. I'm not sure if they just don't understand what I'm saying, or are just so stuck on the solution they designed that they've lost all ability to think outside it. One thing I have confirmed is that it isn't just that I don't have a full picture of the problem, which is the usual situation; I'm quite confident what I'm thinking would work.) However, while that skill is not necessarily something you need a graduate degree for and 20 years dedicated experience, and engineers can pick it up, there are engineers who don't have it yet, or even won't pick it up because they despise it. The list of skills required to be an engineer is already pretty long, requiring this to be added as well raises the bar even higher.