Hacker News Reader

Comment by blowski | Hacker News Reader

I don't know whether it's in the book - perhaps it's in the "How to Win Friends and Influence People" chapter - but one thing I struggle with is communicating outwards and upwards.

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.

View on HN

To expand on your last point, I've found 90% of the success of your team is largely based on your team's ability to self-promote. I like to "talk up" my senior people when they're not in the room. This is the "upwards" part as a manager's influence is largely restricted to the management class. Most engineers roll their eyes and discount about 50% of what a manager outside their team says, so you likely won't be able to build credibility with them yourself no matter what you do.

The "outwards" part is teaching your team the right ways to evangelize to people on other teams at levels below you. They'll almost certainly be interacting with engineers on other teams, and the quality of these interactions is greatly enhanced with a combination of good documentation and good presentation skills.

This is so important that it doesn't really matter how good of a job your team does as long as they can talk about it in a positive way and work effectively with other teams. All of your "good engineering practices" should be geared towards enabling this kind of culture because the technical deficiencies in your code don't really matter.

> I've found 90% of the success of your team is largely based on your team's ability to self-promote.

This makes me feel bad about my past behavior. I've walked in on past managers when they've been talking about my accomplishments or background with other managers or company owners. My instinct, and the way I was raised (military family), is to play it down and be humble ("eh, it was a team effort", or "I was in the right place and right time") or make some self-deprecating joke, but now I can see I was likely (unintentionally) undermining my boss.

I had already realized this wasn't a good idea the last time it happened, and resolved next time to just smile and say thank you or something similarly neutral. However, this comment underlines how bad of an idea it is to play down your successes at work, even if it's in your nature (I've also had people openly tell me to be careful about this re: my own career).

I just can't stand people boasting about bullshit at work, and want to avoid coming across like that. But I'll be more careful about playing down my own successes now.

I totally agree on your final sentence there. There's a number of things in that chapter you mention, and there's also material on managing upwards earlier on in the book.

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.

You really hit the nail on the head there. It's so hard to give the right people the right information at the right time.

I like the idea of the newsletter. Do you focus mostly on achievements, or discuss 'ways of working' as well?

I'm really looking forward to the book, by the way.

Thank you!

The target audience for the newsletter was decided as "the busy exec". Not too much text, lots of gifs of functionality that we've built, etc.

There's some separate newsletters we do as well - there's a fortnightly "what's going on in the backend" one, curated by our infrastructure teams that's aimed at engineers.

Currently the general case newsletter goes to Engineering, Product, Product Design, and the exec group. We don't think it's quite good enough for the staff@ mailing list yet, but maybe we're just being over-cautious. It's really hard to get the balance right.

Gifs? Don’t low quality animations make it hard to read?

When they're embedded in a Google Doc, they're pretty good at getting the point across - then they can have a link to the app itself too.

We have an internal website with user-maintained groups/content. Every week, you get an email with major updates from the teams you want based on the important information they've been telling themselves. That's been useful for culling and focusing the information flow to each person.

In my experience, newsletters don't work well for internal communication. As you said, keeping the content relevant to a wide readership is too difficult. It does, however, work well as a recognition mechanism. A team seeing it's achievements blasted out to the company is very motivating, even if they are the only one's who notice it.

> Often, this comes back to bite when I learn that other managers think the team should be managed differently.

I’m going through this right now at my company, and it’s completely devastating our engineering org’s morale. I’ve never experienced anything like this.

Sounds like you and your colleagues are really going through a tough time there, sorry to hear that.

How and why is other teams managers opinion devatating the team you are in? Are they trying to meddle or force changes?

I've seen this handled by making a team charter. It describes who you are and what you do in a couple paragraphs (no more than a page). Put it in front of upper management for comment/approval. Share it widely and keep it on hand when meeting with upper management or other teams. Expect it to be a living doc.

Managing expectations is hard. Everyone will have different expectations of you unless you handle it for them.

Reply on news.ycombinator.com