M&Ms: Building a Team Outside the Boxes
The 78th Edition on how I built a team in spite of everyone saying no at first.
Hey Team,
Years ago, I was the only engineer working with the marketing team at a startup.
I realized right away that many things had to be built for them to succeed. Far too many things for one engineer to build. But no one up top budgeted for a “growth engineering”* team. Especially not when the core product desperately needed help first.
But instead of giving up on the marketing team and that startup, I built, hacked, convinced, and cajoled other teams as much as possible to get what we needed.
It got so bad the core front-end team started to hate me and marketing.
But by the time things got bad with other teams, we managed to convince upper management to stop saying no. Management admitted that we were doing valuable work.
With that blessing, I hired a few great back-end people.
But relations with the core front-end team continued to deteriorate. Things got so bad they stopped helping us completely. Everything was now a “NO!”
So we took headcount we had earmarked for back-end people and hired a few front-end engineers.
But the crazy thing is that my team was only supposed to do back-end work. All of the front-end people in our hiring funnel were supposed to go to the core front-end team. They were short-staffed. And all we were “mandated” to hire was back-end. We did not let that No deter us; we went online, searched our network, and funneled in our candidates, and pushed them to apply to open roles. Never mind that it said “back-end developer.”
In hindsight, my pitch to potential hires seems nuts.
I told them, “If I don’t have enough front-end work for you, are you willing to learn back-end? We’ll teach you and help you.” And even though everyone else was saying No to us, many of these folks shockingly said Yes. They wanted to learn. And in software engineering, filtering for people who aren’t afraid to learn seems to be one of the best hiring filters of all.
By hiring a few front-end people, we practically created our own school to take front-end people and help them do back-end work in the spare cycles. And take back-end people and help them learn front-end if they wanted to, of course.
And it turns out that if you hire great people, it’s incredible how fast they learn.
Then months later, we spun up full-fledged systems and tools with beautiful UIs. We could do pull requests into the core product to get features out to customers.
And a few years later, by the time the startup was acquired, we had more full-stack engineers than any team in the company.
We could build almost anything.
The irony is that top people in the company would point to my engineering team and say, “see how innovative they are.”
But the truth was that everyone was saying no to us. We were forced to color outside the boxes.
The constraints pushed us to do things we would’ve never thought of doing. This experience forever taught me that I don’t need to build in the boxes they’ve set up for me.
*If you want to learn more about how growth engineering teams impact scale-ups, this video by Gustaf Alstromer for YC does one of the best jobs I’ve seen explaining it.
Two Tweets: Viktor Frankl on Meaning, Never Wrestle a Pig
This quote by Viktor Frankl is incredibly insightful when it comes to human nature.
It brings to mind another quote by Machiavelli about why people risk what they have for things they don’t have.
“Men desire novelty to such an extent that those who are doing well wish for a change as much as those who are doing badly.”― Machiavelli, Niccolò
And usually, because there isn’t much meaning.
With so much shade being hurled around on social media and other places, this advice by Codie’s Dad is incredibly valuable.
Two Articles: How to Communicate as a Developer, Incentivizing Yourself
Karl's excellent article, with concrete examples, on how developers can communicate better at work.
Contrary to popular belief that software development is mainly about writing code, it is far more of a people business than many realize.
In most development teams, most of the time is spent communicating and collaborating.
Derek Sivers wrote a nice two-part article about how we incentivize ourselves and how that impacts our ability to achieve what we want.
It’s a short, fun read.
Two Memes: Pitching learning, Excel still rules the world
That pitch to software engineers that they’ll learn is a stronger pitch than most engineering leaders realize.
I bet its true outside of engineering too.
When I made software for Big Banks, it was shocking how many folks still relied on excel.
So this meme is far truer than most would realize, and there is still immense opportunity to take complex excel sheets and turn them into robust standalone software.
As always, thank you for reading.
-Louie
P.S. you can reply directly to this email; it will get to me, and I will read it.
One of your best ever issues, Louie.
> software development is mainly about writing code, it is far more of a people business than many realize.
Now trying to negotiate with my customer's head of sourcing (who is not technical and obviously did not do any research about the impact of my work nor about the current tech labor market) for my renewal, and this just resonated with me a lot.