The Operating Model of Tomorrow
“Would I rather be feared or loved? Um. Easy. Both. I want people to be afraid of how much they love me.” – Michael Scott
Principles aren’t just Ray Dalio’s secret sauce. In my experience, good ones will help your business grow and help you flourish in a competitive environment. Better ones will differentiate you on substance and value. The best ones will allow your employees and your customers to trust you.
Not love you.
Trust you.
And in business– as with life after 50– trust is more powerful than love.
What follows are 10 principles– blue sky ideas– for building the software services platform of tomorrow. They are an explicit departure from the operating discipline of India’s IT outsourcing industry.
And not just India’s IT firms. These are the principles for the businesses of tomorrow– anywhere– an experiment in building equity.
In no particular order….
Invest in building dreams
I’m not trying to be poetic or inspirational. I mean literally. Give your employee-owners 1 day a week (or its daily equivalent) when they get paid to build their side hustle. Embrace the inevitable– the 4-day work week– and don’t try to own the outcomes of day 5.
No one’s dream is to have their employer thank them for their next big business. Google almost got it right, except for the ownership part. And I’d like to think that there’s a reason the guy who invented Gmail is now an angel investor– he is doing for others what the system (conventional business thinking) failed to do for him.
That’s not to say “be completely hands off.” If the side hustle grows large enough– preferably with your help– then spin it off, with the employee as the CEO or CTO. The parent company can take some pre-agreed (small) percentage in the new venture.
That would transform every IT professional services firm into a private equity investor– with its own Y-Combinator-like ecosystem of portfolio companies.
Imagine a world where you don’t have to be the billionaire founder of a company to go on to become that company’s version of the Paypal Mafia. That isn’t socialism. It’s intentional inclusion. It’s reappropriating the word equity so it’s less about vesting schedules and more about justice.
Takeaway #1 - Invest in dreams… because that is step #1 to building trust with the best engineers in the world– the top 1%. Be realistic about the value proposition to them for joining your shitshow. Seriously. Unless they’re founders, why else would the 1% ever… EVER!... even consider a professional services firm?
Pay bonuses for objective quality
If a tech-services/professional-services company is to reshape itself into a platform, it needs to address the old operating model’s performance shortfalls– how to improve its quality of output.
For instance, every CIO sets an admirably high bar for the quality of code they expect from their engineers– i.e., “quality as table stakes”; quality as what developers are expected to produce for their base salary. But not a single CIO can demonstrate that the high bar they’ve set is reflected in their engineering outcomes.
And every CIO struggles with how (or whether) to change the financial incentives of that ecosystem. The popular answer these days: OKRs… which are brilliant(!) for single-function, single-product tech companies. And… when they’re applied to big and complex… well, they end up reading exactly like old-school pre-OKR quarterly/annual goals.
To be fair, CIOs all quietly want to pay bonuses based on quality and impact, but they still rely on the management structure’s subjective impression– not objective measures– to make that happen.
That’s where this principle starts.
Pay employee bonuses based on a combination of objective business and engineering outcomes.
Nothing with a check box (i.e., did the person do the thing the business expected/wanted them to do– yes/no).
The best way to measure this is in dollars– $$ saved through efficiency or $$ gained through revenue. Most organizations can figure out some way to do this. They just need to apply it to tech employees and consultants.
And then there are the engineering outcomes. How well do they code by themselves and with their team?
The operating model of tomorrow will need to turn virtuous engineer-level and team-level habits into monetary incentives. How many lines of critical code were covered? What was each engineer’s role in mitigating their team’s prod issues… permanently or reducing the time-to-detect future incidents? What are the team’s error rates and latency?
All of these virtuous outcomes can be measured objectively…. And be translated into how the system rewards engineers.
Instead of just setting a high bar that demands excellence without an objectively-derived incentive.
Takeaway #2 - Pay bonuses for objective quality… because once you land the top 1%, they can focus on engineering, instead of managing their managers… or– god help us– managing clients. If the top 1% cared about managing others, they wouldn’t be in the top 1%. They’d be the soulless demons who set up meetings.
–
Before we jump to the next principle, one quick note. There is zero chance that this dynamic is just in the software engineering space. I don’t care what function you play in the corporate world. There’s a high probability that you are paid and promoted based on your manager’s gut impression of your contributions.
Subjectivity sucks in that context, especially when we’re in a position to change it.
We might live in a world where “perception is reality” but that’s our failure– the system’s failure– to invest in searching for objective truth.
Train Business Gods
Someone (other than me) has got to be tired of me writing about this. I am honestly starting to annoy myself with what a broken record I am.
[Play the clip, Bob.]
“In the enterprise context, if you’re a technologist and you don’t know the business better than your business partner, you’re a waiter. At best. Your only career progression options are to become a lifer and hope that the younger executives continue to mistakenly believe that you know where the bodies are buried.”
[Next clip… 90’s outfit.]
“Career progression without knowing the business? No soup for you!”
[Next clip. Flock of Seagulls haircut.]
“And if you think that’s bad for employees… well, that’s the mold that most outsourcing shops– onshore and offshore– fill with human Jello. Because they think that’s what clients want: some limp form of yes-sir professionalism. The funny thing is that any time a consultant breaks that mold, everyone on the client’s side fights over who gets to convert the brave consultant into a full-time employee.”
Suffice it to say that in the old/current operating model, consultants could use some assertiveness training.
That wouldn’t work in the operating model of tomorrow. If anything, once you land the top 1% of engineering talent, they’ll need humility training.
Add business depth to their arsenal and the 1% will be beautifully, wonderfully obstinate.
Great problem to have.
All joking aside, I don’t know of any business people that wouldn’t fall over themselves to work with that kind of tech partner. Today, these kinds of engineers are rare but once recognized, they’re called “business contributors.”
Tomorrow, they’ll be the business.
Takeaway #3 - Train business gods… because knowing how to write (code) is < knowing what to write. And both are < knowing why to write. It’s the difference between being a waiter and a chef. One has autonomy, agency, and impact; a path to mastery and self-respect. The other… just… can’t wait for their shift to end.
Recruit Teams, Not Individuals
I started to do this years ago. Want to join my team? Bring the people that complete you. Not in 6 months. On day 1.
It’s an incredibly powerful ask of someone, especially if they fancy themselves a leader.
I’m not challenging that perception. “I believe you’re a leader. Come with your followers. That’s the most I can do to set you up for success.”
Because no one succeeds alone.
Takeaway #4 - Recruit teams, not individuals… because you’re exemplifying how your clients should also operate. Unless they follow your lead, they’ll keep asking for staff augmentation– individual hole-fillers. And there are no holes shaped like one person. Your clients– like you (and thru you) should be hiring teams.
Sell substance
My favorite analogy for doing cutting-edge technology work is that it’s like eating cake. It’s a well-deserved treat after you eat your vegetables– the more painful stuff you have to do to keep the lights on.
In large enterprises, there are entire classes of employees that don’t even get vegetables. They have to eat cardboard. Mainframe developers. Production support. Whichever poor coder picked the short straw and has to rep the team during an architecture review or two or ten.
And god-help-you if someone from the cyber team taps you on the shoulder. They come with pallets from Home Depot, filled with wet cardboard… with no explanation of why it's wet. Just eat it… before tomorrow. No, wait… before midnight tonight.
Everyone does (or should do) their share of the boring but substantive work– of eating cardboard, not cake.
So operating models like those of some banks that create Innovation Centers– where 20 lucky engineers get to eat cake all day– are fundamentally inequitable. Plus, the lucky 20 all get to suffer from digital diabetes. Any more sugar and their toes fall off.
The operating model of the future demands a healthy, sugar-free diet. If anything, we need to take something seemingly cardboardy (like application modernization) and show how incredibly delicious it can be… with the right chefs.
[Someone please take that chef analogy away from Hood.]
Takeaway #5 - Sell substance… because there’s nothing worse than a company/client that outsources their cake-eating. They either have never eaten cake (because they’re monsters) or they have tasted the angels and don’t think their employees should (because they’re monsters). Don’t work with monsters.
Sell Working Code, not Meeting Attendance
I’m hoping that I don’t have to explain this one. Meetings are every dysfunctional organization’s adult-sized binky. Nervous? Chew on the binky. Tired? Hungry? Wet yourself? Binky!
The next time you think “meetings suck”... know that I mean that very literally.
Takeaway #6 - Sell working code, not meeting attendance… because your clients’ persistent demands to have you and your team on a lot of calls is a reflection of their dysfunction– a signal that they don’t need engineering… they need a business model transformation. Code or just thank them politely and walk away.
Use All That Code You Now Know How to Build to Deliver Products.
You’ve built a pricing platform at three different shops. Hey, crazy idea: don’t build it at the fourth shop. Sell them a pricing platform.
[Tap. Tap. Tap. Is this thing on?]
Takeaway #7 - Use all that code you now know how to build to deliver products… because life is too short.
Stay Small, Local, and Specialized
Think of your company as a balanced network. Each node should have a max size of 150 people (because anything larger and you bring in the machinery of bureaucracy to manage the scale… and bureaucracy is the death of great talent).
But don’t worry, your business is not limited to 150 people. That one autonomous node is.
Growing your network– your business– will require a second/third/fourth node. Each autonomous. Each operates on the common principles that helped the first node succeed. And all of the nodes remain loosely coupled to one another.
That’s how you keep it small.
Local and specialized?
Well, the specialization can’t be tech alone. Ideally, it will lie at the intersection of a business vertical and a proven tech methodology. For instance, banking… app modernization. Healthcare… data management. Specificity is a powerful salesperson.
And those business verticals should align to the node’s local region. Want to build a 150-person node in Connecticut? Your business vertical has already been picked for you by history. Insurance. Boston? Education. DC? Defense contracting. Houston? Energy. The list is an exercise in the obvious.
Apply it globally? Basel, Switzerland? Pharmaceuticals. Zurich, Switzerland? Medtech. All other cities in Switzerland? Toblerone.
The key is to never grow a function past 150 employees per node. Focus on autonomy. Create micro-companies based on shared principles and governed by a common, network-wide operating model/discipline.
Takeaway #8 - Stay small, local, and specialized… because the benefits of organizing/growing like a network of autonomous nodes give you a size and speed advantage against competitors who rely on traditional management hierarchies. A loosely-coupled business architecture helps grow more nodes in the network while growing each node to its maximum ideal size. All so agility– not bureaucracy– can become your operating model’s defining attribute.
Sell Your Swarming Abilities, not the Swarm
If you’re not familiar with the term swarming, it’s also called the kitchen sink. To quote the Dalai Lama, it’s “what you throw at a problem when you’re “up to here with their bull$#*!!”
[Yeah, I didn’t realize he cursed either. Disappointing.]
Swarming is what CIOs do when they need to light a fire under a program’s ass. For instance, an important program is late… or, a critical application keeps burping… or their boss’s favorite business partner has an unplanned delivery and the bench is empty. A CIO will airlift a dozen of their best people from programs that are not on fire and land them on Omaha Beach.
[Take a quick break from reading and go watch the first 20 minutes of Saving Private Ryan.]
[Back?]
[Yeah. That wasn’t fun.]
The point is that battles are won by swarming your problems. Short, intense bursts of engineering leadership.
The problem is that every program that you pull a super-soldier from– even for a week– tends to start looking like Omaha Beach.
Unless… you can buy a trusted external swarm.
Takeaway #9 - Sell your swarming abilities, not the swarm… because every business ambition (and every pending program failure) could use a boost of engineering enthusiasm. Because sometimes, the client has half-assed code/design/architecture that no one should start from scratch. It just needs a murder board that isn’t filled with the usual (internal) suspects, but rather… the 1%... hands-on.
And finally,
Let the top 1% work from wherever the #%^# they want
One exception: sales. And by sales, I mean literally everyone who doesn’t code for a living.
Don’t get me wrong. If you don’t code, you’re needed. Period. And, you’re needed at the client’s site.
Only exception: if the client is remote-only.
Takeaway #10 - Let the top 1% work from wherever the #$% they want… because as long as they’re motivated, engaged, aligned to a specific node, and available during the client’s hours, the other principles will compensate for all the stupid fears that old-school orgs will forever have. And once there are enough nodes in the network, this whole question will become moot.
Conclusion
The principles above sow the seed of trust. They can help create a different kind of company, a different kind of trust– a reimagining of how equity– not stock options– but justice herself can be the foundation of an industry.
With clients, trust transforms into enduring, ever-deepening relationships.
With employees, it paves the path for autonomy, mastery, and self-actualization.
So… would I rather be feared or loved?
Um. Easy. Neither. I’d rather be trusted.
Postscript
I love the language that birthed American democracy. Hamilton called it the Great Experiment.
Tell me that isn’t cool.
He and his peers were all about hope. They were all about immersive, experiential learning a couple of centuries before those terms were coined.
Jefferson wrote “No experiment can be more interesting than that we are now trying, and which we trust will end in establishing the fact, that man may be governed by reason and truth. Our first object should therefore be, to leave open to him all the avenues to truth."
Wow.
He wrote that unironically.
Didn’t leave open the possibility of alternate truths, alternate facts– casual demagoguery– the greatest threats to the Great Experiment.
–
The world of business hasn’t had its Great Experiment moment.
Yet.
It’s still toying with the language of equity and social justice. And I don’t mean that as a slight. I think it’s actually hopeful.
It sets the tone for what should come next.
Business just needs a new set of founders.
Send me some 1-on-1 feedback with your thoughts on this piece or head back to LinkedIn to post a comment and participate in the ongoing discussion. You can also “love” this piece there (because a “like” is cold and impersonal and makes everyone think that you don’t actually read anything).