MVP Developers are MVPs
Matt Watson
Product Driven Engineer, Founder/CTO for 20 years, Bootstrapped a SaaS company to a 9 figure exit, CEO of Full Scale
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:
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 amp; 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?
I Digitize Data with AI and Facilitate Ventures with Reporting Dashboards. ? Making Tech Solve for You ??? SAAS .Net Core (C#) | .Net Architect | Azure | AWS l JS Architect | Angular & React | Node.js | Typescript
11 个月Being the MVP developer myself, I can completely relate to this, very relevant revelation.
I help people work smarter, think differently, and navigate their careers
11 个月“The final 20% demands meticulous attention to detail, which bores me.” - I relate to this. Once I KNOW I can do it, I kinda lose interest in doing it.
Technical (co)Founder | (f)CTO | Senior Solutions Architect
11 个月hmmm - interesting take. for me, anyways, i think starting from scratch and building to MVP is a much easier task than shifting through an existing codebase and make a valuable contribution there - having to learn the mannerisms/idiosyncrasies of the previous developer(s), even if it's all good and proper, takes more time IMO. maybe it's just a perception/preference/excitement of digging-into a new project that makes it seem easier :-) anyways, i certainly recognize the two different skillsets and the necessity to have BOTH personality types present on the team - in essence the "starters" and the "finishers".
Practitioner of Uncommon Sense | Human Intelligence Agent
11 个月“Starting something new is way harder than tweaking something that already exists. This is especially true for software development” Only someone that never maintains anything they build would believe that. I’d much prefer to work developers who have the ability to grok the design from existing code and suggest improvements than deal with the code from a grass is always greener in “greenfield development”. Writing a CRUD app with the latest shiny framework doesn’t impress any of your colleagues that can also google shiny framework example. ChatGPT can write this code easily. Knowing what the tradeoffs of using a new framework are and how to apply it to solves a real business problem is a valuable skill for sure. I would speculate that 80% of devs given the opportunity would use the latest shiny thing to fluff up their resume without a thought. 20% would ask “how does this help our business partners? is it easier to maintain than what we have now? can we integrate shiny holistically with our existing code and migrate, or is it a big bang rewrite, just for developer’s entertainment?” That 20% is who you want to hire, they add tangible value. Software engineering should follow the precedent of journeyman -> craftsman-> master
Technical product owner@ VOIS
11 个月How do you choose the type of project you want to develop, is it the idea? Or project feasibility?