You canât build a reputation on what youâre going to do.
- Brian P. Morgan
A common theme Iâve noticed in my 1:1s is frustration.
âWhy donât people trust my plan, I know what Iâm talking about!â
âWhy wonât my manager let me lead this project, I know I can do itâ
Iâve been there too, you know yourself better than anyone else so itâs easy for you to see why youâre able to do something. But the fact of the matter is, thereâs no reason anyone should trust you by default.
Iâll give you 3 simple ways to gain that reputation:
Execute
Execute
Execute some more
Thereâs no amount of product designs, proposals, or talk that will get you the respect you desire at your company.
Think of who you look up to the most on your team. Why do you look up to them? Iâm going to guess itâs not about what theyâve said in your meetings but what theyâve done at the company.
Now, what does execution look like? Letâs talk about a few of my favorite strategies:
Fixing the annoying problem everyone ignores
Asking the hard questions
Consistently doing what you say you will do
1. Fixing the annoying problem everyone ignores
What is starting to sound like a broken record in your stand ups?
Iâll give some examples of my past teams and potential solutions:
I was paged last night but it was a no-op, the API is probably more sensitive than it should be
Figure out how to update thresholds for your team and do it
I wasnât able to get my task done, the customer experience team needed my help updating some configs that only can be updated by scripts right now
Create a UI that allows customer experience to do this directly
Iâm not sure what to pick up next so I just did some random things in the backlog
Create a process that makes it easy for any engineer to know what the next top priority there is to be done
Taking just a few hours a week to solve these problems is probably the easiest way to gain respect. Engineers love someone who just fixes things instead of talking about how we should fix them.
2. Asking the hard questions
Have you ever noticed a project going downhill but didnât say anything? Maybe during lunch you complained with your friend about how incompetent a leader was, how bad a design was or even how the project was a waste of time all together.
Once the project fails, you find yourself telling your friend âI told you so, I knew the project was a hot mess!â
Well⊠why didnât you say anything đ
Ok, you might be thinking, âthatâs above my pay grade, not my job to fix this disaster.â That may very well be true, and you could leave at that! But why not use it to your advantage?
Instead, when these meetings are happening ask the hard questions.
As usual, here are some examples of situations and hard questions you could ask:
You notice the lead of the project says that itâll take 2 weeks to do something that you know will take at least 3 months
âI noticed you said adding the CRUD APIs for the dashboard will take 2 weeks but last time we did something similar it took 2 months due to how long it took to get feedback from DevRel on a public API â how are we able to cut that down for this project?â
During a planning meeting you notice the team going down a rabbit hole about adding a features not on the original product spec
âWhile I think adding feature X would be awesome, wouldnât that push back our timeline? It wasnât on the original product spec so just wanted to make sure that itâs worth potentially modifying our timelineâ
It might be difficult to speak up at first, but these comments can save you and the team months of wasted efforts.
3. Consistently doing what you say you will do
One of my favorite quotes from Michael Seibel comes from What Makes The Top 10% of Founders Different:
Itâs pretty intimidating to work with someone who is constantly getting things done ⊠intimidating in a way where they demand respect because they get shit done.
Notice this doesnât have anything to do with what youâre getting done or how you get it done â but more about just doing the damn thing. Hereâs examples of anti-patterns.
Saying in planning that youâll be able to get something done but end up coming back 2 weeks later saying things came up and you werenât able to finish
Offering to set up a brown bag or code review club but never committing to making it consistent
Promising to create an onboarding document for future new hires but not having anything ready by the time the new engineer starts.
Start to take your word seriously. Before saying yes to something ask yourself if itâs something you should be doing. If not, say no! If yes, get the damn thing done no matter what.
Thanks for reading â€ïžâđ„
Eden