Why Principal Engineers Shouldn't Say "No"

Рет қаралды 3,342

Күн бұрын

One mistake I made in the middle of my career was saying "no" to work requests. The right thing to say instead is a "qualified yes." This video explains more about giving a 'qualified yes' and why it's good for your career, your team, and your company.
TABLE OF CONTENTS
00:00 Introduction
00:52 A Qualified Yes
01:41 An Example Problem
02:54 Solution
04:32 Summary

Пікірлер: 21

@alexfortune9716 Жыл бұрын

General rule of thumb in life seems to be - don't just say no outright, it creates tension, and makes you look like someone who doesn't care about making stuff happen. Great video, as a long-time quora reader, I'm glad you created a channel!

@frustratedalien666 7 ай бұрын

This is great advice. Several years ago when I was a senior engineer, my manager told me that I was the best engineer he'd hired and I was great at most things with one caveat - I say no when I should say "yes, but...". I took it as one of those weird corporate-speak thing but played along. In reality, that was the best advice I've ever been given and yet it took me years to realize that.

@Gergaferg Жыл бұрын

I'm a junior SWE at a FAANG (3 yrs exp), I love watching your videos. This tip is particularly insightful for me because in my design work, I might not be making the same sort of decisions as a principal, but I also have to work with my stakeholders (other engineers) to make sure the work I do is delivered on time and does the right thing. Giving a qualified yes to potentially demanding clients is a great idea.

@TheDeliberateEngineer Жыл бұрын

I'm glad the advice seems useful, thanks for sharing!

@Rugaar Жыл бұрын

Hey John. I'm a huge fan of your videos. I noticed in this one that the frequent changes in your camera zoom felt distracting. I wonder if anyone else was bothered by it? Either way, it might be useful to you as feedback. Thank you for making these videos and sharing such valuable advice. It always feels well tested, well grounded, and well intentioned. I hope your reach keeps on growing so more people can benefit from your content. All the best.

@TheDeliberateEngineer Жыл бұрын

Thanks for watching, and for mentioning it! I watched the video and I was appalled at both the focus and the distracting zooming in and zooming out. I'll spend a bit more time on production for the next one and it'll hopefully be better focused and less jumpy!

@alexchan4976 Жыл бұрын

Thanks for these thoughts. I actually just witnessed someone say no from a technical side to the business side which created conflict and tense exchange. These gave me some helpful insights on how to handle this situation if I were in control.

@TheDeliberateEngineer Жыл бұрын

I hope it'll be useful in the future!

@mbw365 Жыл бұрын

I have mixed feelings about your approach, but I can't argue with the success of it. How would you apply this to leaders who gravitate towards "ambulance chasing"... That is, their approach is always to prioritize emergencies. This is common in many orgs within more traditional support teams. Simply reacting to emergencies tends to get you more of them to deal with, not less. When you engage that approach, it's difficult or impossible to make progress on long-term proactive initiatives, because urgent problems always get the priority. This is especially problematic in corporate cultures where "management by emergency" is rewarded in terms of goals, promotions, recognition, and compensation. I'd be curious to know how you'd approach a problem like that. I do think that there's a place for "no" in our working lives. I'm probably using it more than I should, and I suspect the answer is that this isn't a good place to have a principal engineer, because building software isn't a priority.

@TheDeliberateEngineer Жыл бұрын

It all depends on who sets your priorities. If your leaders keep changing your priorities and keeping things from being done, that's technically their right, but they also get the consequences for that. So in this case, if it was my direct manager, I'd keep making sure they understand the tradeoff they're making and then accept it, if that's what they want to. If it was a skip manager (a few levels higher up) then I would try to get them to work with my direct manager who will get the blame. If it's someone outside of my organization, I can get the options but then it's up to the people who pay for my time (my managers) to say whether it's the right thing to do. I've been in the case where I was working with a team that kept changing their priorities. After I was unable to get them to change that, I tried to get my managers involved. They thought they fixed it once and of course it just broke a few days later when the next idea came to those managers. Ultimately I wasn't able to do anything more than prioritize other work. I'm sure there's a better solution.

@mbw365 Жыл бұрын

@@TheDeliberateEngineer thanks for taking the time to provide a well reasoned response. I really appreciate the thought and perspective you bring to these conversations with your videos.

@PatrickCoffey777 Жыл бұрын

Wisdom bomb! Thanks John! Keep the videos coming, please!

@TheDeliberateEngineer Жыл бұрын

thanks!

@hareepjoshi Жыл бұрын

Drawing strict boundaries is never a good idea. This is great advice.

@TheDeliberateEngineer Жыл бұрын

Thanks for watching & commenting!

@deegthoughts Жыл бұрын

This is great relationship advice too

@ml-techn Жыл бұрын

Hi, thanks for all your content, it is really helpful! I am ML research project leader (80% project management, 20% Technical) in mid-size company (not tech but Aerospace). I did a PhD in Information Retrieval 6 years ago and then after my phd I joined my current company. I was hired as ML scientist and then after 2 years I switched to Project management as I was good at communication, making people work together from different organisations, building roadmap and vision. So, I was not coding and deep dive in technical aspect of the project (just high view). Now, I feel I have lost my time and now I feel I am not good at coding and ML. With all the rapid ML in the last 4 years, now I am straggling. I want to change and work in tech companies (like amazon, Microsoft, google , ...) and I an targeting MLE and Applied Scientist roles but I am not good. So, Now I am given myself 1 year to deep dive and learn from scratch ML. Do you think,I should target Senior roles or Mid-Level? I have 6 year of experience and ML Phd (not a really good work, just OK), the last 6 years were more project management than coding. Thanks for your help

@TheDeliberateEngineer Жыл бұрын

I don't have relevant experience to guide you here, I'm afraid. When you're deciding what level to apply to, think of A) what you can get, based on your experience, and B) how you think you will compare to the other people doing that job at that level after a year. You don't want a job where you will struggle for a year and then get clobbered in reviews and KEEP struggling. If you're wanting to move out of research roles into production roles, your research experience may not count for much, and your degree won't matter more than e.g. a B.S. unless you're doing research in production. If it does count as e.g. 6 years experience, that's more of a mid-level role, at Microsoft the job title would be 'senior', low end of that band, possibly the level below senior. Again, I don't have experience in your specific situation, so this is just opinions. Good luck...