Big Bang Technology Blog

Links of the Week 8

2012-02-09T02:21:49Z

This Week: Essential Reading, Testing, Ruby/Rails, Database, Javascript, Design

Essential Reading

The Hacker Way

Essential Reading.

Introducing Chrome for Android

I hope this spurs some competition from Apple. I'd love to use that remote debugging everywhere.

thoughtbot presents: The Playbook

Noticed a bunch of new improvements on the playbook. Very inspiring.

Testing

Decoupling Data from Presentation

I'm not a fan of using data-attributes for this purpose but it's an interesting take. Storing state in data-attributes always seems so non-semantic to me.

Yes, You Should Write Controller Tests!

Yes. Yes you should.

Acceptance and Integration Testing With Kookaburra

I feel like I dreamt about this after reading the same book. This is killer, I can see even non-developers using the Domain Driver.

Ruby/Rails

ileitch / hijack

I'm not sure where I would use this, but I have a feeling I should save it for reference.

josevalim / active_model_serializers

I really want these to be in Rails. In any case I really want to convert our application to use them. Great idea.

assembler / browsernizer

An easy way to inform people that they need to upgrade their browser.

Ruby Trick Shots

Cool tips that you may not know about Ruby.

Database

PostgreSQL by Harold Giménez

Cool Presentation on PostgreSQL. Thanks to @releod for tweeting it.

VIM

Vim anti-patterns

I do basically everything that they say you should not. Slowly...weaning...

JavaScript

Backbone versus Ember Transcript

Long and civil argument between wycats and jashkenas. Very very interesting.

UIkit Modern UI components for the modern web

Some of these components are pretty sweet. I can see myself using them on new projects.

JavaScript Jabber

New weekly JavaScript podcast.

Design

engineyard / engineyard-theme

This is an interesting way to make your theme easily includable in other projects. We're following this approach for our next redesign of Woople.

What's the difference between a dashboard and an activity stream/feed?

Surprisingly interesting thread. Last version of Woople we basically called everything a dashboard. Next version we be much clearer.

Pears

I was a little confused at first thinking this was another html/css framework. It's actually much better, a framework for documenting your framework. Huzzah!

Links of the Week 7

2012-01-31T17:50:33Z

This Week: Testing, Front-End, Back-End, Reference, Teamwork

Testing

commondream/tconsole

Seems like a great way to remove the startup overhead without hassling with the configuration.

Taming a Capybara - Emmanuel Oga's Software and Stuff

More on getting capybara to run smoothly. I'm glad the community is sharing these sorts of things, we're definitely benefiting from it.

The evil unit test

I 100% advocate testing behaviour over implementation. That doesn't mean mocking is bad. It means you need to use it to mock out dependencies.

Front-End

HTML5 Please - Use the new and shiny responsibly

A good way to lookup how pervasive the feature you're about to use is. Ideally you'd just use Modernizr and make your application work either way.

Gettext style i18n for Modern JavaScript Apps

I know of a few front-end heavy projects that should be using something like this.

Color - Method of Action

Another cool game designed to teach developers about design.

Back-End

Inject that Rails Configuration Dependency

I love any article that helps me understand dependency injection more. We've recently started using our config more as we're connecting multiple applications together. This does make testing bothersome. Great tip.

On My iPad

A seriously great list of applications. Fraser is definitely an iPad expert.

PUT or POST: The REST of the Story

Great resource for API developers out there. Are all your PUT requests Idempotent?

My five favourite "hidden" features in Rails 3.2

Some of the lesser known features in Rails 3.2

Reference

Node.js reference

A more readable form of the Node.js documentation.

The Little Redis Book

I'm going to use Redis for something one of these days. Saved for reference.

Teamwork

Scaling GitHub

Zach shows why GitHub is so awesome.

Why Software Development Estimations Are Regularly Off

An fresh perspective on why software estimates are bad bad mojo.

Links of the Week 6

2012-01-23T14:07:17Z

This Week: Movies!, Gems, Essential Geek Reading, Reference, Teamwork

Movies!

Wat

Seriously hilarious. Also an awesome catalog of e-learning videos. Why didn't I know about this sooner?

Gems

acts_as_api

Putting view logic in your model is never a good idea. This is an anti-pattern. Use a presenter to handle this.

Factory Girl 2.5 Gets Custom Constructors

While we heavily use Factory Girl I can't help but think that it keeps getting more complicated. We're relying on stubs a lot more these days.

Essential Geek Reading

The Trello Tech Stack

I love this stack. Although I'm not completely sold on 100% single page apps things like pushState are slowly convincing me.

Distraction is a Symptom of a Deeper Problem: The Convenience Principle and the Destruction of American Productivity

We believe the right kind of distraction is a symptom that knowledge hasn't been properly socialized on the team. Cross team interruptions however are definitely bad.

An object is not a hash

I can see a whole new generation of javascript injection/cross site scripting issues because of this.

Reference

JSRef - JavaScript Reference Manual

Seems like a YARD style reference for JavaScript built on top of the MDN

How to run rvm scripts as cron jobs?

Dave was having problems with this one earlier this week.

Teamwork

visionmedia/git-extras

Seems like there are some good commands in here for working with teams.

Advice for Lean Startup Machine Toronto Attendees

2012-01-18T21:38:08Z

Last year I flew down to Boston with some colleagues and we participated in Lean Startup Machine. I’m not lying when I say it changed my life. All of a sudden, I could separate and connect the theory of customer development from its practice. But more importantly, I was stripped of the fear (and any other excuse) of finding customers and trying to sell them a product.

I also learned a ton about customer development and I've been trying to share those lessons ever since. After that experience, I immediately knew that Toronto needed this event. This year, I’ve been lucky enough to be acting as an LSMTO event organizer and participate as a mentor. And because of my prior experience attending as a participant, I’d like to share what I learned last year so you can make the most out of your weekend.

Joining a Team

This is the first big decision you’re going to make when you show up at LSM. A few people have asked me if they should try to pitch the idea they’re working on, or if they should join another project. My advice to them has always been the same; whether you’re pitching your own idea or joining another team, there are three things to keep in mind:

Customers - Choose a product that has customers who will be accessible to you over the weekend. Definitely avoid projects that can only be sold to the VP Marketing at fortune 500 companies. They don’t work weekends.
Agility - Choose a project you’re not afraid to change. This might be a good argument not to pitch the project you’ve been married to for the past two years. LSM is about rapid change based on validated learning. So if you’re afraid to kill your ugly baby, don’t pitch it.
Balance - find a team with a balance of designers, developers and “marketers.” The last thing you want is to join a group where nobody can install google analytics on your landing page.

Tips for Winning

I believe the winning team will be the group of people who show the most acceleration in their pirate metrics based on the pivots they make. Each pivot should be based on validated learning. So how do you make that happen?

Once you’ve picked a product to work on and you’re ready to get started, I would suggest that you split the group into two teams: the Inside Team and the Outside Team. The main strategy is for both teams to collaborate on structuring experiments, and then run each experiment independently to accelerate the learning process. Consensus among both teams is paramount, so there are certain activities which should be done together. Namely, defining the problem, defining the solution and agreeing on each pivot.

The Inside Team is responsible for testing the viability of the online channel. They’ll be putting up landing pages and A/B testing various pricing models and value propositions. They’re going to be writing blog posts, and building out the MVP.

The Outside Team is responsible for hitting the streets, making customer contact, validating problem areas, leading solution interviews and selling the MVP face-to-face. Personally, I think this is the place where you want to be.

After each group completes a round of experiments, you should regroup, review the results, brainstorm many possible pivots, decide on which one should be implemented, and then start the experiment cycle all over again.

How Can Mentors Help?

We have some great mentors attending the event that can help you out in a few different ways. The mentors are your objective source of feedback, your fresh eyes, who can tell the forest from the trees.

They’ll let you know if they see an opportunity for you to pivot when you’re slamming your head against the desk. They’ll help you brainstorm novel ways to put yourself in front of customers, and they’ll do their best to help you structure your customer development experiments. And most importantly, they’ll motivate you, hold you accountable, and force you out of the building.

That’s it

I can’t wait to see everyone out at LSMTO. Good luck to everyone, and remember to look out for me if you want to work with the most aggressive mentor on the floor. And if you want to talk more before the event, feel free to get in touch.

Links of the Week 5

2012-01-18T02:40:07Z

Instead of posting links the minute I find them, I've started holding on to them for a week and then blasting you with them if they still hold my interested by the end of the week.

The Twelve-Factor App

If we wanted to move our app to Heroku here is how we'd have to design it!

Evaluating alternative Decorator implementations in Ruby

Decorators, and presenters, and patterns! Oh, my!

Media queries and multiple columns

A cool way to use @media queries to create dynamic columns based on the vertical height. Not applicable to our upcoming redesign though.

wbailey/command_line_reporter

We have lots of scripts which execute on the command line. This seems like a good way to get feedback from them. We currently use "puts" :)

Factory Girl 2.4.0 (Factory Girl 2.4 Goes Meta)

Our application has 6000 factory instances in it. This should speed things up a lot.

Paulasmuth/fnordmetric - GitHub

Seems like a self-hosted version of mixpanel.com with less analysis.

Exceptional Ruby: Master the art of handling failure in Ruby

Avdi has some great blog posts and this is sure to be great as well.

Android Design

Design reading for all, not just Android developers.

Links of the Week 4

2012-01-11T23:49:25Z

Instead of posting links the minute I find them, I've started holding on to them for a week and then blasting you with them if they still hold my interested by the end of the week.

Resourcing Pair Programmers in an Agile Team

2011-12-27T19:20:46Z

Everyone knows that practicing pair programming and agile development are the best ways to produce high quality software as fast as possible. But setting these pairs up is a lot harder than it looks. Here’s how we do it. How can we improve?

The Challenge

Resourcing pairs in an agile shop is difficult for a lot of reasons. One of the big challenges is that they have to constantly change. While one of the big objectives of pairing is to reduce developer blind spots, the same thing can also happen if you pair the same developers together for too long.

To further complicate matters, not everyone starts the day with a clean slate. They might have started a story yesterday and not finished it, or they might be leaving for an hour to go to the doctor’s office. The big point is that not everyone has the same amount of hours to devote to writing code.

Every developer has areas of expertise - and every developer has areas where they’re a novice. One of the biggest opportunities pairing brings to our team is to have these areas of specialization transfer to other developers. And unfamiliarity increases the quality of the pair because the expert is forced to articulate the challenge in a simple way to the novice.

In our experience, the key to resourcing pairs is to match people based on expertise and availability. We don’t have the perfect approach to resourcing, but we wanted to share what we’ve been doing lately in hopes of learning from you.

Our Approach

Every morning we meet for our day-planning meeting. It runs from 9:15am to 10:00am. The first order of business is to review the work each person completed yesterday, and review the work they started but didn’t finish. This step is repeated for each team member. Based on the commitments they have, we count the hours they have available for writing code, and we write it on the whiteboard.

The next thing we do is open Pivotal Tracker. As a team, we review each user story that was completed yesterday, as well as each story that was started but not finished. Then, we begin selecting new stories from the current iteration - which have already been prioritized by our product manager and customer support agents.

After we select each story (starting with the ones that weren’t completed yesterday), we create a pair based on their available hours, and their level of familiarity with the particular story. We’re looking for people who have about the same amount of productive time available. We also keep an eye out for an expert and a novice. We keep assigning stories until all the pairs have a full plate.

Next, we sequence the stories - discussing any dependencies or scheduling conflicts, and discuss any risks associated with other commitments. Once that’s done, we open up the floor to questions, and when those are done it’s time for announcements, which can be professional or personal. And we generally save a few minutes to look at one of Dave’s awesome youtube favourites.

If you like lists, I’ve included one below so you can review it and put it use. If you have an idea on how we can improve the way we resource pairs, please find me on twitter or write something more detailed on hacker news.

The Big Bang Morning Meeting:

Each person states yesterday’s accomplishments
Each person states work that was started but not completed
The number of available hours are recorded on the whiteboard
Repeat for all developers
Open Pivotal Tracker
Review work finished yesterday
Review work started but not completed
Select a story from the top of the current iteration (including stories started but not finished)
Assign the pair based on available hours and Expert/Novice
Sequence the activities to account for prior commitments
Assess any risks
Questions and Announcements
Get to work!

The Path to Being a Programmer

2011-12-13T16:18:54Z

Most people don’t know what their career will be when they are in high school, and I was no different. Now that I’m a young adult, I’m ready to graduate from university and kick-start my career as a professional programmer next May.

Naive Thoughts

Before I started university, I knew nothing about computer programming. I used computers to check emails, chat on MSN, download MP3 files, create PowerPoint slides and write Word docs. Somehow that seemed enough to choose ‘Computer Engineering’ as my degree at University of Waterloo. I already liked using computers, so I figured I wouldn’t mind learning more about how they work.

I did a lot of programming in my first year. C# was the first programming language I ever learned, and at that time I thought programming was fun. It reminded me of playing with LEGO when I was a kid. It was challenging to bend the the computer to my will, and the joy I felt when my code actually did what I wanted was amazing.

I remember coding in my residence with two roommates who were taking the same courses as me. Sometimes we worked together because none of us had any programming experience before coming to university. It was difficult enough to get my code to work while receiving help, and it felt almost impossible while working alone.

I wasn’t good at asking for help when I needed it, and I needed it often, and by the start of my second year I became completely overwhelmed. Programming wasn’t something I looked forward to, and soon became just a school project I had to complete by a deadline I could never seem to meet. It felt like ‘professional programmer’ was not a viable career option.

Breaking Point

When I got my third co-op job as an automated test developer, I programmed alone most of the time. My job was to tweak and maintain an internal tool built on VBScript that was only going to be used by me and my supervisor. I found it really boring, and it showed. My boss caught me dosing off on my desk, and it ended any chance I had at having a pleasant work term for the remainder of my three months. I was ready to leave the world of programming for good.

I put school on hold and decided to take a year off to closely analyze what kind of person I was and what kind of career I wanted. I was told by family and friends that travelling is good for soul searching so I even planned on going to Japan to teach English for a year. I almost did it, but in the end I got cold feet. I was afraid of being away from school too long and not being able to adjust to being a student again.

Epiphany

I switched out of Computer Engineering hoping for the best, but no one told me that even in Management Engineering, I would be doing some kind of programming. It turns out learning about Information Technologies and Management of Technology involves programming in HTML, PHP, MySQL, and C#. Programming for the first time in close to a year brought feelings I couldn’t understand. I knew I wasn’t supposed to like it, but I found myself wanting to give it another try.

That term, out of all the courses that I was taking in Management Engineering, the ones that required programming were my favourite. I now had a different attitude while programming - I enjoyed it. These projects had less restrictions and allowed me to work at my natural pace. The mandate of Management Engineering is not to teach students how to program, but rather to teach them just enough through application in order to understand the bigger picture of software design, telecommunications, and other issues associated with the use of information technologies. I could not leave the programming world - but I didn’t want to anymore.

Now

Two years later, I somehow ended up at Big Bang Technology as a Junior Web Developer. I still consider myself pretty bad at what I do, but it feels right at the moment, and I’m sticking with it until my next revelation.

You can find me @joonhashin on Twitter. I'd love to hear your story on how you ended up choosing your professional career.

Selling Lean: The “Two Promises” Approach to Sales

2011-11-16T21:47:49Z

In this post, I’ll show you a Lean way to test a product and get paying customers over a weekend.

This approach is tailored to the attitudes and behaviours of visionary customers, not the typical customers who “need to see it live” before they sign up. These are the customers who are truly excited about what you’re building, and they’re willing to sacrifice a full feature set for that one magic button that solves a problem they care about.

I challenge every one of the Dooo.sh/it participants to run an experiment: Get at least fifty paying customers before you write your first line of code or put up your first splash page. A lot of people think this is impossible and never come back. But it’s not, and it’s a great way to separate the entrepreneurs who believe in Lean from those who don’t.

You can also read about some other lessons I learned while putting this tactic into action.

I said before that this activity is an experiment, and therefore we must have concrete criteria for success. I usually recommend seeking 80% validation from a sample size of 40 customers.

The Scenario

Approach a Customer

Rule number one is the customers must not be friends or family. These people are great, but give you skewed data because they want to see you succeed. Real customers only care about your product, and that’s the only thing that matters.

Problem Interview participants, referrals, cold-calls, and drop-ins are ideal candidates for this experiment, and it really highlights the need to track who you’ve talked to before so you can contact them when ready.

Prepare the Shock

I always recommend that you start with the bad news - that you’re going to be asking for money. Remove the anxiety the customer feels by getting it out in the open and moving right along. I like to say something along these lines:

“We’re a serious company building a serious product - but we need serious customers to make this whole thing work. So at the end of this interview, and i’m going to ask you for twenty dollars. It’s the only way I know for you to prove I’m doing the right thing. Now let’s get started.”

Demonstrate the MVP

I like to start by describing the problem, walking the customer through a set of wireframes, giving them a data sheet about the deal, and most importantly - telling a compelling story the whole time. Stories build trust and empathy, and they help you demonstrate a deep understanding of the problem at hand.

When the demonstration is over, it’s time to start thinking about the Close. Remember the twenty bucks you mentioned before the demo? Yup, it’s coming back.

Typically I’ll say something like, “I’m going to be honest with you - 20 dollars might not seem like a lot to you, but it’s a big deal for me. And if I’m going to ask you to go out on a limb for this product, the least I can do is make you two promises in return.”

Two Promises

Promise 1: The Date

Even without a piece of software, I’m not afraid to say “I’ll deliver you a piece of working, beautiful software by [Insert launch date here]. And if it isn’t done, I’ll send your money back with an explanation of why.”

I also like to use humour to my advantage and offer up my parents’ home address, my cell phone number, and the name of my bank manager to establish that I’m a local guy and I’m not going anywhere.

Promise 2: The Discount

Then to make the deal sweeter, I say something like, “Because you’re a visionary customer, because you obviously get what I’m trying to do here, I’ll give you $200 of credit to use with my product when it launches.” Notice the subtle compliments we’re giving the customer at this point. These visionary customers have an opportunity to “join the cause,” so to speak. And having a targeted position will always present a more compelling pitch.

Close the Deal

And finally, I’ll say, “I’d love to do business with you today,” maintain eye contact, and let the air hang dry. I try to avoid asking questions like, “Can I sign you up?” or “Would you like to go ahead with this?” and prefer using affirmative statements. As you sign up more visionary customers, the goal is to gradually reduce this discount until it is equal to a one-month free trial.

If you’re lucky enough to sell, there are three critical follow ups that need to happen. First, ask for a referral. This will most likely be your next paying customer. Then, I always recommend that you get a picture, with your customer, holding the twenty dollar bill. You have no idea how much this will motivate your technical co-founder. After that, give them the data sheet outlining the deal with the two promises, and record the customer’s info in your CRM tool.

Me and a customer after selling a product that doesn't exist

Next Steps

If you don’t hit your goal of 80% validation for your sample group, you have the following options:

Keep your solution the same, and pivot the type of customer you’re talking to.
Keep your market the same, and pivot your feature set.
Pick a new problem and start again.

Here are some topics that haven’t been talked about in this post:

Lean solution validation for free products (article coming soon)
Lean soluton validation for enterprise sales

Hope you found this useful. Find me on twitter if you’d like to talk more, or join the conversation on hacker news. But instead of doing that, you should get out of the building and sell something.

An experiment in Geolocation

2011-10-27T20:29:47Z

I’ve been experimenting with web-based Geolocation technologies in a small proof of concept Rails application. The application itself is pretty vanilla: I wanted to build something that shows me where I am right now, and where some determined locations are at a fixed position. The idea being that I could see how far away I am from my favourite donut shops.

The biggest challenge in designing a system like this is deciding how to track Geolocation information in the application. I already know there are many server-side IP-based Geolocation patterns. But HTML5 offers a Geolocation api, so I wanted to look into some of the patterns that are just emerging, so I could choose the best way to track location data.

Round Pegs, Round Holes

If you’re a real software engineer, you probably know interesting problems have many possible solutions - the best of which will depend on what you’re actually trying to accomplish. Based on what I wanted the app to do, I started to research both server-side and client-side solutions, with the intent of really understanding why to use one over the other.

Below I will explain some of the realized benefits and disadvantages of each.

Server-Side IP-Based Geolocation

Benefits:
– lives on the server, so signal strength isn’t a factor.
– does not require end-user permission, so your UX can be slightly simpler.

Disadvantages:
– usually relies on existing geo databases; which could become stale
– accuracy suffers - you can only locate people at the city level.

Where would I use this:
– Auto-selection of country specific information; language, currencies, etc.

Client-Side HTML5 Geolocation

Benefits:
– high accuracy (street level) - You can locate objects within a few metres of their actual location.
– requires end-user permission - People are fickle.

Disadvantages:
– browser compatibility (HTML5) - if you care about that sort of thing.
– depends on signal strength - EDGE may not cut it.

Where would I use this:
– Real-time indicator of users location, nearby points of interest, etc.

After gathering this research, I realized my application serves two primary functions: One to track a visitor’s current, ever-changing coordinates. The other to locate a destination based on fixed coordinates. I am using a combination of these technologies, and also a hybrid model which interfaces the client-side information back into the Rails application.

If you are interested in reading the source code of this proof of concept, take a peek at my Github repository.

Update: Working for a Startup

2011-10-26T14:24:42Z

My name is Joonha Shin, a co-op student from University of Waterloo, and I’ve been working at Big Bang Technology for just under two months.

“So how’s your work going so far?”

It’s question that I get asked often. Whether it’s close friends from high school or fellow classmates also working in Toronto, they want to know what kind of work I do and what the working environment is like. I’ve also found that people are more curious about my work now that I’m working for a startup than when I used to work for big, international companies.

It’s almost like they also want to try working for a startup, but don’t want to take the leap of faith and try it for themselves. Maybe they would rather hear my stories and experience them vicariously, and that’s good enough for them. They ask me questions like, “So what’s the work place like?”, “What do you guys do?”, “How many people are in your company?”

I wanted to write this blog post so that people can get a feel for a life at Big Bang HQ, without actually working here.

First Day to First Two Weeks

On my first day at Big Bang Technology, the first thing I noticed was how the place looked: wooden floors, white brick walls, high ceilings, comfy couches, paintings, plants and six 27” Apple monitors. I felt a blend of both modern and classic design; I liked it.

When I first started in September, there were eight of us including myself. Soon, that number will go up to nine. For the first two weeks, I was floating around, pairing with as many people as possible. I got exposure to our development environment, the typical work flow, and how we make money. It took a while to get my feet on the ground, but after the first two weeks I started contributing a lot more.

Development Environment

One thing that’s very different here is that development is almost always done in pairs. The only time this isn’t true is if we are doing simple chores or research. Whether we are implementing new features or resolving a complex bug, we are always working together. The only time I work alone is when I’m writing blog posts or doing some quick admin work.

Even if it’s not strictly development, it’s not uncommon to see two people sitting side by side at a desk and working together. This is easy to do since we don’t have cubicles here. Sometimes, we take the concept of pairing a bit too far, like while making coffee or playing Deus Ex: Human Revolution (as well as Dark Souls) during lunch or after work hours.

To be fair, pairing isn’t always great. I’m not the world’s greatest developer yet, so when I’m pairing, I spend most of my time watching and trying to learn, rather than giving useful feedback. Sometimes it can feel like I don’t have as much input - and sometimes I feel a little useless. No one makes me feel that way though - that’s just me.

What’s Next?

One of my my biggest goals during my co-op term here is to improve my programming skills. Not too long ago, Cameron asked if I wanted to pair with him after work to do some Code Kata; I gladly accepted his offer. And although becoming a master programmer is big goal for me, having great experiences and great stories to tell is just as important.

If you’re a co-op student and you’re curious about my story, you can find me on Twitter and ask me anything you’d like.

Why I Chose a Startup

2011-09-28T20:16:59Z

My name is Joonha Shin, a co-op student from University of Waterloo, and I chose to work at a startup. Here’s why.

Backstory

In January 2011, I tried starting a company with my classmate. Our university allowed us to do this as a co-op term, so it was a chance for us to do something risky but still receive some kind of a reward in the end. We had just four months to build something, then make it cool.

Over the next four months, we built a prototype that was still far from production. And even though we were learning a lot, we ran out of time and decided to put our project on hold. Our new plan was to graduate, find work, then bootstrap our company on the side.

I still had one more co-op term to complete before our graduation. I really wanted to work for a startup; someone else’s startup. I wanted to experience first-hand what to do, and what not to do when growing and managing a startup. After about seven interviews, I accepted an offer from Big Bang Technology for my final work term.

One Last Chance

Choosing the right place to work is not an easy task. There are so many options available and so many factors to consider. I knew I wanted to work for a startup, but I wasn’t sure what kind of startup I wanted to work for. I decided to figure it out as I went along.

I only applied to startups or small-sized companies. I saw my friends interviewing with Facebook, Apple, Microsoft, Deloitte, and so on. Those are all great companies, don’t get me wrong, but they weren’t what I was looking for. I’ve worked for Siemens, Research In Motion, and CGI Group; all very big companies. I experienced about two years worth of the corporate scene and I wanted something different. I was craving for a smaller, fast-moving, young group of friendly and enthusiastic people. I only got interviews with companies none of my friends heard of. Big Bang Technology was one of them.

The Result

By the time I met Max and Cameron, I already had about five interviews under my belt, and they were starting to become a routine: listen to them talk about themselves for ten minutes, then answer questions regarding my resume, then answer few programming questions. Big Bang was different. The two had made a list on the whiteboard. They were conversation topics: some were about them and others were about me. They asked me to pick five topics and that would be the interview. I got caught off guard. When the interview was over, I realized they made an impression on me. They weren’t like others, they were memorable.

Even before the offers came, I was already leaning towards Big Bang Technology. And if there were more than just blogs on their website, I would have made my decision a lot quicker.

Each time a co-op term ended, I never felt satisfied with I had done and I knew that there was something better out there, waiting for me to try it. But I’m happy to say after six co-op terms, I’ve finally found a work place that I’m content with.

To my fellow co-op students, my advice to you is this: Don’t give up and don’t settle.

One Year of LeanCoffeeTO

2011-09-28T17:25:50Z

This week marks the one year anniversary of LeanCoffeeTO, a meetup group that we’re proud to belong to. I’ve written about why I think LeanCoffeeTO is a rare and valuable community resource, so we were happy to host one of the five consecutive sessions being held this week throughout the city.

The first two sessions were held at MyCityLives and The Working Group. We focused on a retrospective approach, where we looked to the past, remembered how the group got off the ground and talked about some of the amazing things that happened as a result.

We wanted our session to move the conversation forward, so instead of continuing that trend, we invited the attendees to jot down experiments that we could run in the coming year based on the conversations that have already happened.

Here are the trends and experiments we discovered:

Channel Experiments:

Create a LCTO website outside of meetup.com
Promote and work closer with the “splinter groups” that are emerging: Dooo.sh/it, ECSA, etc.
Live stream each session to increase our accessiblity and reach
Create a Chapter Kit to help other LeanCoffee groups to get started quickly and learn from our mistakes
Integrate some sort of Q&A into the site to promote more dialogue between members

Special Event Experiments:

Host a full-day LeanCoffeeTO conference
Have an evening meetup once a month, IE LeanCocktails
LeanCoffeeTO Bootcamp - a four session intensive workshop to onboard new LCTO members as quickly as possible
Mentorship and Residence programs - facilitate residence programs between startups to socialize best practices

Activity Experiments:

Pitch Day was very popular. In this experiment we’d critique member pitches before getting in front of actual investors (There was even talk of inviting investors to attend)
Elevator Pitch practice - Pair up and give another member your elevator pitch, and have the listener repeat what they remember to see what parts of our pitches need improvement.
Run Customer Development experiments at a LCTO meetup
Lead Customer Interviews during a session to improve that skill

Format Experiments:

Formalize and publicize a process for members without office space to facilitate sessions
Follow the development of a specific startup over the course of two months
There were a number of suggestions to bring in Subject Matter Experts and business leaders in for a speaker series

Wrapping Up

I’m not here to critique or endorse any of the experiments that came up today. However I do believe that LCTO could benefit from a lot of these ideas. I also think we can set ourselves up for success if we keep these ideas in mind:

Run the smallest version of the experiment instead of attempting to pull off major initiatives
Structure the experiments so they can be run no matter who shows up for a specific LCTO
Allow pain to drive which experiments we run, instead of ambition
Ensure the governance of the group continues to be decentralized

Looking forward to seeing you tomorrow at Jet Cooper, and judging by the package they just sent us, it should be a good one.

LeanCoffeeTO at Big Bang HQ

Your Employees’ Personal Goals Should Matter to You

2011-09-21T15:44:44Z

Understanding your team's future goals makes your business better.

Many companies do business-specific goal planning with employees to determine how to get the most out of them, and ensure they are working hard towards the company’s goals. And we do that too. But our personal goal planning is equally, if not more, important. Personal goal planning is separate from the business itself, and instead focuses on the employees and their lives holistically. And while it may seem like a “nice to have” and not a “must have,” for us it is all about championing our staff, and their goals, to ensure our company and its staff are aligned. We have committed to personal goal planning with our employees because we think it is a worthwhile experiment. After all, we do spend most of our waking life as adults, at work.

A few months back, when we were a smaller team, we did a group workshop in personal goal planning. After the workshop, we created a book with a page devoted to each employee’s personal goals. Not only does this help us keep each other accountable, we also like to share it with prospective employees and important office guests.

The Big Bang Goal Book

It was a great experience during the early growth phase of the company. We all learned a little about one another, and about how to be personally mindful of our aspirations. But we knew it would be difficult to continue workshops like that one as our team grew beyond 5 or 6 people. As we continue to grow we want all of our new team members to be able to participate in the experiment.

One of my personal goals, which came out of our goal planning workshop, is to someday be an authority on company cultural development and management. I could not think of a better project for myself personally or professionally than to lead the goal planning workshops for the newest members of our team.

Over the course of the next few months as our newest employees go through the goal planning process with me, I will be blogging about what it’s like to lead this workshop. Since I am totally new to the world of goal workshop facilitation, it will be as much a learning experience for me as it will be for “The Daves” (our newest gang members). Hopefully this will give other small businesses or start-ups some ideas about what worked well for us and what we learned along the way.

How to Poach a Startup Employee

2011-09-16T19:16:01Z

It’s easy: Walk down the street to the next startup, find someone awesome, and offer them something better than they already have.

If you’ve ever worked in a startup, you know how close the bond can be between the members of a small team. So when someone quits, it’s easy to get bent out of shape. But lately, I’ve seen situations like this get a little too personal. Here’s the bottom line: business is business. And if you lose an employee, it’s nobody’s fault but your own.

Let me just say that employees are people too, and they should be able to work wherever they want to without justifying it to anyone but themselves (and perhaps their loved ones). They also deserve the best job they can find. In my opinion, job one for any business owner should be hiring the best people around. Job two should be making sure they laugh recruiters out of the room.

Eight ways we make recruiters hate their jobs:

Daily Feedback: We’ve written in detail about daily feedback and our day-planning methodology. It keeps the team engaged, and promotes a horizontal management structure. When everyone holds everyone else accountable, we help each other learn.

No Overtime: Zero, zip, zilch. We’ve also written about that.

Developer Development: Our unique skills workshop isn’t just for developers. We benchmark everyone’s skills, set goals, and structure experiments to help our team get better at their craft.

Full Benefits: A great benefits package, 100% covered by us. Our team has bigger things to worry about than dentists and eye-glasses. If you’re a startup employee and you don’t have them, we’ve even written a series of blog posts to help your bosses get started.

An Awesome Office: We’ve designed an office space that no one wants to leave. Then we force them to go home at five. Pretty awesome, eh?

Continuing Education: We have a dedicated education budget (still underutilized, tsk tsk) that our team can use to buy books, attend events, and enroll in classes.

A Healthful Atmosphere: We encourage everyone at Big Bang to lead a healthy lifestyle. That’s why we provide unlimited free yoga at Downward Dog, and stock the kitchen with tons of free healthy snacks.

Team Lunch: We take our whole team out for lunch once a week. The team loves it, and we’ll keep doing it until the only available option is getting caterers to come into the office. We also make a point of eating together at the same time whenever possible.

Retrospectives: Our weekly retrospectives deserve their own blog post. We take an hour every week to discuss what went well, and what didn’t. Then we structure experiments to fix what went poorly and augment what worked nicely. So far, we’ve implemented about 15 experiments. I’d say about five of them have been successful.

The Big Bang team during a retrospective

Here’s the Deal

As business owners, we shouldn’t wait till a team-member quits then burn valuable bridges. Instead, we should always strive to design a work experience that delights whoever is brave enough to work with us.

So yes, it hurts when someone leaves your team. But business owners need to get over it, step up their game, and take away every reason to leave.

Love it? Hate it? Find me on twitter or jump on hackernews and let me know.