Thursday, August 28, 2008

Why to Work for a Small Company

I've worked for very small companies (less than 50, privately held) and for very large companies (50k+ Fortune 500), for significant periods of time and in a variety of software development roles.

Below I've laid out several reasons in favor of working in software development for a small company. I'm not saying that these things are guaranteed, but I am saying they are out there and you can find them; and you are more likely to find them at a small company. Caveat emptor.

I also have a post on Why To Work for a Large Company.

Generally speaking, based on my experience, work for a small company if you value...

Risk Taking

If you are going to work for a small company, you should be somewhere on the spectrum between risk tolerant and risk-loving. Here are some risks: the company could fail for reasons beyond your control, the owners and/or co-workers could be difficult to work with, decisions that you make could negatively affect the company, everyone knows when you fail.

But for every risk, there is a potential reward. That's part of the thrill and payoff of working at a small company -- the entrepreneurial spirit -- taking risk and reaping the reward. Yes, everyone knows when you fail; but everyone also knows when you succeed. And your personal successes can have a highly visible and significant positive impact on the success of the company, the success of the people your company serves, and your own sense of self-fulfillment.

Connectedness

You should work for a small company if you enjoy the feeling you get when you can easily relate what you work on to the success of the company or the impact it has on the success of the company's clients or end users. I.e. You have a strong desire to feel like you are making a difference and helping others to succeed. When you are at a large company, that connectedness is often missing.

Like-Minded People

People who work for small companies are more likely to have values that align with yours and that are on this list. I.e. Risk-takers, entrepreneurs, optimists, do-ers, etc.

Less Incompetence

At a small company, you cannot hide. Everyone knows when you fail and everyone knows when you succeed; and the company cannot afford incompetence. Because of this, incompetence gets weeded out.

Familial Culture

Small organizations tend to take on the personality of their leaders, so if you find a small company whose leaders share your personal values (E.g. honesty, integrity, sense of humor, etc), the vast majority of the employee population is likely to also share those values; and this makes for a very nice fit and a familial atmosphere. It's hard to find this type of atmosphere at a large company.

Variety

At a small company, it is likely that you will become a generalizing specialist. In other words, according to Scott Ambler: "Multi-disciplinary developers, cross-functional developers, deep generalists, polymaths, versatilists." This will be true with respect to the technology and tools, the people you interact with, the domains you work in, and the roles you play.

At a large company, as a software developer, you are more likely to have a singular purpose (e.g. DBA, Performance Tester, Project Manager, etc.), where you can acquire a depth of knowledge within your narrow domain. If depth is what you are after, a small company might not be the best option.

Personal Marketability

My experience has been that breadth makes you more marketable -- it gives you more career options. Exposure to a variety of things also helps you to discover areas of personal career interest that you might otherwise have never discovered. Small companies help people to attain a more well-rounded skill-set.

Of course, breadth has a dark side: "jack of all trades, master of none". If you have to make a transition to a specialty, you will be behind others who already have that depth; but it has been my experience that, for career advancement and security, breadth is better than depth. There are exceptions, of course.

No Nonsense

Small companies tend to be very lean. Process and bureaucracy are overhead, and small companies don't want it and/or can't afford it.

Small companies do not suffer from the complexities of communication like large organizations do; and thus they do not tend to put in place restrictive, bureaucratic, and frustrating processes. Small companies tend to be agile by default.

For more on this, read up on Diseconomy of Scale.

Fast Pace

No nonsense translates into a fast pace. You don't rest on your laurels. You may work a lot of overtime. The cadence is just plain fast most of the time. You probably won't be bored. If you like to be busy, you will like working at a small company.

Flexibility

At a small company, there tends to be more flexibility in your terms of employment. Many aspects of your terms of employment may be negotiable, such as vacation, work schedule, etc.

Small companies tend to be more laid back about certain things, such as dress code and your personal work space. Jeans and t-shirt may be every-day attire. Perhaps shorts and sandals in the summer. Arrange your desk the way you want it. Put software on your computer without having to get permission. Listen to music. Take a mental break and play a game. Bring your dog to work.

Responsibility

Empowerment at a small company can vary greatly according to the policies and whims of the owner. It has been my experience that there is more empowerment at a small company. If you think about it, based on what I've previously said, this makes sense. There is less incompetence, which leads to more trust, which leads to empowerment. There is less overhead, which translates into less micro-managing, which leads to empowerment.

At a small company, you will have a responsibility to influence what the company does as a whole. You will have direct access to the owners and other decision makers. You may have direct access to the customers as well, and an ability to make decisions on your own based on what customers are asking of you.

Tuesday, August 19, 2008

Applying Agile Techniques to an Individual Workgroup

Generally speaking, I believe Agile frameworks define the best practices for managing complex software projects; and I believe you can say that these same practices can be applied to any set of work items that are to be executed by any organizational team. I want to take some of the foundation and theory that Agile is built upon and apply those principles to general team management.

A "project" can be abstractly defined as "A planned endeavor, usually with a specific goal and accomplished in several steps or stages" (from wiktionary). An individual organizational team that is supposed to be collaborative, then, to execute its set of work items, can think of its work items according to that definition; and the practices from Agile that are applied to the larger concept of "software project" can be applied to an individual team's work items.

It will be easier for me to express what I want to do using the terminology of a specific framework, and for that I choose Scrum.

Let's start by looking at the top reasons for project failure:
- Poor requirements management
- Insufficient communication and collaboration
- Lack of domain expertise

Now let's restate these items in a way that makes more sense in the context of any cohesive managed work (i.e. stuff done by a team):
- Poor definition and management of the expected work
- Low level of team collaboration, customer involvement, and management involvement
- Lack of knowledge by staff, of product and tools

These are the problems we want to try to solve. Knowing what problems we want to try to solve, let's take a look at some of the specific concepts within Scrum and see how we can apply them to any individual workgroup/team:

1. Open work environment

Improve collaboration by removing physical barriers to communication, such as cubicles.

2. Product backlog

More generally, let's call this a "prioritized work queue". A team should have an explicit list of things it is expected to work on.

3. Sprints

A "Sprint" is a time-box for executing a set of work. Get the team to focus on a set of items from their work queue by time-boxing their work. Provide up-front planning for each Sprint to define what is to be done in more detail, and provide post-Sprint retrospectives as feedback into the process.

4. Daily stand-ups

Keep the work transparent. Hold a 15-minute meeting each morning, where each team member answers three questions: 1) What did I accomplish yesterday; 2) What am I going to accomplish today; and 3) What obstacles are in my way?

5. Scrummaster

A Scrummaster is a person who shephards the team through the execution of a Sprint. They run the Sprint planning and restrospective meetings, they run the daily stand-up meetings, they remove obstacles, etc.

It's not that hard to see that you can take concepts from Agile and apply them to any team in an effort to increase the value of the team's work.