Small businesses starting out today have a few things going for them that make it much easier than in the past. For one, the cost to get a team equipped with computers and software is significantly lower now than it has been.

Refactr has been able to make use of many free or low-cost hosted applications rather than shelling out, up-front, for “enterprise software” licenses (and really who wants that crap anyway).

We use Basecamp (which includes a Campfire chat) for communication and organization between the three Refactr principals, rather than for managing projects. I would imagine the new version of Backpack would work for us in that regard but we have too much info in Basecamp now to switch. We use Google Calendar for tracking our schedules as it is more powerful and flexible than the calendaring in Backpack.

To solidify our 37signals fanboy status we round out the suite by using Highrise to keep tabs on who we contact in terms of potential projects and potential hires. We love Highrise but it is bittersweet for us as we were going to begin development on a similar application just before it was announced.

Our team tracks its time in Harvest using a “grand-fathered” deal that is no longer available. It works well because it is easy and allows us to add contractors into the mix. We manage our payroll and taxes via PayCycle and are impressed with it’s feature set and ease of getting started. 

We use Gmail for our domain and collaborate on documents and spreadsheets with Google Docs. This used to be enough of a frustration that we broke down and purchased Microsoft Office Suite (after trying to make due with NeoOffice for months). Google’s offering is much improved in the past month and with Gears and offline access to your docs - so much so that I often prefer it to opening Word or Excel (I especially hate the Mac interfaces for these programs).

Aside from Textmate and Photoshop CS3, nearly everything we use is or could be a hosted web application. Since that is what we build, it is good to see the offerings mature and see evidence that companies like ours can survive and thrive by using these tools.

At Refactr we don’t often get RFP’s (Requests for Proposals). Most of our consulting project work comes from word of mouth and referral where we help brainstorm what is to be created at the outset. It is the only time in a project where there are routinely meetings for more than an hour - a time of much personal interaction. I would say that sending out an RFP, sends an entirely different message. At best, it is impersonal and puts up walls that must be knocked down. More seriously, when it comes to software development projects at least, RFP’s can set the stage for failure.

An RFP attempts to describe and document the project. The first part of this (to describe) is good, but the intent for an RFP to do anything other than get some ideas down and start a dialog between the stakeholders and developers* is misguided. An RFP is drafted prior to development, when the least amount of information is available and with a small subset of the whole team in place.

Another side-effect of the RFP process is the creation of a mindset that software development is something that happens to an organization by an external source. Software development should be one of the most collaborative endeavors into which businesses enter. Stakeholders and developers should work side-by-side in designing the software, customers and those who use the software should be involved in the use-and-feedback loop.

To underscore the idea that RFP’s are simply the “hello” to a longer conversation, we often informalize the process right up front by meeting in person and responding with text emails rather than fancy Word or PDF file proposals. Our hope is that this helps to establish a new tone for the project and have found that when formality dissolves away, real communication happens.

* The terms developers and software developers are used here to encompass all people who develop software including visual, information, and interaction designers, client-side coders, server-side programmers, etc. I could also have used software designers to mean the same bunch of folks.

This is a little bit older, but pretty interesting: Nine Things Developers Want More Than Money.

It should be inherently obvious, but seeing lists like this every once in a while is a good reminder that creating and maintaining high-performing teams is clearly more about people than it is about process, technology, or anything else.

Much has been written in blogs and in the news media about Best Buy’s Results Only Work Environment (ROWE). And while the idea (do whatever you want, work however you like, as long as you get your work done.) is cool and it is nice to see a big company embracing some agile ideas, this is not a post about ROWE*.

As a follow-up to my post earlier this week, I wanted to post some pertinent bits of a recent discussion I had with Geek Squad founder and current Best Buy executive, Robert Stephens. He is implementing a plan to “think small” from inside the behemoth that is Best Buy. Stephens’ plan addresses each of the points that Mike Speiser of laserlike.com concludes are important advantages that startups have over large organizations in terms of innovation, namely: the investment model, incentives, and risk taking.

His idea would focus on technology and software solutions developed by small teams or individuals within Best Buy (or failing that, using small teams or individuals from the outside). The first step would be to create an infrastructure that allows for projects to get up and running with very limited administrative or technical setup. Once a problem or opportunity is identified, employees are encouraged to bid for the opportunity to tackle a problem by offering up their solution and what it would take in terms of time and money. The best ideas are funded (in the form of a bonus) or, in some cases, combined into teams. We aren’t talking about large “corporate-type” budgets either - these could be a couple thousand to twenty thousand dollar budgets. The goal is to side-step the typical flow of events in corporate business: get an idea, meetings and discussion, document the idea and discussions, sending the idea “up the flagpole”, having more meetings, having the idea morph, incorporate additional ideas, and finally either get the “green light” or be canceled weeks, if not months after the solution would have ideally been implemented.

This concept allows Best Buy to act like a startup in all the ways that are important. It allows for “distributing investment and other decisions” (a new investment model) across the organization allowing for risk-taking by individuals who are incetivized by the ability to create something great and get paid extra for their efforts.

* For more on ROWE, check out this Tim Ferris post for more on ROWE or the blog of ROWE instigators Cali Ressler and Jodi Thompson.

One of the best parts of Minnesota’s barcamp, minnēbar this year was the panel discussion on the state of technology in Minnesota. During the discussion everyone got the chance to hear from and ask questions of some leaders in the Minnesota tech and business communities, including: Doug Olson (Founder of Authorware, led the development of Adobe ImageReady, and now starting a Microsoft office here in Minneapolis), Jamie Thinglestad (Former CTO of Dow Jones MarketWatch, and 2008 Business Journal “40 under 40″ award recipient), Michael Gorman (Co-founder of venture capital firm Split Rock Partners), Robert Stephens (Founder of the GeekSquad), Dan Grigsby (2008 Business Journal “40 under 40″ award ), Matthew Dornquast (Co-founder of code42 Software).

A large portion of the talk was comparing the environment in Minnesota with those on the coasts in terms of entrepreneurial spirit, startups, and venture money with a good deal of discussion mirroring Dan Grigsby’s post titled A Plan For Minnesota. The consensus seems to be that our tech start-up community isn’t thriving,  not for lack of access to great people or ideas (or even money though I think that’s debatable) but rather for lack of guts.

It definitely takes guts to leave a nice salaried job where, frankly the expectations for you are set pretty low. Big banks, insurance companies, and even tech-focused companies rarely can sustain the culture and spirit that got them there. The sheer size of the machine becomes so large that innovation and personal accountability shrink into the shadows. Despite billions of dollars spent on research inside Microsoft, Oracle, Yahoo, and yes even Google, all too often the game-changing innovations are created by small, hungry companies who then get purchased.

Venture capitalist, Mike Speiser over at laserlike.com has some great insights on this. He looks at the 2007 R&D investments at 3 major companies (Microsoft: $7.1 billion, Google: $2.1 billion, Yahoo: $1.1 billion) and then the $5.1 billion VC’s put into startups and makes some observations:

My strong suspicion is that the return earned by investors on that $5.1 billion (in aggregate) will exceed the returns on the $10 billion (in aggregate).  If you buy this argument, then there is only one logical conclusion. There isn’t too much money in venture, but rather there are too many good people in large firms.

He states that startups are the right place for innovation for these three reasons (I am paraphrasing here):

1.  The investment model - Big companies often won’t kill bad projects where small companies must. Startups are more practical and results oriented in what they prioritize. Centralized knowledge and limited employee ownership/investment hinders large organizations. Large firms should create a system for distributing investment and other decisions.

2.  Incentives - Paying for performance is easier in small companies. The probability of success equals the number of experiments per invested dollar times the number of dollars.

3. Risk taking - In big companies perceived risk curtails innovation and agility. This must be overcome.

There is a positive selection bias in startups towards an appetite for risk.  People have “overcome” their fear — at least enough to be at a startup.  When you have an entire group of people who have overcome their fear, you get positive feedback.  People egg each other on to break the rules.  To “think different.”  To be open minded.  That sets off a cycle that drives people to throttle risk up and up and…

As much of the panel at minnēbar concluded, it is this last point that they believe is holding Minnesota back as a hotbed for technology startups. Minnesotans are hard workers but for whatever reason, are more risk averse than their coastal brethren.

Yes, we have moved into new offices in Minneapolis. North East Minneapolis at 4th Street NE and Hennepin to be exact. We have a suite on the top floor of a three story building. The space has high ceilings, ample windows, and wood floors. We are very excited and have been furnishing it and planning for the future.

It seems efficient, inspiring office configurations are very hard to come by. We have read many online accounts of what many people hate and what some people love, taking special note of those in our industry: software development.

We have gravitated toward the “open floor plan” for a couple reasons. We enjoy collaborating and find that by breaking down walls (in this case literally) the speed and ease of communication is greatly improved. The benefits of knowing virtually everything that is going on, and thus, not needing to track tasks and activities, outweighs the inevitable distraction and productivity loss that can happen in this type of layout.

FeedBurner founder Dick Costolo had this to say last fall about the topic of open offices:

1. Speed of communication begets speed of execution.
2. Friction begets friction, transparency begets transparency.
3. Motivation.

The first two are pretty self-explanatory. Motivation is a by-product of people not wanting to screw around when they are out in the open and expected to be productive.

While open floor plans are great and collaboration is essential, we still understand that there are occasions when concentration is required and interruptions would come at too large a cost. Like Joel Spolsky of Fogbugz Software we believe the that the right environment “can improve programmer productivity” and that it should be nice if we are spending a large part of our days there. In Joel’s words “It better be nice.”

Here is a loose set of requirements we are going by when building out and furnishing our new offices:

• Ample table space so that people can sit 2-4 at a table when needed.
• Individual “work carrels” for when you just need to crank.
• Conference room and break room areas where phone calls and meetings can be held in greater privacy and quiet.
• To restate our thought from above, the office should be cool. It should be someplace that we want to invite people to visit.
• We want to share the space with colleagues who are seeking similar space. This will allow us to collaborate with more people and make use of the space until the day (if that comes) we grow into it fully.
• The ability change up any of the above requirements and areas as our needs change.

With these requirements in mind (and a couple other constraints, namely budget and time) we have come up with a plan (shown at left) that allows our team to work in the way we want and allows us to reconfigure should that change.

We have a group of tables (and several whiteboards) in the lightest and most enjoyable place to work. This is where most of the magic will happen. There there are some smaller tables divided by bookcases and corrugated plastic to provide privacy for solo working conditions. There are plans for a conference room that can seat 8 around a table (potentially too big?) and house a projector and whiteboards.

Outside the conference room there are several spaces to for more casual seating, either in chairs facing another whiteboard or in front of a flat-panel screen on the couch. Lastly, there is the break room/alternate meeting area with several tables a fridge and a sink. All told, it is a pretty simple (and relatively inexpensive) arrangement that serves our needs well.

We’ll be planning a small open house of sorts soon. We’ll be sure to post about it when we get that rolling.

You can view a few more office photos in the Refactr Flickr group. More photos will be posted as we go so check back and/or join the Flickr group.

G2One is a new company founded by Grails lead Graeme Rocher, Groovy lead Guillaume LaForge, and Alex Tkachman of IntelliJ IDEA. Here is Graeme’s post about it. Refactr wishes them good luck but they won’t need it with that team as a foundation.

On some level it seems to make sense, when building your startup staff, to want your “generals” in place before you start drafting your soldiers. That way plans can be made, hierarchies established, and processes put in place. But, it is precisely because these seem like perfectly responsible and sensible things that so many software start-ups spend so much time and money before they ever ship a product. Ostensibly, the goal of hiring the project managers, business analysts, data architects, and the like is to lay the groundwork and improve the efficiency of the team. The problem is, the efficiency these companies are seeking is squandered in the weeks and often months that it takes for these roles to actually get going at full-steam.

When organizations get top-heavy and the management and analyst ranks swell to outnumber the designers and developers there is cause for concern. The startup would be much better served hiring more developers and designers and let them build software inefficiently for a while. Then they can figure out their work patterns and identify where improvements to the process can be made. I would take 6 months of inefficient software creation over an equal time spent in visioning meetings, “process engineering”, and gantt chart plotting. How about you?

With many parallells to the Selling Agile to the Enterprise presentation Ross and I gave at last month’s minnēbar (un)conference, Scott Ambler, goes a bit further by providing specific language (like diminishing returns* or, my favorite, opportunity cost**) to use when speaking to senior management when speaking about agile methods and their benefits.

Senior managers are generally smart people, regardless of what we might like to believe, although they will often be operating with less than perfect information and choosing from a multitude of alternatives. If you go in with an “us vs. them” or an “I’m smart and management is stupid” mentality, you’re likely not going to get what you want. A better approach is to recognize that you need to provide sufficient information, or more importantly a coherent argument, to them using language that they understand.

While I agree that data is a very important aspect of presenting agile, (and Scott touches on this also) you shouldn’t underestimate the “gut-feel” that people have towards agile methods telling them intuitively that they do actually do work. This should not be surprising as it is how management felt about development years ago, before we (software developers) drilled it into their heads that software has to be planned carefully and methodically and that changes to The Plan^TM must be met with resistance, followed by pain and suffering. Things like communication, transparency, and dealing with ambiguity are things that top managers have known and have used frequently to get to where they are. They also happen to be three key strengths of agile methodologies. Still, maybe we can find beauty in NOT doing agile development.

* Diminishing Returns. As more investment in something is made, the overall return on investment (ROI) increases at a declining rate until it reaches a point where it begins to decline. For example, if a diagram isn’t yet good enough for the situation at hand, then you can keep working on it until it is good enough, at which point any more work on that diagram is a wasted effort. Although the continued work still adds value, it doesn’t add as much value as when you first started because you likely addressed the critical issues right away. The concept of diminishing returns is critical because it enables you to recognize that it doesn’t make sense to try to “complete” a work product.

** Opportunity Cost. This is the cost of passing up a choice when making a decision. For example, if you could have spent $10,000 in additional testing and avoided a mistake that ended up costing you $15,000 to fix, then the opportunity cost of not testing was $5,000 ($15,000—$10,000). The concept of opportunity cost enables you to communicate the value in taking, or not taking, a course of action.

I wrote a longish follow-up to minnēbar over at Alt Text but wanted to make mention here of the presentation that Ross Niemi of Thoughtworks and I gave this year, titled: You can do that? Selling agile to the enterprise. The slides are a bit sparse (though there are a few extra notes that show up when you print or view without styles) as we spent most of the time talking about related topics and fielding questions. I am happy with how it went as it was the first time I had given that presentation and was please that it wasn’t the same old intro to agile talk I have prepared time and again.

Here are a few notes from Christopher Warren on the session.
I’m not the only one who was involved, though. Here’s a quick post of some of what the Refactr team did at minnebar:

Jesse ran through a well-received session where he created a conference scheduling application using Groovy and Grails in 40 minutes or so. And Scott participated in the Web Frameworks panel in which he represented Grails. Other panelists included: David Heinemeier Hansson (Rails), Jack Ungerleider (Zope), Nate Straz (Django), Scott Vlaminck (Grails), and Derrick Shields (Code Ignitor).