8 ms·

> probably not top 5-10%, because they also cared about the non-technical requirements that a good manager needs to cover It sounds like you're saying that top

• varjag 6y ago
  Essentially a manifestation of bikeshedding. Yep, very common.
  • skohan 6y ago
    Yes and it can go especially poorly when you have a "problem oriented" person on the team: 1. Manager proposes low quality requirements 2. Problem oriented team member points out a flaw in the requirements which is orthogonal to the actual goal of the feature/team/organization 3. Endless discussion around this one detail 4a. Manager changes the requirements just to end the debate, in a way which sacrifices the core goal and weakens the product/team/organization when there is a simpler solution available to reach the core goal OR 4b. Manager accepts an extremely complicated solution which maintains the specific requirement which was not required to reach the core goal in the first place, thereby risking the timeline
    • tomlagier 6y ago
      Oof. The number of 4b's I've had to deal with in my career... What are some techniques to use when you see this happening? I frequently try to get stakeholders to simplify and really identify the core problem / proposed solution, but I run into a lot of "all or nothing" or "design for every possible use case" folks in startups.
      • skohan 6y ago
        A couple approaches I have seen which can be effective are: - Call attention to the timeline and frame things in terms of specific tradeoffs: "Yes we can do A, but that means we won't have the time/resources to do B" - Propose an incremental approach. I.e. "There are some technical challenges with achieving A+B+C, so what if we start with A, and then asses the best way to reach B and C." With the incremental approach, I think this can help avoid the stakeholder feeling like they lost something, and 9 times out of 10 once you give them A they will find out that's all they needed in the first place, and they don't end up asking about B+C again.
        • slt2021 6y ago
          little bit of caution on "Yes we can do A, but that means we won't have the time/resources to do B" - this, along with Agile method of squeezing work every two weeks will lead to simply mediocre quality hacked together deliverables and accumulation of technical debt. Sometimes you need to spend time upfront and do it properly from the beginning, otehrwise the software quickly can become unmaintainable
    • datavirtue 6y ago
      Sounds like the text book description of how to start wrecking a software project.
    • nullsense 6y ago
      4b... Sums up the last 12 months of what should have been a 3 month project.
• RHSeeger 6y ago
  > having a thorough understanding of, or at least an accurate intuition around the subject matter. > they often work on the wrong set of parameters. Discussions often revolve around details which are not really important to the success of the project, There's a fairly large gap between those two positions. Personally, I'm a fan of a manager that knows enough to discuss the topic with me, but they don't need to know enough to analyze the problem itself. I want to be able to explain to my manager what the problem is, what the various solutions are, and which one I think is best and why. If they can understand all that, that's enough for me.
  • 0xEFF 6y ago
    I agree with this up to a point. It’s been valuable to me as an IC, and I feel it’s a value I provide when the problem is so hard there isn’t a clear solution. It’s nice to be able to say, “what do you think I should do?” as an IC, and nice to be able to analyze the problem if necessary as a manager. On the other hand if nobody knows what to do with a hard problem, everyone gets stressed out about it.
    • RHSeeger 6y ago
      > On the other hand if nobody knows what to do with a hard problem, everyone gets stressed out about it. Those are the problems that it's the developer's job to figure out, in my opinion. If the manager can figure out the problem and solution but the developer cannot, then the dynamic is backwards (or the manager is actually a dev/tech lead, not a project/product manager). Or it's a totally different team structure than I'm used to.
      • skohan 6y ago
        The reason I think it's good to have a product/project manager who can get down to this level if needed is that it increases the scope of possible solutions. With a strict division between tech and product, typically the solution space is bounded by the product requirements. But if you have a product manager who is able to operate on the level of implementation details, you can adapt the requirements in ways which are better on both a user side and implementation side. It shouldn't be the norm that a manager is operating on the level of implementation details, but it is good if they can understand them, because maybe they have more levers than the development team has access to in terms of unblocking a tricky issue.
• random314 6y ago
  Very often when folks describe the ideal manager, they are describing themselves.
  • Retric 6y ago
    That’s an interesting idea. Arguably my best manager had a graphic design and UI background. Where they excelled was having worked directly with software developers and non technical people for a decade they could understand the relevant tradeoffs without getting into the weeds. However, former software developers where generally much better the deeper and more relevant their technical background. Seemingly because they understand what to prioritize, but perhaps it’s was simply easier to communicate with them.
  • lbotos 6y ago
    A quote I stole from some conference talk that i think of all the time as a manager: "You become the manager you wish you had, you need to become the manager your reports wish you had."
  • Der_Einzige 6y ago
    Yes, and that's why worker self-management is the proposal one sees from any form of politics that doesn't care for managers -> https://en.wikipedia.org/wiki/Workers%27_self-management https://en.wikipedia.org/wiki/Workers%27_self-management To be honest, I would love to work for a place that implements self management even half hartedly. My understanding is that Valve is like that. Valve may not make things on the schedule that people want them to - but no one can deny that their quality is supreme.
    • skohan 6y ago
      My perception is that valve has suffered some negative experiences due to bad actors interacting with its radically libertarian labour practices. I don't have insider knowledge, so I could be wrong, but this is the sense I have gotten reading articles over the years about how the IP for VR was handled for instance
      • 6y ago
• danielscrubs 6y ago
  I agree, when I was working with small companies this kind of thinking was all too common: Can we make a Twitter clone in a week? “Yes it’s just a backend and a frontend.” Vs “with support for 187 million active users? Which level of accessibility? Will we have a cloud provider? Media upload support? Redundancy? What kind of login functionality? Do we have support if they loose their email account? Why are you looking at me like that? You know what: no we can’t do it. No I don’t care that your grandson thought anyone can do it”.
  • Guest42 6y ago
    And the common question..."How quickly can you do it if I add 10 people....ok 11, but no more, because we have to be mindful of cost"
    • ljw1001 6y ago
      This question depends more on the manager’s motives than on their knowledge.
  • chasd00 6y ago
    heh in the consulting world it's pretty common to be in a situation of "i signed a contract to deliver a twitter clone in a week, here's the kickoff date. get started."
  • 908B64B197 6y ago
    > Can we make a Twitter clone in a week? Yes. The v1 isn't the hard part of building a competitor to Twitter. The hard part is scaling the user base, getting funding to keep the site running and being able to grow it.
    • danielscrubs 6y ago
      V1 is a hard part, what you are talking about is the insanely hard part. ;)
      • 6y ago
• watwut 6y ago
  I agree, knowledge matters. It is pipe dream to think that empathy and people skills are enough for manager (or anyone) to compensate for lack of knowledge. Lack of technical knowledge does not imply neither peoples skills nor empathy. Technical knowledge does not imply lack of either Moreover, I found that non-technical managers had often trouble in empathy and people skills departments. I think that a lot of issues stemmed from non-technical manager having basically inferiority complex, confusing disagreement with disrespect, being unable to distinguish between mistake and lie. Moreover, not understanding culture technical people tend to create or even not being aware that there is such a thing as difference of culture. The cultural difference is a big thing - non-technical management in my experience value completely different things, ends up insulting engineers or otherwise creates difficult situations. All of that then implies that I as a programmer suddenly have to deal with interpersonal issues that manager created or is unable to deal with. The thing is, the choice is not between non-technical person with people skills and technical without. The choice is between person with technical knowledge and one without, where the one without them has also disadvantages in peoples skills.
• briankelly 6y ago
  > It sounds like you're saying that top-tier engineers are not generally qualified in terms of non-technical requirements, and I don't know that this assertion is justified. I see this sentiment or implication that technical skills and people skills are somehow mutually exclusive often, even on here which is crazy. I think this stems from some broader trope that people are "balanced" like RPG characters or something, e.g. nerd vs. jock or artist vs. scientist, salesman vs. accountant, etc. The reality is that people who achieve in one area are more likely to achieve in others. If someone figured out how to be a good engineer, they can probably figure out how to be a good manager, too, if they wanted.
  • TheOtherHobbes 6y ago
    They might. But it could easily take a few years, during which time they'll very likely be a mediocre to poor manager. Expecting someone with five years of engineering experience to become an effective manager overnight - often with no training or mentorship at all - makes as much sense as expecting an intern to operate at the same level as a senior on Day 1. Even really smart people with multiple talents need more of a warm up than that. And most people are neither that smart nor that talented.
    • skohan 6y ago
      But that's true of non-technical people too right? So the question is if you as an organization are considering investing a year or two to develop a manager, why not start with a subject matter expert?
      • deleted 6y ago
        [deleted]
    • datavirtue 6y ago
      Hopefully it is never an overnight switch and the engineer's career goals are respected. Any non-shite company is going to have engineers taking on leadership responsibilities at various levels they are comfortable with before turning them full loose. In some companies, like Gore Industries, and other employee owned entities the engineers and operations people organically select their own supervisors by consensus and set pay democratically. I have been in environments that did that without explicit structure even, and it was very productive. Unsurprisingly,none of those were publicly traded.
• ghaff 6y ago
  >top-tier engineers are not generally qualified in terms of non-technical requirements It's just that both sets of somewhat orthogonal skills are less likely to reside in one person. An analogy from baseball is why are pitchers generally lousy hitters (even pre-DH)? Did they get less practice? Probably. But it's also the case that (again even pre-DH) any ability to do more than lay down a bunt was absolutely a nice little bonus but their job 1 and 2 and 3 is pitching the ball. On the other hand, even the best fielding shortstop in the league still needs to have a half-way decent batting average, even if they can get away with a lower one than other positions.
  • ccmonnett 6y ago
    This analogy is interesting because it kind of proves you're both 'right', depending on the environment. In middle/high school, there is often 'that kid' who _is_ the best at all skills - they are the pitcher, they bat cleanup, they do everything. In the pros, though, that's virtually unheard of these days, because the amount of time it takes to specialize in a skill sufficiently to make it to the majors is so extreme it precludes you from being able to do that for multiple skills, with rare exceptions. Not disagreeing with you, or at least I don't intend to, but I definitely remember playing against 'that kid' when I played baseball in middle and high school. Same analogy for the kid who's great at several sports in HS but has to specialize to get the DI scholarship or go pro, etc.
• bumby 6y ago
  >it's not only about empathy but also about having a thorough understanding of, or at least an accurate intuition around the subject matter. I read the OP with a very different takeaway than what you may have inferred. I did not get the impression they were saying empathy and technical skills are mutually exclusive. By saying their best managers were in the top quartile, they are implying they were technically competent but not necessarily the most competent in a single domain.
• cwyers 6y ago
  Even if two traits are positively correlated, they can end up looking negatively correlated when you are selecting on those traits: https://twitter.com/page_eco/status/1373266475230789633 https://twitter.com/page_eco/status/1373266475230789633
• Guthur 6y ago
  And so will you then become a gradually worse leader as some of those engineering skills start to atrophy? The unfortunate truth is that you won't have the focus time to do large scale engineering tasks any more, unless you neglect your leadership responsibilities.
• taneq 6y ago
  > It sounds like you're saying that top-tier engineers are not generally qualified in terms of non-technical requirements, and I don't know that this assertion is justified. True, but your top-10% engineer who's also a top-10% manager is going to be 10x rarer and harder to find.