The National Park Bucket List

One of the purposes of this site to share my experiences and lessons learned while trying to fulfill my quest to visit every single National Park in the United States.

Yes, every single one.

The quest started when I declared a bucket list to visit all of the National Parks in the United States.  Since it is a bucket list, the time frame initially was a long one – before I kick the bucket.  Since we originally created the bucket list item, we’ve refined the time frame a little bit, hopefully making it a bit more restrictive for reasons which should seem fairly clear.  

For those of you who may be familiar with the National Park Service and all the various sites they manage across the United States, you may be thinking “Holy Cow!”  All these folks will be doing is traveling.  To set the record straight, I should point out that we are only visiting National Parks, those things noted in the Ken Burn’s documentary as “America’s Best Idea.”

There are currently 63 National Parks.  I say currently because the count:

  • Went from 58 to 59 in January 2013 then Pinnacles National Park was created
  • Went from 59 to 60 in February 2018 when the Gateway Arch was made a national park
  • Went from 60 to 61 in February 2019 when Indiana Dunes went from a National Lakeshore to a National Park
  • Went from 61 to 62 in December 2019 when White Sands National Monument became White Sands National Park.
  • Went from 62 to 63 in December 2020 when New River Gorge National River became New River Gorge National Park.

My father has asked me what happens when a new national park is created.  Well, if it is created before we finish the list, we have to go, don’t we? Here is the full list of National Parks as well as when we visited them.

What this bucket list does not include are all of the National Monuments, National Preserves, National Historical Parks, National Historic Sites, International Historic Site, National Battlefield Parks, National Military Parks, National Battlefields, National Battlefield Site, National Memorials, National Recreation Areas, National Seashores, National Lakeshores, National Rivers, National Reserves, National Parkways, National Historic and Scenic Trails, National Cemeteries, or National Heritage Areas.  That’s not to say that we won’t visit those places if we happen to be near by, but we’re not going to go out of our way to visit them for purposes of this bucket list.

What Constitutes a “Visit”?

As luck would have it, we did actually visit a few of the parks before we established the Bucket List.  (Those parks are marked with an asterisk by the visit date until we meet the criteria below).  To make sure we kept things above board,  we (my wife Beth and my daughter Paige) established the following rules.

  • We (at least one of the three of us) have to physically be in the National Park.
  • Proof of a visit is via the official stamp in my National Parks Passport which shows the date of my visit.  (This makes the Passport book a very precious commodity).  This is also an indication that one of us was actually in the Park Visitor Center
  • Preferably view the main sites in the National Park and go on at least one hike.

Those are the rules.  We tried to keep them simple and straightforward.

We obviously try to make the most of each trip because it would be kind of silly to make a long trip from say Iowa to Alaska solely to get a stamp.

We spend more time in some parks over others.  The shortest time spent in any of the parks was probably Cuyahoga National Park.  I spent a couple of hours there in March while on a trip to Cleveland for a speaking engagement.  I at least went and saw Brandywine Falls.  Probably the longest we have spent at any Park is Rocky Mountain National Park – we have been there four times – twice for a week at a time.  As you could probably suspect, that’s our favorite.

Our National Park Roster

As of January 2022, we’ve visited 41/63.

Name Location Date formed When Visited
AcadiaMaine February 26, 1919 July 2010
American SamoaAmerican Samoa October 31, 1988
ArchesUtah November 12, 1971 March 2012
BadlandsSouth Dakota November 10, 1978 July 2012
Big BendTexasJune 12, 1944 January 2013
BiscayneFlorida June 28, 1980  November 2016
Black Canyon of the GunnisonColorado October 21, 1999 March 2012
Bryce CanyonUtah February 25, 1928 March 2014
CanyonlandsUtah September 12, 1964 March 2012
Capitol ReefUtahDecember 18, 1971 March 2012
Carlsbad CavernsNew MexicoMay 14, 1930 March 2021
Channel IslandsCalifornia March 5, 1980
CongareeSouth Carolina November 10, 2003 July 2018
Crater LakeOregon May 22, 1902
Cuyahoga ValleyOhio October 11, 2000 March 2012
Death ValleyCalifornia, Nevada October 31, 1994  March 2013
DenaliAlaska February 26, 1917  August 2016
Dry TortugasFlorida October 26, 1992
EvergladesFlorida May 30, 1934  November 2016
Gates of the ArcticAlaska December 2, 1980
Gateway ArchMissouri February, 2018 April 2021
GlacierMontana May 11, 1910  June 2017
Glacier BayAlaska December 2, 1980 June 1995*
Grand CanyonArizona February 26, 1919
Grand TetonWyoming

February 26, 1929

July 2009*
June 2015
Great BasinNevada October 27, 1986 July 2021
Great Sand DunesColorado September 13, 2004 March 2012
Great Smoky MountainsNorth Carolina, Tennessee June 15, 1934 June 2018
Guadalupe MountainsTexas October 15, 1966 March 2021
HaleakalāHawaiiAugust 1, 1916 February 2000*

February 2015

Hawaii VolcanoesHawaii August 1, 1916February 2015
Hot SpringsArkansas March 4, 1921 December 2012
Indiana DunesIndiana February 15, 2019 May 2019
Isle RoyaleMichigan March 3, 1931  August 2014
Joshua TreeCalifornia October 31, 1994  March 2013
KatmaiAlaska December 2, 1980
Kenai FjordsAlaska December 2, 1980  August 2016
Kings CanyonCalifornia March 4, 1940
Kobuk ValleyAlaska December 2, 1980
Lake ClarkAlaska December 2, 1980
Lassen VolcanicCalifornia August 9, 1916
Mammoth CaveKentucky July 1, 1941 June 2019
Mesa VerdeColorado June 29, 1906
Mount RainierWashington March 2, 1899 August 2013
New River GorgeWest VirginiaDecember 27, 2020
North CascadesWashington October 2, 1968
OlympicWashington June 29, 1938
Petrified ForestArizona December 9, 1962
PinnaclesCalifornia January 10, 2013
RedwoodCalifornia October 2, 1968
Rocky MountainColoradoJanuary 26, 1915 November 2002
July 2008
July 2009
March 2012
March 2019
SaguaroArizona October 14, 1994 March 2021
SequoiaCalifornia September 25, 1890
ShenandoahVirginia May 22, 1926 June 2018
Theodore RooseveltNorth DakotaNovember 10, 1978 July 2012
Virgin IslandsUnited States Virgin Islands August 2, 1956
VoyageursMinnesota January 8, 1971 August 2014
Wind CaveSouth Dakota January 9, 1903 July 2012
White SandsNew MexicoDecember 20, 2019March 2021
Wrangell –St. EliasAlaska December 2, 1980
YellowstoneWyoming, Montana, Idaho March 1, 1872 July 2009*
June 2015
YosemiteCalifornia October 1, 1890  October 2015
ZionUtah November 19, 1919  March 2014

Who is talking about Business Agility?

You can tell that an idea is starting to catch on when different people or groups start trying to advance it independent of each other.

The advantage of that is people who hang out in different circles find out about the idea. The downside is that they run a chance of finding out wildly different views about that idea to the point when people from those different circles start talking to each other, they can’t tell whether they are even talking about the same thing.

Business Agility is in that territory right now.

I defined business agility for Agile Alliance’s Agile Glossary as:

Business agility is the ability of an organization to sense changes internally or externally and respond accordingly in order to deliver value to its customers.

Business agility is not a specific methodology or even a general framework. It’s a description of how an organization operates through embodying a specific type of growth mindset that is very similar to the agile mindset often described by members of the agile software development community.

There are at least three different views of Business Agility of which I’m aware. I suspect there are others. They have some common themes, primarily the ability of organizations to respond to change and a focus on their customers. They also have some differences.

Agile Alliance

Agile Alliance has an initiative, facilitated by a group of current and former business leaders focused on identifying and sharing methods to explore the adoption of the Agile mindset and methods in the enterprise.

The initiative includes a monthly webinar that connects business leaders to the Agile community to share perspectives and insight of how Agile works within a business and an ongoing worldwide narrative-based retrospective of Agile and business. The goal of the program is to identify both positive and negative stories from the agile community and to work to amplify what makes Agile work well for business.

ICAgile And the Business Agility Conference

The International Consortium for Agile (ICAgile) has added a Business Agility Track to their Learning Roadmap that will provide a path toward a business agility certification.

ICAgile presented the Business Agility Conference in 2017 The conference was 2½ days of authentic short stories and facilitated deep dives on business agility; focusing on organizational design, market disruption and product innovation, agile outside IT and next generation leadership. You can get the videos from the 2017 conference from InfoQ.

Evan Leybourn the conference chair of Business Agility Conference 2017 described business agility in the article Domains of Business Agility. In that article, you can find the following comment:

“If, and until such time as, there is a Business Agility manifesto, the values and principles of the Agile Manifesto apply across all areas of the organisation with one minor modification.”

He posted that article in May, 2017. By September, a Business Agility Manifesto showed up.

A Business Agility Manifesto

In September 2017, Roger Burlton, Ron Ross and John Zachman published the a Business Agility Manifesto with plans to “officially” announce the manifesto at the 2017 Building Business Capability Conference (BBC). The manifesto includes a few supplements, including the SideBar for IT Project Professionals which appears to try and address several agile adoption anti patterns.

Making Sense of these Perspectives

If your organization is trying to implement business agility, you’ll find some practical experiences and stories from the Agile Alliance efforts and the Business Agility Conference content. I haven’t seen much practical information from the Business Agility Manifesto, but then again manifestos are primarily intended to communicate principles and intent.

Did I miss any discussions about business agility? Let me know in the comments.

Photo by Climate KIC on Unsplash

A Collection of Manifestos

Photo by Mona Eendra on Unsplash

A thought crossed my mind a couple of weeks back when I saw the announcement on LinkedIn about the Business Agility Manifesto.

“Oh great, another manifesto…”

(Full disclosure: I played a part in creating one of those manifestos, the Declaration of Interdependence.)

Then I wondered how many manifestos there are in the world of business and software. So in a bout of productive procrastination, I conducted a search. The results are listed below in an admittedly arbitrary organizational scheme. During the search, a couple of questions came to mind.

Why Write a Manifesto?

Manifestos are generally used to publicly declare principles and intentions and have been used for political purposes for several centuries. Geoff McDonald (no relation) compiled this list of famous manifestos which includes things such as the Bible, the US Declaration of Independence, Martin Luther King’s “I have a Dream Speech”, and the Communist Manifesto.

One of the other items on that list is the Cluetrain Manifesto. This manifesto, originally posted online in 1999 spoke to the impact that the authors foresaw the internet having on business. It probably signals the start of a trend toward using manifestos to share principles outside of the political sphere.

The document that had even more of an impact on the manifesto trend in technology and business is the Manifesto for Agile Software Development written in 2001. The Agile Manifesto provided a statement of values and principles that became a focal point for the agile software development community to form around.

Since it’s original creation in 2001 the Agile Manifesto has been widely referenced and has inspired a host of additional manifestos, including a fair share of parodies.

People with a set of beliefs in some aspect of business or technology look at the spread of agile software development, attribute the spread to the presence of a manifesto and reason that if it worked for agile…

What makes a Successful Manifesto?

Since manifestos are intended to declare and spread the ideas of its authors. Therefore a successful manifesto is one that spreads those ideas wide and generates actions that are aligned with the ideas contained within.

If you look at the manifestos in the list below and see which ones are more well known than others, there are some possible patterns that contribute to success:

  • The manifesto resonates with people and expresses principles that they share.
  • The manifesto is simple and concise
  • The manifesto is created by a group of people from different organizations who may compete, but share the same values and principles
  • The manifesto is backed by a community where people can share ideas and experiences about how they’ve actually applied the ideas in the manifesto in their actual context.

Examples of manifestos that meet these criteria to some extent include: Manifesto for Agile Software Development, The Manifesto for Software Craftsmanship, and Modern Agile.

Here is a list of manifestos related to Business and Software. Please let me know if I’ve left any off.

Agile and Agility

Manifesto for Agile Software Development

The Declaration of Interdependence

Modern Agile

Product Agility

The Business Agility Manifesto

The Responsive Manifesto

Agile Manifesto Variations

The Waterfall Manifesto for Realistic Software Development

Manifesto for Half-Arsed Agile Software Development

Dark Manifesto for Agile Software Development

Software Development

The Manifesto for Software Craftsmanship

A Software Development Manifesto – Klipfolio

Manifesto for Responsible Software Development

The Reactive Manifesto

The Boring Software Manifesto

Manifesto for AntiFragile Software

Manifesto for Adoptable Software Development

The Good Eggs Software Development Manifesto

Manifesto for Minimalist Software Engineers

Manifesto for Async Software Development

The GNU Manifesto

Software Architecture Manifesto

SOA Manifesto

Software Gardening Manifesto

The Rugged Software Manifesto

Business Analysis

Business Analysis Manifesto (Xebia)

The Business Analyst Manifesto (Bridging the Gap)

The Business Analysis Manifesto (Business Exchnage)

Jeffrey Davidson’s BA Manifesto

The Lean Business Analysis Manifesto

The Junior Business Analyst Manifesto

User Experience

UX Manifesto

Testing

The Testing Manifesto

Continuous Testing Manifesto

Agile Testing Manifesto

GDS Agile Testing Manifesto

Testing Manifesto

The Open Source Test Manifesto

Project Management

The Pragmatic Manifesto for Project Management

The PMO Manifesto

 

Make a Habit of Reading Books You Enjoy

I look forward to those Sunday mornings when I can sit down with a cup of coffee and read through the Farnam Street Brain Food Newsletter. Farnam Street, founded by Shane Parrish, shares information on mental models, decision making, learning, reading, and the art of living. The material on the site provides a real, meaningful alternative from the crap that exists in other parts of the internet and social media.

This morning’s Brain Food newsletter caught my attention with it’s lead article Why You Shouldn’t Slog Through Books. A couple of years ago Farnam Street suggested a way to read more and make your way through large books: form a habit of reading at least 25 pages a day, every day. The thought was that if you keep that habit up, over time you will make some considerable progress through those huge volumes that you always wanted to read, but couldn’t find the time.

The post in this Sunday’s newsletter addressed two misconceptions about that first article. First, the 25 pages was a minimum not a maximum. Reading at least 25 pages will help you form a habit, and there will be many times where you’ll find yourself keep going.

Second, if you don’t find a book interesting, don’t keep reading it. Just because you’ve had a book recommended to you, or it’s a classic doesn’t mean you have to read it (unless this is my daughter reading this and the book is a homework assignment). Put the book aside – you may find it’s a better tie in with your interests later. Or, you may find that you can consume the book better in different ways – ie audio.

That second piece of advice especially caught my eye. I had started a quest to read Bertrand Russell’s History of Western Philosophy (affiliate link) and while I found the subject matter interesting, I also found that it couldn’t hold my attention reading it. I found myself switching back to the library on my Kindle App to see what other books I was missing out on while I was reading this one.

The Farnam Street Post helped me to remember that the way I consume history and large works like Russell’s book is to listen to them, not read them. So I downloaded the audible version of the book (affiliate link) and can now turn my attention to books I’ve been meaning to read and summarize for this site and for kbp.media.

I wasn’t previously aware of the 25 pages a day suggestion, so finding out about it comes at a great time. I was looking for a way to put my evenings at home to good use rather than roaming around social media getting irritated. This provides a nice path forward to make progress through my backlog of books and help me to identify ways to continue living an effective life.

The Five Year Plan

My wife and I have a plan.  This should not be surprising to anyone who knows us as we are both planners, though one is much more of a planner than the other.

Our plan is that by the time our daughter graduates from high school, we are able to go where we want to go, when we want to go there. In other words, we’re seeking to be location and schedule independent.

While it’s nice to dream of “early retirement” we’re going to probably need to do some sort of income generating activities.  My view is that I’ll always want to do something, so I want to make sure it’s something I enjoy that doesn’t require me to be in a specific location and to be tied to a specific schedule.

With my current gig I am mostly there. My wife has a little ways to go to get to that point.  My posts on effectiveness will cover the techniques I’ve used to get to location independence, what I’m working on to get to schedule independence, things we’re trying to get my wife there, and what we do to make the most of those opportunities.

I’ll admit, a lot of the tips and techniques that I’m going to share are things I’ve heard from the slew of personal improvement books, podcasts, blogs that are already out there.  So you may be wondering – why add to the overwhelming amount of content out there surrounding personal improvement.

That’s a good question, and one that I’ve struggled with for a while. I decided to go ahead with it because I provide a different perspective than a lot of the personal development and self help content out there.

First, I’m still going through the journey and will make some mistakes along the way.  I’ve found I do learn from mistakes, but I learn even more when I can talk through (or in this case write through) the lessons I’ve learned while they happen.

Second, while I have location independence, and I have a good income, that income is tied to a specific gig.  Many of the people I look to for personal development guidance have through one way or another removed the need for a a gig either because they had smash book sales, are bringing in revenue from course sales, had great investing success, or a combination of those things. I’m not there yet and I imagine a lot of people who also look at personal development information aren’t there yet either.  I can discuss how the personal development techniques I hear about work for someone in my context, and hopefully you’ll find that helpful.

Finally, I’m doing all this from a piece of paradise in the middle of Iowa, not a big city. That means that there are some time saving techniques and life hacks may not work exactly the same, and my role as #ubersherpa becomes even more important. At the same time, we’ve removed ourselves from some of the stressors that city life brings, so we wouldn’t trade it for the world.

I encourage you to join me on my journey to fulfilling our five year plan. Hopefully you’ll be able to pick up some ideas along the way that will help you with whatever plans you have to lead your own effective life.

Satisfy needs instead of solving problems

The Daily Stoic newsletter for September 19, 2017 shared a common optical illusion that depending on how you looked at it could appear to be a couple of different things.

For the record, I saw the duck first, although with a little staring I was able to see the rabbit.  I’m not sure whether which animal you see first says anything about how your brain works, but the the fact that you can see multiple things in the image does.

The lesson here is that how you look at this illustration, and what you “see” resembles how our perceptions work. From the Daily Stoic newsletter:

Most of our perceptions about anything—people, situations, problems, anxieties—are like this. You can see a problem; or you can see an opportunity. You can see a crippling defeat, or you can see a fresh start. You can see the end, or you can see the beginning.

Your assessment is what changes.  The Stoics suggest that while you can’t control outside influences, you can control your reaction to them.  You can change how you think about them.

One change I’ve made over the past couple of years, and this has a lot to do with my work at kbp.media is that I talk about needs to satisfy rather than problems to solve.

To be clear, part of the reason I chose that language is because “needs to satisfy” is the way that concept is described in the Business Analysis Core Concept Model (BACCM) from IIBA. They were trying to make satisfying needs the standard (and admittedly shorter) way of saying “problems to solve and opportunities to exploit”.

 

If you look at it from a stoic perspective there’s another, perhaps greater reason.  You are no longer surrounded by problems.  Rather you help your customers by satisfying their needs.  You’re helping them move forward rather than just always getting them back even with everyone else (although there is certainly good that comes from that).

That small change in words can have a big impact on how you view your work, and the value you derive from it.  Give it a try.

Farewell Cassini

The Cassini Spacecraft during testing in 1996

Imagine for a moment, working on the same thing for over 20 years of your professional career only to see it end as a loss of signal from a piece of hardware over a billion miles away because you intentionally sent it careening into the object the the mission intended to observe.

Photo Credit: (NASA/Joel Kowsky)

That is what leads to images like the one above – the end of the Cassini mission that has been exploring Saturn and it’s moons since 2004 after leaving earth in 1997.

20 Years.

In case you haven’t heard what happened at Saturn amidst all the idiocy happening on this planet. The team working on the Cassini Mission chose to plunge the spacecraft into Saturn in order to reduce the risk of the spacecraft crashing on one of Saturn’s moons and potentially contaminating a moon that might have life.

I find it interesting that this team seems to have more concern for objects a billion miles away from Earth than many people and corporations do for areas on this planet.

It gives me hope that maybe, just maybe, humans can care about the world and the universe in which we live to make a decision that while personally difficult and painful is in the best interest of the bigger picture.

Cassini is was a probe launched in 1997 to explore Saturn and it’s moons. The original planned mission was supposed to be four years in duration once it reached Saturn in 2004.

It continued to gather data about Saturn until it’s final, intentional plunge into the planet 20 years from it’s launch on September 15, 2017.

There’s not too many government activities you can point to that continue to add value for twice as long as their intended life.

I would like to thank these people for making Cassini happen and for getting us a bit more information about the universe in which we live.

The Cassini Mission Team

If you would like to know more about Cassini, goto NASA’s Cassini Site. While you’re there, check out what else NASA is up to.

The Agile Industrial Complex: Solution over context?

…we must guard against the acquisition of unwarranted influence, whether sought or unsought, by the military-industrial complex. The potential for the disastrous rise of misplaced power exists and will persist. –Dwight D. Eisenhower’s Farewell Address to the Nation

The Swinging Agile Pendulum

The agile community, like most other movements I suppose, has gone through several pendulum swings since it was “officially” became a movement in 2001 with the creation of the Agile Manifesto.

Leadership summits are too exclusive. We shouldn’t talk about leadership in agile
to
How do we get the executives to come to our executive summits?

Agile is only for small teams
to
We must scale!

Extreme Programming is the way to go
to
Scrum is the way to go
to
SAFe is the way to go
With a healthy dose of Kanban (whose proponents would argue “is Lean, not Agile”) mixed in there for good measure.

The most recent pendulum swing is from a large number of, for lack of a better term, self organized organizations providing consulting and tools for agile to a raft of consolidation.

CA acquired Rally

CollabNet acquired Version One

Accenture acquired SolutionsIQ

Apax Partners acquired ThoughtWorks

That’s a sampling of the announcements from the last couple of years. While each merger has a specific reason it happened, I can’t help but think that this is a trend that warrants some attention.

If you look at the announcements, most (but not all) of the acquisitions are a larger entity trying to buy their way into the “agile space” by purchasing skills or products they don’t currently have in order to enter a target rich environment they currently do not inhabit. That is a typical reason to do an acquisition.  However in this case, these new entrants have a disturbing effect on the community as a whole and the amount of new ideas that get generated.

To understand why, it’s helpful to consider different types of communities.

Consolidation Changes Focus From Needs to Solutions

Chris Matts took a look at the agile community in terms of Geoffrey Moore’s technology adoption curve and Cynefin and described how different types of communities are better suited for different points along that curve.

From Communities of Need & Communities of Solution by Chris Matts

Starting out on any new technology or idea, you have a Community of Need. These communities consist of people who try to solve their problems by looking at solutions from other contexts and try to adjust those solutions to fit their own context. They tend to focus on the areas to the left of the chasm.

As word starts to spread about about a particular idea or technology, folks start to form Communities of Solutions which are focused on selling the idea or technology to the people on the other side of the chasm. Unfortunately, the idea or technology that is sold is something that worked in a specific context of the organizations to the left of the chasm, which may not be the same context as that on the right.

Because the motivations of the people in the Community of Solution is spreading an idea as quickly as possible, they aren’t as interested in figuring out whether it’s appropriate for the new contexts. Chris described how this happened in the agile community in his assessment of agile as a broken learning machine. To make matters worse, while there are certainly aspects of agile that have been figured out (how to build software in small teams) there are several aspects that are not ready to cross the chasm, yet these are the problems most prevalent in the organizations being approached by the community of solutions.

These consolidations take organizations which at one time (some more recently than others) were part of a community of need and assimilate them into a community of solution. Any tackling of problems in different contexts, any unique approaches to unique solutions, any sharing of failures along the way that will lead to learning and success down the road will stop. That’s the case with most acquisitions in other industries. The new ideas and different approaches of the organization that was acquired gets lost in the way we’ve always done things of the acquirer. The new ideas can’t survive against the inertia of the collective and caring for context and fit for purpose get pushed to the wayside in the interest of meeting unreasonable sales targets. This community of solutions forms a part of the Agile Industrial Complex.

Meanwhile, the people at the organizations that get help from these new merged entities find themselves in the midst of another transformation program of the month. They figure if they keep their heads down this change will wash over them like all the others and will follow the same path out of the organization in due time, until the next transformation program of the month comes along.

There is a better way

Don’t seek to adopt agile, or lean, or SAFe, and certainly don’t impose those practices on your teams. Seek ways to more effectively satisfy your customer’s needs. It just so happens that many agile and lean ideas will help you accomplish that, but adopting agile should never be your end goal.

Remember your context in everything you do. By all means find out what worked for other organizations. It’s only smart to avoid reinventing the wheel. But also seek to find out why a particular technique worked in that context, and then understand the difference between that context and yours.

Seek out communities of need. These are your local gatherings of people who share their successes, and their failures. Local agile groups often have those types of discussions for people directly involved in software development. Groups such as the local Product Tanks do the same for product people.

If you find your organization has engaged a member of the Agile Industrial Complex who is trying to impose practices on your team, follow Chris Matt’s advice: “show them the door and find a new partner whose goal is your success rather than an easy life.”

Update 09.19.2017:

If you would like a nice description of the ideas above and enjoy videos, you may want to check out the video of Chris’ talk on InfoQ: What Is the Purpose of the LLKD Community?