Oof, that situation is rough + the skip level's response to "don't take it personally" and read this book might be nearly as bad.

I agree with Lee's points, and have a couple other suggestions to tack on to hopefully improve **your** relationship with this E6 in the meantime of the managers hopefully working on it too.

The first thing is on mindset: **It will be very difficult for your E6 to be offended by your questions if the following 2 things are in place**

1. **Intent:** If your E6 knows that your intent with your questions is purely to gain a better understanding of the task he is assigning you
2. **Mutual purpose:** Do both of you want the same thing? If he believes this to be true, then again it will be very difficult for him to get frustrated by your questions. For example, do both of you want to just perform well so your EM can notice and then give you a positive performance review. Probably. But in the moment, he's probably not thinking about this.

See if you can get him to align with you on these. Don't call it out as explicitly as I did. But here's one potential avenue for approaching asking:

"Hey E6, I'm looking forward to jumping into this. It seems like an interesting task. Thanks for sending it on. So that I can get a better understanding for my process, would you be open to a 15 min zoom where I ask a few additional questions?"

I padded in a bit more niceties than you may need, but modify based on your style and relationship. That could hopefully communicate the 2 things of intent on why you are asking your question and mutual purpose, that both of you just want to do well. On mutual purpose, you may be able to add in something else to emphasize it a bit more.

As a second piece:

You can have a 1 on 1 with your E6 where you let them know some of the challenges you've been experiencing and how it has been making you feel. 

I'm not great on advice for asking for the 1-1, but generally, when requesting it, don't put them on the defensive like saying "Hey, can we talk about your communication this last week." Instead, maybe something like, "Hey, I had some things on my mind about the handoff process we've been doing and was wondering if you would be open to having a zoom 1-1 to chat further?" I don't necessarily like that too much, but just giving you a general idea.

For the actual 1-1, this goes into the "giving feedback" form of advice I'm sure you can find on Taro; but some things to keep in mind are...

**Focus on these:**

1. The situation and actions, not him as a person
2. The impact on you
3. The intent and mutual purpose that you share above.

Tell him that you want to have a great relationship with him and you'd like his thoughts on how to better accomplish that.

If you did your job right, he will probably first apologize profusely for his actions, tell you he is going to take steps to correcting it, and get a better communication process with you going forward. He may not do exactly this though just FYI, especially based on his prior actions. But based on his level that's what I would expect.

I wish you the best of luck with this sticky situation! Feel free to connect with me on LinkedIn: <https://www.linkedin.com/in/jordancutler1/>. I'm always looking to grow my network with like-minded people :)

Senior Software Engineer and Career Coach

Jordan Cutler

Hey there! This is a great question I'd love to weigh in on. I know this got partially answered during office hours so I'll reiterate for posterity + add some thoughts of my own.

During office hours (and I 100% agree):

- Set up a framework / process / policy for contributing to your area of the code. It's so much easier to defer to policy as a rule to follow rather than getting in a verbal or typing battle with someone
- Make it easier to contribute in a way that doesn't lead to bugs. As Lee mentioned, depending on what's being added, you may be able to allow them to add code elsewhere that "plugs in" to your system without it affecting much of your code. This may be a win on both ends. You don't need to maintain it or review their code, and they don't need to view you as a blocker.

Here's what I'll add regarding communication:

- **Be ok with being the gatekeeper. Just do so respectfully but sternly.** Given you are a senior engineer, it's your responsibility to safeguard the code from bad patterns and bugs, especially from external teams. I can't imagine the external teams challenging that authority at all. So the only question then is how to approach that safeguarding mentality...
- **Be as collaborative and understanding as possible.** If they are adding features or at least making an attempt to make your system better, they are making an active step to avoid putting that work on you as a feature request. This should be viewed as a positive thing and you can have the mindset that they are a good samaratan that just needs a bit of guidance. For example, thank them for their contribution and the time they spent on what they are trying to add. After thanking them, suggest having a chat over zoom so you can get a better understanding of the change and go through it together. In zoom, communication will be much easier than typing. In zoom, you can bring the topics up like you being looped in earlier so that you can have ample time to review and its not a surprise to you. Speak from your perspective on this and how it has affected you, and don't make it about them. Make it about the behavior / action that has occurred of a large review being sprung onto you. Speak about it in a way that they will empathize with. Doing that would hopefully create a more collaborative and understanding relationship. You can then ask them given that, what suggestions would they have for a process that would be beneficial for both of y'all. What is it that you can provide that they need? And you can offer up a suggestion or two.

That last bullet spiraled out of control a little bit, but I just wanted to nail in the mindset of the collaborative relationship, and you are just looking for a process or way that you two can work together that will benefit both of you.

Hope this helps! Best of luck.

This is a fantastic question! I have a few thoughts:

First, let me just start by saying I totally get where you're coming from. In my first job, I ended up having a time where my manager needed to get me and another coworker into a room because we were constantly not seeing eye-to-eye. And we needed to hash it out with him there. It was not a great time.

From that and other experiences, here's what I've learned:

1. **Fix the problem before it begins.** Oftentimes, you can feel a sense of tension building between you and another coworker. If you feel that, try to find ways to lower that tension and build a relationship of greater compassion. For example, you can lightly bring up things in a recurring 1-1 with that person before it spirals into a barrage of things that have built up over the past few months. Or you can catch yourself and find other ways to ensure a good relationship.
2. **Understand that anger / frustration is almost never the answer, so it's in your best interest to think of alternatives--at least when speaking directly with that person.** It's ok to let out frustration to others such as a friend, mentor, or coach. But don't show that to the person you're disagreeing with. Let's say you are frustrated with someone else because they don't code review your code often. You'd probably see a better result empathizing with the fact that they're probably very busy and wondering if there's any way you can help them out (assuming you see that they are busy) instead of expressing your frustration for them taking long to code review your PRs.
3. **Understand that sometimes there isn't much you can do to change others, so be okay with agreeing to disagree.** Sometimes you just won't see eye-to-eye with people. And that's ok. Just be respectful about it, acknowledge their points, but agree to disagree.

Lastly, here's a copy-paste of the bullets I refer to when I get in a disagreement to help me stay level-headed.

If someone disagrees with you, the first instinct should not be to show why they are wrong but to **understand why they disagree**.

## Process

1. Try to bring the conversation into zoom instead of over text. This makes it easier to get an understanding for each other.
2. Approach the discussion with an open mind and understand why they disagree.
3. Repeat back to them their point to make sure you’re on the same page.
4. Weigh the pros and cons, and evaluate what makes sense as a step forward.
5. Consider other potential options that take both sides into account
6. If a stalemate occurs, call it out and bring in a 3rd party like the rest of the team. At this point, I would try to collaborate with the person on a pros & cons doc that describes both options to bring to the team.

If you found my answer helpful, I'd sincerely appreciate a follow/connect on LinkedIn! I'm working on building up my network and would love your help. <https://www.linkedin.com/in/jordancutler1/>

You've asked a really solid question and it's a difficult situation.

From a high-level, when facing problems such as this, there are 3 levers you can pull.

1. Scope - how much do you expect to accomplish. What can you cut to meet the deadline you want
2. People - Can people be added to speed up the project
3. Time - The other 2 lead into this one, and if you can't get more time, you need less scope or more people.

Given that, you could essentially have a discussion with your manager about any of those three things. Maybe he can get you more people to help, or you could find ways to cut scope or add technical debt in the short term.

One thing I would suggest is to think about it from your manager's perspective--why does he feel the need to imply that people work overtime to get this done? Is it because this project landing is essential to the survival of the company? Is it because he will be impacted negatively in some way by the project not getting shipped on time? In what way will he be impacted? If you can find that out, you might be able to come up with the best way to communicate your concerns to your manager, and potentially solve the problem he has with it going on a bit longer.

Some actionable approaches to the conversation with your manager:

- As always, make sure to stay level-headed and come off as respectful, but be willing to stand your ground
- Approach to asking: "I understand there were some unexpected roadblocks that came up which are giving us some issues with meeting the deadline; I plan on scheduling a team retro so we can discuss how to plan better in the future. For the current state of the project though, I'd love to explore what options we could come up with to get as close to the deadline as possible. Would you be open to that?" Manager says yes, then you present a couple options. 
- If in the end, it ends up leading to no possible options (not able to reduce scope, add people, maybe reduce time spent in meetings, etc.)-- again, try to find what the urgency is around the deadline and discuss solutions around that.
- If THAT ends up leading to nothing, this is the point where you have to decide if you want to stand your ground. If you do, do so respectfully--"I'm not comfortable with asking my team to work overtime. And I have responsibilities I need to take care of after work. I understand that this isn't a great situation; I can promise you though that I will be working as hard as possible during working hours and am going to keep you updated with the progress of the project".

My advice here is a bit more specific to your situation, and I'm sure there are other approaches, so it might be worth waiting to see if others chime in.

There is a video on this I recently watched here too, which may not apply 100% directly but you can get some general principles from: <https://www.youtube.com/watch?v=sBNHvx8Vc6M>

Please let me know how this goes! I'm very curious and I'd like to know if this ended up being helpful. Reach out to me on LinkedIn here: <https://www.linkedin.com/in/jordancutler1/>

I love this question!

TL;DR - There are many different approaches. Pick the one that works the best for you. One approach I recommend is the following 2 step approach:

1. Ask yourself who your audience is and how that affects what content you write and how you write it
2. Ask yourself what is the one concept or takeaway you want your readers to get. Emphasize that, and divide into sections that further help the reader grasp that takeaway.

**More things to do to help you achieve your desired outcome:**

- The person you are working with likely has their own methods. Consider asking if you can shadow or work on a doc with them to learn from how they do it. You can also continuously try to pick up any patterns just from reading the docs they write.
- Ask them for mentorship on a doc you are writing so they can tell you what you may be doing wrong or could be doing better.
- Follow formats or pull from formats you like in other articles. Here is a few I have saved up:
  - <https://dondo.org/2022/02/18/on-writing-documents/>

    <https://laurensperber.com/2016/02/25/presentation-building-software-at-etsy/>

    <https://about.gitlab.com/direction/>

    <https://rinaarts.com/how-to-write-an-effective-design-document/>

    <https://adr.github.io/>

    <https://blog.pragmaticengineer.com/scaling-engineering-teams-via-writing-things-down-rfcs/>

    <https://www.lennysnewsletter.com/p/my-favorite-templates-issue-37?s=r>

I hope this helps! 

Feel free to follow me on LinkedIn for more advice like this to a broader audience: [www.linkedin.com/comm/mynetwork/discovery-see-all?usecase=PEOPLE_FOLLOWS&followMember=jordancutler1](http://www.linkedin.com/comm/mynetwork/discovery-see-all?usecase=PEOPLE_FOLLOWS&followMember=jordancutler1)

Senior Software Engineer at Series C Startup

Awesome! So glad that’s helpful. Thanks for posting the original context. That’s helpful. Have a great night!

For me, one of the biggest things is having a source of new knowledge coming in via people you respect or admire as engineers who set the bar for the rest of the industry. I follow peoples newsletters and LinkedIn and catch up on their posts and read their articles daily or at the end of the week if I didn't have a chance during the week.

I make it easy to catch up on them using a tool called Mailbrew (<https://mailbrew.com/>) which bundles up your emails into one for the day (though I think there are other tools too)

I'm happy for the question, though I do want to share a bit of feedback. When asking the question that involves external context, try to provide the resources or summarization necessary for the answerer to get caught up on that context as quickly as possible.

To roughly quote Alex, "make it easy for the person answering your question to help you"

So with that said, I don't really have context on this "One Diff, One Thesis" video; I tried to look it up but didn't see anything. But I can take a guess at it and give you advice based on what I got in your question.

This is going to be short and simple but, "Make a stack." PRs should really only be &gt; 500-1000 lines if you are doing some large change across the codebase that literally requires it to be that long, like a library upgrade or implementing a new linter rule or migration or something.

A PR stack involves having a feature branch, which then has multiple branches over time branching off of it to implement small parts of that feature. It may be a small piece of the logic for example. As long as each PR gives the broader context to the rest of the PRs and the vision as a whole, you should be fine to take this approach for something you would have considered to be a 2000 line PR otherwise. A tool called Graphite exists that makes making stacks easier <https://graphite.dev/stacking> for people who don't have the tooling at their company by default (like there is at big tech companies).

I hope this helps!

This is a fun question. 

It's hard to tell exactly without being in the situation, but thinking from your leads' perspective, **any feedback is good feedback**. The fact that you are feeling this, means that whether you are right or not, the lead (or the two of you) should sort out a better understanding of each other.

Action items for this would depend on how close you are to your lead and how candid you can be with them.

One thing that stands out to me as a potential reason why it comes across as defensive is that he is bringing up the timeframe that X task was ago. For example, 

"What about task y?" sounds much less defensive than "What about task y from 2 weeks ago?" because the 2 weeks ago example shows he is keeping much more of a micromanaging eye on it.

I think one avenue could be providing that feedback to him of saying that you understand where he's coming from with wanting to check in on those things, and that one way to make it come off a bit softer to you personally would be to not mention the time ago that it was. Leave it at that. Don't add to the feedback more than that. Before sharing this feedback, you could leave them open to it by first asking if they would be open to you sharing a small piece of feedback that you think could help **you** out a lot. Again, the focus should be on you. Don't make it about the team since you don't want to speak for the team; just yourself.

Hope this helps!

This is a great question, and one that I often struggle with as someone who loves to read books and take tons of highlights and retain only a few things.

I think I've found my groove at this point though. Here's my advice:

1. Let yourself know that it's ok to go down those learning rabbit holes. Life isn't all about the side projects you accomplish. If you're having fun learning, let yourself enjoy it.
2. With that in mind, it's important to make sure you are actually learning. There are a bunch of approaches to this. Here's a few...
   1. Build a second brain from what you are learning: <https://www.youtube.com/watch?v=K-ssUVyfn5g>. Take notes and categorize to better your retention.
   2. If reading a book, use Readwise so they refresh you on your highlights, and read with the goal in mind of getting little snippets you will be reminded about that will be valuable to you.
   3. Reverse your learning. Focus on the side project, and when you hit a roadblock, do some learning. Once you got yourself past that roadblock, continue on the side project.

I hope these tips help. If you find my advice helpful, feel free to follow me on LinkedIn: 

[www.linkedin.com/comm/mynetwork/discovery-see-all?usecase=PEOPLE_FOLLOWS&followMember=jordancutler1](http://www.linkedin.com/comm/mynetwork/discovery-see-all?usecase=PEOPLE_FOLLOWS&followMember=jordancutler1)

Love this question!

\+1 to Rahul's comment about giving credit. Give credit even for the smallest things, like if you did something above and beyond in standup but you being able to do that quickly was due to very fast code reviews from another team member, give them a shout-out.

A couple of other ideas come to mind as someone who leans heavily on the side of self-promotion:

- Try to be self-aware of how many times you may be saying something that could come across as bragging, even if you're not, and just gauge it / minimize it based on the vibes you get.
- Only give updates that are relevant to other team members. For example, if you shipped a change that is an internal tool that people can now use, feel free to tell the people it would be valuable to. But if you are working with someone outside of your team and helping them on something, it's not relevant to bring up in your teams standup unless it is negatively impacting your ability to get your things done. Instead, ask that person for feedback regarding the thing you helped them with when reviews time comes around, and your manager can find out about it then (or in 1 on 1 if relevant)