3 ms·

I don't like appealing to authority, but I'll make a note for you that Camille Fournier is conventionally a pretty accomplished engineering manager and leader,

I don't like appealing to authority, but I'll make a note for you that Camille Fournier is conventionally a pretty accomplished engineering manager and leader, and her blog Elided Branches is full of tons of what I find to be really well thought out advice from both sides of the coin. It might make more sense to consider this post not in isolation, but in context of her previous posts. Certainly, this could be understood to be building on her previous thoughts there. But, you know what? As I've written this comment, I've realized that I do agree with some part of the spirit of your comment. I'll take a stab at addressing what you're pointing out: While I think that this post is meant to be a map for managers or tech leads, I find its conclusion to be unfortunately lacking: > Noticing how people get stuck is a super power, and one that many great tech leads (and yes, managers) rely on to get big things done. When you know how people get stuck, you can plan your projects to rely on people for their strengths and provide them help or even completely side-step their weaknesses. You know who is good to ask for which kinds of help, and who hates that particular challenge just as much as you do. > The secret is that all of us get stuck and sidetracked sometimes. There’s actually nothing particularly “bad” about this. Knowing the ways that you get hung up is good because you can choose to either a) get over the fears that are sticking you (lack of knowledge, skills, or confidence), b) avoid such tasks as much as possible, and/or c) be aware of your habits and use extra diligence when faced with tackling these areas. To a manager that is actively interested in mentoring and growing their engineers, this is horrible advice, frankly. It's horrible because it's essentialist, and it's not going to help you as a manager. The obvious first answer is "it depends" and "get more detail" -- rather than resigning yourself to the current state of who "is good to ask for which kinds of help, and who hates that particular challenge just as much as you do" it is better to figure out why things are a certain way for a certain individual getting stuck. Is it specific to them? Are there team to team dynamics getting in the way? Is a particular manager not integrating well into the rest of the org, and so their team takes the heat? Is another individual contributor within the org or team stonewalling them, perhaps unintentionally? Are the requirements unclear, changing, or in need to refinement? Without understanding this underlying context, it's impossible to get a sense for the institutional foundation your report or colleague is develeoping, evolving in, being rewarded and punished in. It's perhaps the most important part about developing an effective response as a leader -- you need to figure out the extrinsics that are shared before you can untangle that from the intrinsics, or you'll probably risk conflating the former with the latter. Perhaps, though, these kinds of utopian organizations exist where every problem an IC encounters is due to a lack of development or intrinsic ability that they must either work past or accept, and these other kinds of things I've pointed out never occur. I've certainly worked at smaller organizations where, due to sheer lack of complexity, these things aren't as big of a problem. But, at larger orgs, these things have always become an issue. As such, a huge amount of this blog post could be distilled into the values and skills of prioritization, thoughtfulness, curiosity, and communication. If you notice your teammates or reports having these issues, you should figure out which of one of these things you can help them with. This is mentorship work and coaching work -- it's high effort, high nurturing, high reward work. Once people feel supported and safe, they become orders of magnitude more effective at self-debugging any of these lower level issues she points out.

Benjammer 7y ago
Thank you for replying earnestly to what was probably an overly emotional and flippant response to this article from me to begin with. I couldn't possibly agree more with your description of subjective management, and the underlying context questions to explore with each subject individually. IMO, people management is literally the most subjective generally-applied skill on the planet. The reason that I came off like that in my initial comment is that the article gives me (an IC) the feeling of a manager expressing frustrations with ICs, in a way where it's mostly that the person seems to be frustrated that ICs are actually individual humans with subjective interests as well as competencies. The list seems to be pointing out areas where the "human" parts of curiosity, teamwork, and creativity poke through cracks in systems designed to treat the ICs like interchangeable parts. It's literally generalizing as the thesis of the article itself. It also comes off like it's written for other managers or tech leads to read in a sort of "virtue signaling"-ish tone. It's a list of high level vague points designed to land emotionally with other middle manager types. The only thing this seems to be telling me as an IC is that my feelings for how to add value are mostly wrong and I should just shut up and do what my manager says, because my assigned tasks are far more important than anything I could come up with on my on which to spend my time.

Benjammer 7y ago

Thank you for replying earnestly to what was probably an overly emotional and flippant response to this article from me to begin with. I couldn't possibly agree more with your description of subjective management, and the underlying context questions to explore with each subject individually. IMO, people management is literally the most subjective generally-applied skill on the planet. The reason that I came off like that in my initial comment is that the article gives me (an IC) the feeling of a manager expressing frustrations with ICs, in a way where it's mostly that the person seems to be frustrated that ICs are actually individual humans with subjective interests as well as competencies. The list seems to be pointing out areas where the "human" parts of curiosity, teamwork, and creativity poke through cracks in systems designed to treat the ICs like interchangeable parts. It's literally generalizing as the thesis of the article itself. It also comes off like it's written for other managers or tech leads to read in a sort of "virtue signaling"-ish tone. It's a list of high level vague points designed to land emotionally with other middle manager types. The only thing this seems to be telling me as an IC is that my feelings for how to add value are mostly wrong and I should just shut up and do what my manager says, because my assigned tasks are far more important than anything I could come up with on my on which to spend my time.