I'd like to understand what data engineering inside Nike is actually like. I'm curious because I have relevant experience on my LinkedIn profile, and I get reached out to almost weekly from third party recruiters trying to fill really low paying contract data engineering and ML jobs with Nike. These roles seem to be targeting people with professional experience in the US but pay roughly a 3rd of what I would consider the going rate. There's another top level comment here that this tool might make sense "in a shop with a lot of inexperienced devs", which would confirm my anecdata. Maybe the roles are actually scams, who knows :shrug:
Nike's data engineering is very bad. It's hundreds of temporary contractors, mostly offshore, all with 6-18 month tenures, and everyone reinvents their own square wheel. Thousand upon thousands of abandoned confluence pages of documentation. The most convoluted SQL and data architecture you'll ever find. Getting answers to simple questions like "How many shoes did we sell in-store vs ecommerce last week?" is a nearly impossible task.
> How many shoes did we sell in-store vs ecommerce last week?
That is perhaps not a great example. My brother is a business analyst at Nike (has been for 15 years or more). I just asked him how hard it would be to answer that question and he said it would be pretty easy. Granted, this is the kind of data he works with routinely, so it may be more difficult for other teams that do not.
Is he the person running the query or is he reading a blood spattered report pulled from the dead hands of some data engineer who perished battling the system to retrieve said data?
A little of both? He's a team lead. Definitely runs queries himself, but probably spends more time interfacing with management and other teams on a day-to-day basis.
> I find this type of thing scary as an outsider looking in. How a company so large has such immature engineering continues to astonish me.
It's management that doesn't want to risk their positions by doing the very difficult business of either starting over or properly simplifying their stack. It's not easy, it's not quick, but if they can't even answer that basic question then they need to do the work.
To defend management a little bit, these massive companies have existed through many eras of technology with many different managers. They work with many external companies in many different ways. They have an exceptionally complex, but functioning tech stack, that allows all of these many dependencies to function together. Lastly, they are successful as they are!
It's not usually an issue of immaturity, it's just really hard. To make things worse, often people don't really want to do the work because literally any other data engineering job would probably be more enjoyable.
Simplifying the tech stack would probably require simplifying their business operations, which probably means less revenue.
Starting over is often literally not possible because there are so many interconnected systems that aren't all necessarily owned by the company trying to make the decision...
Nike's success in the marketplace has approximately zero to do with their tech stack. That's why their tech literacy is so bad. It just doesn't matter to their business.
This is the most succinct point in defence of management really. Tech stack has no impact on business results, so quite rightly they don't make it a priority to 'fix' it.
> Simplifying the tech stack would probably require simplifying their business operations, which probably means less revenue.
I don't understand this perspective. Simplifying the tech stack might mean taking multiple services in multiple languages, and deprecating some in favor of migrating that functionality to the most maintainable codebase. This shouldn't mean "simplifying their business operations", or affecting their business operations in any way.
I agree there probably are areas were they can simplify with no impact to operations.
But I would imagine there are a lot of pieces of apparent cruft hanging around that is actually there because if you remove it things break.
Maybe a large retailer that you rely on requires an integration with an old version of SAP, and then a logistics partner only provides files over FTP, and you need to use OCR to retrieve any data from the files they're sending.
Management can't just mandate that you will 'simplify the tech stack'. Even refactoring smaller parts of the tech stack is often a pretty massive job.
"Look, my setup works for me. Just add an option to reenable spacebar heating."[0]
> Management can't just mandate that you will 'simplify the tech stack'.
In my experience, it's the devs who want to do reactors for love of the craft and satisfaction of a job "well" done, while management seeks to sweep as much technical "debt" as possible under the rug, and they'll burn through as many Romanians' nights' sleeps as it takes to reach their numbers.
My experience with these kinds of tools (and I've built some myself) tells me that you're better off hiring people who know what they are doing or having enough experienced people PLUS culture to train up juniors.
The idea that you'll just build a tool that makes hiring 10x as many inexperienced devs work is dubious. Just one more new DSL bro. Certainly we have cracked the code that no one else has.
The problem with these types of orgs/tools is that by its nature your DSL constrains the juniors/inexperienced devs to what is currently possible. There is not a lot of learning unless you rotate them through the tools team periodically, which no one does. It's also awful for the devs who are building in experience in something they can't use anywhere else.
I was in one shop where the "tools team" guys epiphany was he would meta-recruit by poaching the best data engineers out of the ETL team, lol. Very explicit "good team / bad team" vibes.
Speaking only my own experiences, my contract was ~2x what competitors were paying in the US. This was similar amongst the contractors I worked with, depending on seniority.
