Market VIsion Hospitality

The main project I worked on was Oddfellows Food Hall. Oddfellows was a 13,000 square foot food hall in downtown Salt Lake City. It was a $4MM project and was the first high stakes project I helped manage. I fulfilled many different roles for OF. 

A lot of our design was on the fly, and we didn't have the time or money to go to professional designers, so I learned to draft, architect, and CAD our creations.

During my time with MVH we also worked on systems administration and proprietary software development. 

In this section, you’ll find a high-level overview of how we unified scattered data silos and automated real-time decision-making. By creating a secure company intranet and bridging software “middleware,” we eliminated inefficiencies, reduced bias, and leveraged data-driven logic. If you’re curious about the technical details or want to learn more about the practical applications, feel free to read on.

We began by building a central and secure company intranet to serve as a repository for all company information and a UX center for operation. From there, we created “middleware” that integrated with the software systems already in use, enabling these systems to communicate with one another, our intranet, and produce automated, data-driven managerial decisions and outcomes. Instead of requiring manual inputs—often riddled with bias or inaccuracy—this middleware aggregated data to automatically assess everything from performance metrics to operational forecasts and respond in real time to changes in the business environment to capture opportunities and mitigate problems.

The basic issue that prompted this initiative was that all the SaaS on the market were modularized silos of information and data that didn't really flow with proprietary business logic from one to another. Over the previous 10 years of innovation in the space, many SaaS companies had come to create quite robust software systems that addressed the particular needs of that administrative or operational function—so there was no need to rebuild the wheel. However, the power of these data silos was mitigated due to them being disconnected. No owner-operator of a business that size could integrate all the valuable but disparate data from a myriad of software platforms and synthesize them into real-time decisions that reflected the business environment of that day.

There were some vital flaws in the design of some of these existing software platforms. For example, there were many manager inputs required that could instead be quantified and automated to prevent employee bias and error. The ultimate vision we had was a system of market-provided software modules that fulfilled administrative or operational functions; that were then pieced together with proprietary business logic in the form of middleware; that allowed the system to not just manage information, but to make decisions in real time.

The essential process was taking business data, generating business insights from this data and the owner’s knowledge bank, taking those insights and turning them into business logic, coding that business logic, embedding that code in a broader UX that made it manageable.

A consistent problem that recurred in restaurant employee schedules was manager bias and incompetence in scheduling (I use incompetence here kindly, it was a job for a computer). Many times you would see managers providing the most lucrative shifts to their favorites (or even worse, those they were having inappropriate relationships with) rather than the employee best suited to supply the demand during peak hours of operation. We wanted to be able to manage the scheduling process and give the best employees the best shifts while still giving the other employees the chance to move up (the best shifts can skew the data to make someone look like the best employee when they were not, causing management to overlook these employees – we had to find a way to correct for this and create disruptive feedback loops that made the resulting employee ratings flexible rather than a permanent biased node in a software system that created entrenched positioning not allowing new employees to shine).

Restaurant revenue is highly non-linear, so you want to capture as much revenue as you can during these peak periods and peak shifts by having your most experienced staff members on shift. There were existing software programs that managed this process, but they required a "manager input" on a scale of 1-5 for employee capability. This introduced bias, favoritism, and if you are using the power of a computer, why the g(x) would you use something as non-sophisticated as "1-5"?

So the idea was to generate an objective numerical value of an employee’s objective contribution to the company, and use that as the "manager input" in a broader scheduling system. You could call this a restaurant employee FICA score (this score would affect other aspects in the system than scheduling, but for brevity, I won’t get into it). The first step in these projects is to break it down into business logic, and then find some schema to attribute numerical values to it.

Starting from this point, we came up with the following data inputs: average sales, average tip, training level acquired, how many times an employee has clocked in late, total tenure with the company, how many times the employee has covered another employee's shift, number of corrective actions, and some other more proprietary measurements I can't mention. These were then given a weighted value which was made up of a function (there was some more advanced mathematical work on isolating bias and lessening the effect of large revenue days to the average sales and average tip; you can be a great employee and if you had shifts with fewer customers, there was a threat of data bias—this data bias would cause the employee to get worse shifts, worse data, worse shifts, worse data, and so on; so we used a mathematician to model that out). So this employee character score function you could call g(x).

This numerical value was then plugged into the broader scheduling function that determined which employees would get which shifts, which you could call f(x). This function took into account weather, last year's sales, yesterday’s sales, holidays, etc. So f(g(x)). In reality, it had probably 100 nested functions. But it was a cool example of how these things can be used. There are also many examples of where disparate data sources (such as smart facilities sensors and data) can be used in this way as well, nesting the data from existing products and services into broader business logic.

We did some things that our coders were blown away with (one example was an RFID in name tags that tracked movement and helped predict server industriousness, which then fed into a broader system for calculating the objective value of a server that would determine speed of upward employment mobility and raises). There are opportunities to break down processes into quantifiable steps that can be leveraged into self-managing software modules everywhere. You just have to be cognizant of these opportunities and have an intuition for what processes can benefit from a more comprehensive solution.

-------------

Below are some basic system outlines we started with. It gives you an idea of how we conceptualized things, but the proprietary business logic is where the real value is, and that is not mine to share.

Market Vision Hospitality provided me with my apprenticeship working under someone immensely capable and immensely demanding. Every project seems easy now compared to the intensity of those projects. I feel completely capable now to take on almost any project - no matter the liability, no matter the accountability, no matter the public scrutiny, no matter the stakes.

The owner ended up closing his businesses due to some personal issues, a lot of it reads like a Greek tragedy actually. It was surreal to see all that I had worked for go up in smoke - but the skills and character I developed will last forever. 

Much of MVH I miss. The owner was insanely demanding - past the point that most could deal with. I've heard many people complain about being held accountable for things that weren't their responsibility, but for me it cultivated accountability to the shared higher purpose. It made me realize that everyone in a team is accountable to the higher purpose, and drawing lines of accountability, though useful for project management, doesn't reflect reality. For high performance teams, there should be lines of responsibility, but completely shared accountability. This radical accountability also forced me develop intense awareness (bordering on project paranoia) & become zealously proactive.

All of this sounds like a turnoff to most, but the level of creative freedom and manifestation that was fostered in this company was unbelievable. 

Not a day goes by that I don't use something I learned at MVH.