Ask HN: How do I become an asset to my developers?

FWIW, my favorite IT managers have been ones who, for example:

> That's one principle I try to follow - leave estimates to the ones doing the actual work.

And...

> In other words - I try to help them understand what the end goal/needs looks like, and I leave it to them to create the architecture and estimate the workload.

So it sounds like you're on the right track.

One last detail, which may or may not be relevant for your case: managers who can isolate us developers from being directly pestered by other management or sales/marketing folks have always been among my favorites. That is: a manager who insist that other teams do not directly come ask that manager's devs to take on tasks, instead filtering all such requests through the devs' manager. That's not nearly as common as i'd like to hope it is, and the managers who do that well have always had my loyalty for doing so.

i've been in several teams where the Marketing Folks were used to just walking to to the devs and "asking" them to take on specific tasks, completely bypassing the chain of command. Many devs aren't as stubborn as i am and will accept such tasks rather than complain about it. Great managers help ensure that that sort of violation doesn't happen more than once.

Well, you don't wind up in such a situation by being completely passive about it. In another thread this month somebody formulated something so succinctly that I bookmarked it, just to be able to quote it in appropriate situations:

"I also concluded that doing meaningless administrative/management work is addictive and those who engage in it will actively and constantly try not only to overemphasise their importance but also force themselves on top of those who they know are doing actual important work. This is in my opinion a form of understated and poorly understood violence, but also a natural survival instinct for those who feel themselves useless (maybe correctly) and must then fight to remain relevant at all costs." (https://news.ycombinator.com/item?id=39626648)

So, while I think the situation is inherently not solvable in some manner where there is a real value added by this kind of role distribution, I think your technical colleagues will see and maybe to some extend even appreciate if you muster the decency to to minimize the amount of time & energy you take away.

In general you are on the right track. One more thing you could do is align the priorities of stakeholders and keep them aligned for as long as possible. The thing that causes most problems in my team are the changes of priority on short notice. This causes a lot of unfinished work.

The reasons for these priority changes are to some degree our fault. We did not clarify our roadmap with all stakeholders involved. This lead to more powerful stakeholders adding features with more priority to our roadmap after we already started with the development of other features.

Developers like being involved in decision making processes. Probably more than they should be. Definitely a lot more than non-technical people think they should be.

Bring a couple of your senior developers, tech leads, or eng managers into the process early. Let them participate in things like project ideation and prioritization. It might feel unnecessary to you but it will go a long way towards the developers feeling empowered.

Developers hate having tickets thrown at them by non-technical people. They'll disagree with ideas, prioritization, etc. Getting them involved in that process helps reduce that feeling.

1. avoid teams, developers who just "hate" non-technical project managers. Either they lack experience or full of shit.

2. the most valuable thing developers appreciate in managers is the answer to question "WHY". Why are we building this? Why is this feature has such priprity? Why are we dumping this tool? Why should I care about the this type of users? etc.

3. the above implies first and foremost deep quality business domain knowledge, also care about the mission and the goal of the project, product.

4. the skill of breaking down complex ideas and goals into clear points, vision is a huge bonus

5. all the above does not require programming skills and is a full time hard work if you take it seriously

You might want to take a step back and think about how you ended up where you are. I mean no offense by this, but it's worth asking yourself why you're in this spot to begin with. The divide you're talking about? You've actually hit the nail on the head describing it.

Let's face it: you're in a role that might seem a bit superficial, and yes, the pay is more than generous. Maybe it's time to own up to that reality. Let the developers do their magic; after all, that's what they're here for.

There's this fascinating case about the EBT card system across different states in the US. They noticed something intriguing: a couple of states managed to roll out their systems smoothly, staying under budget and finishing early. So, naturally, everyone wanted to know their secret. Turns out, these successful states had one thing in common – they handed the reins over to the actual developers. No fuss, no frills, just straight-up development work, and it paid off big time.

On the flip side, the states that ended up way over their budgets and deadlines? Those projects were bogged down by external consultants and layers of consultancy. It's a clear message: sometimes, keeping it simple and trusting the people directly doing the work is the best approach.

> I realize there's a lot of "hate" towards non-technical it-project managers

That's probably not true. There's certainly some "hate" towards pointy-haired managers in technical projects which don't care about the technical view on the project. I've both been a project manager (with a technical background) and have had project managers without that background. Whether you're the "used to be a software engineer", "mechanical engineer" or "gender studies" type hardly matters, though, for the software engineer.

The projects with the biggest problems were generally those, where the project manager was disinterested in the technical aspects or didn't have the capacity to grasp basic concepts, in particular regarding interfaces and architecture. (I remember one particularly annoying project manager who sighed audibly in meetings that were specifically there to discuss interface details, if interfaces were discussed. Of course, she ended up not even understanding the top-level interface of the project she managed and thus we lost weeks during integration.)

So, if you feel like you're just taking notes and you can't contribute, I have one important point: Involve the other engineers. Ask questions if you're unsure. If you're insecure, believe me, they will in all likelihood already have sized you up and know your level of knowledge. There's nothing you can do to embarrass yourself and if you want to work as a team, it's important that they know what you know.

> Right now, I'm focussing on "shielding" my devs from managers/clients, by translating the business-needs of the clients to somewhat accessible backlog items (stories, features etc.) that I simply ask my team to complete with proper descriptions, estimates etc.

Engineers may or may not want that, depends on the details. In particular in agile-ish environments that shielding is considered not helpful. If the requirements are well-known and well-established beforehand, though, make sure that your translation does not introduce further confusion. (Typically, at least in formal projects, this is often done by establishing tracking between initial requirements and your specifications. Thus, your engineers can work on your interpretation and consult the initial requirements as well.) Shielding feedback is necessary if the feedback is obviously not helpful, unproductive or not in line with the project goals.

> given the fact that I'm in charge of progress and business outcomes?

This may be the most important point here, as this is (probably) your task: Track the state of the project, its progress, its impediments and keep the project in line and every stakeholder, including the engineers, informed.

You also need to understand the progress, as it can be tricky. A not well-understood progress may indicate 90 % completion, whereas you still need the same time you already needed to get it to 100 %. To understand whether this is the case, you need to be able to ask the right questions. I.e. if something an engineer tells you seems fishy, ask about it. If they have concerns, ask about them. Good engineers generally don't mind questions, so involve them to that degree in your job.

However, these points aside, there are a lot of other things that make people good project managers for engineers. For example, if you're in a high-conflict team you may need to help resolve conflicts. If you're in a slow team, you may need to push for a faster pace. If your engineers produce low-quality output you may need to tweak your requirements for more testing and accept that the estimations will go up.