Reaching 20k+ readers on Medium and over 3k learners by email, I draw on my 4 years of experience as a Senior Data Engineer to demystify data science, cloud and programming concepts while sharing job hunt strategies so you can land and excel in data-driven roles. Subscribe for 500 words of actionable advice every Thursday.
[ETR #18] What Makes Data Engineers Say "No"
Extract. Transform. Read.A newsletter from Pipeline Hi past, present or future data professional! When I worked at Disney, the absolute worst thing you could say to a guest was “No.” It’s not so much that Disney guests would hear “yes” throughout their vacation; they just wouldn’t hear no. And that’s why, as a developer and individual contributor, it’s important to master what The Art of Being Indispensable At Work author Bruce Tulgan calls the “good no.” A bad no is a no said to something that could be feasibly accomplished. A good no is a no uttered in an effort to establish or reiterate priorities, like telling a stakeholder “No that dimension can’t be added to the pipeline during this sprint because it will require a new request to a separate API endpoint.” Good nos can also put requests into the context of larger team and organizational goals; for instance, saying “no” to production-izing an ML model that only generates 15 rows of data that isn’t relevant to larger initiatives is, without a doubt, a good no. It’s not just the sentiment of a denied request that can irritate a stakeholder or colleague. The word “no” just doesn’t sound good. It’s sharp. Definitive. If I can’t say “yes” to someone, I focus on fulfilling two needs that are almost as good:
Providing context: “I can’t put your query into production because I’m currently working on x initiative which impacts our team’s OKR for this quarter.” Offering an alternative: “Unfortunately, I don’t have the bandwidth to take on a backfill of your requested scope. Instead, I can backfill the data to the prior quarter so you can at least see data within the last 90 days, which is what your dashboard seems to focus on.” Even if you’re not working in a data role currently, this lesson can be applied to the bane of most students’ existence: Group projects. Putting your efforts into context can help avoid scope creep and make sure you don’t end up with a disproportionate amount of work. And so you don’t end up with too much work, here are this week’s links as plain text.
Questions? zach@pipelinetode.com Thanks for ingesting, -Zach Quinn |
Extract. Transform. Read.
Reaching 20k+ readers on Medium and over 3k learners by email, I draw on my 4 years of experience as a Senior Data Engineer to demystify data science, cloud and programming concepts while sharing job hunt strategies so you can land and excel in data-driven roles. Subscribe for 500 words of actionable advice every Thursday.
Hi fellow data professional! This edition almost became an apology because I’ve been on a tight deadline and pre-baby morning wake up thinking/writing time has become GSD (get sh!t done) hour. Long story short: I got brought in late to a time-sensitive project that required me to speed through a planned pipeline migration. As a recovering news junkie (aka journalist), I used to live and die by deadlines. But, given the unpredictability of data-oriented work and internal deliverables, it’s...
Hi fellow data professional! For years, the opening of The Simpsons, specifically Bart writing lines on the chalkboard, has been incredibly relatable to me. Not because I’m up to mischief (none I’ll admit to here, anyway), but because I spend most days writing the same three lines of SQL over and over again. If you've ever been paranoid about a table's content, you might know what I'm talking about. It’s the aggregate COUNT(*) grouped by a date field, ordered by date DESC. The output of that...
Hi fellow data professional! In a previous newsletter, I mentioned an idea that I wanted to explore deeper. At the risk of double-quoting a la The Office’s Michael Scott quoting Wayne Gretzky (“You Miss 100% Of The Shots You Don’t Take - Waynze Gretzky - Michael Scott”), here is the idea. “To be marketable as a candidate, you don’t just want to show how you can go from A to B (requirements->pipeline). You need to go from A to C (requirements->pipeline->scale/support).” You might be asking...