Adding constraints to projects for success

The company Github is known as a place where engineers have an unusual amount of freedom to self-organize as far as what projects they work on.

Here’s a very interesting blob post from a Github engineer, Brandon Keepers, on “Lessons learned from a cancelled project” — he has six lessons, which are really six principles or pieces of advice for structuring a project and a project team.

In some ways the lessons learned are particular to an environment with so much freedom — however, reading through I was struck by how many apply to the typical academic library environment too.

Since an academic library isn’t a for-profit business that measures success by it’s bottom line, we too can suffer from lack of defined measures of success or failure. (“Define success and failure“).

I think this isn’t just about being able to “evaluate if what you’re doing is working” — it’s also about knowing when to stop, as either a success or failure. I think many of us find ourselves in projects that can seem to go on forever, in pursuit of perfection, when there are other things we ought to be attending to instead of having one project monopolize our own time, or our team or organization.

This is related to Keepers’ second principle as well, “Create meaningful artificial constraints“. While we can’t say “money is not a factor” in an academic library, or that we are given ultimate failure to do whatever we want — I think we often do find ourselves with too many options (and too many stakeholders trying to evaluate all the options), or the expectation that “we can meet all the requirements at once,” which Keepers suggests is “paralyzing.” (Sound familiar?).    In a typical for-profit startup, freedom is constrained by a focus on the “minimal viable product”, the quickest way to sustainable revenue. When you have too much freedom — either because of Github’s culture of self-organizing, or an academic libraries… let’s say lack of focus — you need to define some artificial constraints in order to make progress.

Keepers highlights the “milestone” as an artificial constraint — a fixed date ‘deadline’, but one which “should never include scope”. You say “first beta user 2 weeks from today”, but you don’t say exactly what feature are to be included. “If you work 60 hours per week trying to meet a deadline, then you have missed the point. A constraint should never be used to get someone to work harder. It is a tool to enable you to work smarter.”

Which brings us to “Curate a collective vision“, and “People matter more than product.”  On that second one, Keepers writes

“For the first 9 months, I cared more about the outcome of the product than the people on the team. I gave feedback on ideas, designs and code with the assumption that the most important thing about that interaction was creating a superior product. I was wrong… If you care about people, the product will take care of itself. Pour all your energy into making sure your teammates are enjoying what they are doing. Happier people create better products.

That’s a lesson it took me a while to learn and I still have a lot of trouble remembering.

I don’t know if academic libraries just end up similar to the Github environment, or if it Keepers has come up with lessons that really apply to just about any organization (or any large non-startup organization?).  Either way, I found a lot of meat in his relatively short blog post, and I encourage reading it and reflecting on how those lessons may apply to your workplace, and how might account for them in your own organization.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s