You Get What You Pay For

One of the lessons that I find to be simultaneously essential to learn and incredibly difficult to teach is an idea that I refer to by the shorthand “being a consultant”–the notion of saving the customer from themselves.

Paul Sherman’s amazing presentation “The UX Unicorn is Dead” (if you haven’t read it, stop reading this and go read that) highlights an excellent opportunity to save the customer from themselves: customers asking to forgo UX or QA work (or, in some horrifying instances UX and QA work) in exchange for a lower price or faster timeline.

You get what you pay for.

As a veteran developer, I can tell you with absolute certainty that it is exceedingly rare to find a developer of quality that can do testing adequately. It is similarly rare to find a developer of quality that has the ability and the training to perform UX tasks.

During the planning phases of a feature, it is the UX practitioner that I turn to for expertise in creating a unified experience for the user that remains consistent and engaging. Prototyping can certainly aid in this area, but it is in no way a replacement for the skill and knowledge that my UX team brings to the table.

Likewise, speaking with an expert tester (and if you don’t believe testing is a skill that requires expertise, you don’t really deserve a seat at the decision-making table here) is how features end up with sufficient testing coverage–automated and otherwise. If you’ve ever sat in a room where engineers are discussing the feature they’ve puzzled out how to build without a member of the QA team, you’ve almost assuredly gotten to watch that glorious moment when the QA practitioner rattles off a series of “what happens in this case” questions, deflating the room. It’s fun to watch, and it’s entirely avoidable.

So as consultants, it is our job to convince our clients that the decisions they are making out of sensitivity to cost or timeline are going to be infinitely more expensive or time consuming in the future. We have to convince them that they’re getting what they pay for, and that cuts both ways. We have to save them from themselves.

Or we could just deliver mediocre software.

July Kayamping Trip

Next weekend, I’m going on a 3-day, 2 night kayak-camping (kayamping) trip down the Au Sable River near Grayling, MI. The plan:

  • Drive up to Carlisle Canoe Livery in Grayling on Thursday, July 21 and unload gear.
  • Drop my vehicle off at Parmalee Bridge and get shuttled back to Carlisle.
  • Take a leisurely paddle to Whitepine Canoe Campground. Day 1 should include about 7 hours of very casual paddling.
  • On day 2 (Friday, July 22), break camp then take a short 5 hour paddle to Parmalee Bridge Canoe Campground.
  • Day 3 (Saturday, July 23) will be breaking camp, pulling out at the Parmalee launch, loading up the vehicle, grabbing some breakfast, and coming back down to SE Michigan.

All of this, of course, presumes that the weather is going to play ball, but at this time, it certainly looks that way!

If this sounds like the sort of thing you’d find fun (and you have nothing going on very last minute next week), the total cost is going to be south of $50 plus food and whatever gear you’re missing. Carlisle rents boats, so if you don’t have a boat, I believe it costs $70 to rent one for the trip.

In the interim, I’m going to take lots of pictures and post about the trip, as I’ve never done the Au Sable before!

Stepping Down

This post was originally going to be posted once the formal announcement of the change it describes was announced at work. Having been laid off mid-month, that announcement will never come, but I consider the concepts to be important enough to post anyway.

I resigned from my managerial role today.

Actually, it is more accurate to say that at the beginning of this month, I gave notice that I would be stepping down from my managerial role by month’s end. Today, that resignation simply became official. [Edit: Plus or minus a little…]

The fact of the matter is that I’m not especially well disposed to being a ‘manager’, at least in the fashion my job required. I have a particular set of skills1, and I took on management of my team because I saw an opportunity where my specific skill-set could be beneficial for my company, for my team, and for me.

In taking authority over my team, I was able to work with everyone individually to ensure that they were happy, productive, and capable of doing their best work. It was my responsibility to build a safe space, and I had the authority to do it. Our team flourished, and as a result our projects flourished.

In taking authority over our projects, I was able to mentor teams to listen actively to our customers, to learn to be consultants, and to deliver accurate, quality solutions rather than to hastily respond to customer queries. It was a delight watching my team improve while seeing how strong the client reaction became; to the extent that they would lament the loss of our leadership when we were done with their projects. My crowning achievement is in coaching our teams to make our customers miss us.

In taking authority over our process, I was able to help our offering improve and grow. Migrating us from waterfall toward Scrum was an exercise in steady, measurable, reliable progress. After the initial changes, the time I spent coaching dozens of teams to work cooperatively to deliver better was transformative—I can only hope as much for them as it was for me.

Following our company’s acquisition, my role shifted—subtly at first, but with each passing month it changed with increasing rapidity. Gradually, the skills that I excelled in bringing to bear became less important than my ability to deliver bad news and shuffle paper. I became, in a very real and very unfortunate sense of the term, a middle manager.

Years ago, I swore off from management because I refused to be one of those do-nothing, useless appendages whose sole addition to the organization was a layer of bureaucracy. I naively thought that was what management was. In the years since, I’ve had better leaders than that, and I’d like to say that I’ve become a better leader than that. Once I recognized that my role was no longer that of leader—that I was a mere manager—the right thing for me to do became obvious. I stepped down.

Does this mean that I won’t take on a leadership role in the future? Absolutely not! The past couple of years have been among the most rewarding and enjoyable of my career. This has simply cast into sharp relief the attributes of the role that would allow me to be successful. Given the right role with the right organization, I would be delighted to manage another team.

No, this means the opposite of that: I look forward to taking all that I’ve learned during the time that I was allowed to be a leader to my next opportunity to help a team grow. I learned a great deal in the last few years, both good and bad. All of this has contributed to the leader I wish to become.

This was yet another step along the way…


1 I can no longer hear/see/type that phrase without hearing it in Liam Neeson’s voice

Heterosexual Pride Day

It appears that the sort of folks that always have to find a way to make everything about them (AllLivesMatter, anyone? NotAllMen right a bell?) have gotten #HeterosexualPrideDay trending on social media. At this point, it’s hard to muster anything more severe than disappointment in such a predictable set of actions.

Rather than get upset, since my upset is going to accomplish nothing productive, I’m choosing to observe Heterosexual Pride Day in my own way. I invite you to join me.

I choose to recognize that while there are zero states in which I can be fired for being heterosexual, you can still be fired for not being heterosexual in more than half of the states in our country. I take pride that it isn’t 100%, while continuing to do what I can to make it 0%.

I choose to take pride in the fact that while heterosexual people can assume that they will get joint custody of their children when they separate, it is only now becoming a possibility in some states. I recognize that we have a long way to go in order to resolve that disconnect.

I choose to be proud of the fact that there are increasing numbers of non-heterosexual people in the media that are not stereotypes, while still remembering to call it out when I hear someone referred to as “gay” or “faggy” for being different or for enjoying hobbies traditionally associated with the opposite gender.

I choose to recognize the fact that, while I can take pride in the fact that we have come a long way in terms of gay marriage, there are still states in which it is not legal.

This is how I choose to celebrate Heterosexual Pride Day; to take pride in how far things have come while recognizing how terribly far we have to go. #heterosexualprideday

The Valuation of Time

Let’s begin with a basic concept with which we should all be able to agree: time has inherent value. Nobody seriously questions this fact, what we argue is what that value is.

I was thinking about this while I was doing some yard cleanup this week and the lawn folks came by to mow. As the two of them swept in and back out in about 10 or 15 minutes, I found myself pondering the cost of that fraction of an hour in a very intellectual fashion…

“Are you fucking shitting me, that’s $100/hour to mow my lawn!” I thought, intellectually.

And that is certainly one way to apply a value to time; from the perspective of how much you are outlaying in exchange for the difficulty of the job. “Those people are doing such a trivial task for so much money.” You can see that line of thought being applied to all manner of things in politics today: “How dare fast food workers demand so much money for flipping burgers” or “how dare retail clerks demand the same salary as EMTs” for example.

There is another, more accurate way to assign value to time; from the perspective of what it costs to the recipient in exchange for NOT having to do that job. If I were to mow my own lawn at the same level of quality I currently get for $25 per week, I would need to:

  • Obtain a lawn mower and weed whip
  • Supply fuel to said devices
  • Provide maintenance for said devices
  • Actually move those devices around the yard in a meaningful way reliably

Having formerly done this task on this very yard, I can tell you that it takes me close to an hour to do the job; and that ignores the beginning and end of year maintenance and other miscellaneous chores that go along with the job. Is my hour worth $25? Absolutely. As it turns out, this was why my family opted to spend the money rather than do the chore ourselves. As it turns out, once you factor in the costs ownership, maintenance, and the time spent actually doing the mowing job, we were investing considerably more than that $25 in doing a job that we hated.

Those lawn guys aren’t asking ENOUGH. They could probably get $5 or $10 more out of me if that was the only option.

I use this line of thinking when I price my services as well; it matters what I want to pay for the service, but it matters even more what the service is worth to the recipient. When I started factoring that in, I started charging a much higher rate and found myself enjoying the work that I was doing considerably more.

So the next time you find yourself pricing out a job, ask yourself “what would it cost them to do it themselves” and surprise yourself with the actual in-house cost of such thing. And the next time you find yourself cursing under your breath at a drive-through at how much money these “lazy takers” are wanting, ask yourself it is worth the extra $0.50 you might have to pay not to have to obtain ingredients, cook and serve ingredients, and clean up afterward. If it’s not, go make yourself some food.

Idle Hands Are a Good Thing, Right?

Today the majority of my team and I were let go from work. Laid off. Reduced. RIFed. Whatever the right term for that is. This being the third round of layoffs it isn’t entirely surprising anymore, although the degree of commitment represented by the depth of the cuts does take one aback.

This is not the end of the world for me. Truth be told, I’ve been sitting on a blog post describing why I—at the start of the month—stepped down from my position. This is the logical consequence of resigning. I am, however, tremendously concerned for several members of my team, and I’ll be reaching out to many of you in the coming weeks to see if I can find homes for developers and a PM.

For me, I’m going to take some time to figure out what the right next step is. I initially took a managerial role with my current organization not because I desired a managerial role, but because it was the right fit for me at that particular time with that particular organization. That was no longer true post-acquisition, so I would hate to step right into another management role simply because it’s what I last did.

Honestly, lately, I’ve been thinking that the role of Agile Coach is more up my alley. I love doing it, it contains most of the things that I loved in my role as manager, and I am given to understand that I’m pretty good at it. In the year and change that I’ve spent coaching agile teams directly, I have felt like it dovetailed my love of process, my ability to deliver quality, my enjoyment of teaching, and my skill in mentoring teams all together nicely.

As it stands, I have some time to make a decision, and I fully expect to make a fully reasoned, calculated one. This is going to be a good thing, I think.

That or I’ll be posting here in a month or so saying “holy fucking shit, I’m broke, I need a job, someone please help me!!”. One or the other.

Vaccine Schedule: 1960 vs 2016

Fun fact: if your friends and family are sharing this idiotic vaccine schedule comparison on social media, they’re fucking morons.

I know, I know, you’re already shaking your head and clucking your tongue at how mean it is to call these simpletons morons, but bear with me here, because I’m not the only one that must think that the sort of folk likely to share this are not blessed with an over-abundance of brains—the people who MADE the document knew it too. Here’s how I know:

  1. They inflated the 2016 list by adding more than 20 items to the list that aren’t vaccinations or aren’t a part of the vaccination schedule . They aren’t routine vaccinations. (Fucking VITAMIN K is on the list)
  2. They deflated the 1960 list by leaving off at least two vaccinations that I noticed at a glance (smallpox and polio).
  3. Here’s my favorite: they then put the number 70 next to a list that contains less than 60 items knowing that their constituency would run out of fingers and toes before they got anywhere near high enough to call them on it. (for those keeping score, that means the list is actually closer to 10 vs 35ish…but who’s counting)
  4. My second favorite: they included 18 years worth of vaccinations knowing that their core audience’s attention span would only last through about a third of the list before they hit “share” in a blind rage.

The real crime in all of this, though, is the stupidity that underlies the core message…the real message here actually translates to “we knew everything we needed to know about medicine 55 years ago, why change now?” Should we exclude all medications since 1960? Let’s assume that I agree with the wrongheaded notions implied by this empty-headed list; that means we need to lobby to rid ourselves of: heart transplants, Lyme disease treatments, HIV treatments, ultrasounds, cochlear implants, MRIs, CAT scans, PET scans, the entire concept of antivirals, insulin pumps (sorry diabetics), not to mention hundreds or thousands of medicines that are used commonly to both prolong life and improve the quality of that lengthened life.

Let’s remove the decade of life expectancy we’ve gained since 1960, while we’re “fixing” progress.

I get it, many of you grew up in a generation that was told that nobody was smarter than you, nobody was better than you, and you were just as intelligent, athletic, and useful as anybody else in the world. You have a participant trophy from your 10th grade tee-ball team hanging next to your 20th runner up spelling bee ribbon to back it up. Understand, though, that there are people smarter than you, and there are certainly people more educated than you—especially on this topic.

There are people that have studied for years to learn about this shit, and your 8 minutes researching at Google University doesn’t mean shit compared to that. I don’t care how smart you think you are; you’re not…and you’re dooming your already-hamstrung-by-having-a-stupid-fucking-parent offspring to the risk of death due to polio, measles, mumps, etc. You endanger the lives of people with compromised immune systems that can’t get vaccines because your parents were assholes that told you that whatever clever idea you get in your empty head is just as good as a degree.

But sure, continue to spray your ignorance of mercury, aluminum, formaldehyde, and statistics…nothing will show the rest of us just how right your mommies and daddies were like your broadcast ignorance over the sound of your kid’s whooping cough.

Breathe, Jer…breathe.

Anyway, if your family or friends are posting that piece of ignorance, my apologies that they’re so stupid. Here’s hoping you don’t have to do holidays with them!

Committing to Estimates

“When will it be released?”

In the pantheon of my least favorite software questions, this ranks near the top.

“When it is done.”

This response has to rank near the top of management’s least favorite answers.

The problem above isn’t a simple battle between the management team and the development team about estimates. The problem shown above is a catastrophic misunderstanding of the difference between an estimate and a commitment and a needlessly flippant response to that misunderstanding. The question “when will it be released” is not a request for an estimate of any sort—not of time, of complexity, or of effort. It is a request for a commitment. A commitment that cannot in good faith be made.

Let me repeat that last bit for you one more time: the commitment that is being asked above cannot be made in its current form. The closest thing to an accurate answer to a commitment like that above would have to take the following maddening form:

“Assuming the team is structured like this ______, nobody has a sick day or a family emergency, no responses are needed from the client or from vendors, management doesn’t reallocate teammates for an emergency project, no new information is found, the team runs into no difficulties, and our current understanding of the problem accurately represents what the client expects, it is likely to be done by _______. Release can follow that.”

Look at that pile of caveats—and make no mistake, given more time I’m sure that we could come up with several more that aren’t listed here—for now, let’s assume that this is a fairly complete list. Look at the items that are outside of the team’s control: sick days and family emergencies, client response times, vendor response times, and management reallocation of teammates; a formidable list. Given that, how could anybody accurately assess when something will be delivered?

Simply put, they cannot. We learn this lesson time and again in organization after organization but the lesson never sticks.

Estimates are not commitments. Estimates are meant to be used for the singular purpose of making informed decisions, but none of those informed decisions should include delivery date. Some decisions that estimates can be helpful for do include determining what to charge, determining how to staff the project, coordinating multiple parts of a delivery, or even approximating when the work is likely to be done. Note that important difference: when work is likely to be done is very specifically NOT the delivery date. If you are using estimates to create a delivery date, you are taking on a tremendous risk.

I’ve made no pains to hide my general disdain for estimates. I typically refer to them as “polite fictions we share with one another”, “random guesses supported by lies”, and “suppositions with numbers attached”, and these are just the most polite terms. I loathe estimates because they are so often used poorly, but they can be a highly effective tool. It is up to you to ensure that your estimates stay estimates rather than sliding into the delivery-destructive bomb that is known as committment.

Teaching your entire delivery team and management structure the important difference between and estimate and a committment might be the single most loving act you can commit on behalf of your clients.

Kayaking the Huron River Water Trail

Ger and I spent the morning paddling the Huron River water trail, at least the northern part of it from just below Proud Lake to just before Kent Lake.

It’s one of our favorite stretches to paddle; it’s nearby, easy to get into and out of, it’s a relatively easy paddle with only one portage that is at a good break point, and it takes only about 2-3 hours even on a slow day.

During today’s trip, we saw several blue herons, a few turtles, one giant reddish-brown bird that looked and sounded a lot like a demon heron, and several swan and goose families. Plus a ton of drunk river partiers.

In all…a relaxing trip, but I’m exhausted and ready for a lengthy nap.


I have so much going on at the moment; several cool development projects to work on that I’m really excited about, numerous books on the queue, the weather is nice and the bikes and kayaks are calling, there are some recently released video games that I enjoy quite a bit, I have writing ideas that sound like fun, my foot pain seems to be improving…I’m surrounded by great shit and life is, by any real measure, great!

I’m also finding it borderline impossible to get the ambition together to do almost anything with any of it. At work, I struggle to maintain concentration while working on even the most simple task. At home, even reading a book or playing a game sounds like more effort than I have energy. Even writing this blog post feels like a herculean effort. I nap a lot, despite not feeling particularly tired (which means that I don’t sleep well at night).

I’m not sure what it is, and I don’t much like it. It feels an awful lot like what people describe depression as, but I don’t know that I feel “depressed” per se. What I do feel is a complete absence of ambition, essentially no energy, and mentally exhausted all of the time without any real reason to feel that way.



I’m sitting in the main room of Self.Conference waiting for the start of day 2 and mostly trying to figure out how I’m going to absorb another day of material. It’s a problem that is somewhat unique to Self, in my experience.

When I attend a tech conference, it’s with the inherent understanding that I’m going to be deluged with technical information, and I’ve developed a note-taking system to accommodate that; a sort of mind mapping that gives me the ability to use future research to fill in gaps.

When I attend a non-technical conference, I find myself mentally triaging information as it comes in so that the important stuff has room to perch; keep…discard….discard…discard. The information density is sufficiently light that it’s a fairly trivial task.

Self is different. The mix of soft and tech talks surely has something to do with it, as does the fact that most topics end up falling firmly in between: a discussion of algorithm development that also deals heavily with the societal ramifications of hidden assumptions, for example. The culprit is more likely the emotional energy this conference gives me. For the next few month I want to learn new languages, do bigger things, and exert whatever modest leverage I possess to make things better. I will be a better denizen of my industry for the next quarter on the back of the inspiration Self has provided.

What I think I’m saying is that I need this to happen about four times per year.

Until that happens, I’m going to settle in, absorb as much of day 2 as I can, and try to use the energy it provides for the foreseeable future in a positive way.

If you haven’t made it out to Self, I highly suggest giving it a try next year!

Fast Food Delivery

I’ve written and spoken on the subject of managing customers fairly extensively because I feel that it is often done incorrectly—no, not just incorrectly, but extraordinarily incorrectly, cartoonishly so. In my experience, most customer management is done from a place of complete fear. How do we avoid losing the customer, how do we avoid offending the customer, how do we avoid failing the customer.

So defensive. So reactive. So rooted in negative emotion.

There is an allure to doing what the customer asks when concerns like the above are the foundations for your mindset. How do we avoid offending the customer? We always say yes! How do we avoid failing the customer? We deliver precisely what they ask for, even if what they ask for changes or is bad for them! How do we avoid losing the customer? By being unfailingly giving and saying ‘yes’ no matter what! We act out of fear and watch in horror as customers migrate from partner to bully and then to gone over the course of a relationship.

As a rule, customers don’t become bullies because they want to be bullies. Customers become bullies because they are frustrated into the role by order-takers. They pay money to have industry experts help them, they place an order for what they think they want, they get exactly that, and they are left no better off than when they started their endeavor sans experts. Their results are similar to what they’ve always gotten under their own guidance, but now their wallets are a little lighter. They’ve paid extra money to end up back where they started. How amazingly frustrating must that be.

“No, we can’t do that, but…” is the most powerful customer service tool in your arsenal. Observing the customer’s situation, anticipating their needs rather than listening to their wants, then selling their needs to them—that is the place where real customer service is born. It’s scary and it feels dangerous, but in an industry full of order takers trading on lowest cost, there really is precious little danger in rising above by focusing on the strength of your solutions rather than the attractiveness of your rate card. If what you are selling is your competitive rates, it stands to reason that what you are not selling is your amazing services. You’re in a race to the bottom, and nobody wins down there.

Nobody pulls up to a drive-thru window looking for a culinary experience, they pull up looking for a fast and cheap solution to the dining problem.

Anybody can order-take based on a customer’s desires—and anybody will—it takes vision and skill to create and enforce boundaries on behalf of a customer’s needs. Don’t pass requests out of a window in a brown paper bag, define the expert services you offer and use that commitment to deliver excellence on an attractive plate in an elegant dining room.

Nobody brags about the speed of the service or the amazing value they received at their local fast-food establishment, but they do extol the virtues of the amazing steak they had on their anniversary. It’s up to you how you want your customers to remember you.

Layoffs: Those Left Behind

Last week we went through a round of layoffs (or reductions in force, or whatever trivializing euphemism is currently en vogue). Over the course of two decades in the industry, I have been through numerous layoff cycles—as an employee being laid off as well as being among those that retained their employment, and later as a manager having had to lay folks off and escaping having had to do so. One thing that I have never done is escaped unscathed.

It is easy to lose track of—amidst the concerns about properly delivering a layoff message, dealing with the actual act of letting a teammate go, and severance packages—the human impact a layoff has on the rest of the team. When someone is fired for cause, justified or otherwise, there is at least a reason. There is no sense of the arbitrary. You can point to specific things and say “if I avoid that, I avoid being let go” to some degree.

With layoffs, there is a sense of randomness, of chance, of inevitability. That uncertainty can be devastating to team morale. Too often, a layoff is a signal of instability to those that remain, resulting in a wave of voluntary exits in the weeks and months that follow. When you are planning the deployment of your layoff messaging, remember that those left behind need attention, not just those with whom you are parting ways. As brutal as a layoff is to those let go, it can be profoundly traumatic to those left behind as well.

Decision Triage: Cost to Revert

In a previous post, I discussed using decisiveness to reduce or eliminate decision debt; but how do you do that? I mean, if you haven’t made the decision yet, doesn’t that—by definition—indicate that you aren’t yet ready to make the decision?

From my perspective, there is only one useful way to categorize decisions: by their cost to revert. It’s less a taxonomy than a scale, but the basic organizational schema for decisions should be in ascending order from most costly to change to least costly. From there, logic dictates that you should only exhaust as much exploratory effort to make a decision as its cost to alter.

For a decision that is trivial to wind back, I expend almost no energy in trying to find the best route. Whenever a new decision is brought to me, I want to first drill through all of the data to find the answer to one important question: What happens if we are wrong?  In most cases, you will find that precious little happens if you are wrong, you just pick a better direction.

“How should we solve this technical problem? We think that option A solves the problem and it only takes a half day to implement, but it requires a half day of validation to see if it will solve for all aspects of the issue. Option B, however, will assuredly work, but could take multiple days to solve the problem.”

Right there, after just that much data, I can make my decision. Obviously, do option A. If it works, we’re out a half day and we have a solution. If it doesn’t work, we’re out a half day that we would be out after investigating anyway and we can just do option B. As an added benefit, by performing an implementation, we’ve naturally learned more about our problem domain just by working with it.

The solution is obvious, when you think about it in terms of what happens if we make a bad choice. Cheap, bad choices can be made with impunity.  The more costly a decision change becomes, the more energy I am willing to spend to plan on it.

Another common example would be determining which off-the-shelf product to use to solve a problem. The expense of the product can be very high often times; but a trial period (or even a liberal return policy) can suddenly mitigate that.

So when evaluating decisions, ask yourself what happens if you are wrong—not “what is the worst that could happen” but “what is the real result of an incorrect choice here” and spend only the effort that the cost to course correct demands. If you are like most people, you will find that many of your decisions have been getting a degree of attention that they do not deserve.

Manager vs Leader Talk at Penguicon 2016

Dawn Kuczwara (@DigitalDawn) and I talked a bit about the difference between managers and leaders at Penguicon this weekend. Penguicon always pulls a different sort of talk out of us, and this is no exception. The informality of the panel-style discussion lent itself to several things…

The attendees of the panel helped pull us in a much different direction than we had expected to take, so we never really did hit all of the topics we had intended.  This resulted in, from my perspective, a much better and much more interesting panel.

The lack of formality resulted in a much more obscenity-laden talk that is usual for either of us. We get pretty obscene for a 10am panel. If you have an aversion to the word ‘fuck’, you are going to want to skip this one.

We answered a LOT of questions. I would love to do this exact same panel as a 2-hour long session. We really had to stop with a significant number of questions outstanding. Tons of people came up to us to ask followups afterward (which is always welcome), but I think most of those questions would have been well served by having taken place in the broader group.

All of that said, here is the audio. Enjoy. Or don’t. I’m not the boss of you.

Decisiveness and Decision Debt

Consider your brain to be like a Git repository, constantly changing and updating and checking in new information. Everybody who has maintained a Git repo for any length of time is all too familiar with the amount of technical debt that is accrued through open branches. The more branches you have open and the longer you have branches open, the greater the likelihood that merge conflicts, hidden bugs, and other evils lurk in your future code.

Decisions work in very much the same way. Each decision is an open branch in your brain’s repository. The more you have open, the more places you are spending modest amounts of attention. The longer you have decisions unresolved, the more data gets trapped in that branch in need of sorting, reviewing, resolving, and handling. In short, the more and the longer you have open decisions, the more decision debt you accrue.

The problem with decision debt is the same as the problem with technical debt–what it robs you of are minor issues. When your project is rife with technical debt, there’s no such thing as a small change, because all changes have the potential to create a catastrophic effect. When you are plagued by decision debt, there are no small decisions; all decisions add to the pile, and suddenly where to go for dinner is just as stressful as which car to buy or how to proceed with a problem at work.

The cure is absurdly simple though: close branches. Make decisions. Find the decisions that are trivial to change later if you get more information and simply make the call. Just like with writing code, most times it’s easier to simply commit and see what the results are than to theorize for any longer. Pick the decisions with a low cost to change, and simply make those decisions and feel your anxiety melt away.

Here’s the hard part, once you’ve made your decision, be done with that decision. Don’t lament choices not made, don’t worry about whether or not you made the right decision–believe me, if you made the wrong decision, that will become apparent, and then you can simply change your decision if it’s needed.

Spoiler: a side effect of this is you are going to find that you have to revert precious few decisions. Most decisions you have to make aren’t worthy of the weight you are giving them. More on that in my next post.

Penguicon 2016 Schedule

This year, I have a fairly light schedule at Penguicon, affording me an opportunity to relax and visit with friends and (perhaps) attend some panels! My pesky responsibilities include:

Manager or Leader? Running a Technical Team

Saturday, 4/30 @ 10am-11am

The blurb: “Are you currently supervising a technical team? Maybe you’re considering taking the plunge? Come hear a few voices “from the trenches” talk about what it’s really like to lead a team: the good, the bad, the horrible, and the horribly funny. Topics will include: the differences between a manager and a leader, leading from the front, why your manager isn’t out to get you, managing up, ethical communication, and more.”

Dawn Kuczwara and I will discuss the finer points of being a manager, or leader, drawing from a combined 2-3 decades of leadership experience. While this is a “serious” talk, neither Dawn nor I are capable of being completely “serious” per se.

Sharing an Oral History: The Art of Verbal Storytelling

Sunday, 5/1 @ 2pm-3pm

The blurb: “We’ve all been there: this absolutely amazing thing happened to you yesterday and you want to share it with your friends and family. You take a deep breath and begin…only to helplessly watch as the story falls directly on its face. Storytelling is an art, and like any art it takes practice, study, and one of those books where you draw Sparky the turtle on the grid then mail it to Pueblo CO. This panel will basically be the turtle grid.”

This idea sort of rose out of listening to story after story after mind-numbing story that should be entertaining, but doesn’t quite make the cut. Dawn is an improv comic and I talk a lot, so, between the two of us, some good information might get thrown out there.

Penguicon Board Meeting

Saturday, 5/1 @  1pm-3pm

The blurb: “You’ve done the convention, you’ve met the staff, and you’ve even socialized with the ConCom. But what about those *other* Penguicon people? Those shadowy figures that create the multi-year rules, have their fingers on the money, and cause a ConChair to mysteriously appear every year in a puff of penguin-scented smoke? Ever wonder what the Penguicon Board of Directors does in their secret sanctum, and where they are taking Penguicon? Come to the Board of Directors meeting and see!”

I don’t know about shadowy, but we do have money fingers! I think I read that correctly. This is basically a 2 hour long glimpse into how the sausage is made. It’s not really a panel, but if you’re interested in what decisions are made at the board level, I’ve always found this interesting to watch, even before I was on the board.

So that’s me Penguicon weekend. Aside from those items, I’m sure there are a ton of panels that I’d want to attend, but they’re really hard to find on the online program listing (the program listing not showing who is on what panel this year is really a disappointing lack; I’m bummed by how unusable the online program listing is at the moment). Things that I am sure I’ll want to attend include, however:

  • How to Actually Relax
  • Continuous Delivery: Fast, Painless Software Deployment
  • Improving Leadership with IT
  • Intro to Agile/Scrum

Beyond that, I suspect I’ll be lounging on some random public area visiting with friends. What are your must-see panels this year?

Coaching vs Mentorship

As I discuss leadership, I often use the terms “coaching” and “mentoring” in a manner that would lead a casual reader to assume I mean them to be synonymous—that they are interchangeable. They are not.

For most of us, our first real exposure to a coach is in high school sports. My high school wrestling coach knew two important things: he knew what made up a successful wrestler and he knew that I had no idea what made a successful wrestler. With those two things, he set out to teach me the things that I needed to learn to be successful—often over my objections, frequently against my better judgement. He had a clear vision of what the goal for me looked like, and he helped me achieve.

Well, sort of, I never ended up being much of a wrestler.

A coach provides an end goal for someone who doesn’t clearly understand what the end goal should look like. He or she provides direction to achieve that goal, and supplies guidance along the way when his or her charge strays from the path. A famous example would be Mr. Miyagi in the first Karate Kid movie. Daniel’s vision of a successful practitioner of karate would have made him another Cobra Kai clone—Miyagi had a stronger vision for him.

A coach is a supplier of both the vision and the direction (the ‘why’ and the ‘how’) who guides someone through making good decisions about the ‘what.’ 

Conversely, a mentor is not supplying the vision. A mentor is working with someone who now has enough understanding of the field to know what success looks like—and that success is a deeply personal assessment of the state of things. A good mentor can listen to the goal, disagree with it entirely, and help guide the mentee toward their own vision.

To belabor my Karate Kid metaphor, in the second movie Mr. Miyagi took on the role of a mentor to Daniel. No longer was he rigidly enforcing his vision of how to employ karate, instead, he showed Daniel how to commit acts of violence against inanimate objects because that is one of the things Daniel found important.

Along the way, as happens in movies, the mentor and mentee’s common values resulted in each of their respective visions becoming more closely aligned. This is fairly commonplace in this sort of relationship, but should never be the goal of the mentor. Your goal is simply to teach the mentee how to be the sort of person that achieves their vision.

A mentor learns the vision of the mentee (the ‘why’) and teaches the mentee how to develop the ‘what’ and the ‘how’ required to achieve their vision.

It would seem then, at a glance, that coaching lends itself naturally to early in the career whereas mentorship becomes more useful later in the career. While that isn’t entirely inaccurate, it is more fair to say that at any given time I need mentors and coaches alike for various parts of my decision making—I am constantly a beginner in some areas and more expert in others, and so are most people. Patience, practice, and a heavy emphasis on listening will teach you which to use at any given time.

We Were Born Agile


No child learned to ride a bike by reading books about it, nor by rigorously documenting all of the steps that will be required in order to do it, planning those steps, then executing those steps. Children learn to ride a bike by experimentation and incremental improvement; they learn by taking minor risks fearlessly until they pay off.

Everything we learn as a child is done iteratively, incrementally…agilely. We learn to walk in tiny experiments, we learn how to read in the same way, most of us learn how to act socially (for better or for worse) by that same spirit of experimentation. As we get older, we learn to refine the experiments, but the experiments live on. At some point, we pitch experiments in favor of Gantt charts in MS Project. We spend countless hours learning about critical paths, fishbone diagrams, Monte Carlo analysis, and cost performance indices precisely because they are not intuitive. Documentation doesn’t come naturally. Long-term planning isn’t our natural state.

Our natural state of achievement is to do so agilely, so I bristle slightly when I hear that various forms of iterative delivery are difficult to learn; they shouldn’t be. Doing what you can and advancing forward bit-by-precious-bit is innate. While it is true that the accoutrements of frameworks like Scrum require a certain degree of education (especially in areas like vocabulary), the fact of the matter is the concepts are fairly elementary.

If your implementation is difficult to understand—especially if it is significantly difficult to grasp—perhaps you should be asking why you chose to make it so complex? Maybe there were good reasons, but shouldn’t you be consciously aware of those tradeoffs?