Sometimes the decisions are easy.

About 15 months ago, I left Best Buy, where I’d been for 13 years. I joined Digital River to help transform the platform and the company.

Today, my colleagues there learned that I’m leaving Digital River. My last day there will be Friday, August 15th.

I’m leaving behind friends who I’m going to miss. I’m also leaving behind work that I’ve started that is not finished, and I wish my teams well as they continue the journey.

I’m making this decision because I discovered, while being a full-time parent in June and July as my wife Christina was travelling, that there is a young man named Alex living in my house that I don’t know very well. I like him. He’s funny, and smart, and considerate, and I want to take the time to get to know who he is before he turns 18 and leaves the house. I also want to make sure that I get the chance to know my daughter Nell in the four years that I have left before she turns 18. I haven’t seen much of her the last couple of months, but I like her – she’s brilliant and witty and wise beyond her years.

I can’t be the father that my children deserve and the leader that my teams deserve with the amount of time I have. So I need to make a choice, and it’s a surprisingly easy one, although not without regrets.

To stay busy, I’m going to be consulting. It’s been a long time since I worked for myself, and I think it’s going to be fun.

DevOpsDays Minneapolis 2014: Comments

I spent last Thursday and Friday morning at the DevOpsDays conference. It was a good experience, and featured some truly excellent presentations, including an opening keynote by Sascha Bates that set the tone for the conference (it’s all about the empathy and inclusion), Dan Slimmon on Conway’s Law, Jeff Sussna on Promise Theory, and Ian Malpass on dealing with failure without scapegoating. Plus more – full list here, including videos of the talks.  I wasn’t able to stay for the afternoon open spaces, unfortunately. Parenting is more important than careering. I also wasn’t able to stay for the social event Thursday night, which I would have liked to do.

I had a really good time, and it was very much worth it.

But…

Something bugged me about it. Sascha’s keynote set the tone that pretty much every other presentation echoed: what DevOps is about, at its most essential, is the idea that we should come together rather than break apart. As Katherine Daniels asked in her presentation, “do we really need a new word for not being dicks to each other at work?”

In the spirit of that, here are the constructive criticisms that I supplied in the post-conference survey. I also spent a few minutes with Bridget Kromhout, one of the organizers, giving her this feedback in person.

I really do intend this as constructive criticism. I think DevOpsDays was an excellent conference, and I’m glad that I went. I intend to go to future instances, and will recommend it to people.

But…

I think that it’s less than it could be, and thus I offer the following criticisms.

1. Inclusion is a great theme; remember that it also means those over 40, those who use Windows, those who are not liberals, and those who do not drink. Subtle messages mean a lot, and the overall tone of communication conveys that the modal person in the community is young, Mac-using, liberal and a fairly heavy drinker. Think seriously about whether you want to send this message.

Disclosure: I’m 48, Mac-using, liberal and a drinker. Please think carefully about why I would have problems with the issues I noted above – you were (mostly) speaking to me.

2. Speaker introductions should provide background on who the person is and what they’ve done that’s relevant outside the community as well as inside it. Having @littleidea introduce Patrick meant a lot to many in the room, but nothing at all to me, because I had no idea who @littleidea was. Still don’t, because he gave me no reason to care. I got the sense that I was watching some people have a conversation, rather than having someone introduce a speaker for a closing keynote.

3. Drinking as a theme was troubling. I don’t have a problem with drinking, but the emphasis on it was making me uncomfortable. I got the distinct impression that I should have been at the party on Thursday night, and that those who were hung over or who missed Friday entirely due to recovering from drinking were culture heroes. This is almost certainly not the message you wished to send.

4. There were a lot of in-jokes and inside references that made it clear that I was a newcomer to this community. Previous conferences I’ve attended (Velocity, Glue, Agile Day, Agile Coach Camp, and others) have made a point of providing explanations of the in-jokes that helped me become an insider. If your desire is to grow your community (and I believe it is), then you need to think about whether your community is seen as welcoming, and whether it provides ways for newcomers to learn about it and become part of it.

Think about the fact that I just used “you” when talking about the community. I clearly don’t consider myself a part of it, despite having attended the conference. Why is that? Is it something that you can affect?

Shandar Ben Bransvik lives on.

You may not know it, but I’m in the credits of a bunch of computer games. I’ve been playtesting games for Digital Eel for years. If you don’t know Digital Eel, you should – they make really fun games, the best of which (to date) is a game called Weird Worlds, itself the sequel to a game called Strange Adventures in Infinite Space. Both of them are micro-scale 4X games, where you can explore a galaxy in 30 minutes.

Being a playtester for an indie games studio is a lot of fun – I’ve been able to see games while they were in their early stages, and my feedback has helped to shape the final game. There’s something magical about seeing software take shape over a number of iterations, and having a dialogue with the creators of the game is a special treat.

The latest game from the Eels is Infinite Space 3, and they took to Kickstarter to make it happen. Of course I had to back it. One of the reward levels let backers name a starship captain. Of course I had to choose that one. And, of course, the name of the captain was obvious.

So when you are playing Infinite Space 3, and you get Shandar Ben Bransvik as a captain, and you want to know the story behind it, you can find it here: http://theunintentionalexpert.blogspot.com/2013/04/remembering-shandar.html

Slicing: good for bread, bad for people

A loaf of bread is, in most cases, improved by slicing it. This is because a loaf of bread is more than you need; you can make a whole thing (a sandwich) by using a part of the full loaf. Also, the cost of the slicing in terms of lost bread is very low, assuming you use a relatively sharp knife.

This is not true for people. While you may be able to get a whole thing from a part of a person’s time, the cost of slicing is large.

This is because there is a cognitive burden when switching tasks and arriving at a constructed mental state. I worked with a designer who described getting into a state of “Photoshop Zen” where he had awareness of what the layers of a given drawing were, and which he had active at any given time, allowing him to know what the effect of his actions would be. Getting to that place could take anywhere from a few minutes to more than an hour, depending on the complexity of the drawing. Something as simple as answering a question could cost him that constructed state, resulting in a loss of all the time he’d spent getting there and necessitating spending it *again* to get back there.

Understandably, he didn’t like being interrupted. And once I understood what it cost me (as the one depending on him to finish things), I didn’t like him being interrupted either, and I took steps to make sure that I didn’t do it, or let other people do it.

This idea of “flow state” or “maker time” is fairly common, and many of the agile teams that I’ve worked with in the past few years have evolved ways of dealing with interruptions to try to minimize the impact on team members. This is a very good thing.

I think management is still catching up to this idea, though. While we get that interrupting people is bad, and we should give them no-meeting time to focus, we’re still tempted to slice people up, spreading them across multiple projects. “We need her expertise on both of these – let’s have her split time between them” is something that I’m still hearing.

And it’s wrong.

When you cut someone’s time in half, you don’t get 50% of their productivity on each subject. You get maybe 40%, because of the time lost to constructing a mental state and context for each topic as you switch. The cost of switching is incurred at each switch, and doesn’t just represent lost time, it represents lowered effectiveness. So if you have someone trying to handle two things over the course of a day, they may never get to the point where they’re able to be truly effective – never get to “flow state.” This is especially bad if you’re doing it to the really important person you just had to spread across two efforts – they’re going to have a hard time meeting your needs, and they’re going to be really frustrated at not being able to get to doing real work.

You can minimize the cost of switching by minimizing the amount of it – have dedicated full days on each subject, or better yet full weeks – but you can’t get rid of it. The more switches you have, the more time you lose. Which means that splitting someone three ways is worse, and so on.

I should note that I’m talking about non-management roles here – the people who spend their time in meetings are doing a different kind of work. We still need “flow state” for things like writing up proposals, but when that’s not your primary deliverable, time-slicing has fewer consequences. That doesn’t mean it has none, mind you. Just fewer.

Advice time.

For people who need “maker time” to do their work (programmers, designers, writers, and the like), don’t slice them up across multiple simultaneous efforts. If you have to – and ask yourself really, really hard if you actually have to – then minimize the amount of task-switching by using full-day increments.

Instead of celebrating failure, let’s do science.

One of the closely held tenets of agile software development is that we should “fail fast” – we need to do the thing that’s commonly referred to as failure, because it helps us to learn. An aspect of this is that we should try to find ways to celebrate failure, to remove the stigma from it, and give ourselves permission to fail. This is correct, and it’s also admirable; we’re trying to reclaim the word failure and remove its power over us.

I think, however, that this effort is probably doomed to failure. No pun intended.

The problem is that words have power. We give them that power, of course, and we can change it. But so much of the power of words is a collective effort, so much is the product of all of us together, that a small movement has little change of reclaiming a word and repurposing it for their own means. All of the people who haven’t heard of you will still be using the word, and more importantly hearing the word, in the existing context and with the existing meaning.

We may, in our community, talk about “failing fast” and regard that as a good thing. But for those outside our community, who don’t have our context for this use of the word, it sounds like we’re trying to do a bad thing more quickly. And that’s weird. Weird things may make good conversation starters, but I’d rather the conversation was about the kind of benefits we’re trying to achieve than about the semantics of our word choices.

We’ll just skip over the fact that this entire blog post is about word choices. :)

All right, if I don’t think that we should be talking about “failure,” then how should we describe what we’re doing? I think we should use a word that describes both the process we’re using and has positive connotations (at least for most people):

Science.

Science is about figuring out the world. It’s about finding out what works and what doesn’t. Isn’t that what we’re trying to do with our “failing fast”? We’re trying to determine what works by testing things. We’re not failing. We’re learning. We’re doing science.

So let’s stop trying to make “failure” into a word that doesn’t mean bad things. Let’s instead stop using it to describe what we’re doing when we learn. Let’s talk about learning what doesn’t work. Because that’s an unambiguously good thing.

Who’s with me?

I do not think that word means what you think it means.

When Inigo says to Vizzini “I don’t think (that word) means what you think it means,” it’s possible that he’s making a remarkably insightful statement about both of them.

I’m an anthropologist both by education and inclination. I attended Macalester College in St. Paul MN, and I had the good fortune to study under Dave McCurdy. Dave’s one of the leading figures in ethnographic interviewing, which is an great tool for studying microcultures – groups of people who share a common language and understanding.

It’s probably useful to put microcultures in context.

I’m an American, so I’m part of that culture.
I’m a gamer, so I’m part of that subculture.
I played World of Warcraft, so I’m part of that microculture. Not that it’s particularly “micro.”

Microcultures can nest inside one another – to World of Warcraft players, there’s a notable difference between Alliance and Horde, for example, or between those in your guild and those outside it. They can be as small as a few people.

The thing about microcultures is that they’re defined primarily in terms of sharing a common language – not English or Spanish, but still full of meaning. An example: My wife and I were discussing a way to the word “Hudson.” We live in Minnesota, so she said “like Wisconsin.” I work in computer engineering, so I said “like the build server that Jenkins is branched from!” I knew what she meant, because we share the “from Minnesota” culture. She had no idea what I meant, because she isn’t part of the “computer engineering” culture.

We’re all part of many microcultures. Each of them adds layers of meaning to our lives, and we use words within those contexts to communicate efficiently with other people in the same microculture. When I remember to listen for the words that people use (nouns, verbs, adjectives – anything), and set aside my own understanding of those words, I can figure out what the people saying them mean here and now, instead of assuming that they mean the thing I would if I used them.

This is especially useful when you’re in a discussion with people who are embedded in different contexts that give them different sets of understandings for the words they’re using. My friend Michael Nygard has a presentation called Architecture Without an End State (which is eminently worth watching), in which he makes the point that different parts of an organization have different meanings and expectations for “customer.” Order Management thinks about those-who-have-orders, Marketing thinks about those-to-whom-we-market and Dotcom thinks of those-who-have-a-login. They’re all right, for their microculture context, but using the same word when crossing domain boundaries makes for confusion and anger. I’ve sat in far too many meetings with people getting shouty at one another about who gets to define data requirements for “customer” for one lifetime, and I bet I’m not done.

Sometimes (not always) I’ve been able to add value in these meetings by pointing out that we’re using the same word to mean different things, and trying to tease out the assumptions behind the words. If done early enough, this can defuse the argument over who “owns” the word in question in favor of an attempt to reach understanding, or an agreement to use a different word with less baggage.

So what’s my sage advice for you, dear reader? Listen. Ask yourself if the words you are hearing are being used to mean the things that you think they are. Because if they’re not, and you think they are, then you’re going to make mistakes.

Sleepwalking down memory lane

I have this feeling that I’ve written about this before, but I can’t find it in my blog, or in Michael’s. And looking back through the last year of posts over there was… painful. So if I’m repeating myself, forgive me.

When I was in college, I was a DJ. It started the summer before I began classes, in fact. Michael somehow found out about WMCN, which was weird, because we could barely get the signal way over in Minneapolis, since WMCN was just 10 watts. But somehow he figured out that it existed, and that I could get a show there. I applied, got a show, and we did it together. We called it “Sleepwalk” and led off with the Ultravox song of the same name.

It was fun, and I kept doing it throughout the four years I spent at Mac (1984-88 for those keeping score at home). As he had that first summer, Michael shared the studio with me many times – often enough that when I was filling out the application, I’d list the DJ as “The Unstoppable Matheny Brothers” – and even when he wasn’t there, his influence was.

If you want to get a sample of his (and my) musical tastes of that time, check out his Pandora station: http://www.pandora.com/station/play/917077119442963905.

This summer is my 25-year college reunion. And the folks at WMCN are offering alumni the chance to DJ a show. I jumped at the chance, and signed up for Friday June 7th from 10pm-Midnight. My pitch was to do a retrospective of New Wave from its roots in the late 70s through the modern artists still keeping the sound alive. That sounded like a really good idea at the time, but having just spent a couple of hours in iTunes building a playlist, I realize it’s going to be a tall order to fit into two hours. I’m going to have to be ruthless in my selection, because right now I’ve got 11.2 hours of songs.

And it’s going to be hard, because part of the reason I’m doing this is for Michael. I wouldn’t have been a DJ if not for him. Explaining that is hard – I mean, I can do it in writing like this, because no matter how tight my throat gets I can still type. And thanks to my high school typing classes, I’m a touch-typist, so the tears blurring my vision aren’t a problem. Go me.

So I’m going to ask my friend John Slade if he’ll be my wingman for this – he was my best friend in college (and still is) and he knows my musical tastes. And if I’m unable to take the mic to explain why I’m playing a particular song, he’ll have my back.

Wish me luck. And strength. And come Friday June 7th, give a listen at http://www.macalester.edu/wmcn/. I promise you’ll hear good music.

One week in

I started work at Digital River this past week. Here’s my thoughts after the first week.

I’m excited. Not only is this a new start for me, which is great, but I’m impressed with the people here. We need to make some changes in the way we develop software, of course, but I’ve never met a group as open to change and as aware of the need as I’m finding here. There’s not the kind of resistance that I encountered at Best Buy. There aren’t people saying “no, we can’t do that.”

It isn’t all rainbows and unicorns, of course. There’s hard work to do and significant pressure to do it right. But I’m convinced that we have a great plan, and that our leaders have their heads on straight.

Sadly, I couldn’t say that when I was at Best Buy. I have a lot of respect for Hubert Joly and Sharon McCollam, but I (respectfully) think they’re setting the wrong course for BestBuy.com. They’re thinking in terms of a turnaround, which is appropriate for most of the company. But BestBuy.com isn’t in a turnaround, it’s in the midst of a transformation. That’s not the point when you get tight on expense dollars – that’s the point when you double down on investing, because you have the cash and you need the benefits sooner rather than later. Days are more important than dollars, and they’re losing days and weeks as they try to minimize spend. The emphasis on cost control and inspection is wildly wrong for positioning BestBuy.com and the Platform for success. It’s right for much of IT, because of the bloated management-heavy structure that’s a legacy of the Accenture outsource. But it’s going to kill the Platform, and that makes me sad. I hope I’m wrong, because I am proud of the work we did and I want it to succeed.

But enough about Best Buy, I’m talking about Digital River.

DR is in a different place. Yes, we still care about controlling costs. But our leaders are investing in engineering. That starts with putting Dave Moore in charge, which is a truly awesome thing. He’s not just a visionary leader with a deep knowledge of the business and how to grow it, which is a rare enough thing in a technology executive. He’s also a really great human being.

Let me tell you a story. Some while back, when I was being recruited, I’d told Dave about someone I thought we should bring in in a coaching role – a colleague of mine named Kyle. In my first week, I reached out to Kyle and asked him to stop by for the end of the day on Friday (which is Beer Friday at DR, by the way). Kyle came out, we grabbed a beer and I was giving him a tour and we ran into Dave.

Dave moved another meeting and spent 20 minutes talking non-stop to Kyle about what we’re doing and why he (Dave) believes in this, before he had to run to another appointment. Talking with Kyle afterward, I pointed out something that I’d noticed: Dave didn’t spend any time at all trying to evaluate Kyle. He just pitched him on why DR was a great place to work. This is because I’d told Dave that Kyle was good, and he trusted me.

Let me repeat that: Dave trusted me. If I said Kyle was good and we needed him, Dave wasn’t going to waste any time second-guessing me.

That’s incredibly rare. I’ve had that just three times in the last 25 years.

And it makes me want to share it with other people, in particular my friends and colleagues that I’ve met at Best Buy – spending 13 years in one place means that my network is heavy with BBY folk. But recruiting people out of BBY is not just tacky, it’s wrong – as I noted above, I want the Platform team at BBY to succeed.

So I’m arriving at this…

For my friends and colleagues at BBY: Keep up the good work. I’m rooting for you. When your work there is done, if you’re willing, I’d love a chance to tell you about what I’m doing and what we’re doing here and see if what we’re building is something you’d like to work on in your next phase.

– Kevin

A new chapter begins

13 years is a long time. When I started working at BestBuy.com, the Internet was a lot smaller than it is today. Youtube and Facebook didn’t exist, nobody had heard of Google, and while the iPod owned the portable music player market, it had a monochromatic screen and moving parts.

It’s long enough for me to have been part of some very cool things – Best Buy Entertainment, the Digiterra Project, ARIES, Remix, EPIC, and the replatforming of BestBuy.com on open-source and the cloud. I’ve had the chance to work with some truly awesome people, and I’ve learned a lot.

And it’s time to move on. I’m resigning at Best Buy, and joining Digital River to lead API development. I’ll be working with some really excellent people – some of whom I’ve worked with before, and some who are new to me – and I’m excited about the challenge in front of me.

I’m sad to be leaving Best Buy behind. It’s been a great place for me, full of people I’m proud to have worked with and learned from. I’m disappointed that I won’t be able to see the work that I helped start come to fruition, but I have every confidence that it will be awesome.

Update posted over at Mike’s blog

I’ve posted a melancholy update over at http://theunintentionalexpert.blogspot.com/2013/04/remembering-shandar.html.