Per my previous post, I’ve left Stitch Fix after six years to find something that fits my strengths and experience a bit better then the public going concern that Stitch Fix now is. This page will serve as a way to articulate what that might be, in particular what experiences I have that it might be worth sharing with you or your team.
This is about me and if you don’t care about that, there’s no sense reading this page. I just need a URL to point to :)
Where I Work Best
I am a good fit for an early stage company that relies on technology (but whose product doesn’t have to be technology). I have a lot to offer from seed to scale. I know this is somewhat vague, but in terms of engineering team, going from zero to 100 developers is a good fit for my skills and experience (as well as being the stage of growth I truly enjoy).
What I’m Looking For
My short term goal is to find teams where my experience at Stitch Fix can help them get through an inflection point. Stitch Fix had several, and we weathered them well. The company was and is well-run, both as a business, but also culturally, and I think these two things are intertwined.
There are a few things, in particular, that I can help with:
- Scaling a technical architecture sustainably
- Building and managing a distributed team
- Product management, roadmap prioritization, and defining a Minimum Viable Product (MVP)
- Developing a hiring process to find the right people for you
I’m always open to chat about any of this stuff to see if my experience can be helpful.
Below are more details, if you care.
One thing to know is that Stitch Fix did not follow the standard Silicon Valley playbook. I believe this was a key to our success, but it’s important that you understand how we differed from what is considered the conventional wisdom of building a high-growth startup.
Stitch Fix Is Somewhat Unique
For a high-growth startup, the “exit” is a significant point in time. While Stitch Fix was never focused on an exit, the company saw an opportune time to go public and in November 2017, we did. The investors in your startup are going to be pretty interested in getting to some sort of exit, and an IPO is almost always a desirable one.
I bring this up, because I want to focus on what got us there (not what we’ve done since), mostly because the typical story of a startup begins at some sort of seed round and ends at an exit, and that’s the story the includes the way Stitch Fix did things differently.
At the time of our IPO…
- we had no product management organization (1 mid-level PM, 1 director who’d been there a month or so). Engineers and business-unit owners planned work together.
- we had no “front-end” engineering team. We had only three “front-end” engineers and two were almost brand new. Most engineers were generalists and did whatever work was needed.
- we did not have a bug tracker—we fixed critical things as needed, and ignored non-critical issues as a way to focus.
- over 50% of the engineering team was not in the San Francisco Bay Area, and the entire team operated as a fully-distributed team. From my first day to my last, Stitch Fix’s engineering team was effectively fully-distributed.
I was not the driver of all of these decisions, though I did have a part in some of them. I 100% agreed with all of it. What this told me is that you don’t need to do things a certain way to have a profitable successful company that provides a nice exit. There’s no standard playbook.
Again, the exit was never a strong focus, but since it’s a framing device for many founders and employees, it’s a handy reference. This should also tell you something - we focused on building a business, not creating an exit.
Given all that, here is some of my specific experience:
My LinkedIn Profile gives a good timeline of my work history.
Because I have been heavily involved with a company through various stages of growth and several inflection points, the experience I can bring is best suited to early stage teams or teams who’ve reached one of those inflection points and aren’t sure how to navigate them. I also have product insights related to SaaS products targeted at technical teams, since Stitch Fix uses them deeply (I have used Heroku in anger :).
Here are some specific highlights of my experience:
- Third engineer at Stitch Fix. Over 6+ years there, I had a direct impact on.
- product Management and Roadmap Planning.
- technical Architecture, Coding Standards, etc.
- recruiting, Hiring, and Onboarding.
- building and managing a distributed engineering team with upwards of 200 engineers.
- team structure through various stages of growth.
- IPO-readiness & International Expansion (SOX, GDPR, and all that :).
- Seasoned software engineer, having direct experience with:
- event-driven architectures.
- data modeling.
- “DevOps” Culture / Continuous Delivery.
- Practiced public speaker and published author
It’s also worth understanding my values and how I work.
My personal values are:
As an engineer, I strongly believe in:
- Having a growth mindset
- Aligning on problems before proposing solutions
- Focusing on impact over technology
- Scale comes from consistency, iteration, feedback, and prioritization
- Diverse teams are better-performing teams
It’s certainly confirmation bias to say that I believe these values and beliefs lead to success but, I do believe that. It’s important to have a point of view (it is not important stick to it above all else).
My working style follows from my values. As an introvert, I do tend to process information in my head rather than reacting in the moment, and as a writer, I tend to process information by writing, not talking. Not to say I can’t talk about stuff, of course :). While I don’t endorse Myers-Briggs as a general personality assessment, I can say that I am an INTJ and the description of what that means is pretty accurate for me.
If you made it this far and you have a problem you think I can help solve, please reach out.