Quality and Innovation

In July, Paul Graham posted an article called “Maker’s Schedule, Manager’s Schedule“. He points out that people who make things, like software engineers and writers, are on a completely different schedule than managers – and that by imposing the manager’s schedule on the developers, there is an associated cost. Makers simply can’t be as productive on the manager’s schedule:

When you’re operating on the maker’s schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in. Plus you have to remember to go to the meeting. That’s no problem for someone on the manager’s schedule. There’s always something coming on the next hour; the only question is what. But when someone on the maker’s schedule has a meeting, they have to think about it.

For someone on the maker’s schedule, having a meeting is like throwing an exception. It doesn’t merely cause you to switch from one task to another; it changes the mode in which you work.

I find one meeting can sometimes affect a whole day. A meeting commonly blows at least half a day, by breaking up a morning or afternoon. But in addition there’s sometimes a cascading effect. If I know the afternoon is going to be broken up, I’m slightly less likely to start something ambitious in the morning.

This concept really resonated with us – we know about the costs of context switching, but this presented a nice concept for how a developer’s day can be segmented such that ample time is provided for getting things done. As a result, we attempted to apply the concept to achieve more effective communication between technical staff and managers. And in at least one case, it worked extremely well.

Case: Ron DuPlain (@rduplain) and I frequently work together on technical projects. I am the manager; he is the developer. More than we like, we run into problems communicating, but fortunately we are both always on the lookout for strategies to help us communicate better. We decided to apply the “makers vs. managers” concept to meetings, to see whether declaring whether we were having a maker’s meeting or a manager’s meeting prior to the session would improve our ability to communicate with one another.

And it did. We had a very effective maker’s meeting today, for example… explored some technical challenges, worked through a solution space, and talked about possible design options and background information. It was great. As a manager, I got to spend time thinking about a technical problem, but temporarily suspended my attachment to dates, milestones and artifacts. As a developer, Ron got the time and attention from me that he needed to explain his challenges, without the pressure of knowing that I was in a hurry and just needed the bottom line. As a result, Ron felt like I was able to understand the perspectives he was presenting more effectively, and get a better sense of the trade-offs he was exploring.

We had the opportunity to meet on the same terms, all because we declared the intent of our meeting up front in terms of “makers” and “managers”. Thanks Paul – this common language is proving to be a powerful concept for achieving a shared and immediate understanding of technical problems.

Michael Davis (@yellowfish_md) and I were talking last night about effective email and other electronic communication.  We were discussing the utility (importance?) of making twitter updates/tweets clickable.  (I really don’t like saying “tweet,” but I’m getting used to it.)  You can make tweets clickable by adding URLs, using hashtags when appropriate, and using @twitter names whenever you can.

So Lance (@dmmandil) says, on twitter,

It’s meteor time. Grab your blankets, and get your view on Tuesday night into Wednesday morning for best view. #Perseids

I click on “#Perseids” which gives me a search across twitter.  A guy in Sweden (@maltesk) posted:

(So many folk twittering about the #Perseids coming next week – they’re here now people. Deal! http://www.imo.net/live/perseids2009/)

… and I check out http://www.imo.net/live/perseids2009/ — which is an amazing breakdown of meteor sitings.  (BTW, this site is a great example of reporting data points and geo summaries — refer to it for good vibes in your project.) The page/site says to send feedback to Geert Barentsen.  ”That’s a familiar name,” I thought.  ”I know that guy.” Sure enough, I do.  I spent a week with him in Santa Fe; we spent a lot of time hanging out and headed out about the city.

So in this social+technical network, a guy I don’t know (@maltesk) in Sweden was connected to Lance (@dmmandil) because they both used the same hashtag (and used it very well).  That guy in Sweden (@maltesk) is connected to Geert at least in that he uses Geert’s tool.  I’m connected with Geert through past experience. I discovered all of this in 15 seconds thanks to clickability.

PS – Be sure to check your links after posting if you want people to find who/what/where you are discussing.

On April 9, 2009, Computerworld published a highly “Digg-ed” post entitled “Why Goofing Off Boosts Productivity”. This article highlighted some recent research results from the University of Melbourne that demonstrated the utility of occasional Twittering and Facebook-ing from work, and suggested some additional anecdotal reasons why “Internet slacking” might be productive.

Productivity has been described in many ways, for example as the ratio of output to input , task completion through David Allen’s Getting Things Done, or focus on business results using the concept of the Results-Only Work Environment.

But it is easy to forget that quality and sustainability also play a role in productivity as well. Jorgenson & Griliches (1967), for example, explicitly define productivity as the ratio of total input quality and quantity to total output quality and quantity. Hawken, Lovins & Lovins (1999) consider total-resource productivity in Natural Capitalism, a measure that emphasizes the efficiency with which a production process uses its energy, natural resources and other inputs. That is, you can’t be productive if you are creating a lot of waste – and you are optimally productive if the outputs of your process are useful inputs to someone else’s process!

Problem-solving capacity, in my opinion, represents one of the key elements in total resource productivity – and one that we routinely overlook. As a result of the process of working, can you simultaneously accomplish results and emerge feeling refreshed and renewed? The human psyche and capability to achieve is the ultimate renewable resource, and “burnout” is the indicator that you may be sacrificing total-resource productivity for higher levels of “more traditional” productivity.

The same theme was touched on in an April 8, 2009 post by Dan Markovitz called Why Isn’t Thinking Time Part of Your Standard Work? Although it is acknowledged that thought without action may not be productive, he notes that action without thought can be wasteful as well:

Action without thought leads inevitably to one of the seven forms of muda. It’s very hard to actually stop doing and start thinking, but that’s the real way to eliminate waste and create value. There’s a recent story about a computer room at Toyota’s Torrance headquarters that was getting too warm. Most people would get that email and immediately turn up the air conditioner. You know, respond immediately to the email. But these guys did a root cause analysis and found that the real problem was a blocked air duct. The symptoms didn’t go away immediately, but the real problem was actually solved. It just required some time to think.

The lessons here are interconnected: a) quality and “people-sustainability” are factors in total resource productivity, and b) time to think and reflect contributes to quality in the problem-solving process. Not building “reflective time” into a project schedule or a GTD/ROWE process can negatively impact results when the whole system is considered.

---

Hawken, P., Lovins, A. & Lovins, L. H. (1999). Natural Capitalism. Little, Brown, & Co.: New York.
Jorgenson, D.W. & Griliches, Z. (1967). “The Explanation of Productivity Change”. Review of Economic Studies 34(99): 249–283.

Tom Erickson, in his introduction to one of the sections in the forthcoming Handbook of Research on Socio-Technical Design and Social Networking Systems, explains socio-technical design well:

“Socio-technical design is not just about designing things, it is about designing things that participate in complex systems that have both social and technical aspects. Furthermore, these systems and the activities they support are distributed across time and space. One consequence of this is that the systems that are the sites for which we are designing are in constant flux. And even if we were to ignore the flux, the distributed nature of the systems means that they surface in different contexts, and are used by different people for different (and sometimes conflicting) purposes.”

Socio-technical design is, understandably, related to sociotechnology. There is much work to be done to develop the processes and techniques that will be required to manage quality and continuous improvement in the context of socio-technical design!

Technology is the “sum of ways in which social groups construct the material objects of their civilizations.” The things that we use – the “design artifacts” of the processes used to build them – are socially constructed to the same extent that they are technically constructed. The convergence of technological and social insights in the creation, construction and use of artifacts is sociotechnology.

For example, we typically build a bridge when there’s some expectation that people need to get from Point A to Point B, and there’s something they need to bypass along the way (e.g. a river, a canyon, another road). Failure to consider the social factors as well as the technical factors could lead to a “bridge to nowhere” – and we all know at least one person who’s had a problem with those. Non-technical factors pertaining to the environment in which an idea is created and implemented are crucial.

According to Bunge (1998), sociotechnology is the process of applying insights from the social sciences to design policies and programs. More specifically, this is how Gingras & Niosi (1990) explain Bunge’s perspective:

Ten years ago we were talking about the convergence of customer touch points: phone, fax, web, cell phones, email and regular mail. With handhelds and mobile devices becoming more and more ubiquitous, and services like Facebook becoming more integrated into our daily lives, the next convergence is between people and the technologies we use. The boundaries are becoming increasingly blurred, and the impact of this convergence on business must be explored. Reviewing research by pioneers like Tom Erickson is a good place to start. We are all becoming sociotechnical.

(Note: Sociotechnology is an important part of socio-technical design.)

---

Bunge, M. (1985). Philosophy of science and technology. Vol. 7 of Treatise on basic philosophy, Dordrecht: Holland.
Bunge, M. (1998), Social Science under debate. A Philosophical Approach. Toronto University Press: Toronto.
Gingras, Y. & Niosi, J. (1990). Technology and society: a view from sociology, in Georg Dorn and Paul Weintgartner (eds.) Studies on Mario Bunge’s Treatise, Poznan Studies in the Philosophy of Science, Amsterdam and Atlanta, 421-430. Retrieved from http://www.archipel.uqam.ca/506/01/On_Bunge.PDF
Nieto, C. C., Neotropica, F., & Durbin, P. T. (1995). Sustainable development and philosophies of technology. Society for Philosophy and Technology, Vol. 1, Fall 1995. Retrieved from http://scholar.lib.vt.edu/ejournals/SPT/v1n1n2/nieto.html – (Note: I added this one simply because I really like it, and it’s related to the discussion on sociotechnology.)