A Real Cool Hand

I'm Craig Sturgis and this is a web site.

Beware the Answer

A pep talk to myself and others

In almost all fields, most people are searching for “the answer.” The silver bullet, the cracked code. Product development is no different.

Don't smash 'em

“Scientific management” arrived on the scene before 1900. Taylor’s methods lit a match under the modern pursuit of the “right approach” to making things. A pursuit that has exploded over the last 15 years.

Those of us working in software enabled products are drowning in versions of “the answer”. Process driven iterations of scientific management are everywhere. We’re all agile now, whether we’ve considered the manifesto or not. MVP is on everyone’s lips, even if it almost never lives up to the spirit of the original definition.

Many people also look to a new set of technology frameworks to provide the fastest, easiest path. With the right tools, surely no waste will slow down the construction of new and innovative ideas.

Consider the ratio of talk about innovators and their dilemmas vs. actual developments that are new and uniquely useful. Many recent approaches to “the answer” are those that aim to help decide what to make. Whether you subscribe to service design, jobs to be done, or something else, there are more frameworks than ever to apply.

The makers of these methods refined them to be used in a narrow sense, with care and skepticism. But, once popularized it is all too common to see them applied broadly. The results are often presented as fact and not the best interpretation at the time.

The simple, but not easy fact is that we’re all competing against luck, no matter what tools we use.

Product makers should invest in deliberately learning the latest approaches, then practicing them. Combining fresh methods with fresh assumptions may not be a sure thing, but it might bend the odds favorably.

Any of us is going to be lucky until we fail, or fail until we’re lucky.

Most people bold enough to try their hand at product development have to assume they’re going to be lucky. The prospect of being wrong is what prevents many from even trying. But, once armed with “the answer” many bet they’ll be successful.

It’s hard to get any product development effort off the ground or its direction changed. Funding, approval, alignment, team buy in, or any number of other things can stand in the way. It’s tempting to think that once we take care of those hard things the output should be easy. It rarely is.

Big ideas are easy, execution is hard. Most people think the opposite.

Start with the assumption that you are almost certainly going to fail, and you might need a lot of attempts to get lucky. No approach or tool can eliminate that possibility. It can help guide you much earlier to a way of working that is very easy to talk about but very hard to do.

Those of us doing this work are all human, and human beings rationalize. This makes it very difficult to assess results without telling ourselves the wrong story. Embrace the human limitations of yourself and your team. Plan to counteract them. Set up both your execution and your feedback loops to learn how wrong you are earlier than what you think the right time is. Then reflect on whether you can cut it even shorter every iteration.

Put systems in place to make it hard to rationalize what you assumed before the results came in. That way you can be less wrong sooner, and you’ve got a lot more at-bats.

There is no answer. Learn, apply, and go fail until you get lucky. If you start lucky, celebrate and get back to work. For most, luck is fleeting.

Have a story about when you thought you had the answer? Or someone you worked with? Tell me about it. cs@craigsturgis.com

(This post includes affiliate links.)

If you like this post, you may be interested in joining my Product Balance For Everyone mailing list

Great Products Need Balance

One of those most ingenious features of modern, rule of law governments is how power is separated and provides a system of checks and balances. It’s a fundamental assumption that different branches have to remain balanced over time to keep a state functioning well without authoritarianism. Carrying that concept into product development could be incredibly valuable for companies as they try to make and keep their products great.

Check out my drawing skillz

Uber, AirBnB, and Slack are just a few of the most prominent examples of how evolving from a “requirements” vs. technology approach to proudly experience driven products can be transformative. Not only to the markets they operate in, but to everyone’s expectations of how products and services should work in a world where every company needs to be a technology company.

Experience driven product development is a huge step forward, but doesn’t fully explain what makes these and many other products truly great. It’s the companies whose products truly balance the demands of great customer experience, scalable technology, and driving a sustainable business that grow and maintain greatness. This is true of bootstrapped, seed stage, high growth, and public company products and services.

The company that tips out of balance toward business needs builds a Frankenstein product that eventually no one wants to use, or gets mired in technical debt. Too much focus on technology can result in a marvel of a system that scales but never needs to do so thanks to lack or loss of product market fit or funding. The worst customer experience is growing to love and depend on a delightful product that goes out of business or is “sunset” when its economics don’t start making sense.

This is probably a restatement of a more obvious concept, but the best product teams are ones that put systems in place to maintain the balance that fits their situation in an ongoing way.

This is not just a product manager’s job. Balanced thinking should be understood and appreciated by everyone involved in making a product: developers, designers, product managers, founders, executives, salespeople, marketers, the whole lot. Not everyone has the individual skills necessary or can take on all the roles needed to ship code, design interactions, tell a compelling marketing story, or close a sale, but through direct contact with customers and teams that cross disciplines, a team of any size can collectively and deliberately work to prevent their center of gravity from moving too far.

A personal note

One of my mottos is: the second I think I have things figured out that’s when I’m done having a chance to truly do great things. I firmly believe there is no one perfect or right way, but there’s always a way to learn more and do better.

I would love to discuss and debate this concept outside of my immediate social circle and the company where I work. I want to be a student of the experiences of others, but there’s a seeming lack of a community that embraces a balanced product mindset more inclusive of roles beyond product managers or founders.

If that’s not true, I’d love to see places where that role agnostic community is coming together both online and even in person. If it hasn’t happened yet, I want to start one. Point them out, or come join me.

Slack Civics: Ways to Group Chat Without Sweating Too Much

Recently as Slack has continued its rise as a primary tool for people to communicate, there’s been a bit of a backlash against some of the behaviors that result.

One person sent their dear John letter, 37Signals’ Jason Fried shared his strong opinion on the subject, and Ars Technica also released a more comprehensive piece on Slack centered workplaces from a more observational point of view.

All 3 posts are well done and worth reading, and all have their own great points to make, especially around design and the root of how tools affect behavior. But, I think for a lot of groups there’s a way to cultivate a healthier way to leverage the tool and get the big advantages without as much of the stress and the strain described in those posts.

Gotta make adjustments

Having recently shifted from being one of the drivers of a Slack centered, “work as if remote” culture to one that is much more face to face interaction and meeting focused, with some email, wiki, and chat thrown in, I’ve had to do my fair share of adjustment. However, this is also a group that does leverage Slack as its group chat tool, just not nearly as widely or deeply as I’m accustomed to.

Any community of 300+ inside of a broader organization of 1500+ is going to behave differently from a community of 10 regardless of their tools, but having come from a place where I think group chat worked really well for the most part , I have taken to stumping for something that’s more like a set of civic duties to be aware of that make for a better Slack society.

(In the interest of brevity, I write Slack when almost all of these things also apply to other similar group chat tools like HipChat, Flowdock, IRC, etc.)

Everybody needs a vision

In a perfect world, I look at my Slack app after a good bit of focusing on other work and see all the conversations relevant to me, I know the correct place to go to start any conversation, and I know which ones are urgent and not urgent. But, none of us live in a perfect world.

I firmly believe that like most things, there is no one right way to group chat or communicate within a team, but I thought I’d share the key disciplines I’ve seen work well:

Information in the open

The primary advantage that Slack has over email and one off conversations is that it allows for more information to be shared in an open, recorded context. That way, not everyone has to be in a status meeting or copied on every email thread to know what’s happening- and conversations and history are located in an easily searchable place. However, this requires that people actually get into the habit of sharing the information in the first place.

Some examples that are helpful to share are links to / summaries of meeting agendas and decisions, outlines of one off conversations, relevant reference material and supporting documents, etc. If those things remain in email or private chats or vanish into the air in a meeting room, information is often lost or shifts as it is recollected in a game of idea telephone.

Commentary Track, Not the Movie

If I’m curious about a topic that is not core to my normal frame of reference, I should be able to dip into (and out of) channels to get the conversation and follow links to the appropriate supporting material. I should not need to stay in every channel and read every message or do a search through the chat history to cobble together a good sense of where something is.

Other reference systems such as Trello, JIRA, Basecamp, and the like are way better for keeping track of individual bits of work and their current status and context. However, when updates are syndicated to Slack it can help people get a sense of that moment in time, and give more depth to the meta-conversation that may not necessarily apply directly to those specific bits of work. It can also help the non regulars figure out what part of a reference system is actually relevant for a topic. But participants also need to be guided to share appropriate information in the underlying tool rather than just in Slack too.

Tuned Integrations

In a related sense, easy integration with outside sources and services is a huge benefit to using Slack, and making sure it’s sending the right amount of information is key. If there’s a firehose of links in the channel, it’s hard to carry on a conversation without pieces of it getting lost. Tuning the integration to give the broader strokes and not every status change or comment can go a long way, and could even need to be maintained over time. But it is worth it.

Russian Nesting (Public) Channels

Depending on the number of people in your group, you probably want to have appropriate sub-groupings for people to sort themselves into. Think about the example from your biology textbook of species classification (or if you prefer, your favorite object oriented language inheritance example).

If I’m a duck and I’m in the Slack for the “all animals” organization, I probably belong to some group of appropriate channels for conversations at the level of #vertebrates, #birds, #ducks, and potentially other ways to slice things that don’t fall into a strict hierarchy like #pond-swimmers, #gimme-bread, #lovable-loser-youth-hockey-team, etc. This way it becomes easier to tell where the right people to talk to at the right level of specificity are.

Notification and Channel Etiquette

Much like email, the first big step to a more sustainable personal Slack experience is tuning the amount of notifications1 you personally get so you’re not constantly bombarded and distracted. However, many times you still need to figure out when something actually needs attention sooner rather than later. That requires help from everyone involved.

When people are guided only to use the appropriate version of @here / other group messages when that is warranted, only @ mention people when something needs a specific person’s attention, and they can trust that the non urgent things will get a good response in a reasonable amount of time, that is a culture that is more helpful and less needlessly distracted. Finding this balance with your group is the crucial counterweight to the “expectactions” problem that Hulick and Fried justifiably point out.

Cross Talk

One thing Slack is decidedly not good at is when people are trying to discuss more than one topic simultaneously in a channel, which can create a confusing soup of multiple topics. There’s more than one way to mitigate this problem, but even having everybody be aware that this makes things difficult to follow is the first step.

Creating a post that people can comment on so discussion is collected on a single item, or my favorite recent strategy- breaking out a new, short-lived channel that can be archived when the topic is done can be a huge help in maintaining focused conversations while keeping useful information in a public, searchable place. It acts a bit like a code branch for the topic at hand.

Community Guidance

The thing about communicating this way is that it is a relatively new experience for a lot of people, and they really only get good at it by being exposed to its use as something beyond another place to exchange words in the same way.

Otherwise, they may stick to the muscle memory of meetings and emails or using it like any other IM style tool. Slack does a good job of nudging people, but it still requires a helpful civic culture to help patiently guide people into the right habits and give directions to the right places, maybe even with a deliberate onboarding process to help, just like introducing someone to a new physical office culture.

Oh, and robots

Some of the most fun can be had by leveraging slackbot, custom webhooks, and even hubot to add random fun touches, do all the janitorial work like archiving inactive channels, and to pipe in custom information specific to your codebase and operations. It can also be a good steam valve for developers and other people who write a bit of code to create something to share which might have culture value if not direct work value.


Sounds like a lot of work huh? I’d argue that so is maintaining any good society and culture, whatever methods are used to communicate.

I think it is fair to call for better design that leads to more falling into the pit of success, but regardless of tool design, culture eats process that doesn’t match it, and entropy will always win in the end. But, if you and your cronies are deliberate, thoughtful, and together maintain a self examining environment then it is possible, and even probable that you can collaborate better with group chat as a communication centerpiece vs. without it.

  1. (pop pop pop sound)

The Tools vs. End Product Spectrum

It’s no secret that there’s an ongoing, accelerating proliferation of tools for makers of software, especially if you write code. New and evolving programming languages, frameworks, libraries, databases, PaaS offerings, and more show up seemingly every day.

Some of us are energized by this explosion and chase the bleeding edge. Some ignore it as much as they can and stay mostly in their comfort zone. Most people live somewhere in between, but there aren’t many people who make software who don’t care deeply about the tools they use to do that job, no matter where they fall on that spectrum.

Over the last couple of years I’ve noticed a shift in my own thinking and behavior along that line that makes me wonder about a potentially more interesting axis: the spectrum of the tools used vs. the end product produced with those tools.

I’m a (mostly lapsed) guitar player. In the guitarist community there’s a common phenomenon called “GAS” or gear acquisition syndrome where people who are really into guitar can’t get enough of buying yet another guitar, amp, pedal, or processor in search of the perfect tone. I’ve had serious cases myself1. But, Kurt Cobain played era defining riffs on a cheap Fender mustang running through a $30 boss DS1 distortion pedal. Sometimes the guitar isn’t the thing in the way.

Great tools can make a big difference, but these days I’m mostly interested in balancing learning of new tools in concert with using the ones I already know in order to efficiently produce the end result I’m after. That, and making progress in less calendar time.

How many side projects would have gotten off the ground if I didn’t try to tie that project to also learning a new tool in parallel? What if I split out small, breakable toy2 projects from my “I want to make this thing” projects?

When I recently wrote about finally learning Ruby on Rails, I wrote from a perspective where the learning material didn’t match the web development world I lived in. But, what if it does match a much wider world that still serves the huge need for server side generated, shorter session web sites vs. high engagement, long session, single page web applications? Maybe good old Rails is still the fastest and best solution to that problem and a great solution to many others, and that’s the point?

This past fall I was thinking about devoting my full time and effort into my software consulting business, and I got a great piece of advice to take a free email course from Brennan Dunn called Charge what you’re worth, which among many other things3 urges freelancers to stop calling themselves (X tool or language) freelancers and position their value based on the end results you can create for people – something which is a key insight for way more than just consultants.

While I didn’t take that path as my main focus, I have gone so far as to fully shift my primary day job role from software engineering to product management. However, I do still have a burning need to directly make things. And so, my toolbox still has to evolve to help me make those things.

The question I’m asking myself and other makers of software these days is: what are your favorite tools now? What is the next tool you are looking to learn how to use? Now, what are the things you can make with those tools that you couldn’t before? I want to hear everyone’s answers to those questions – and the more I tease that question out, the more I think there might be an underserved community on the other side.

If this resonates with you, email me. I think there are more of us than you might think, and we might be able to help each other and our friends and colleagues build better things.

  1. Such as when our band actually used to play more than once a year, or at all.

  2. A brilliant “duh” concept introduced to me in a link from this post by Matt Swanson

  3. If this sounds interesting to you, I urge you to take the course rather than taking away my butchered one sentence summary.

Swing and a Miss

If you’ve been paying attention to some of my recent writing you may have noted a more downbeat and reflective tone. The open secret behind a lot of this reflection is that the business I co-founded has stopped operating and is shutting down.

Naturally, this was a really big disappointment for all of us. Rationally, I know I will almost certainly have worse days in my life, but the way I felt the day we had to break the news to our team that we were out of money is not something I want to experience ever again. It felt like I’d let everyone down, from our investors and service providers, to our homeowners who spent their time and money with us, right on down to the dogs who wouldn’t get to spend days at our office anymore.

After a little bit of time, I don’t feel ashamed of the failure or have a desire to whitewash our story. We have no need for flowery “sunset” euphemisms. We took a big swing, and we didn’t connect.1 The disappointment lingers, but I have a big sense of pride in what we built, our culture of communication, speed, and continuous improvement, as well as the hard problems we were able to attack and make a dent in before we ran out of fuel.

I think calling attention to lessons learned when things don’t go as planned and the practice of writing post mortems is just as valuable as hearing the success stories that inspire us to take those big swings. Jim’s version of ours is here:

This is the End – Haven Post Mortem

It’s a really succinct summary of the many factors that led to us not being able to make the business work. The biggest lesson not spelled out in that post that I’ve internalized is one that’s really painful as a “product guy.” It was a line I’ve heard many times but didn’t really and truly understand until recently- the market is way more important than the product.

I can link the famous Mark Andreessen post but hopefully most have read it already. I did way back when, and didn’t learn the lesson, but it’s so blindingly obvious in retrospect. Even the best product in a market that isn’t good enough or isn’t ready will still fail to generate a sustainable business.

The iPhone is arguably the most successful single product in history not purely because Apple states that its mission is to make great products, it’s mostly because the smartphone market is maybe tied with railroads as the greatest market in human history.2

I still believe in creating great products — it’s the main thing that motivates creators. But, I have a new passion for minimizing wasted effort starting with laser targeting the right market first, then building the best possible product that fits that market, and making the iteration cycles take as little calendar time as possible.

I do still have a perfectionist instinct to indulge by making the things that I’m proud to share with others, but in the future I will make sure it’s a labor of love first and any business that comes out of it is a bonus.

In the end, my Haven stock is not going to make me wealthy and I do not have an “exit” on my resume. But, compared to the opportunity costs of a more comfortable job or a bigger salary, I believe the last few years with Haven and what is now SmarterHQ before that have given me an education I couldn’t have gotten any other way. I’m excited to leverage that hard fought knowledge and learn even more in what I do next.

One of our Haven lunch and learn speakers3 said something that really stuck with me. I don’t remember the exact quote so I’ll paraphrase:

This is not a line of work that has a high probability of success, but nobody here is going to starve. If you stay in it long enough and learn enough, you’re probably going to be successful.

It may take me a year or five or ten, but if I’m fortunate enough to stay on this Earth, I see myself taking another ride on the founder rollercoaster. There’s always more to learn, and there’s no better way to learn than by doing.

  1. Maybe I can use this metaphor to get my twitter circle to start arguing about hitting a home run vs. a major league pitcher vs. hitting a hole in one from the tips on a PGA tournament par 3 again.

  2. Almost all of this particular point is I’m sure cribbed from / better articulated by the brilliant Ben Thompson of Stratechery whom you should be reading and subscribing to if you are interested in the business of tech.

  3. Another thing I think we did way better than any other version I’ve been a part of in the past

My Couch Is Nerdier Than Most

Having a laptop or a tablet on the couch while watching TV is of course not a new thing. As soon as portable computers shifted from something that looked like a suitcase to the trackball sporting beasts of the early 90s, people have been participating in the dual screen experience. Lately however I’ve taken a new approach to partially reclined computing that I’ve been enjoying.

A pain in the neck

A couple of years back the consequences of 25+ years of hunching over in front of computers caught up with me in the form of some severe neck and back pain. This forced me to not only get a bunch of treatment, but also to really think about my posture and ergonomics in every daily situation.

One consequence of this stretch of time is I had to give up using a computer for anything more than a few minutes if it didn’t involve sitting or standing up straight in front of a screen at eye level. Not really something that’s compatible with a laptop on a couch.

My solution was to just not use a computer unless I was seated at my office desk with the full complements of my fancy chair and all the proper adjustments. Otherwise, any other electronics time was conducted exlusively via phone or iPad, and was mostly passive reading or messaging.


Over time, I’ve been mostly happy with my “OS X downstairs, iOS upstairs1” approach, but I’ve been more recently motivated to try something new. I have a wonderful girlfriend and a menagerie of pets that I would like to not be secluded from, but many things I like to do call for a good deal of typing, and I would like to do so without injuring myself.

That, and I wanted to be able to quickly and easily type incomprehensible gibberish reactions during Colts games in front of my big dumb plasma television.2

It’s alive

On a whim, I MacGuyvered a solution from things I mostly had lying around. The most important thing for me is being able to look at a display at eye level so I can avoid hunching over.

So, starting with my beloved iPad Air 2 I mostly use to read, I acquired a cheap adjustable arm, attached it to our always handy C-table, and paired up a salvaged bluetooth keyboard. Then, it was off to the comfortable typing races, with the added bonus of being able to quickly and easily dissassemble and stash away my weird looking monstrosity.

Kinda looks like screwball Daffy Duck if you squint

iOS 9

The thing that really makes all this work is the expanded keyboard support for iPads in the newly released iOS 9. Just the ability to cmd+tab between apps and cmd+space spotlight searches almost makes me feel like I’m right at home on a mac. It’s not quite 100% there, but it’s way better than other attempts I’ve made in the past. Often I prefer the more constrained approach to multitasking, especially when I am most likely already doing so by looking at a big screen in the first place.

But what does it do

I won’t lie, this is mostly a thing that will get heavy usage for chat slinging and checking fantasy football scores on fall Sundays, but I am intrigued at having another set of tools at hand to write with.

Right now it would be hard to make a complete end to end post to this site due to the way it’s built, but coming up with an easier process could be worth exploring. Either way I can type, and stringing words together is 99% of the battle anyway.

Another pipe dream is being able to write up some quick code from a shell or even something like Coda for iOS, but I’m probably way too picky make that work. But who knows, obsessing about only using just the right tools is something I’m trying to do less3.

I’m also interested in trying more things I would only consider doing on a traditional computer with this neutered robo-giraffe setup. Some interesting people seem to like creating things mostly on iPads. Maybe I will too. Clearly I don’t mind looking silly in the process.

(This post includes affiliate links.)

  1. Alternatively- business in the front; party in the back

  2. One of the last production runs panasonic did :(

  3. Which I’ve of course proven by writing 800 words about some tools I use.

Riding the Rails, Backwards

Recently I’ve been getting the opportunity to work with / help out some software companies that base their tech stack on rails. Now, languages and frameworks are all just tools, and one doesn’t necessarily have to be an expert in the tools to be able to make a material contribution to shipping a product.

But, in order to truly be helpful, one should probably be able to “swing a hammer” and have a good grasp on the mechanics and most of all the philosophy and approach to leveraging the tools.

Wait, you don’t know rails?

Sadly, no. I read the pickaxe Ruby book in 2005 right after I graduated from college, but that was around the time got a job for a company that did all its development in .NET, and during that time of my life the primary tool I was interested in spending my personal time mastering was the guitar. So, what software tool skills I developed remained mostly in that sphere until much later.

However, Rails was deservedly the poster child for the growing consensus around how data backed web applications should be built – the smash hit that launched a thousand frameworks. Frameworks I ended up learning in my previous life as a .NET developer and then as I became more and more a Javascript expert on both the client and server side, and informed choices in the tools I was using to structure my node/express and client side MVC code.

All aboard

So, while the concepts at play are very much an old, familiar hat, this particular set of tools I’ve only ever admired from afar, and my astigmatism doesn’t help. Time to get up close and personal.

At first, I thought maybe the quickest way for an experienced developer to get up to speed on the philosophy and approach of rails was to watch a video course. I have a pluralsight trial and a lynda.com subscription, so I went to both of those and started to dive in.

While the intro videos gave me some of the philosophy, the material was targeted way, way below my web development experience level. I needed something I could move through more quickly.

Getting Started

After some more googling around, and deciding I didn’t want a full book, I went full bore into the official Getting Started With Rails guide. Overall, it was a good intro to the framework, and provided a very decent overview of the simple MVC mechanics and how things are laid out. I was able to connect a lot of the dots and see the lineage of a lot of other things I’m familiar with from .NET MVC, express, Angular, and the like, and like a good student I completed the exercises.

What’s Missing / What’s Next

The problem I am running into while I look into the best resources to help me get up to speed effectively is that a lot of guides / tutorials I run into seem to be targeted towards a web development world that I don’t live in anymore.

The server side aspects of web development for me now are mostly about exposing a set of JSON based apis for client applications to consume, whether they are Javascript based web frameworks or native mobile / client apps. Good old static pages with some forms and javascript for flavor still have their place, but that tent is rapidly shrinking.

Javascript, whether you love it or loathe it1, is where most of the action is in terms of providing the surface area for users to interact with web apps. Really what I need is the ability to get up to speed on using rails to most effectively provide a set of APIs – CRUD is great, but based on my recent experience sometimes more tailored verbs are called for on API routes.

I’d love to find resources that help me get up to speed on the API focused approach so I can focus whatever other software tool based learning I do towards moving data around on the back end in the right way before it gets turned into JSON, and towards tools and conventions that help to build better client side applications both on the web2 and natively3.

I do think ActiveRecord is something I should dive into and understand fully, and I absolutely need to re-familiarize myself with the details and patterns of ruby the language, and especially understand how to do concurrency well in a rails context.


If you’re reading this somewhat recently after it’s posted and you are a ruby / rails expert, please do point me to the resources you think would be the most helpful for me at this stage. I’m in sponge mode but want to get the most bang for my time spent. Email away to craig @ this domain or tweeter me at @craigsturgis. I’ll owe you a coffee!

  1. I fall a lot more on the love side of it now that I use it mostly as the functional language it is and will even more when I can use ES6/2015 everywhere, and that day is pretty much here thanks to Babel and the like.

  2. I’ve enjoyed my dive into Angular, but React really speaks to me and I’d like to explore it more, not just because it’s the new hotness but the parts of Angular that chafe a bit seem to be addressed by React/Flux. We’ll see

  3. Dabbling in native development has been both invigorating and frustrating. But, I’m most interested in building great user experiences, and being close to the metal is a great way to be sure that no limitations will pop up to degrade that experience.

Craigslist Literature: Aeron Edition

When I post anything that’s not completely boring or straightforward for sale on craigslist1, I decided to try to add a bit of extra flair to my listings. If nothing else, to try to entertain people who might see it, and at best increase my chances of selling the item. This was my first attempt, and the chair sold today!

Wounded Aeron Chair Seeks A Better, More Mechanically Inclined Partner – $200 (South Broad Ripple)

I used to be so majestic.

I was a shining example of that most famous of office chairs, the Aeron. The crown jewel of Herman Miller’s eye, bringing joy and ergonomic fortitude to the backs and hind parts of the beleaguered office worker.

I was as flexible and supportive as any chair could be, until for reasons I’ll never understand I wasn’t enough. I was unceremoniously shipped off into the secondary market where I joined a group of my brothers and sisters in a lot put up for sale on this very website.

And that’s when I saw him – my new partner who took his time sitting in each and every one of the chairs – passing up the other brand new upstarts in the shop for old reliable me. I was the pick of the litter. My second act was about to take flight!

But the honeymoon did not last. I remained supportive as ever but my lower half was not as strong as it used to be, and I could not stay adjusted to the new height required to be ergonomically stable. And so I was relegated to the sidelines once again, awaiting a shipment of a hydraulics replacement kit.

When the day arrived for my surgery, I was apprehensive, but looking forward to getting back in the game. A couple of pdfs and some youtube videos later, and I figured it would be smooth sailing with all this support information.

The surgery was not a success. Despite clear instructions from all over the internet my new owner was not good at removing my well implanted seat screw, and ended up breaking out the screw housing completely. Also, despite his best efforts, he could not figure out a way to remove the hydraulic assembly that was the main reason he took me apart in the first place! I do not think he is as mechanically inclined as he thinks he is.

So, now I sit, in pieces, hoping for the day when somebody who actually knows how to properly assemble a chair will come and rescue me. To add insult to injury I had to watch as another more functional chair was wheeled in as I sat broken in the corner, a refugee from the island of misfit chairs.

Please, if anyone out there is not a complete failure at chair repair, you can have me and my $79 hydraulic replacement kit for one low, low price. I’ve still got so much love and support to give!

  1. I colloquially refer to craigslist as “my list”

I’m From the Future

I’ve had the occasion to be doing a lot of reflection on the past year and a half recently, on helping start a business, on running a development team, on being the primary person in charge of managing a product – all things I had never really done completely on my own before1. I’ve tried to focus on mainly on crystallizing what I’ve learned from those experiences, but the question “what do you regret” has also been rattling around in my head for quite a while, and has been asked of me directly more recently.

Human beings like to lean on pattern matching when evaluating their experiences and think it would have been easy to make better choices given more information, but by coincidence I’ve been finally reading through The Design of Everyday Things and it’s been helpful in giving me pause when doing this. Its description of hindsight was alone worth the price of the book, and the examples of how simple and easy it can make things seem when many factors that led to a strategic mistake can be glossed over. Luckily our mistakes did not lead to a life threatening situation like the ones described in the book.

There are many things I would do differently if I could travel from this moment back in time to the beginnings of the company2, but the present version me has that gift of hindsight. If I had to convince past me to carry out things differently, I’m relatively sure that my previous version wouldn’t have been ready with the tools or the understanding to follow through on the instructions even if they were listed out step by step3. Only now do I feel like I have the tools to do what should have been done to have a good shot at success the way I presently understand it.

Of course this is not some radical new theory, but that’s the point- you can take in all the advice and read all the books and do all the case studies you want, unless you are truly a phenom or truly lucky, many lessons can’t sink in until you live them. The content is not nearly as effective without the context. Whether you need somebody to yell at you or not, doing something is the most effective way to learn it, whether it’s a failure or a success.

It’s a big thing that motivates me to continue finding ways to challenge myself – if I look at code I wrote months ago and I’m not at least a little bit disgusted, I know I’m not getting better. If I don’t look back and think about how I could have approached a situation in a better way, I know I didn’t challenge myself enough.

Some mistakes are unavoidable, and even in success, hindsight should be there. But I try to incorporate a philosophy of continuous improvement and put systems in place to help make sure to confront where things could and should be better. Awareness of the biases and emotions and stresses that can affect our decisions is not sufficient to avoid being negatively affected by them.

I continue look forward to future me continuing to smirk at how naive current me was. The day I don’t want to travel back in time and knock some sense into myself means I’ve lost the drive to get better. That would be a true failure.

(This post includes an affiliate link.)

  1. My 1999-era computer building business does not count

  2. After the obligatory time traveling Hitler assassination

  3. Alternate timeline Biff Tannen still had to figure out how to parlay his money into dystopian power on his own.

Developing Product Management[0]: Starter to Finisher

Among the first things taught to students studying physics are Newton’s three laws of motion, the first of which (paraphrased) is that an object in motion tends to stay in motion unless acted upon by an outside force.

Many people struggle with being a starter and not a finisher on any number of projects, and can’t keep things in motion. Countless github profiles are just like mine on the public facing side – a few repositories created or forked with good intentions, but that don’t end up amounting to very many finished products if any at all.

This of course is not specific to open source contributions. Inertia is something that has loomed large for me over the last couple of years, in trying to build a business, in doing my job as a developer, and especially the not insignificant amount of time I’ve spent trying my hand at product management.

Coming at product management with a developer’s background and mindset has been one of the biggest challenges of my career, but it has also taught me quite a bit that I plan to write about as part of a series of posts.

First – how can I apply what I’ve learned doing product management to leverage inertia in my own personal projects, especially those that rely almost entirely on instrinsic motivation to stay in motion?

Personally, the biggest thing that tends to kill my projects is a perceived lack of progress early on, which leads to discouragement, which leads to an object at rest; a stone gathering moss.

I don’t believe anyone starts any project without some sort of plan – but how much of that plan lives completely inside the person’s head working on it?

As I’ve quoted before, writing is thinking. Getting the plan for what needs to be done into a tangible form has multiple benefits, not only leading to better definition, but also making it easier to gauge progress.

The suck threshold is a very important concept when producing any product, but it also applies to the process of producing something as well – the more quickly one feels like a badass, the more likely it is that momentum will be conserved.

The tools used to make a tangible plan don’t really matter. I’m partial to using Trello thanks to its flexibility, but plain old paper, a whiteboard, a spreadsheet, or even Microsoft Project1can be made to work. The key is to find the right balance between between getting enough of the plan in a tangible form to give yourself a road map without spending so much time planning and defining that the momentum of producing is lost.

Once the high level things are understood, more detailed definition is definitely helpful, but even if just one detailed task is broken out of the larger plan and completed, that can be enough to get the momentum going on to the next one.

Common pitfalls and bad habits I run into are screwing around trying to decide what set of tools or technologies to use to accomplish something, or spending so much time trying to learn the tool vs. accomplishing something. In the case of software, things like yeoman generators and the like can help get a project moving faster without fiddling with the setup. I also find it helpful to keep this thought in mind: “what is the primary goal?” Is it to learn how to use a tool2 or to produce a good product?

Even if the market for that product is only the person making it, staying reminded of what it means to finish something makes it way more likely that the endeavor will result in a finished product. The more of those you have, the easier it is to keep the stone rolling and being confident in being a finisher vs just a starter.

Postscript: Now, to practice what I preach. My overall plan for this particaular series of posts is to cover more abstract topics from this perspective, mixed in with specific examples from real personal projects which I will be posting as I go, some as open source software.

(This post includes an affiliate link.)

  1. Note: I’ve never used this piece of software. It looks like not much fun to me, but ¯\_(ツ)_/¯

  2. A completely valid answer!