Learning and mastering isn’t the same

When I first began making applications for the web, getting started was hard. Just figuring out which components to download, how to configure them, and getting Hello World through it all was a daunting affair. Frameworks like Ruby on Rails changed that, and now it really is possible to animate a complete database-backed web application in 15 minutes or less.

That means these days you can go from (almost) zero prerequisites to a (sorta) working software prototype in a bootcamp’s worth of introduction material. That’s amazing. Basic proficiency has never been more attainable or approachable.

Given this leap, it’s no wonder that people mistake the beginning for the end. That getting started is the same thing as knowing it all. But it remains a completely unrealistic expectation, and thus a mistake. Building a complete information system, like, say, your Basecamp or Shopify or GitHub or Zendesk remains real work that requires deep skill. It’s foolish to pretend otherwise.

And perhaps we have pretended otherwise at times. I’m certainly guilty of focusing on just how easy we made getting started that the conversation often didn’t extend to the work it takes to finish. Simply because that’s what felt like the main obstacle to getting more people onto the path of learning at the time.

Now that this obstacle is mostly cleared away, it’s time to focus on the latter part of the discussion: Becoming really good at anything takes time. Web development is no different, not even with Rails. We’ve changed the game from “hard to learn, hard to master” to “easy to learn, hard to master”. Yes, the second part remains the same.

I’m still learning. I’m still getting better. And I’ve been at this web development game for damn close to twenty years (if you count when I started dabbling with HTML/CSS). That doesn’t at all mean it’ll take you twenty years to become good at it, but it probably does mean that you should have realistic expectations about what you can learn in three or six months.

And it’s not so much about how long it’ll take you to learn your way around the framework or the language or the ecosystem. It’s as much as how long it’ll take you to become an expert. It’s one thing knowing there are 10 different ways to do a thing; it’s another to know which is a better fit and when.

This is part of why I like to compare writing software with writing prose. Most people in the developed world will have basic proficiency writing their native tongue by the time they finish high school. But how long does it take to become a great writer? Longer than that. Much longer, in most cases. Few find that surprising.

Yet plenty of people do seem to be genuinely surprised that a developer who just picked up Ruby on Rails, or any other extensive framework, language, or ecosystem, doesn’t make all the right choices the first time they’re faced with them. And that’s just plain silly.

Let’s continue to celebrate how easy we’ve made getting started, but let’s also set a realistic timeline for mastery. Not to scare anyone off the journey, but to prepare them for it. A glorious, years-long journey of learning. It’s a lot of fun if you know what you’re in for.

Focus on the right things

Yup, Goals = Focus

I’ve worked for large companies and not so large ones. Each one had goals set out as reminders of what we were all striving for. We hear about goals all the time and it makes sense to put some focus around what everyone’s working toward. To give it more meaning. To give us something to rally around and use as a guide post.

However, when, after a little over a year of being our own company, we were asked to put together some specific goals here at Highrise, we grumbled a bit at the task. We know what our goal is. It’s to grow the company. To get more users and fewer cancellations. We were already looking at metrics, growth, revenue, traffic, and on and on.

And there’s so much to do. Literally hundreds of different choices of features or marketing or upgrades we could do that may or may not impact those numbers in a way that means something. Does it really make sense to take time away from all of that?

But, then maybe that’s just the time to take a step back and make sure we’re focusing on the right things.

So we set out on the task. It was a bit daunting. There are oodles of metrics we could be tracking and improving. But after combing through dozens and dozens of options, and more importantly looking at benchmarks from other apps and our past performance, we picked 4 metrics we wanted to improve and monitor. And we established some goals where we want those metrics to be by the end of the year. We also created some specific monthly goals on how we would achieve that performance: X number of marketing creations, Y number of experiments, Z number of new features or improvements.

Then after tracking and reporting our performance for a couple months, we were asked: Does it feel like these goals are helpful? Are they worth it?

Remember that grumbling we did? Well, once these goals and metrics were in place our CEO, Nathan Kontny realized the following:

These things are very much helpful. Every decision is now filtered with these things in mind. And getting the whole team thinking along these terms.

For example: we were having a meeting with the team about a month ago talking over that we were behind in some of our quantity metrics (marketing things posted, etc.) and one of our developers was the one who mentioned why aren’t we sending out 2 email campaigns a month vs. just one. Which got us thinking along those lines: why aren’t we doing some more email marketing. Right now our emails are just feature announcements, but it doesn’t have to just be about that.

So now we’ve upped the frequency of our newsletters, and started spending more time writing up Case Studies, How-tos, and interesting customer stories in our newsletters.

That’s had a nice impact! For example a recent post from Lynette was a top traffic referrer. She wouldn’t have even written it had we not had some specific goals laid out to see where we were behind and needed her action on.

Also our users have been very receptive in their feedback to us of now getting email about how to use Highrise, not just news about features.

And it’s got everyone focused on projects to raise our stature.

It’s pushed me to get more writing/content projects done like my contributor position now with Forbes. Chris, on customer support, is writing more articles. Even our contractor is open sourcing stuff for us which is having some nice uptake.

When we do planning, we know to be more careful going too deep with certain features and rabbit holes, if it means we’re sacrificing time we could be putting towards these marketing and traffic goals.

And as for quantifiable effect, it’s still early, but that slow decline in traffic that’s been going on for years now seems to finally be halting. And that’s in large part because we talk about these marketing goals constantly.

So yeah, it’s worth it.

P.S. If you need help keeping track of your goals or who you talk to and what you talk to them about, please take a look at Highrise. It’s a simple tool to manage your communication with others.