Life in the startup lane

After listening to an agile software development presentation at Rally Software that included excerpts from the book du jour for web 2.0 developers today, “Getting Real” by 37 Signals, I went back to a thought that I had after I read the book several months ago. While digesting all the information that I had read, I realized that “Getting Real” offers a great template for agile web app developers; however, it also puts a lot of responsibility on the software developer above and beyond what has been traditionally expected of developers. After reading the book , you realize that a develop is no longer a person who possesses code cranking skills only but a person with a conglomeration of skills in order to satisfy the principles in “Getting Real”.

What skill will I be looking for in our next hire person for our web 2.0 which follows the “Getting Real” agile software development model? As a former, software architect, I identified that the closest skills for a person that fits the bill are that of a software architect (in addition to the developer skills, of course). Now, I am not trying to turn the whole “Getting Real” on its head and introduce the role of an architect, I am merely saying that the skill that should be innate (or trained) in person who can successfully thrive in a startup company implementing the “Getting Real” principles is commensurate with the skill that is required of a software architect.

In addition to suggestions in Chapter 8 of the book, I would hire a person who possesses the following skills that are often associated with software architects:

Constant understanding of a system’s organizational structure

Since we have no req specs with “Getting Real”, the developer must constantly keep in mind the overall view of the system as well as its constituent functional components and their relationships. This goes a long way in cranking out code faster because one must constantly understand how changes affect other parts of the system.

Ability to curb unbounded complexity

It takes a certain level of skill to deliver software that provides value, is simple to use and is powered by a non-complex system. Simply saying ’no’ to feature requests does not necessarily equate to a less complex system.

Leadership

The ability to influence and inspire, is a quality that is continually evident in the 37 Signals guys themselves. “Getting Real” principles result in a product that is characterized by an impassioned boldness of the product and the people; and leadership is definitely an essential quality in achieving both.

Effective communication

A developer that successfully follows these principles outlined in the book must be able to communicate on three axis: X-axis - horizontal communication with the other members of the team, Y-axis - communicate with the your startup management, board, advisors, investors and any other developers under him/her , Z-axis – communicate with the product users. “Getting Real” emphasizes the importance of engaging with your users, this will yield the best results if your developers have effective communication skills.

Understand and appreciate business strategy

In order to “hire the right customers”, “have an enemy” or “underdo your competition”, a developer must understand the business strategy.

Political Skills

While traditional software architects must possess the skill for political navigation through an organization while championing the product, I think the political skill required here is a little different. A developer must be able to identify when politics start to affect the product in ways that are not in the best interest of the product and put a stop to it. Even small startup teams such as those suggested by “Getting Real” have a certain level of political dynamics not only within the team itself but also among other entities that interface with the team such as investors, advisors etc.

In addition to the “Staffing” recommendation in the book, I will definitely be using all the above-mentioned to evaluate our next hire because developers just cannot afford to be simple code crankers anymore.