Originally posted on November 25, 2023
I don't know how verifiable this Mark Cuban clip is, but it's a great story if true.
Mark Cuban - YouTube
Over the past decade, I've been blessed with a team that's grown from 5 to nearly 40 team members. I practice technology law, but I have a background in project finance, which may explain my fondness for the "build-operate-transfer" (or BOT) model. I like this model because the person who designs something has to build it and operate it long enough to prove that it genuinely works, before entrusting it to someone else to carry on. It is a "high accountability" framework in which the builder/operator has to understand and remedy the flaws in their own design. Mark Cuban's story captures BOT elegantly.
Within my own team, we have done this so many times that a specific taxonomy has emerged around how we identify good BOT project candidates [note to self: consider future post on value of taxonomy]. We use this taxonomy extensively - from day-to-day, to team meetings, to goal-setting and performance reviews. The key components are:
1 - Build connections ("develop your information pathways");
2 - Identify gaps and problems ("gather context");
3 - Work, in consultation with others, towards a high-resolution description of the issues ("develop a concise problem statement"); and finally,
4 - Identify actionable steps ("create a program of work").
After I have implemented a new program of work ("Build"), I lead that function myself for months or sometimes years ("Operate"). It's not uncommon for the "Operate" phase to be a one-person show. This allows me to re-test my framing of the problem statement. Once it runs fairly smoothly, a program of work is ready to entrust ("Transfer") to someone else. I am always excited to see THEIR program improvements, since I have my blind spots, and there are always aspects of the problem statement that I cannot fully address.
One downside is I can tend to be perceived as "in the weeds" or "crossing over" into someone else's remit. But hopefully most people see that I'm just trying to get more granular in my framing and more precise in finding an apt solution. A major upside is knowing my team's work well - well enough to parachute in, help out, and, if needed, suggest potential program modifications. Vitally, successfully implementing many BOT projects together gives us insight into how to stitch them together, so the sum is greater than the parts.
Over the years, I've honed my interview skills so I can identify individuals with the potential to do BOT well - comment if you'd like to hear more!
J
P.S. I'd also love to hear some of your stories about growing teams and crafting solutions to complex problems, so please share yours below.