I consult, write, and speak on running better technology businesses (tech firms and IT captives) and the things that make it possible: good governance behaviors (activist investing in IT), what matters most (results, not effort), how we organize (restructure from the technologically abstract to the business concrete), how we execute and manage (replacing industrial with professional), how we plan (debunking the myth of control), and how we pay the bills (capital-intensive financing and budgeting in an agile world). I am increasingly interested in robustness over optimization.

I work for ThoughtWorks, the global leader in software delivery and consulting.

Wednesday, October 31, 2018

Everyone a Beginner?

I had an exchange with Dan North about the subject I wrote about last month, Beginner's Mind. Dan asked an interesting question: what would it take to make work like this every day for everyone, everywhere?

It's a serious question that deserves serious consideration.

To start, it's worth asking: why isn't work like this today, every day, for everyone, everywhere?

There is a difference between development companies (or divisions within companies) and operating companies. A development company is in the invention or innovation business. Investors and customers place high value on seeing something new, be it features or entirely new products. There is a high tolerance for operational inconsistency from a development company. Recall of how tolerant (or at least, how much less snarky) people were towards Windows when Windows 95 was launched, or the iPhone when the 3GS was launched.

An operating company is in the consistency business. Investors and customers place high value on efficiency and reliability. There is low value in seeing something new as it interferes with set patterns and expectations. There is low tolerance for operational inconsistency. To wit: the ribbon interface that replaced the command menus in Microsoft Office 2007 was not met with enthusiasm.

A company can be both a development company and an operating company. For example, Tesla. Inventing battery technologies and designing cars that are sufficiently different from the cars anybody else has made captures the imagination of financier and customer alike. But they have struggled at the basics of manufacturing things at a modest scale. Manufacturing cars is a path well trod, so nobody places a lot of value on Tesla employees learning things already very well known by people in the auto industry.

There is still room for engaged employees in both development and operating companies, but there is a difference in the nature of their engagement. We want passionate people in the development company, people who will look for ways to deliver value where there was none before. But we don't really want passionate people in utility-type businesses: the passionate accountant who finds ways he believes his clients can dodge the taxman is not beneficial to his clients in particular or society in general. What we do want in operating companies are obsessive people looking for ways to make the core transaction between buyer and seller more efficient or incrementally more delightful without materially altering the nature of the core transaction itself. My unexpectedly very late arrival at the hotel has made it impossible for me to get dinner, but an availability of fresh fruit and healthy snacks free of charge not only satiates my hunger but makes me feel the hotel staff is concerned for their guest's well being. It's still a room with a bed and a bath, but I'm more likely to choose that hotel again in the future because they strike me as being prepared for irregular ops situations experienced by their customers.

There is a fundamental difference between these types of employee engagements. Knowledge of something that customers have never thought to do or thought possible is in the "voyage of discovery" realm. Knowledge of something that customers have long known possible and wondered "why can't / won't they do this" is in the "pay attention" realm. That makes prior questions of skill; the latter questions of will. A lot of things in operating companies fall into that latter category: a decision by a customer service person not to do something is a choice the firm they work for makes, either on the spot (by the employee) or as a matter of policy (by management).

But this shouldn't matter, should it? Either way, the employee is learning. What difference does it make?

It matters from the point of view of both the learning intensity as well as the freedom to act on what has been learned. There is less opportunity for learning and less value placed on it by investors and customers in the operating company realm, hence less opportunity to act on it. And, unfortunately, operating company jobs are the bulk of the jobs people hold today.

The business of software is somewhat unique in that the learning intensity and freedom to act are extremely high, precisely because we get to take voyages of discovery all the time. Sure, learning Pascal was something millions had done before I came along. But my ability to apply that knowledge to do things that had not been done before created a very learning-intense environment: the better my skills in Pascal, the different the class of problem I could solve with it, the more new ground I could clear.

That's great for those of us in the business of software. How do we meet the "for everybody, everywhere" standard?

The opportunity will first present itself by being able to get more people out of rote operating company jobs. But that isn't enough. Yes, in theory I don't need any human interaction at the hotel: I can check-in from my phone and use it as the room key and if I opt out of housekeeping services and order food through Seamless I would never cross paths with any hotel employee. All that does is displace more hotel staff and justify fears of our robotic future and a return to the bad old days of industrialization concentrating wealth and suppressing working classes circa the first half of the 19th century.

There is benefit to having people in opco jobs, and not just to supervise the robots. What if opco employees had tools they could use to solve different classes of problems? Not transactional tools, not canned reports that a back-office accountant can study, not 21st century green screens that clerks can use to sell an upgrade. How about tools that are (a) granular; (b) modular; (c) "programmable" by the user - where the user is not the customer, but an employee; and (d) re-composable. Opcos would be able to provide the operational consistency that investors and customers expect, while enabling a work force with tools allowing them to be less obsessed with efficiency and more passionate about solving customer problems.

What if opco employees could re-program the environment, directly, themselves?

That would certainly bring more people on the same "voyage of discovery" that people in software development enjoy. It would redefine the relationship between developers and consumers as peer solvers of problems of different granularity, not producer-user of a confined operational space. And that would mean less tilt in the playing field of the future, and subsequently less inequality.

How do we make it possible for everyone, everywhere to experience the beginner's mind we get to experience every day in software development? By treating them as problem solvers, not operator-executors.