MVP Developers are MVPs
Developers who excel at building prototypes are the MVPs of your team
Starting something new is way harder than tweaking something that already exists. This is especially true for software development. Starting a new greenfield project to build an MVP of something new sounds exciting.
Then you realize the 27 frameworks and guardrails you have in place from your company’s primary monolithic codebase don’t exist to help you.
That is also good news. You are free to build whatever you want and run free! It is also terrifying to start over. You are staring at a blank slate and have to make every decision.
Building something brand new requires an entirely different type of creativity, forethought, architecture skills, and more.
Honestly, many developers rarely get opportunities to build something new. Making minor tweaks to existing systems is much easier and is what most developers do throughout their careers.
Today, let's delve into the unsung heroes of the tech world: the developers who excel at building prototypes and MVPs.
The ones who champion the first 80% of the journey.
Be the Champion of the First 80%
Imagine being one of the best developers in the world.
But only because you are terrific at doing 80% of the job. You actually suck at the other 20% of the job.
That has been my career over the last 25 years. My forte lies in architecting and constructing software solutions from scratch, turning concepts into tangible prototypes, and proof of concepts.
However, I'll be the first to admit that I am not the best fit for dotting the i's and crossing the t's.
The final 20% demands meticulous attention to detail, which bores me.
But here's the thing: that's perfectly okay.
Startups need individuals who can dive headfirst into the unknown and emerge with a solution. Someone who can figure out where to start and how to finish.
These developers excel at building minimum viable products (MVPs), the first iterations that serve as proofs of concept, allowing ideas to be tested and iterated upon in the real world.
This skill set, this ability to navigate the formative stages of a project, is invaluable and, quite frankly, a superpower.
They are the MVPs of creating MVPs—individuals whose knack for rapid development and creative problem-solving kickstarts the lifecycle of software products.
Every company needs people on their team that have this capability. Someone who can help build new things, innovate, and keep pushing the bar forward.
Like me, they might also not be the best “engineer” on your team. They might be the best hacker on your team.
A year ago, I wrote an article on how CTOs should be the champions of PoCs you can also check out.
The Other 20%
Let’s be honest. Most developers spend their entire careers doing that other 20%. They fix bugs, perform maintenance, add small feature requests, etc.
How do we query the database? Here are 100 examples to follow…
How do we do unit testing? Here are 100 examples to follow…
You name it, and there are patterns and practices to follow. Most developers feel more comfortable living in those guard rails.
We need those people, and we require a lot of them. Most big tech companies are filled almost entirely with these people.
A good team needs both. It needs both people who can quickly build an MVP and finish that MVP or maintain other projects in production.
The key is to get the right people working on the correct type of work.
Always Be Prototyping
The value of a developer skilled in prototyping extends far beyond the initial stages of a project. They are often the catalysts for innovation, pushing boundaries, and exploring new possibilities.
Their work inspires and leads the team, setting a direction others can refine and perfect.
However, companies must strike a balance.
While these developers excel at the start of the project lifecycle, expecting them to excel in the final stages of development may lead to frustration and burnout.
As a CTO, I have spent much of my time prototyping major new product features, major architecture changes, or entirely new products. The best value I could provide the team was innovating, not fixing bugs.
The key lies in building diverse teams where different skill sets complement each other.
Juggling the Three Priority Buckets
Let’s be honest… Software development, especially if done right, is controlled chaos.
If you aren’t pushing the team hard enough and trying to innovate, it is a problem.
If you are too stagnate and focus only on busy maintenance work, it is a problem.
Software development is always a balance of the three priority buckets. It is a constant balance of fixing bugs, new features, and maintenance work.
These are the three priority buckets:
Have to do
Want to do
Need to do
It feels like controlled chaos because you constantly juggle these 3 balls in the air. If you drop any of them, it can cause big problems.
In the context of this article, I want to stress the importance of the work you “want to do.”
You need someone on your team who spends some portion of their time on that type of work, which tends to be prototyping and more innovative work.
Don’t drop that ball, or innovation will drop with it.
Finding Time: Netflix & Code
How do you find time yourself as a busy engineering leader to work on these projects?
For years, I did it after the kids went to bed. It gave me a couple of hours a day to work on the things I wanted to work on. Time to prototype and build that next big thing.
My wife wanted to essentially Netflix & Chill.
While she was chilling, I was coding. I couldn’t tell you how many movies or TV shows I have watched while writing code, researching, writing blog posts, or doing something else simultaneously.
Maybe my superpower is watching movies and working at the same time.
Is this the best work/life balance? Of course not.
But sometimes, it is what it takes to move the ball forward. It is the precious time you need to innovate and prototype what could be the next big thing for your company.
Sometimes, I think we all dream of having time to “Netflix & Code.” Time to work on that thing we have been dying to work on. Not sure what to watch? Try HBO’s Silicon Valley.
Being a startup founder isn’t for everyone. I worked evenings and weekends for years to make my companies work. I guess that is one of the reasons they call it the Startup Hustle.
By the way… what are you doing this Saturday?
Definitely an interesting take.
My experience has been a little different but again I'm not even half way there as compared to the number of years you spent.
So far for me, build from scratch has always been much easier as I could do whatever I want, you captured this in your post. On the other hand, build on top of things become very hard as now you need to learn how this complex million lines of code work. Well, that's an exaggeration, but not by much. Working with ultra large code bases, I've found myself spending weeks just trying to understand how the hell something works.
I absolutely resonate with this. I can really build MVPs very fast. But that is only a ground work. I would say making that into production ready is where the real work is done and most difficult. When I build the MVPs my co-founders think, "Okay, how soon we can make the first sale?". They don't really understand it and I fail to convince them.