Archive for November, 2008

Coworking. Poised to take off

About a month ago I started working at Carrboro Creative Coworking located in Carrboro, NC which is basically a part of Chapel Hill.  My experience so far has been really great and I have a few thoughts on why coworking is such a great idea and how I think it can grow in coming years.

Work-Life Equilibrium

For the first two months i was living in North Carolina I was working from home.  Although my office was comfortable and work schedule flexible, the time I spent working was (paradoxically) greater yet less productive.  I’m not the sort of person who had problems motivating myself to work, so getting distracted was not the problem.  I started to realize that separating work and life is not only good for your personal life, it is also good for your work life.  When I was at home, in the same environment every day, it is hard to find inspiration.  I don’t mean inspiration in a grand, snobby, artistic sense.  Just in the sense that seeing different people, places, and things every day stimulates my brain to think in new ways.  This is critically important to me in my job, and I’m sure it is for many others

It’s the People

No big surprise here.  Being in an environment where you can meet other people who have different ideas and different life experiences makes you better.  It makes you think more broadly.  It gives you an opportunity to make serendipitous business connections.  It gives you a channel to hear your thoughts outside your own head.  Whether you are an extrovert or an introvert, having an opportunity to interact with people on a daily basis gives a more rich and balanced life.

Coworking. 10 years from now

So it’s pretty obvious that I’m a big fan of Coworking.  It’s a really great concept and I think if it is able to overcome a few challenges (mostly in the realm of marketing), it is really poised to take off

In my opinion coworking will grow because

  1. A globalized, virtually connected world will create many more ‘work from home’ type jobs
  2. Certain industries (lets say journalism for example) might actually benefit from have a more distributed workforce if they can find a cost effective way to have offices (or coworking locations) in different places

Coworking as a industry has two main marketing challenges that i see

  1. I think the name is not obvious.  When i describe coworking to friends i have started to refer to it as just ‘shared office’ or ‘renting a desk’.  I get a lot of blank stares when i say coworking.
  2. The real benefits of coworking are the intangibles that i list above.  Although possible, it is harder to ‘sell’ these benefits because they are not easily directly measurable

Overall, I think coworking is great and I wouldn’t be at all surprised if this industry which is currently growing organically in different locations, begins to see a real explosion, perhaps big enough to support a larger regional or event national chain of offices.

Our President

Inspiring. Honest. Clear. Unifying. Respectful. Tough. Balanced. Leader…

Congratulations Obama.  Congratulations America.

Out of many we are one

Splitting a Team By Architecture: Bad Idea

Lets say you are working on a project where there are multiple teams all working toward a common outcome.  You are the manager and you sit down with your architect / lead developer (which could be yourself for all that matters).  You know the solution you need to deliver for your customers and you have started to sketch out a diagram of what your software system will look like.  Perhaps it looks something like the random image i grabbed on the left.

You scratch your head and say, “well, lets have team A work on the front end and team b work on the back end.  Well have joe manage team A and jane manage team B.”

Bzzzt!  While this is of course the most straightforward, neat, and logic way break up your development team.  Is is really the best?  My opinion, as you might have guessed, is no.  Here’s why:

One of the basic arguments for splitting a team up into front end and back is that developers on each team have less to learn.  They can focus on a smaller domain and theoretically become more skilled in that limited domain.  This makes good sense IF the main reason why a project fails is because developers didn’t understand their technical domain deeply enough.  Is that really the reason?  I think not.

I think one of the biggest reasons why projects fail is a lack of

  1. Deep understanding and focus on a customer problem (where a customer can be internal or external)
  2. Poor communication within a development team and around a development team.

So, if those two reasons resonate with you,  why would you split a team across front-end back and lines?  Splitting a team that way only serves to:

  1. Remove the back end team from direct exposure with the end customer
  2. Push communication channels up creating a bottleneck at the top

Lets go through my rational for why splitting a team causes these two problems and why they are so bad to begin with

Backend Team has less exposure to customer

All of a sudden, the goals for your backend team just completely changed.  What once was a common goal of “lets deliver a great product to our customer” just became “lets build a reusable/scalable/flexible/<insert quality attribute here> backend for the front-end team”.  While architecture purists might disagree with me, i think this is a very dangerous thing.  I’m all for great architecture.  There are few things more satisfying that beautifully organized code; however, this does not always deliever in the ways that you want to.  Remember what you are being judged on: how much the end customer loves what you build.  nothing else.

Pushing communication channles up

When you have two independent teams that report to different managers you are effectively moving lines of communication up through managers and their managers.  At first, this doesn’t seem like such bad idea.  Take the burden of communication off individual developers.  Let them focus.  Let managers communicate.  This theory is great when the communication is external.  Managers should be shielding the team from external distractions.  However, this is absolutely dangerous when the communication you are blocking is internal team communication.  Internal team communication is never bad.  In complex software systems, the more team members know what their other team members are doing, the better.  This helps to reduce errors, cut down on mismatched expectations, and increase developer confidence.  I can guarentee that 80% of this good mojo will get lost when it’s translated through a manager.  She just became a bottleneck for good communication.

What do we do instead?

For all the reasons I list above, create very small teams that are oriented around end-to-end features of your software system.  it’s okay for individuals to specialize in particular technologies or pieces of architecture, but make sure that all members of your team are focused on a common customer and make sure that they are forced to communicate with one another.  Sure, this is definitely trickier from a managers perspective, but that’s okay.  If you have a good team with good managers, they’ll be able to handle it.  Sure, it’s not going to look as pretty when you put your progress in some nice bar graph in PPT ’07, but how important is that really anyway :)