Hopefully no one is out there to get this noise, but if you are, my apologies. Trying a new synchronization trick, and I don’t know if it will post to the stream or as a draft.

[sometime later]

Ok, pro-tip. You CAN send a post from Bear to WordPress on iOS, and that’s pretty slick. However, if you do so, it will post straight to the stream, for good or ill.

I’m experimenting with this because I’m debating using a microblog for my note booking purposes. Not a published one – just one I can reference to “flip back” through past thoughts. WordPress is almost certainly the wrong tool for the job – I’d be more likely to use a static site generator that can handle markdown files – and there are lots of ways to set that up, but they’re all 75-90% solutions with a little bit of extra work to make it go, and that’s the problem. If I want a notebook alternative, then it needs to be comparably reliable to just picking up paper.

I’ll figure it out. There absolutely are tools for this, I just don’t know them well enough yet.

There is something akin to Maslow’s Hierarchy of needs as it applies to success, and the foundation is something like “I still have a job”, with the next step up being “On track for raise/promotion” and it’s a few more steps up the pyramid before we get to “customer success”.

The thing is, Agile and its adherents can help a team through those subsequent steps, but the first two layers of the pyramid come from their leadership structure, usually in the form of their immediate management. If that leadership cannot create enough safety to get past the foundation, we are never going to get to the peak.

I’ve been drawing variations on this diagram a lot lately.

These are what I think are the core components of an effective team¹. These aren’t revolutionary ideas, but they’re the ones I’ve really zeroed on from a lot of really good sources, including Marquet’s Turn the Ship Around!(which probably informed this most strongly) and Dignan’s Brave New Work, and this is how I like to summarize them.

Like all such models, it’s not perfect – there’s a bit of unpacking necessary to turn it into a story, but I like the process. In short, these are the things that a team needs to know what needs to be done (Clarity), have the skills and resources necessary to do the thing (Capability) and it able and willing to take the necessary action (Autonomy)².

Clarity

Clarity means the group can see the problem and see a path to resolution. This means that they understand the domain, have visibility into the situation, and have enough insight to be able to understand how a solution might work and test that hypothesis. Clarity need not be perfect (tip: it never will be) and it covers a number of critical things like understanding value, measuring the right things and the ability to learn.

In the absence of clarity you can have an incredibly capable team that goes nowhere or, worse, goes off a cliff at very high speed. If the team is good enough, they may still stumble onto success (broken clocks and all that), but that’s a bad thing to rely on.

Autonomy

This is probably the hairiest of the three, because it comes with all sorts of scary ideas like responsibility and independence, but it’s also the simplest to test for – if the team can see the problem (or opportunity) clearly and see how to fix (or take advantage of) it, are they able to do so? Most critically, can they decideto do so?

Usually, they don’t. There are permissions to pursue, processes to go through and a general lack of trust. This mistrust is usually framed as benign – it’s protecting the team from making mistakes or wasting resources. And it’s reasonable enough on its own – it the team has autonomy but lacks clarity, then they’re just a wrecking ball on the lookout for a load bearing wall.

However, without autonomy, even the best teams are hobbled. All that capability and clarity goes to waste as they sit around waiting for permission.

Capability

The biggest and most obvious part of capability is skill, but it’s not justskill. It also means having the resources, access, will and knowledge to do the work. There is a certain amount of flexibility demanded by this in complex situation – the necessary capabilities are not always predictable, but excess capabilities can bring in extra costs. As such, one element of capability is, paradoxically, restraint. The team does not just bring the right actions, they bring it in the right amount.

The absence of capability has the most obvious drawbacks – the work can’t get done. That might seem to make this the most critical of the three points, but it turns out that the opposite is true, for reasons we’ll get into in a second.

The Imperfect Triangle

This trio of keys is easy to spot when you find it, but most real world teams need to operate with a flawed version of these things to get through the day.

If a team has none of these, they’re going to be entirely reliant on proxies (see below) to get the work done. That’s a worst case scenario, and if that’s what’s going on, it’s almost certainly not the only problem.

If the team has only one, that can be worse in some ways. Clarity without autonomy or capability is a recipe for frustration. Autonomy without clarity or capability makes more problems than it solves. Capability without clarity or autonomy is just wasted potential. All three of those scenarios are grating on the soul.

A team that hits two of the keys might be better off. If they have clarity and capability, they might still get a lot done if the authority they follow is reasonably sharp. That is, they will be able to kick ass in the manner they’re instructed to. If they have capability and authority, then they can at least proceed with good intentions and general best practices in hopes that if they try enough things they will eventually solve the problem³. If a team has clarity and autonomy, but lacks capability, then they can learn, and since they know what they need to learn and are motivated to do so, they should have that third key in short order (which is why this is the easiest gap to overcome).

Frustration Remove Clarity => Wrecking Ball Remove Capability => Learners” class=”wp-image-126″/>

Proxies

More likely, though, the team is getting by with a proxyfor one or more of the keys – some other attribute which offers enough similar benefits for functionality, but with some other tradeoff that’s usually for the worst.

The grand-daddy of proxies is instruction– it can technically cover for any gap. Instructions can tell you what you can do, what you should do, and how you should do it. The problem, of course, is that instructions are never as complicated as life, so whichever key is replaced with instructions has now become the limiting factor on the others. This is not necessarily disastrous – instructions canbe good, timely and useful. It’s just a lot of work to keep them that way.

One common proxy for clarity is certainty, a pernicious attribute which often presents itself as clarity but actually overlaps very little. Dogma and enthusiasm can provide the kind of direction that clarity provides, but without the guarantee that the direction is the right one. Unfortunately, because certainty also lacks clarity’s ability to judge itself, the inevitable failures are almost certain to be attributed to someone else.

Capability is a little bit harder to proxy for, but if you need to fake it, then a bit of flim flamgoes a long way. Look busy, produce good looking metrics and just never deliver. If your environment is dysfunctional enough, you can surf on this patter for ages.

Autonomy has a couple proxies, but my two favorites are panicand subversion. Panic is what happens in an emergency, and it’s now all hands are on deck, all rules are set aside and all eyes are on getting the job done. For some, this is their only taste of autonomy, and they will actively find ways to turn problems into emergencies in order to be able to “do something”.

Subversion takes the other route of recognizing that the lack of rules is a problem, and then just working around the problem. Backchannel deals, shadow networks and secret work get the actual work done while maintaining nominal command and control. This is admirable work, but if people on your team need to resort to this, that’s a real problem.

Scaling and Use

Ok, so it’s a triangle. Now what?

Technically, you can use this model to plan – look ahead and see what you’re doing to provide and encourage all three keys – but I admit I find more use in it as a diagnostic tool. If things go wrong, it can be handy to look at things in these terms and ask if one(or more) of the keys is missing or damaged, and if so if there is any way to fix that. It won’t always point to a solution, but it’s a good starting point.

Beyond that, once you get used to the pattern, you can scale it up or down. For groups, the model scales up even as responsibility diffuses and communication becomes challenging. The need for the trio is there, and the patterns of failure are similar, if larger. You can also scale down – these attributes apply to individuals, or even single tasks⁴. Generally speaking, if something needs to get done and it’s not getting done, check for these three things as a quick smoke test of how solid the infrastructure is.

1. This doesn’t JUST apply to teams, but unpacking that is a bit involved. A larger group may have these attributes, but it introduces more questions about how to distribute them. An army may have all three attributes, but they’re not evenly distributed the general may have autonomy, the spies may have clarity and the soldiers may have capability, but extra steps are required to keep those things connected. For my purposes, a team is something where all of these attributes are held by everyone on the team, even if they might be a bit lopsided on an individual basis. ↩
2. If I want a TED talk, I really need to give this a C name, to make this all punchy. ↩
3. This one is really common, even in teams that usually have all three keys, because sometimes the keys are situational or partial. An operations team dealing with an outage may not have clarity on how to resolve the problem, for example. What they do have is clarity on the best ways to identifythe problems, and if those fail, then they have the smarts and the persistence to keep at it. ↩
4. Is it actionable (Autonomy), doable (Capability) and useful(Clarity)? ↩

Fitbit experiment is looking like a failure. My steps have not been great, but I’ve been sick, so I’m not actually thrown off by that. The problem is that the Fitbit is INCREDIBLY GENEROUS in in interpreting steps. I woke up this morning to discover I had 820 steps already, and it similarly adds hundreds every time I take a drive.

So, back to just the watch. Annoying, but workable.

I am about to start rocking a smart device on each wrist. It’s going to look goofy, but I am driven by necessity. See, this past weekend I went to a convention and got in about 30,000 steps over the course of the weekend. Back when I was tracking my steps this would have been a pretty normal weekend, but I’ve been off that habit long enough that I am embarrassingly sore this morning. Enough so to make me want to get back in the habit.

The problem is that I stopped when I switched to the Apple Watch. It’s a great device, and I love mine, but it is crap as a pedometer. Not because it can’t track steps (it can, very well) but because that information is not privileged in the interface. Either I have to drill down into the health app to see my steps, or I have to use a third party app (pedometer++) which is great, but which can’t display in realtime because of the watch’s limitation.

Intellectually, this shouldn’t be a big deal. It’s just a few more seconds and a few more clicks to check my steps – how in the world can that have a drastic impact on behavior?

My suspicion is that it’s all about keeping the information at top of mind. When my steps are presented to me, I stay mindful of them (and the associated behaviors) with no effort on my part. When I have to find them, that introduces enough friction that it’s easy to forget to check, and by extension to then forget the behavior.

That’s the theory. An alternate theory may be that I have just been slacking, and I can’t rule that out. But I have enough experience to know that if I try to solve this problem with good intentions and brute force willpower, then I’ll have a few good days before it all collapses for perfectly legitimate reasons. I need to build a ramp, and in this case, this ramp is going to mean wearing two watches.

 

I may need to tweak the theme to support headless posts for that true microblogging experience. Small challenge, but not a big deal.

Slightly more annoying: the iOS app lets me do everything except configure the size of images, so that is a bit more of an annoyance.

Anyway, that’s all pretty much inside baseball, and I mostly wanted to make two remarks about the iPad, now that I’ve been using it for a bit:

1. The pencil attaching via magnet is amazing and wonderful and the magnet is always about 20% less strong than i expect.

2. I love the physical shape of this, but it is flat and dull and I think I may need to explode with stickers upon it.

Ok, so for sheer simplicity, I paid for a WordPress account and copied the blog contents over to it, in part because I genuinely am not sure how the current nevernotlearning.com url resolves at all, since it’s pointing to a defunct address that is somehow ending up at my Lightsail install maybe?  I am genuinely not sure, because all indications are that it should not work.

Anyway, I directed the DNS to point to this address, and hopefully that will work with a little time.  If not, I may let WordPress manage the DNS, but I kind of don’t want to because they seem bad at it (they charge extra for very basic stuff like privacy protection, and if I decide I want to leave WordPress, I don’t want to have to fight them for the domain name).  So, the next part is a bit of waiting, which I stink at, but so it goes.

Months have passed, and I have cycled back to more or less exactly where I was with the last post. A few things have changed – I have new hardware to play with, and some pressure coming from the imminent demise of google plus – but that core question of where to write is still largely the same.  That this site exists is a good argument for itself, but there is a temptation to move this off AWS (I think it’s currently running on a light sail instance, which is 95% great, but the 5% irks) and maybe just pay for hosting at wordpress.  Realistically, I’m paying $5 a month for this as is (the lightsail price) and if that really bugs me, I should just move it to a t2 micro and call it a day, but that would still have some maintenance overhead.  Alternately, I just spend the same amount on a wordpress private account and maybe just write.

(Aside: I think the thing that throws me most is that I really want to be able to trivially add imaged to posts on iOS, and every solution is actually pretty awkward.)

Someone posted a lovely tweet about bringing back the “dumb internet” – the internet of blogs and weird websites and all those things that existed when it was motivated by interest more than profit. I admit, I really appreciate that thinking – it’s overly idealistic, but I support the thought behind it to an almost foolish extent.

So I’m taking it as a cue to blog a bit more. Right now, if I have a thought in my head it tends to end up on twitter which is extremely ephemeral and has a couple other issues as well. But it’s almost frictionless in its actual use, especially on mobile. I open the app and with one tap, I’m writing. Everything else (including wordpress) has hangtime and clickthroughs and other steps to hope through before the thinking turns into writing.

So, I’m going to take a little time to consider my options, and see if there’s a way to make it more frictionless. Might mean I end up paying for something like micro.blog or even squarespace if it gives the the tools I’d actually use. Or maybe I manage to get a workflow that lets me dump straight from drafts into a static site generator. I dunno. how it will play out, but I’ll update here as I go.

There’s a good piece of advice out there to never call a meeting when an email would suffice. This is mostly true. It’s definitely true when you are the person calling the meeting and you are the person who should be sending the email.

But sometimes the problem is not yours to solve, but rather you need Alice to talk to Bob, and that conversation just hasn’t happened. A meeting shouldn’t be necessary, because Alice could just pick up the phone or write an email, but she has not, and there is only so much you can do.

At that point, the dreaded meeting to “talk about something” becomes the tool you need. Once you set it up, the clock is ticking for Alice, and she knows it. If she steps up and reaches out to Bob, you can cancel the meeting, but if she doesn’t, then the conversation is going to happen.

If you’re facilitating this meeting, you definitely want to keep it short and have a clear agenda. The latter may not be easy because if you knew everything you needed, we wouldn’t need Alice to explain things to Bob in the first place. So in the absence of information, focus on the questions that need answering. It is entirely reasonable (useful, even) to have an agenda that is the list of things that need to be known, rather than the things that need to be told.