Software engineering team design refinement
About three months ago we started arranging our engineering talent at Haventec around a three team principle of personal strengths.
Firstly let me say all our engineers are A players. So ability is up there. But people are happiest when they do things they are good at.
A persons demeanour and other strengths mean they they will be more happy doing certain things over others.
So our Red team does R&D. It can handle fast iterations and can quickly assess, test and dump ideas while trying to break the back of bigger more long shot problems. The Red team must also be able to handle continuous disappointment.
Our Blue Team does our production code so attention to detail and quality tenacity are strengths here.
Our Green team members are our release code engineers. They are sympathetic customer focussed fixers and refiners.
This approach is working well and everyone gets in and helps each other when needed so there are no silo builders at Haventec.
However yesterday I researched some interesting discussions about the difference between a Proof Of Concept POC and Minimum Viable Product MVP.
One article made this good comparison.
A POC proves a function or technologies validity (ie whether it can be done and will work) whereas a MVP proves a products market viability (ie will someone pay for it).
These are two completely different things.
If you really think about this it becomes obvious that even production readiness and tasks such as resilience testing, intrusion testing and hardening are part of delivering a minimum viable product / MVP.
Since we are catering to banks and larger corporations resilience testing and pen testing are part of the MVP.
Originally we thought of the Red team as the MVP team but really they are the POC team. By the above definition the Blue Team is the MVP team and the green team helps mature and flesh out the products with the aid of paying customer feedback.
The other thing that became clear is how important prospective customer feedback and beta testing is to the MVP process.
It's where all the customers questions get asked and answered.
What is the minimum API set we need to run on an enterprise network? What is the minimum feature set needed for someone to use and pay for our product? How good does our documentation HAVE to be? What is the minimum pen testing we need to have done?
Have we got reliable provable answers to all these questions. So besides doing rock solid quality code, the Blue team also has to have constant feedback from marketing, sales and beta testers.
So here is a question. Could a proof of concept team also do an MVP?
Probably not. But it's worth tinkering over.
It is probably good discipline for POC people to talk to prospective customers and get their feedback on what an MVP would look like but once the core concepts have been integrated into a core product, the strengths of red team members start to become a liability.
The patience and relentlessness of a blue team that documents, quantifies and articulates customer product requirements needs a whole other type of discipline.
It's a discipline that personally I do not have.
It will be interesting to see what the rest of the team says about this suggestion.