At both Zoomer and Grubhub, Ryan O’Neil and I built the Decision Science team within the technology organization.
Why?
In 2016, we had strong opinions that decision services should be developed and maintained like the rest of the software stack - repeatable, testable, and scalable.
There is a large Venn diagram of modeling/analysis and developing/scaling when it comes to the job description for a Decision Scientist - just ask Sebastian .
That being said, I’ve seen too many potentially impactful models fail because they fail to make it into production (ie impacting real world plans for the business). These days “production ready” means managing response times, knowing how the service will respond to higher loads, controlling the I/O to maintain integrations with up and downstream systems, performing acceptance tests, and sharing potential impacts ahead of the launch.
If you embed your Decision Science team in the technology org, they can build and release alongside software teams. This engrains a ship and iterate mentality and builds confidence in the solutions the decision services provide.
Ryan and Nicole discussing DecisionOps at DecisionCAMP
One of our early posts at Nextmv - Decisions as code
Our first post on the topic on GrubBytes - Decisions are first class citizens
Where do these teams sit within your orgs? Drop us a line in the comments or on our discuss board.