Disciplined Creative Time
I think every blog has at least one post that says “sorry I haven’t posted in a while.”
Today is that day for me. I started professor-ing in August and have been on the Manager’s Schedule ever since. By the time I get to Maker’s time, which is where I think about the things I see in journals and newspapers, I’ve been pretty worn out. I realized that effectively managing your Manager’s time is the key to getting Maker’s time. If there’s too much physical time or physical energy wrapped up in the Manager’s Schedule, just stop right there – don’t even plan to get any creative work done. When you sit down for your “planned Maker’s time”, if your body is weary, your soul is just going to want to sip on coffee and surf the net.
I will need to take a much more disciplined approach to my creative time if I’m going to produce any useful output. (Valdis, that means MoC!)
Maker’s Meeting, Manager’s Meeting
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.
Clickability improves Discoverability
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.
What Cupcakes Can Teach Us About Quality
After being introduced to Cappellino’s in Charlottesville this past week, I have been thinking a lot about cupcakes. I have actually been thinking about cupcakes for a couple weeks, since the time that my friends Ron (@rduplain) and John (@superninjarobot) went out for “beer and cupcakes”. I thought they were either joking, or that this was a euphemism for something (they are both dedicated computing experts, and I thought they might be hacking Python or their toaster ovens or something). But no, they really meant it – first, a trip to Cappellino’s, followed by a couple hours at the bar talking technology.
So this past Wednesday, I had my first cupcake (“New Yorker”). And on Thursday, I had my second cupcake (toffee nut). And I swear I will have no more cupcakes (well, maybe ONE more) before the end of August. Why, I asked myself, am I so inspired by these cupcakes? Ordinarily, I can take them or leave them (and in fact, I mostly leave them).
When I read this article in the Charlottesville Daily Progress from October 2008, I realized that what I am really connecting with (via the Cappellino’s cupcake) is my appreciation for simple, authentic quality:
Every day, except Sunday and Monday, tasty tributes to the legacy of James Vincent Cappellino are created at Crazy Cakes. Everything is made from scratch.
Frank Cappellino said the business was designed to represent olden times when quality was paramount and family reputations rode on every bite. Only butter is used and Madagascar vanilla, which is twice the strength of traditional vanilla.
What I’m tasting are their company’s values. And I like those values, and I want to espouse those values myself. Although I’m sure I didn’t consciously think this way when I was younger, I now want my reputation to be embedded in the business I do with others. I want my colleagues and clients to know, by dealing with me, that I am not only committed to quality but that it pervades my being – that I think about how to get it, and how to balance quality and innovation, and how to balance structure and agility – all the time. Ultimately, I want what I contribute to the world to be as subtly inspiring as these unique cupcakes.
Disorganization and Changing Your Mind are Both Expensive
Ron DuPlain forwarded me an interesting post from November 2008 (via @duanegran, I believe) called How much do websites cost? It’s a great comprehensive overview of the different kinds of web sites that can be built – the spectrum of customization, interactivity, and intent that dictate whether a web site will cost $200 or $2 million. But what really struck me about this article was one tiny little section that talks about value, emphasizing the relationship between quality, waste, and the changeability of human wants, needs, and desires:
2.) A small company site that has 5 to 10 pages describing the products/services offered by the company. $500 to $2,000 depending on how prepared you are, and also on how clear in your own head you are about what you want. Disorganization and changing your mind are both expensive.
Disorganization is expensive because it blocks action. When your house is disorganized, you waste time and energy trying to find stuff. When the processes you use in the workplace are disorganized, time and physical energy can be wasted engaging in non-value-adding activities, and mental and emotional time and energy wasted in unproductive communications. Wasting time and energy can generate short-term real costs (for example, moving parts or products around a factory or supply chain can delay time-to-market while costing more in fuel for transport), long-term real costs (e.g. reinforcing negative behaviors that lead to breakdowns in interpersonal relationships, teamwork, or morale) or opportunity costs.
Changing your mind is expensive for the same reason: it either blocks new action from taking place, or it eliminates the value that could have been added by prior work. A task is not actionable unless you have the 1) resources to do the job, 2) the information and interest to complete it, 3) the skills and capabilities to make it happen, as well as a clear idea of what needs to be done, and 4) an execution environment that supports getting things done. Changing your mind can erode #2 or #3.
To reduce the risk associated with development, and to control the costs of the project, find out:
- How much do you really know about what you want?
- What essential elements are you pretty sure you’ll still want or need in 3 months, 6 months, 1 year, 5 years?
- What parts do you have the resources, information/interest, capabilities/skills/clarity, and execution environment to get done now? (I call this RICE to make it easier to remember)
The lesson: to get higher quality and lower costs (that is, greater value), focus on those parts of a project that are least likely to change and do those first. This is, of course, if you have the luxury to be agile (highly regulated environments may impose restrictions or limits). Then stop – figure out what your experience working on those parts tells you about how you can approach the problem more systematically and effectively- and repeat the cycle until you iterate to the desired solution. This is the essence of applying organizational learning to your day to day tasks.
