Hey there, Jordan here 👋. You’re probably familiar with most of my articles being a “how-to” guide. Those guides come from my real-world experience and lessons I learned—usually from mistakes I made.
This article is going to cover the 5 biggest lessons I had to learn the hard way through feedback that surprised me. Each of these shaped the engineer I am today.
Hopefully, sharing these lessons with you will help you avoid some of my mistakes.
Caveat: These are lessons based on my personal experience. You may have experiences that tell you a different lesson. If you do, feel free to share with me in the comments. I’d love to discuss it with you!
Lesson 1: Bring solutions. Not problems.
I was a Senior Engineer on a team that relied on 2 other sister teams for data.
The data we requested from one of our sister teams came back painstakingly slow. Because our requests to them took 500ms-4 seconds, customers would see 3+ second loading times.
That team knew about the problem but they were swamped with competing priorities.
Unfortunately, I didn’t make it any better.
I made more callouts to the problem in team retros and team channels. That on its own isn’t such a bad thing. But the vibe I gave off was, “This is a serious problem your team needs to fix” rather than “Can we work together on a solution to this?”
I didn’t realize I was doing this at the time until the feedback came from my manager.
![Fran Soto comment. See link below to view it Fran Soto comment. See link below to view it](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F62f68859-e55b-4e8c-b274-9f19c1f4fb4e_1124x384.png)
I could have scheduled a 1:1 with one of the team leads and collaborated on a plan to resolve it, rather than making anyone feel bad about the problem.
Although I intended to make things better for our teams and customers, I could have done it in a way that made our team feel great in the process.
Something like this would be much better:
The performance of the endpoints are causing 3+ second loading times for both of our customers. I’d love to work with you on options for resolving this together. How can I help?
Steve Huynh’s recent video gives a great example of doing this wrong vs doing this right too.
Lesson 2: Clean code isn’t the end goal
As a junior engineer, I was ruthless in code reviews I gave. I wouldn’t let a single “bad-looking” piece of code go into production.
And it made one of my teammates pretty darn upset with me.
It got raised to my manager which led to a conversation between the 3 of us where we resolved it, but it wasn’t a pleasant situation to be in.
Surprisingly, after this, I didn’t learn as well as I should have. I scaled back a little bit, but then I had an issue with a different teammate constantly pushing back on my comments.
It would lead to multi-comment back-and-forths in GitHub and some tension between us.
I asked my coach at the time what I should do, and he said, “What would happen if you let 50% of your comments go? Is every comment worth fighting over?”
My answer: “The code would be slightly less clean.”
Now think about this: Is “the code being slightly less clean” worth the tension between you and your teammate? No.
So I started being more relaxed about my comments. I commented less, made it clear what was a nit, and approved most of the time unless I had a serious concern.
What happened? My “nit” comments were accepted more often. There was trust between me and my teammate. Rather than them feeling attacked, they felt like we were working together.
![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fd8797612-0511-421b-94e4-137b46e99c19_1405x389.png)
Clean code isn’t the end goal. Collaboration is.
Lesson 3: Team outcomes > individual outcomes
I had a bad habit of getting distracted by code improvements I could do as I was working on my main project.
Don’t get me wrong. It’s ok to do this a little bit. You should improve things as you go. But I’d take on whole initiatives—like being annoyed by our code in JavaScript and converting 40+ files to TypeScript and putting it up for review.
Luckily, at least what I was doing was usually an agreed-upon initiative across the org.
But I wasn’t seeing the bigger picture. All that code I put up for review isn’t just my time taken up. It takes my teammates time to review, and it’s extra risk for our team to merge and deploy work that wasn’t accounted for.
I could have focused on moving the business forward for our team, like:
Asking my manager what their top concerns were and focusing on those
Finding ways to support the team in their tasks
Taking on bug reports from customer support
At the time, I was too focused on what I wanted to do rather than the high-level team goals and moving those forward.
There are a few things that led me to realize this. My mentee, another Senior Engineer, was promoted to Staff in only 6 months because he had this focus.
He was able to get done his expected work extremely fast and then use the extra time to solve some of the biggest problems for the team and its partners like our Customer Support team.
![One stack on the left (me) pushing work items, and a better on the right popping items off One stack on the left (me) pushing work items, and a better on the right popping items off](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F5c1124bb-ed59-46d1-838b-2dd8881cfea9_1333x841.png)
Focus on team outcomes. Not individual outcomes.
Lesson 4: Adapt to your manager
As much as we’d like to have a magic guide to working with your manager, the only true guides are the ones that focus on adapting to your manager.
I’ve had 5 managers in my professional career and I’ve had to adapt to each situation.
For example, when it comes to getting to the next level or focusing on career growth, some will be proactive and tell you exactly what you need to do.
Others may have too much on their plate to be able to give you that level of attention. In those situations, I’ve had to proactively create a plan for myself and get feedback.
There is way more to adapting to your manager that I can’t cover in this post. If you’d like one of the best guides I’ve seen to managing up, check out my Manager Guide and 1:1 Template. Paid subscribers can access the guide here.
Lesson 5: Influence isn’t about wording
For the longest time, I’d read books on influence and persuasion to figure out how to word statements to become more influential.
I’d hear things like, “Get people to say yes to something small so they are in the mindset of saying yes already to your next request.”
Or, use “would you be open to” rather than “can you” because people like the idea of being open-minded, which they associate “open to” with.
Don’t get me wrong, these are helpful. And I do work them in where it makes sense.
But these are the least impactful when it comes to influence.
The most impactful thing you can do is build relationships.
I bet you don’t need to think extra hard about how to phrase a request to your close friend you’ve known for years. It’s because you have a relationship where your friend knows your intent and is already open to helping.
When I realized this, I changed my focus from “wording” to relationship-building. I set up recurring 1:1s with my teammates, gave more shout-outs for good work, and took on more opportunities to support them. This is what helped me build influence.
Focus on building relationships that have trust built up—so you don’t even need to worry about how to ask.
📖 TL;DR
Lesson 1: Bring solutions, not problems. Focus on showing how you are there to support the team that needs the help, even if only as an advisor.
Lesson 2: Clean code isn’t the end goal. Collaborating effectively with your team is more important than ensuring every line of code is as clean as possible.
Lesson 3: Team outcomes > individual outcomes. What you spend your time on should be directly correlated with what will bring the highest impact for the team.
Lesson 4: Adapt to your manager. Every manager will be different. Understand how to adapt to your manager’s style and goals to see the best collective outcomes.
Lesson 5: Influence isn’t about wording. Focus on building relationships with a foundation of trust. That’s way more important than how you word your request.
📣 Shout-outs of the week
- - Tons of examples and principles to follow when giving feedback to coworkers on their work.
Managing up—Stories and Guidelines for Working with Senior Leaders on
(paid newsletter) - Amazing read as always by . 5 important principles for building a great relationship with your manager, told through personal stories and examples.- — Check out ’s System Design Newsletter to learn how scaling challenges are solved at top companies.
Thank you for your continued support of the newsletter and the growth to 51k+ subscribers 🙏
- Jordan
P.S. Here are a few other things you may be interested in:
Path to Senior Engineer Handbook (7.5k+ stars)—Everything you need to get to Senior
My LinkedIn: I write daily content to 56k+ engineers. I’m also ramping on Twitter/X
Newsletter sponsorships: Feel free to reply to this email or check the Sponsorship packages
Did you find this issue valuable? If so, there are two ways you can help:
You can also hit the like ❤️ button at the bottom of this email to help support me or share this with a friend. It really helps!
Great article, Jordan.
Thanks for including my LinkedIn comment in the post!
I have just remembered that the first lesson was the feedback I received in my last performance review 1 year ago. When I reflected on the feedback, I wrote the phrase "Always focus on the path to green" to remember that my interventions should move the ball forward, not just give an opinion.
Related to that topic, I'd add the concept of process-centric email from Cal Newport (we can apply it to any communication, not only email). The idea is to reduce the number of roundtrips.
If we just drop single-line questions, the communication will take forever. This is especially dangerous in async communication, we don't make progress.
Instead, think for a while, lay out a list of proposed actions, and then share them. You have done already the heavy lifting and for the others, it'll be easier to agree with the plan rather than coming up with a full alternative plan.
As a fellow engineer I can say that lessons 1, 2, and 5 really resonated with my experience as well. Especially number 5! The relationships you build turn into another tool in your "tool box" you can use to solve complex problems. The solutions to multidisciplinary issues rely heavily on trust within the relationships between engineers. If you don't trust your counterpart in a different discipline, that adds risk to every solution put forward!