I blogged about this a while ago and just grabbed it to send to a friend!! cate.blog/2018/01/30/managin…

Identify the type of leader they are can help you present info to them in a way they will absorb it best - do they make decisions based on data, visuals, or intuition? Using the right tools you can let them know your vision for yourself and how they can help

Joint efforts: shipping stuff, but also leveling up you, leveling up your manager (it cuts both ways!), leveling up your colleagues, your org. All sorts of things. Identify what you’re both aiming to do and make plans.

We tend to view “managing up” as a coping mechanism for management failure. Rather we should view the IC-Manager relationship as the partnership it is. We have strengths and weaknesses; so do they. Identify them - together! - and see how to move forward effectively.

We’re not always lucky enough to get a manager who understands what we need to be successful. And sometimes we have to work with new managers who recently switched from an IC track. What are some of your tips for managing from below?

Team leads: have you ever thought about reviewing last sprint’s code reviews to help influence who does what in the next sprint? Code reviews can identify areas of growth and areas of expertise. Balance the work you’re assigning based on optimizing for these two criteria.

Book update: 6 chapters in draft, 3 chapters not started, 18 chapters completed. We’re making great progress!

Stole this from I think @dtrenz — Use the 🍰 emoji to mark optional or “hey did you think of this?” comments. Separates the stuff that will hold up a pull request from the stuff that would polish it, and can keep a review with a lot of comments from feeling overwhelming.

Today’s writing: Coraline is working on a chapter all about code reviews. Do you have stories or tips to share? We’d love to hear them!

I’d love to hear what worked and didn’t work for any engineers who were on call and had to engage in real-time collaboration to solve a hairy problem.

Progress!

Daily catch up, code reviews, learn about compassionate language techniques, learn how to criticise the work, not the worker. Say you don't like it out loud. Don't be afraid to say you don't know why, and work it out together.

The chapter we’re working on now is about collaboration, and we start by tearing down the myth of the lone genius. We’re emphasizing that collaboration is truly key to our success. So what are some of your strategies for effective collaboration?

I've found pair-programming quite successful. For me, as having someone working with me (however little they may know about the problem) boosts me up. And the reports are that peers learned a lot, even in a "junior navigator" role.

Settling in to do some writing today! Continuing work on the pair programming chapter. I’ve already got content on the social dynamics of pairing, research showing that the canonical driver/navigator setup doesn’t work, and more. What are your favorite tips for pair programming?