Important Note: The purpose of this post is to discuss the importance of culture fit between employer and employee and use a personal example of why I was not a good fit at a company as a timely example. This article is not intended to bash TourWrist or disparage them in any way. I wish them the best and still have good friends working there who I continue to cheer on in their endeavors.

If you’ve been paying attention to the startup world over the last few years, you are very familiar with the emphasis on company culture. 37 Signals and Zappos might be two of the most famous companies for stressing the concept, but many of the successful startups have discussed the importance and purposefulness of it as well.

When you think about company culture, you might think about the way the office is designed, the clothes people wear to work, the benefits provided, and the company mission statement for dealing with customers and employees. But what you don’t often hear about are all the other pieces that I believe come together to form the company culture.

Read More »

As I transition from full time employment to being fully self-employed (starting in September), I’ve had the wonderful opportunity to talk with a number of potential clients from all industries, with all types of past experiences and varied budgets. In the last month alone, I’ve talked with over 20 different companies. During these talks I’ve learned one major thing that surprised me. I suppose because I’ve been working for individual companies for so long I didn’t realize there were so many misconceptions about developers, web development, and productivity out there in the business world.

Read More »

I finally had a chance to finish up reading the Delivering Happiness book I’ve been reading and writing about for the last few weeks. In all, I do recommend the book both to startups, and to those running a larger company. The book is almost two books in one. The first half, as I covered in my posts, Discovering Happiness and Now This is Real Passion, are about Tony’s early startup experience and the path he was on that led to his personal discovery of what his passions really were. This was the part of the book that I enjoyed the most as it focuses on my situation and on one of my favorite areas of interest: internal motivation and discovering one’s passions.

Read More »

I recently received this question about the Agile method of developing software and thought I’d share it and my answer.

Q. I am doing some research on agile methods, and wanted to know what you think about the use and application of agile methods? Will they continue to be used more in the next decade in internet software development? And what agile methods do you use?

A. Many startups have been using a more “agile” project management methodology without really knowing it. It’s the formalness of the “official” Agile and Scrum practices that are gaining in adoption now. As to if that official set of rules will stay around for a long time it’s impossible to predict, but judging from history, I think certain exact sets of guidelines come and go in popularity. The principles behind what is considered Agile however, I believe will last a long time. Many of us have seen the failure of planning out year long projects, holding daily hours long meetings to discuss statuses, and building 100 page analysis documents before anything is ever built.

Small, lean, flexible teams, working on shorter production cycles will always produce better software than rigid, bloated teams working on long drawn out project timelines. But most teams will do so without ever getting certified as a Scrum master or some official title for following some group’s rules as to how to manage a project. They do it because they observe the failures of the opposite through experience, particularly if they ever worked in a large corporation and had to follow the time wasting mess of project management that typically emanates from such places.

For me, following rules for how a project should go is not agile enough in itself. Guidelines are great, and I recommend understanding the Agile method so you can learn from it’s principles, but true agility comes from fitting the process to the specific team and project at hand. So I recommend never becoming allegiant to a certain methodology of project management, nor even to a certain development process. Use them as guidelines, but adapt them to your specifics and let them grow with you as you learn and experience more. Ensure the team shares in the understanding of why the agile process is better versus things like the water fall approach. Once they do, wether you stick to the Agile Manifesto or not will not be the significant deciding factor in the efficiency of your software development. It’s the underlying principles that matter, and those I believe will be with us for a long time.