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.

Malaise

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.

Do…not…like.

Self.Conference

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?

Post Migration: Episode 1

As I wrote about a few weeks ago, I’m slowly going through the process of merging an older, out of use blog into this one. As such, I’ll be migrating selected blog posts into this space. Most will probably not make the transition for a variety of reasons—there is some truly terrible writing over there, as well as some “probably funny at the time but not so much now” stuff—but as I bring stuff over here I’ll post pointers back to them in case you’re so inclined. My hope is that by doing it this way I can keep the reposting to a minimum and keep posts in accurate date order.

Today, I pulled three posts over, the top three inbound landing pages for years now:

Things I’m learning from this process?

  • I have more poop-related problems than your average person.
  • Nobody in this universe can find me as funny as I find me; I’m strangely okay with that.
  • There is a TON of stuff, and precious little is going to make the cut I suspect.
  • My number 1 topic? Stupid things I do to myself. I completely understand why I don’t have a lot of ego wrapped up in appearing cool and collected. I’m an idiot.
  • My love for the horizontal ellipsis (…) has spanned at LEAST a decade.

Until next time!

Poor Sleep and Decisions

I have been sleeping ridiculously poorly. I am in a unique period of prolonged indecision; which it turns out is a thing that my brain does not like at all. I tend to be a pretty decisive person—I act on the knowledge that I have and course-correct based on new input as needed.

Currently, I’m working from a huge swath of unknowns and most of this decision is going to be based on gut feel. On emotion. Like a caveman.

As a result, I’ve been utterly exhausted for over a week now which, ironically, is the state that I least want to be when making decisions with an emotional component.

At any rate, I can’t think of anything clever or witty to write this week. If I come up with something, I’ll replace this with that—so if you’re reading this, I’m still feeling pretty sluggish.

Here’s to more fact-based information in the near future.

Managing Safe Spaces

There is this concept that has followed me around from team to team as long I’ve managed, coached, or otherwise led people. The description of the concept changes team-by-team—”shit umbrella”, “distraction barrier”, or (currently) “human meat shield” to name a few—but the core idea remains constant; a key attribute of my leadership style is that of preventing the enormity of the weight of the organization from ever falling on the heads of those I lead.

I’ve never given the concept a ton of thought despite the fact that I consider it to be among my most important job functions. It always just seemed like an obvious thing to do; so much so that it has always been endlessly frustrating when I don’t see it happening in my leadership. What it didn’t seem to be is particularly universal; it simply seemed to be a thing that I found important—a quirk of mine, if you will.

Recently, I was listening to a talk that reframed my thoughts on this. The act that my teams refer to with their colloquialisms are my attempts to create safe work spaces for my team members. The fact of the matter is, I know (apparently intuitively) that I do my best work when I feel safe to do that work—when I feel comfortable taking risks, when I don’t feel continuous and uninterrupted stress, when I know that my bad work will be allowed to be a learning experience, when I’m actually freed to do my best work. One of the easiest ways to sour my relationship with a company is to make me uncomfortable taking risks and doing what I do; to make my work space a non-safe space.

I had legitimately never considered this before in quite this way.

So, the reality is that my true goal as an ablative meat shield is for my team to feel safe to excel at what they are doing. There are a lot of ways to feel unsafe—in fact, there are many more ways to feel unsafe than to feel safe in the workplace—so the task of creating that safe environment is non-trivial. Some mechanisms that I, upon reflection, find that I use include:

Reward the taking of risks. It’s not enough to reward those risks that pay off, it’s important to reward the risk-taking behavior in either case, especially when taken with planning and forethought. I seek ways to highlight when risks work out, but also to point out smart risks that are taken and don’t work out.

Prevent punishment of risk taking behavior. This seems obvious when factored in with the rewarding of risks above, but it’s not. If corrective action needs be taken because of poorly planned and poorly mitigated risks, I ensure that corrective action addresses the planning and mitigation aspects of the failed risk, not the risk taking itself.

Teach the team how to take risks. This is an area in which I struggle, because most of my risk mitigation planning is intuitive—which merely means I’ve been doing it for sufficiently long that I don’t have to actively consider each of the steps. It is important to ensure that all members of my team have an opportunity to learn those steps along the way. It’s hard to feel safe when you aren’t sure you understand what you’re doing. That said, I try to teach my teams at a high level that their job is to take risks, their job is to plan for those risks, and that if they avoid making the same mistakes a second (or third) time, they will be alright.

Appropriate and constant feedback. There is an inherent safety in knowing that mistakes are not going to result in the loss of the ability to put food in your family’s mouths. At a very basic level, my team needs to know that they aren’t one or two bad decisions from losing that ability. My method of managing that is through constant and continuous feedback. Nobody on my team has to guess how they are doing; I casually and with minimal fanfare inform them when they are not meeting expectations (typically by trying to find out how I can help them catch up) and I make an effort to let them know when they ARE doing well. I know all too well the fear of being in a feedback vacuum where the only input you get is when you stray from the path.

Make work life safe. I am not an optimist. Further, I don’t feel comfortable feigning happiness about something with which I disagree. I consider myself a realist, and have no problem cheering positive news, but I am not good at being chipper about less-than-positive news. I don’t think that’s completely to my team’s detriment, though. Honesty is as important—no, honesty is more important—than being a cheerleader. My team knows (I hope) that I would not stay in a situation where I’m repeatedly forced to ruin the working lives of my team, so when I’m forced to deliver bad news, any positive spin I convey is spin that I truly believe—I’m not likely to bullshit about such a thing. I equate it to having a doctor who tells me exactly what is going to happen rather than warning me of a “little pinch” before causing tremendous pain for an indeterminate period of time. I trust my team to get through periods of discomfort if we all believe there’s something better on the other side.

Make work culture safe. This is the area in which I struggle the most. The tone for your team is set by you, the manager. It is set by your actions, by your words, and by what you allow to go on. I am sarcastic, I joke a lot, and I tend to foster an environment where that is fairly common. I also find it important to keep an eye on how individual members of the team are doing and making sure that we aren’t accidentally breeding a hostile, cynical environment filled with all snark and no care. I don’t always know if I do a great job of that. I struggle daily here. There is an entire blog post in discussing how I try to ensure that we don’t slip into cultural toxicity within my boisterous, snarky, jokey team.

Obviously, the above is an incomplete list. I am sure that there are many things I do that I’m not even thinking of in these terms, and almost assuredly there are numerous safety-building mechanisms that I don’t employ at all. I’m interested in learning more about both categories as I explore this idea further.

It is interesting to think about something about which I’ve been so blithe and cavalier for so much of my leadership career from a different perspective. The “shit umbrella” concept has long felt like an “important to me, but probably not to ‘real’ managers” thing, but from the perspective of building a safe work space, it genuinely seems like a broadly important act that I have been working on for a really long time. Maybe I’m not as bad a manager as I usually think I am…

Moving to Agile: Doing it Right

It takes a considerable amount of bravery to be in the process of moving an organization from waterfall to agile and to ask questions at most agile meetups and conferences. Nowhere in the universe are you more likely to be told that everything you do, everything you think, everything you are is simply wrong. This is one of my biggest pet peeves.

Somewhere, someone must have printed a checklist entitled “Think You’re Doing Scrum?” that looks like:

  • Test-driven Design?
  • Pair coding?
  • T&M contracts only (no fixed bid)?
  • No managers?
  • No PMs?
  • The entire team talks to the client regularly?

And if you don’t have all of those checked off, you’re absolutely not “doing Agile.” This really hurts the conversation; it makes the more tentative of us not want to speak up and it derails the discussion amongst those with a more mature viewpoint of how change works in an organization.

I suspect that most of the folks thinking that way have failed to really absorb some of the core concepts involved in doing almost any flavor of agile delivery—not the least of which being the ability to adapt to your delivery needs.

I invite all of you to remember a basic tenet of Scrum, that of constantly seeking to improve one or two things from your delivery. Sure, it sounds wonderful to scrap everything and start over, but that’s not iterative; changing inexorably toward agile…that’s what it’s all about.

Moving to Agile: Training

I haven’t really had the mental energy to write much about our transition to agile for the last month or two because I have been spending so much of that time period putting together and executing trainings. Even with as much enthusiasm as I have for this, it has been a draining several weeks.

The human urge to generate complexity when something seems too simple makes teaching simple things a weird chore. When I walk someone through the thought process behind answering a specific Scrum question, it’s often perceived as too simple—I get wary looks from the audience as if I’m trying to trick them. There is no trick, it’s really that simple.

I’ve been working on training folks to problem-solve in a very Scrum way rather than simply teaching a knowledge tree with steps to take—an effort that is dichotomous: when it’s working, it is as good a feeling as I’ve ever had; when it’s not, it is as much frustration as I can remember ever feeling. I think it’s mostly been the former, but I don’t know that right now, in the thick of it, is a good time for me to start trying to estimate how the percentage of ‘working’ versus ‘not working’ is stacking up.

The training sessions themselves went very well. Over the course of 3 weeks my co-trainer and I walked 300-400 people from three sites on two continents through a crash course on applying Scrum principles to our work flow. Travel, late nights, and tons of caffeine happened. We faced a unique challenge in addressing three discrete groups that brought with them three discrete points of view and several distinct challenges. Every time we felt that we had really dialed in the training, we were confronted with the next series of challenges and set to adapting our delivery to the new inputs.

Honestly, it was a great deal of fun.

At a high level, we sought to show the people we were training how to solve issues that come up by thinking critically about how different solutions enhance several criteria we deemed important to “Scrummyness.” By seeking to enhance communication amongst teammates about both the project and the delivery process, by improving the ability of teammates to collaborate on features and tasks, and by increasing transparency of knowledge and statuses, the right solution typically becomes clear. Whenever that doesn’t work, I just make something up.

So far, the training sessions have seemed successful. We recorded several of them, and I am hoping to chop up some of the best parts to make one “refresher” training that can be streamed. We are also putting together a managed FAQ, some helpful documents, and a team of coaches to whom project planners can reach out.

In a future post, I want to walk through an anonymized version of one of our projects to discuss some of the decisions that have been made along the way. I’m sure that’s where the Scrum purists will tell me we’re doing it wrong—maybe that’s the point?!