21 ms·

As an engineering manager myself I concur with all the points. Some of them are difficult though, for example: “optimize the dual objectives of delivering val

• dominotw 4y ago
  > To what extent should one allow suboptimal solutions 100% of the time. After all you can't count yourself being there to 'save the day' every single time, so whats the point of interfering here and there randomly.
  • havkom 4y ago
    I agree (with some reservations, see my other reply to my post)
• havkom 4y ago
  My approach so far is to be very very allowing —- until any failure becomes apparent and it can “naturally be discussed” (or it causes problems with colleagues in the group). This can be quite stressful though — I do not think the people reporting to me understands how much energy is spent as a manager negotiating with others in order to give the team and team members the most space/maneuverability that is possible.
  • chrsig 4y ago
    > I do not think the people reporting to me understands how much energy is spent as a manager negotiating with others in order to give the team and team members the most space/maneuverability that is possible Speaking from experience as an IC -- managers do an absolutely terrible job of surfacing what they're working on. What are you doing to broadcast your efforts? If you don't tell them what you're doing, you can't expect them to know if you don't tell them.
    • pkaye 4y ago
      Maybe use your one-on-one to discuss those things.
      • daok 4y ago
        I don't think 1-1 is the right time. If you have a team of 15 people, you would need to repeat the same thing 15 times. Better to give an update of what you are working on (as a manager) for the whole team once.
        • mateo411 4y ago
          That's a large team. I don't think it makes sense to have 15 direct reports. You probably want to split that into 2 teams so you can feed your team with two pizza boxes. If you do have a team that large, then you need to have a weekly or biweekly meeting with an agenda set beforehand. You can make announcements and possibly have a rotating presentation by somebody from the team about what they've been working on. If you are managing this many people, you are managing people, projects and comms.
• chrsig 4y ago
  As a non-manager, I find that having a company wide policy for what tech stacks are supported really helps with that particular concern. It should be a pretty easy "tap the sign" sort of thing. And engineers should be able to understand that technology spread has a very real cost that's hard to quantify. It also has that cost over time as long as the software they produce needs to be maintained. For things that are much more personal -- allowing suboptimal solutions for example -- those are teaching moments. You don't dictate the solution, you educate on the problems that the chosen solution exhibits and provide resources. Make requirements clear. There's a decent chance that if they're presenting a solution that you find suboptimal, then you haven't communicated the requirements properly. Surface them and re-scope the project as needed. Be sure to double check that the things you're finding as suboptimal are actually important as well. That is, don't be arrogant -- there's plenty of room for the error to be on you, and that you're assuming something may be suboptimal. Also consider that the person in the weeds may have more context than you, and there may be factors you're not considering. Rely on concrete things like tests and metrics to guide those discussions, so you're not evaluating on subjective matters. Don't put value judgements on solutions, frame things as decisions with trade offs. Those trade offs have ramifications that you can discuss, and together you can navigate to a workable solution. Ultimately remember that even though you could give into the urge to present solutions, it is not your job. Focus on your job, and help your reports do theirs. If you don't like that, get a different job.
• acjohnson55 4y ago
  It depends. Part of the job is being the leader is being able to foresee risks and consequences, and also to evaluate your constraints. Sometimes, you can let something be a teachable moment. Sometimes, you need to prevent a decision from creating problems or risks. Sometimes, your reports will do things better than you would have, and you're the one who learns a good lesson.
• jb3689 4y ago
  > To what extent should one allow suboptimal solutions, failure or allow employees to do things inefficiently with their “favorite tech stack” (in cases where it does not add business value) ? All solutions should be put out on the table as business tradeoffs. "It will cost X; we will get Y; we might run into unexpected problem Z". We all need to agree that we want to choose the best solution for the company, we lay out the solutions naked and vulnerable, we pick them apart, and then we make a decision. If we still can't make a decision, we let someone take the sword - potentially making a bad decision in the process - because we agree that forward progress is more important than total consensus. Will we always pick the best solution? No, but hopefully we've come to agreement as to what the pros and cons of each solution. We likely had to make a decision on several shades of grey. Still, we should be held accountable for our decisions regardless of how difficult they were
• sailfast 4y ago
  An underrated approach here is to ask questions if you think someone is making a mistake, and then see how they answer. "Oh, cool - why do you think X is going to be better than what we've been using?" etc. There's a huge difference between asking questions about an approach and prescribing an approach or saying "Nope that's not the right way" and there's a ton of room there to avoid the really suboptimal stuff.