Show HN: I wrote a book for engineers that want to become engineering managers

I tend to assume that everybody else in the company knows that my team works in the way it does because that's how you deliver software successfully. Often, this comes back to bite when I learn that other managers think the team should be managed differently, and because I haven't made enough efforts to sell our methodology, those managers can have more influence than I'd like.

So, as an Engineering Manager, it's not enough that everybody in your team is happy and produce. You also have to be an advocate for your team to the rest of the company.

There are still roles that resemble the classical management role, i.e. there is a role that is responsible for setting strategies and assigning people into roles and monitoring role fit within their 'circle' (think team or business unit), called the circle's lead link. Yet there is a process for any role holder to propose putting those accountabilities into a new role or into a process. Role holders can also propose the creation of new roles or policies if they feel a tension. Then there is a structured process to deal with these proposals, and people need to demonstrate that the proposal would cause harm and reduce the capacity for the circle to achieve its purpose in order to have a valid objection. People in roles ultimately have ultimate autonomy on how they want to achieve their role's purpose. The lead link role can give relative prioritization if there are conflicts, but the lead link can't say 'you have to work on this right now and this is how you gonna do it'.

What ultimately happens is that the traditional accountabilities of a manger end up being distributed across multiple roles, so people might have software developer role, but might also be responsible for defining the hiring standards, or do people development etc.

It's kinda similar to the book "Turn the Ship around" where you don't have to ask for permission to do something and there is a process to address any tensions that arise from this power to act autonomously.

Moving from tangible daily outputs (code etc), to longer term feedback loops can be just as rewarding, you just need to step back slightly.

Empowering others to achieve their potential, watching them grow. Watching great products evolve. Understanding and directly influencing tech decisions. Being able to look further than the next sprint. Interfacing with external parties, seeing how they approach similar / new problem spaces.

IMO, this never gets boring.

As an example of something I personally struggle with: what's the best way to have the rest of the company know what all of our teams are working on without A) going into too much detail B) being obtuse C) opening ourselves up for miscommunication to customers or deadline promises D) giving ourselves room to fail, because not everything will work out.

The current iteration is a fortnightly newsletter that I curate between product and the engineering managers in the department and it gets sent around, but making everyone happy with it is /so/ hard.