5 Major Lessons Learned as an ML Engineer Turned Head of Dev Rel & Solutions For an Open-Core MLOps Startup. Part 2/2.
Or How I Continue To Blatantly Explain Where I've Been For The Past 6 Months.
Hey everyone!
In Part 1 of this series, I started to share some learnings that are super important if you’re thinking of:
Jumping in your first DevRel role;
Jumping into full-time content creation;
Diversifying your content & revenue streams;
Jumping to an Open-Core company.
The two lessons I’ve shared so far are:
Lesson #1: DevRel ≠ Just Content & Solutions ≠ Just Implementations
Lesson #2: You’re Either Growing Product, Revenue, or Users or You’re Deadweight
Here is Part 2 with what I’ve learned in the last 6 months!
Lesson #3: Not All Vendors Are The Same, Especially In The MLOps Space. And There’s Nothing Wrong With Open-Core.
🖊️ Main Points:
There’s a certain cachet associated with pure, full-time open-source contributors that I admire while at the same time am disinclined to emulate 100%.A number of reasons why I find pure OSS isn’t as great a fit for me:
I need to pay rent, eat, and eventually fund a family. Do you know how much it costs to live in SF even in a below-market apartment?
Who is paying my rent? Donations?
Creating educational content takes time, energy, & oftentimes money. As a self-owned business or consultant I would be expected to source my own clients, figure out book-keeping, have energy & time to still do the work, and then take care of my family, friends, & relationships. Did I mention pay for health insurance? Do you know what that’s like in the US? Not fun.
Partnerships can be an incredibly powerful catalyst for creating educational content, building cool projects, and having an impact, however small, on helping the projects I want to see succeed.
🔥 My Spicy Take 🌶️
Stop complaining about open-core being just a marketing and sales strategy. Seriously. Nothing in this world is free but things can be subsidized.
I’ve been trying to find a softer way of contextualizing this lesson but I’ve also told interested parties I’d make an effort to be more direct and less worried about negative feedback.
I’d interviewed and evaluated a number of roles before leaving Mailchimp, taking interviews with Big Tech companies like GCP & AWS for solutions engineering roles, other startups in the Data and ML space for DevRel roles or platform engineer roles.
I knew I wanted more building opportunities and I also wanted to own my content and voice.
I also knew, and had picked up in my learnings about DevRel, that authenticity and credibility were my most important offerings, especially with regards to creating both thought leadership and advising practitioners on how to build ML platforms or become MLOps engineers themselves.
When interviewing around I began to pick up how important having the respect for individual autonomy was, especially when prospective hiring managers would ask me whether I:
Believed in the product vision (answer: Usually no)
Would hardcore shill for the product (answer: aw hell no)
Fit the culture (answer: I’m not day-drinking just to make these functional alcoholics you call “leaders” happy).
After a few rounds of interviews, I realized that the intersection of {open-core} + {devtool} + {ML} really stuck out to me because:
ML: This should be pretty obvious why.
devtool: This was a surprise because I thought I would be totally constrained by the types of customers, teams, and even projects I’d be able to get involved with, partially because “eww vendor” but also because of how some vendors had structured their role requirements. I was very happy to realize that this was not the case for everyone and for startups that were focused on a single stage of the “ML Product Development Lifecycle” there would lots of opportunities to work with partners and projects in all the other stages.
open-core: Maybe this is just another case of classic price discrimination a work but I really like the idea of allowing users who want to bootstrap to be able to try and have access to an open-source project (so they’re not signing a deal blind) or in case they’re super scrappy while enabling larger teams and organizations with additional functionality and services that frankly don’t matter to smaller teams.
I talk in greater detail here about why I joined Featureform but I’ve been quite satisfied with going for an open-core, MLOps devtool company.
Awesome team aside, I grok the product vision and direction and it’s very easy for me to rep them.
In addition, the Featureform team has been adamant that they want me to continue pushing the boundaries of thought leadership, especially with regards to the MLOps ecosystem, developing ML platforms, and enabling both MLOps engineers and data scientists to create game-changing ML products.
Some of the projects I’ve worked on since joining that I’m personally really proud of include:
Giving two completely new talks at conferences including:
“Measuring MLOps ROI and Team Productivity” at CometML’s virtual Convergence 2023
“The Fun-Sized MLOps Stack from Scratch” at Data Council Austin 2023 (soon-to-be-posted here).
Writing up a beautifully illustrated 64 page guide on “Feature Engineering 101 & Best-Practices” (also to be posted and linked here in the future).
And I have a ton more projects in the pipeline.
For folks who missed the talks (or saw them) let me know what you’d like to see more of (or less of).
Lesson #4: For Early Stage Startups, There’s No Such Thing As “Bad Experience” or “Perfect Experience”. In Other Words, Everyone’s Some Kind Of Generalist.
🖊️ Main Points:
In early-stage startups, there’s an equal amount of producing volume, experimentation, & doing things that don’t scale. Oftentimes it’s about just getting the job done, regardless of the task, with as little effort, time, resources, & finesse as possible.
Think in terms of “Wicked” vs “Kind” Environments.
Kind Environments are characterized as:
Consistent;
Highly-constrained;
Limited variables;
Limited choices per variables.
In other words, Kind Environments have:
Clearly-defined success criteria;
High-level of information availability;
Tight & understandable feedback loops.
Wicked Environments are completely different. They’re characterized by:
More variables;
Less visible information;
Less understandable;
Slower feedback.
🔥 My Spicy Take 🌶️
Because of the need for people to wear “multiple hats” the beginning team mix needs to lean farther towards generalists as opposed to specialists.
I don’t have much to add here, other than the role will adapt as the early-stage startup adapts and most importantly the work you’ll be doing on month 4 is going to look drastically different from day 1 or day 31.
Something I have observed is that if you were to dig real-deep for builders and operators that successfully scaled a startup or project from the first 100 to the first couple thousand users, they are far and few between.
And it makes sense but it also means that when you’re asking thought leaders or influencers for details about the tactics they used, they’ll either get cagey or they’ll shrug and say “that was before we arrived”.
The few folks I have talked to that were there in the early stages of an eventual success basically said “try everything & try lots of things”.
So it does seem like there’s no silver bullet or magic potion. Just high volume, consistency and continuous experimentation.
Lesson 5: Personal Growth Means Operating At The Edge Of Discomfort. And Without Psychological Safety, You Can’t Have A Flat Culture.
🖊️ Main Points:
Leaders are the face of the company and how you interact with customers, interview prospects, even competitors will set the tone.
Company values are practiced and lived, not preached and evangelized, only for really embarrassing stories to come out later.
Personal growth also means stepping outside your comfort zone and being open to feedback.
Leaders are directly responsible for culture and the best way to encourage a flat culture is to accept feedback from your direct reports and show you’re implementing feedback where it makes sense.
🔥 My Spicy Take 🌶️
Real leadership means recognizing when you need to step out of the room in order to allow your team to brainstorm and try out new ideas. It also means publicly recognizing when you’re wrong.
I’ve always struggled with giving other people feedback and input that could be seen as negative, especially if I thought it could change the relationship or power dynamic.
I’m particularly conflict adverse and when you combine that with a very strong amount of impostor syndrome, I have a hard time always sharing my opinions, especially on data and MLOps related topics.
I’m realizing more and more how much this desire to float below the radar and be as indirect as possible is hurting me professionally and personally.
I’m grateful to the the team at Featureform for continuing to push me to both share my knowledge, thoughts, and feedback.
Sometimes it can feel a bit like butting heads when we get into robust discussions but I now know that over time I’ll eventually calibrate to the right level of directness and that my ability to serve the data and ML community will only improve.
Because the fact of the matter is, I should be opinionated.
In fact, whether:
you’re trying to break into MLOps as an engineer,
you’re a startup trying to build just enough infra,
you’re a team in a large organization losing their mind over all the red tape
I’m more useful as someone that has a specific lens of the ML Ops ecosystem, trends, and tools than someone that just throws their hands in the air going “it’s all the same”.
Future Of This Substack
Anywho, that’s a slice of what I’ve been up to for the past 6 months.
I’ve been wrapping my brain around whether I still wanted to cover the original topics I said I would, specifically in https://mikikobazeley.substack.com/about where I say :
”I'm a practicing Sr MLOps Engineer that advocates & creates educational content for practitioners & entrepreneurs looking to build full-stack ML applications.
My goal is to demystify MLOps & show how to develop high-quality ML products from scratch from a vendor & architecture agnostic perspective.”
And I believe this is still true.
Specifically I have plans to cover the following topics:
MLOps 101: Terminology, Tools, History;
Building Systems & Platforms, both from technical as well as from an operational perspective;
Expert Perspectives from ML Operators & Builders;
Foundational Concepts (like CS, Python Programming, Interpreters, Testing & Evaluating Models, etc);
DataOps & Data Engineering concepts (where it makes sense).
These will be covered in the form of:
Tutorials (with accompanying videos and code);
Longer-form write-ups;
Infographics;
Videos;
Occasionally as workshops.
And for this year, with the exception of some courses I may develop in collaboration with certain learning platforms, all my materials (including this Substack) will be free.
The channels/platforms I’ll be committing to for 2023 are:
Longform: Substack
Video: Youtube, including any streams
Code: Github obv
Social media: LinkedIn, Twitter
I’m incredibly excited for this upcoming year, especially partnering with Featureform.
Part of the motivation for me to put my scrambled thoughts down was because the entire team was out here in SF for the week brainstorming over the product, hacking away with open-source Featureform, and bonding over the office of now 6 dogs and their owners.
We went rock climbing (which I realized I quite enjoy!) and even had some design sesh’s that reminded me of the Design Thinking workshops from Autodesk.
This is a great team and I have high-hopes for Featureform this year.
If you’re interested in learning more about Featureform, please check out our:
Let me know what your thoughts are and what you’d like to see covered over the next year!