Category Archives: Startup

You Don’t Need to Attend a Prestigious School to Network Well

I spent my first two years in higher-ed at our local community college, followed by two more at the University of Maryland (UMD), where I earned a bachelors in computer science. Both schools ranked okay nationally–especially for public schools–but I got grief from certain life advisers at the time for not attending a more prestigious school, like Carnegie Mellon or MIT.

I valued my family and friends too much at the time to move away, and I didn’t want to accumulate crippling debt. I was inclined to stay local. One thing I weighed losing out on was the ability to rub shoulders with future leaders. Being a commuter student who lived an hour off campus meant I would be spending most of my campus time in class, at the library, or in the computer lab. My classmates and I weren’t the best at networking. It simply wasn’t in the undergraduate CS culture at UMD.

I appreciate the connections I made while there, while also regretting not taking more advantage of the time I had with them or seeking out even more connections. I have learned since then that I didn’t need a prestigious school to network well. Several of my former classmates or schoolmates I met for the first time in industry years after graduation. We compared notes, figuratively, and realized we were in many of the same classes and even had vague recollections of each other. They have been great coworkers, advisers, and friends over the years. They are leaders at significant organizations. And I’ve had the fun of seeing them run circles around people who attended more recognized schools. Here’s just a smattering of examples:

  • Patrick Joyce, Director of Engineering at Stitch Fix
  • Jeremy Rickard, Staff Engineer at VMware
  • Ben Tedesco, Senior Consultant at Carbon Black
  • Nicholas Tedesco, Senior Consultant at Microsoft
  • Salman Haq, Engineering Manager at Capital One
  • Min Kim, Engineer at InstaCart
  • David Potsiadlo, Principal Product Designer at Main Street Hub
  • Kevin Conroy, Chief Product Officer at GlobalGiving
  • A co-founder at LivingSocial
  • And another I reconnected with at a private event at Skywalker Ranch

I have a wealth of connections and friendships that I’m extremely grateful for–all who attended the same public school I attended.

I’m not belittling prestigious schools in the least. I’m simply encouraging us all to get past the stereotype that to make significant professional connections you have to attend a prestigious and expensive school. Don’t limit your opportunities like I did those two years; you’re probably just a few feet from greatness.

Advertisements

Continuous Delivery, not Continuous Deployment

Engineering teams like Etsy’s have popularized the idea of continuous deployment: infrastructure that automatically rolls-out newly minted code to production in a safe and gradual manner. In Lean Startup and Web Operations, Eric Ries explains the rationale behind continuous deployment: making a safe habit out of shipping product. I loved the motive, but it was clear that the practice as described required heavy operations infrastructure:

  • A continuous deployment server for automatic deploys after successful continuous integration runs
  • Live monitoring to discern if a code change negatively affected business metrics
  • Automatic rollback if business metrics are negatively affected
  • Incremental rollouts to production servers so as not to deploy to all servers at once
  • Code architecture that allows for both old and new code to run in production simultaneously while code rollouts are in-progress
  • Feature switches

While leading a team at LivingSocial, I set out to achieve the goal of safe code shipping as a habit but without the complicated and time-costly infrastructure. We were successful by incorporating good software engineering and deployment practices–all of which were generally good for us and didn’t require as much dedicated tooling or time. Later we discovered others outside the company were starting to do the same under the label “continuous delivery.” We have been even more successful with continuous delivery at LearnZillion, where I am today.

Unfortunately, the cost of continuous deployment infrastructure can discourage engineering teams from investing time in their development and deployment process because they don’t realize the lower-cost alternative, continuous delivery, is also a viable option. I want to share how we do continuous delivery at LearnZillion, so that others can achieve similar results without the overhead of extra infrastructure.

0. Assumptions

I am going to assume the year is 2015, or even 2010 or 2006, and that you have a deployment script or tool like Capistrano to automate the basic deployment steps for your application. As well, I’m going to assume your team or organization wants to do continuous delivery. If neither of these are in-place, start with them.

1. Individual responsibility

Although we work as a team, individuals are responsible for carrying work forward to completion and doing that well. Staff are responsible for taking features from initial definition to production shipment. Along the way, they collaborate with and incorporate input from the broader team and company. (See Multipliers and Drive for reasons to give employees meaningful responsibility in the workplace.)

With these responsibilities come expectations:

Do not break the site. Do not break features. Do not break the test suite. Do not commit code you did not write (this is a smell of a bad development database on your machine, failed merge, etc.). Run the tests regularly–especially before merging into the master branch. If the master branch code changes in-between your test suite run and your re-attempt at commit, run the tests again after cleanup, as appropriate.

Unfortunately, I have found that in many organizations, lack of trust is the default. A tech lead or manager is responsible for scrutinizing code from all team members, merging, deploying, and ensuring the application won’t break. This may make sense for new team members until they understand and are comfortable with the team conventions and have demonstrated that they are capable engineers. Otherwise, it should not be the norm.

2. Smallest overlap of responsibilities

We often pair a product designer (design, UX, HTML/CSS) with a full-stack engineer (SQL, Rails, Ruby, JavaScript, HTML/CSS) to work on a feature. However, we avoid assigning multiple engineers the same feature. We try to keep engineers working on “orthogonal capabilities.” (See “The Three Musketeers” and The Mythical Man Month for the rationale behind this approach.)

3. The master branch is sacred

We deploy to production from our master branch. Developers can depend on master as a reliable foundation to fork, merge, and rebase from. Features are developed, reviewed, and QA-ed in separate branches. If you have test failures, it’s most likely your code. Feature branches are only merged into master immediately before deployment. It is the responsibility of the feature owner to make sure the branch is reasonably current with master before it is merged itself. There are loads of articles on “simple git workflow,” which you can find online, like this one. git and GitHub make this paradigm easy to follow.

4. Follow “The Twelve-Factor App” methodology

I will let the methodology speak for itself. See part X in particular. The biggest continuous delivery benefit is no surprises during deployment.

At LivingSocial, my team ensured the application development environment behaved like production, except where Rails intentionally separates the two. Truth be told, we didn’t have a reliable staging environment at our disposal, so we went straight from development to production. Believe it or not, because of our practices, this still worked quite well.

At LearnZillion, we take this further by using similar SaltStack configurations for production, staging, and a Vagrant-powered development environment. In development, the Ruby process and gems for the app are still installed on the host operating system but everything else runs inside VirtualBox. It has the side benefit of speeding-up the on-boarding process for new engineers.

5. A test suite

At both LivingSocial and LearnZillion, we used Ruby on Rails, which strongly encourages use of a unit testing framework. Engineers make certain to have a passing test suite before merging a branch into master, must have a passing test suite on master post merge, and a failure on the master branch takes top priority–second only to a live site outage.

At LearnZillion we took this farther by integrating CircleCI with GitHub to minimize the execution burden on engineers.

6. An automated QA test suite

At LearnZillion, we have a QA team. They naturally have the potential to be a bottleneck for getting features out. Since quality is their main objective, you want them to be gatekeepers. What you don’t want is for their review and gatekeeping processes to be cumbersome or inefficient. The most powerful lever you can maneuver within your QA team for continuous delivery is to automate their testing. Our team has an extensive QA test suite, which QA engineers can run against any branch, at any time, on a staging server. Automated tests are usually written soon after deployment to production, but sometimes are completed before then. Manual QA of emerging features still takes place, of course.

7. Look at your dashboards

It doesn’t take much effort to have a short list of links to Google Analytics, Mixpanel, or your error reporting service like Bugsnag or Honeybadger. An engineer can inspect them after deploy to see if something broke. Engineers and product designers should be doing this anyway to see how users are responding to changes or new features.

Bonus 1: Manual QA in a different time zone

When an engineer’s code has passed peer review and the automated QA test suite, it is sent along to QA for manual inspection. Test results are back by the next business morning because some of our QA team members are located in India. They test our work while we sleep.

Bonus 2: Continuous QA

At LearnZillion, we’ve integrated a GitHub pull request web hook that deploys a branch to a staging server and runs the QA test suite against it. This means that a branch has been regression tested before it gets to the QA team and usually before it gets to peer review. If you want to read more about our automated QA process, see Kevin Bell’s article about us over at CircleCI.

In Summary

With the good engineering and deployment practices of continuous delivery, you can achieve the same benefit of continuous deployment: safe, consistent delivery of product as a habit. You don’t have to build-out a dedicated infrastructure, and you can build a better engineering team and environment in the process.

Looking for your next gig?

If this sort of engineering environment is appealing to you, and you are interested in being a Senior Software Engineer or Senior Product Designer at LearnZillion, please apply. We would love to meet you.

[Thanks to my team for reviewing this post and recommending improvements to it.]

Google Analytics Crash Course Notes

Thinking that you will adequately learn Google Analytics by clicking around the product, even over years, is a foolish concept. You will only understand a subset of its features and how they work together. You need to do your homework.

I cannot improve upon Google Analytics’ (GA) own crash course, titled Google Analytics IQ Lessons. It covers just about all the material in the paid Analytics courses (101, 201, and 301) at just the right level–not too high, and not too deep.

Here are my notes of the key gotcha’s and items to configure for your GA Web Properties. As well, I’ve linked to other helpful learning resources. As is my standard practice, this is mostly for my reference down-the-road, so it’s not comprehensive. However, I figure others can benefit from them as well.

Gotcha’s

  • Incognito mode and other browser privacy sessions count as new Visitors, Visits, and Page Views, as if the user had cleared his cookies. Not a huge surprise to most, I’m sure. (Although other trackers can still track you.)
  • Visits are separated by exits from the site or a 30-minute cookie timeout while on the site. Advertising Campaign attribution expires after a 6-month cookie timeout. Both are customizable.
  • Time on Exit Pages is not tracked because time is calculated between page loads on the same site. This also means that Bounce Page time is not tracked either. This has serious implications for some genres of sites, like blogs where a bit of traffic goes into and out of a single article. Know how to track Exit Page times and Bounce Pages, if you need to.
  • A Visitor can only trigger a Goal conversion once during a Visit, but can trigger an E-commerce Goal multiple times in a Visit.
  • Filters are applied between raw data capture and the Account’s Profile where the data is ultimately stored. Even if you change a Filter that sits in-between the raw feed and Profile, you cannot recover historical data. Try accomplishing the same filtering with Advanced Segments instead, which don’t run the risk of losing data. At the least, you should use Advanced Segments or other features to test concepts before creating a real Filter for them.
  • Domains and subdomains can break tracking in many glorious ways–especially E-commerce Goal tracking.

Basic Checklist

  • Always have a raw Profile that has no Filters, Advanced Segments, etc.
  • Have a Profile that excludes internal IP address so you’re not tracking yourself and your staff as they click around your site.
  • Have a Profile that exclusively tracks internal IP addresses for debugging Google Analytics code on your site.
  • Use the Google Analytics Debugger Chrome Extension for your own debugging and analysis of competitors’ tracking.
  • Enable Auto-Tagging between Google AdWords and Analytics if you are using both products.
  • If you create an AdWords Profile, set up two Filters to focus-in on AdWords traffic (Campaign Source: google, Campaign Medium: cpc).
  • Set up E-commerce tracking.
  • Set up Goal tracking.
  • Set up Internal Site Search tracking. (It’s much easier than you think.)
  • Utilize _addIgnoredOrganic to attribute Organic Search Visits for your web site’s address (i.e. someone searching for “example.com”) to a Direct Visit instead.
  • Set up appropriate Custom Variables to track additional information about Visitors, Visits, and Page Views.

Hopefully, all these will help us do a better job optimizing our customer average lifetime value (LTV).

Team Debt

I’m currently having a blast leading the technical team behind the LivingSocial Takeout & Delivery web site. One of the challenges of a growing team is maintaining appropriate amounts of communication. You want everyone to know everything that’s important, but not everything. Otherwise, you end up being a case study in The Mythical Man Month.

Although our team did not follow this plan when it was ramping-up, hindsight reveals the need for a team debt management strategy as it grows. After mulling over it for awhile, I’m fairly sure that if I lead a new team in the future, we will follow this path:

First engineer to join the team

  1. Sets-up the source code repository
  2. Writes a starter project README
  3. Provisions the application and team notification email addresses
  4. Wires-up application notification email(s)

Second engineer

  1. Sets-up the continuous integration (CI) server
  2. Provisions the CI notification email address(es)
  3. Wires-up CI notification emails

Third engineer

  1. Sets-up the team’s Campfire
  2. Wires-up commit and deployment notifications (Campfire and/or email)

Fourth engineer

  1. Sets-up a scrubbed production database dump that engineers can use for local development

What tech team debt tools do you typically employ, and when do you employ them?

My Startup Lesson Learned

A few years ago, I quit my job to build a bootstrapped startup called SandwichBoard–a content management system for restaurants. Patrick Joyce and I put $5,000 into the business and made a leap of faith to live off savings and occasional consulting gigs.

After we got the sales routine down, we were growing at a steady pace, but not early or fast enough for our personal lives. We both really wanted to marry our girlfriends. We needed money, and ultimately had to ditch the bootstrapping salaries. I was elated to be marrying the woman I had been waiting for my whole life, but throwing-in the startup towel felt like a huge loss. It was something I had been working towards for a long time, but giving it up to marry my wife was the best decision I ever made.

Now that I’ve had time to reflect on what went well and what didn’t, I have my own list of lessons learned–things I would do again or make sure never to go near when building a business or product. But you’ve already seen that sort of list before. Instead of dumping a bunch of do’s and don’ts on people, I would rather leave them with an encouragement–one that will give someone else the courage to take that leap of faith.

My lesson learned: even though the startup plane may come to a fiery end, the pilots have ejection seats.

Our efforts were not wasted. While building SandwichBoard, we became proficient in Ruby on Rails, resulting in a great product and more than two significant open source contributions. This helped land Patrick a position at a company called Hungry Machine and me a job at Razoo. Taking that risk propelled us from working typical IT jobs into the startup world. I’ve had fun just about every day since I took that leap of faith, become a better engineer at an accelerated rate, been able to work with incredible people, and turned that savings loss into a short-term investment.

Patrick’s employer renamed itself LivingSocial, and his first major responsibility was to develop a small site called LivingSocial Daily Deals. (Maybe you’ve heard of it.) I rejoined Patrick this July and am leading the technical team responsible for building LivingSocial’s latest local-commerce product: Takeout & Delivery–restaurant takeout and delivery ordering (currently only in Washington, DC). It’s a fitting end to the SandwichBoard story.

Results may vary, but I still think it’s worth a try. Give it a go; jump off that cliff!