The world of entrepreneurship today is very different than it was in 1999.  The cost and time related to developing web applications are both much lower today than they were years ago.  That’s not to mention that entrepreneurship has grown considerably in popularity.  Starting a company now is a lot cooler than it used to be.  And people are getting involved at much younger ages.

The net effect of all this is that the world of entrepreneurship is much more competitive than it used to be.  So the natural question is: how can you be successful in such a tough competitive environment?  Let’s examine some of the differences between critical success factors ten years ago and today.

Of course, the above is an over-simplification.  But the core observations still make intuitive sense.  Getting a 1.0 product out the door is not the differentiator anymore.  There is a lot of competition on the internet today.  Getting a product out the door without a business or distribution model is about as good as not having built one in the first place.

So the more experience I have in building a company in today’s world, the more firmly I believe that creativity and innovation are really the core competencies required to build a successful business.  It’s about building something novel and valuable.  And doing so in a way that is delightful and easy to use.  There are choices for nearly every kind of web application today.  Being the easiest to use and to share with other users is critical to success.

I think every american high school male, at some point, has a jaded ‘nice guys finish last’ phase.  It’s 2 parts sulking and 1 part being bitter that the world is not fair.  I was no exception.  I remember how sure I was that there was a correlation between being a jerk and having success in social situations (and with women).   I wasn’t the only person who was sure of this, either.  Just about every friend I had in High School complained about the same thing.  Except for those, of course, who weren’t ‘nice guys.’

Fast forward several years later, and I find myself thinking about how those teenage experiences shaped some of my later thinking.  From movies to books to pop culture icons, I found that there was this very consistent theme out there about ‘finishing last’ if you’re a good person.  The people who are successful in movies, books, and TV are typically those people who ‘do whatever it takes’ with blatant disregard for the wellbeing of others. (Think Lex Luthor)

I’m not sure how much of my thinking from younger years stuck around, and how much of this was just reinforcement from media, but I guess I always did subscribe to the ‘nice people finish last’ way of thinking (albeit, latently) until recently.

I have recently come to think that, in many industries, being a nice person really is a competitive advantage.  While I find some successful people generally unfavorable, I’m not so sure that’s the rule.  I was thinking about this particularly in the realm of Venture Capital.

VC is a fascinating space.  It’s a space that is made out to be cut-throat and dominated by ‘sharks.’  While I do understand that the valuation incentives in Venture Capital can be complex, I am starting to get the feeling that it’s a space where nice people actually finish first.

I’ve had the pleasure of meeting and working with a number of great Venture Capitalists over the last 5 years, and I’ve found myself to be really surprised.  As I think back on our decision making process for choosing capital partners, I find that we focused primarily on fit.  At the end of the day, all money is green, isn’t it?  Everyone who was going to help us with the capital part of the equation was going to bring money to the table just the same.

Yes, it’s true that each VC has a different ‘brand reputation’ and some are known for having stronger networks and more of an ability to contribute strategically to businesses than others.  But what I have found is that most companies end up talking to competitors within the same ‘tier’ of investors.  Within a tier, it seems that most VCs are comparable in terms of networks, reach, and reputation.

And more importantly, I have found that no amount of brand reputation was significant enough for us to overlook the feeling of ‘fit.’  At the end of the day, we chose partners who were comfortable working with for the long-haul.  People we thought we could trust and rely on in times that were good or bad were the ones that stood out.  And perhaps most importantly, we wanted to work with people that we truly believed had our best interests at heart.

And we think we got really lucky.  As I think about some of the really stand-out personalities we’ve had the opportunity to work with, I realize that we probably did get lucky.  But I also think that we’ve managed to build a great business so far, so I’d like to think that our investors will do pretty well also.  If they were ‘not-so-nice’ people that don’t care about the wellbeing of others, they would have missed out on a fantastic investment opportunity.  (If I can say so myself.)

–

So, my thinking has really evolved on the subject of ‘being nice’ and ‘doing well’ in life.  I am not so sure anymore that nice people finish last.  I think that, over the long-term, being a really good person can be a competitive advantage.

That’s a heartening thought…

So, I have been in social situations with fellow managers and have brought up the topic of group development and the model of ‘storming, norming, and performing,’ and no one knew what I was talking about.  So I figure it’s a fun topic to blog about.

ModCloth has been growing our San Francisco presence very rapidly.  When I first got here in March, it was just me.  Literally.  Today, about 3 months later, we now have more than 20 people in the office!  Something that has fascinated me since we started adding new members to the team was the dynamics of the group, and how they changed as more people were added to the team.

Sometime in business school, I learned about Bruce Tuckman’s stages of group development: Forming, Storming, Norming, and Performing.  Other than sounding cool and rhyming, I wondered if these stages actually had any meaning in real life.  (I wondered this about a lot of the stuff I learned at business school.)

But now that I have had the opportunity to grow a team faster than I ever had in the past, I am starting to get what Tuckman was talking about.   While I am not an organizational behavior expert, I do feel like I have seen some of the characteristics of these stages during our growth here in San Francisco.

1. Forming: The first stage of team building.

In this stage, Tuckman describes members of the team as being on their best behavior.  People are trying to be accepted by the team and get to know other folks at the same time.   There is a general sense of avoidance of conflict for this reason.  People work mostly independently because they don’t know other people well yet.  Because people are avoiding conflict and working independently, not much gets done during this phase, according to Tuckman.

I definitely feel like I have seen some characteristics of our early team that resemble this behavior.  Early on, people didn’t know what to expect from one another, so they focused mostly on their ‘own deliverables.’  They didn’t quite collaborate on anything, and they were still getting to know eachother.

2.  Storming: Competing ideas rise to the surface.

In this second phase, the team starts to put out competing ideas for consideration.  This is not only for the tasks/initiatives at hand, but its also for agreeing on the leadership and decision-making model the team will use.   This is the phase that people who dislike conflict will be the most uncomfortable with.  According to Tuckman, some teams will never actually leave this phase, depending on the maturity of the team and the willingness of members to give up their original ideas.

This is a facinating phase description to me, becuase I feel like I totally get it.  This resembles the stage that we were most recently (and may still be) in.  We have people from excellent backgrounds at exciting companies who have just joined the ranks and have a lot of ideas about how we should do things here.  Similarly, we have some people who have years of experience in this organization who have opinions about what works and what doesn’t.  It takes a lot of time for these ideas to come out and for the team to take the best from each.

For me as a leader, knowing that this stage exists in the first place is hugely developmental.  For someone like me, who is hugely impatient and is focused on results, this stage can be a little bit frustrating and disorienting.  Part of me just wants to get stuff done.  When people are thinking and talking about ‘how we are going to get stuff done,’ it was a little bit frustrating at first.  But I realize now that it’s a critical step in the teams growth and it’s going to enable us to reach a cruising altitude pretty soon.  In the end, we’re going to be better for it.

3. Norming: The competing goals merge into one.

This is the stage that Tuckman talks the least about.  I think he calls this out as its own stage because teams will not always get here.  If people are actually willing to put the goals of the team above their own, then they will work to put together a plan that everyone is reasonably comfortable with.

4. Performing: Only the best get here.

At this stage, the team is now effectively interdependant.  Team members are able to get work done without inappropriate amouts of conflict.  People have a sense of when they should work collaboratively and when they should work independantly.  The team will, at this point, be capable of making most (or all) of its decisions without external guidance or supervision.

I am not sure our current team is at this stage yet, but I do think that we are getting close.  I feel like I know this stage to exist because I have had the opportunity to see it in other organizations at other times in my career.  Being part of a high-performing team like this is fun and really empowers everyone to feel accomplished because the team is getting a lot done.

So, that about covers the model.  All in all, I think it’s pretty cool.  Just like most organizational behavior stuff, it probably doesn’t fit every team scenario.  That said, I have seen parts of this in the teams I have worked with, and it intuitively makes a lot of sense.  The most important set of takeaways for me are that different things are needed from leaders at different phases of team development.  Also, teams can revert back to different phases as a result of changing circumstances (such as people being added/removed from the team.)  Those are definitely things that I am going to keep an eye out for…

I often hear practitioners in creative fields (such as photography, design, and writing) and engineering fields (such as development, QA, systems, infrastructure) talk about how different they are from the other group.  This is sometimes in reference to processes from the other camp that ‘won’t work here’ or in reference to a frustrating experience that leaves people wondering how they could be so different from one another.

In either case, this is a topic that I’ve noticed people get pretty impassioned about.  It’s an interesting topic to me because creative and engineering practice areas are so critical to success in the my world of entrepreneurship and technology.  So I think it would be fun to explore (out loud) some of the similiarities and differences between to the folks in either practice areas.

I have to warn, of course, that this based on anecdotal evidence only and is in terms of my experiences.  I know there is a bigger world out there, and I am not trying to make sweeping generalizations here.  Anyway, here goes:

How are engineering and creative different?

It’s obvious that people in engineering and people in creative are different.  But people often draw this conclusion only by outward appearances, which I think is misleading.  So let’s dig deeper into the real ways in which the two archetypes are different from one another:

• They often work in different cycle times.  I have seen good engineering work and creative work happen iteratively.  But what I have come to notice is that the right cycle time for each type of work is often different.  Creative work generally operates on shorter cycles (1-day to a week) whereas engineering work often spins in longer cycles (1 week to a month).
• The way the teams collaborate is different.  Because of the cycle time of much of our creative work, one person can often own a task from start to finish without creating a reasonable burden of time.  (A great example of this in our organization is the creative writing team, where each writer can often take full ownership of writing a piece.)  Whereas in engineering, because of longer cycle times, usually a small team will take on a task, collaborating just to get to a 1.0 version.
• They talk differently.  Each group has their own set of acronyms and buzzwords.
• Their work has a different level of visibility to the user.  Basically everything that is done in creative is a direct touchpoint to the user.  While many technical tasks share this trait, there is a whole category of technical tasks that are completely under-the-hood.
• Non-practitioners shy away from one rather than the other.   Almost everyone in the organization has an opinion on creative, whether the have a depth of expertise in the practice area or not.  Engineering, on the other hand, is something that folks rarely comment on.  This likely has to do with the visibility point mentioned above.
• The skill it takes to do each kind of work is different.  This is obvious, but it’s worth noting.  There are people who ‘bridge the gap’ of skills between engineering and creative very well, but in my experience, those folks are few and far between.

How are creative and engineering the same?

Surprisingly, I think that there are quite a few similarities between folks in engineering and in creative.  Here are a few:

• They both require a strong attention to detail.  Whether you are 1 pixel off or you are missing a semi-colon, the tiniest things can throw a huge wrench in your day.
• They both collaborate to get meaningful stuff done.  I mentioned above that these teams often collaborate differently, which is true.  But collaboration in and of itself is critical to people in these practice areas getting quality work done that is consistent in architecture and/or style.
• The number of ways to do any one thing approaches infinity.  There are a million ways to design, photograph, or write something.  Similarly, when it comes to solving a technical challenge, there are a million ways the solution can manifest itself (even down to difference in technology choices!)
• Having ownership of a problem is critical.  Folks from either group hate it when solutions are prescribed to them.  The reason they are in their field of work is because they want to solve interesting problems and they want a sense of ownership of those tasks and initiatives.  Neither group wants to feel like drones that are simply doing monotonous tasks.
• User feedback drives their worlds.  Neither group can create terrific results without being plugged into the user community that actually touches their deliverables.  If either group operates in a vacuum, their likelihood of greatness hinges mostly on luck.
• Perfectionism comes stock.  In either group, skilled practitioners have a hard time ‘letting imperfection slide.’  If something doesn’t seem right, its going to gnaw away at them forever until they fix it.  Also, because there are a million ways to do something, the natural tendency is to try a number of possibilities.  (If we didn’t have a strong sense of urgency from the business side, most of us would just ‘geek out’ with the possibilities, in either camp!)

Conclusions and other thoughts

After exploring this a little bit more, it has become clear to me that these groups are not as different as everyone builds them up to be.  The similarities are more striking to me than the differences, at least to me.  At the end of the day, good practitioners in either category are committed to building great stuff.  In the end, I suppose thats what matters.

Most businesses seem to lean one way or the other when it comes to these archetypes.  That generally has to do with the founders coming from one background or the other.  This is something that I think it is very important to avoid.  Being out of balance in the direction of creative or engineering often causes more harm then good.  I think the degree to which these groups can collaborate together effectively is has a huge impact on the success of your business.

My last few posts introduced technical debt and then explained what you should do about it.  This recent theme hasn’t completely satisfied my desire write about the topic because I think there is a lot more to this ‘debt metaphor’ than most realize.  So I’d like to dig into it a little more here.

The commonly understood definition of ‘technical debt’ does not actually describe all aspects of what you might experience in the world of product development and engineering.  Technical debt is classically defined as writing sub-optimal code with the goal of paying it back (refactoring) at some point in the future.  And depending on how far along you are with your project/application/business, this may be all you ever get exposed to.  But as time goes on, and we increase the altitude of our perspective, we find that this classic definition actually doesn’t tell the whole story.

Technical debt doesn’t tell the whole story

As your organization matures, you are (hopefully) going to have very different needs for your technology.  Let’s take the example of a rapidly growing social networking platform:

On day 1, all you cared about as a founder was building neat features that peopled cared about.  The whole goal was ‘stickiness,’ because if people didn’t like the experience enough to come back, you’d be out of business in no time.  Let’s say, in this example, that you were very fortunate and your social network really took off, spreading across college campuses around the country.  Before you knew it, your focus changed really quickly.  You had to figure out how to keep the site up.  Scaling the application became the bane of your existence.

Eventually, you solved that problem, and new challenges arose.  It became about keeping people hooked on the experience even after they were veteran users.  Then peoples preferences evolved, and they wanted continuous streams of information, so you had to deliver that also.  Then you realized you had a platform on your hands, and it made sense to build in targetted ad-serving technology.  People were already standing in line to advertise, and they had quite a lot of feature requests, so your initial implementation of this system had to evolve many times over.  Somewhere in there, you realized that you could open up the platform to the world and enable them to build social-powered applications on top of your platform.   Then you realized that people actually freak out about privacy, so you had to make everything customizable…

Needless to say, even in the over-simplified view of the world above, we see that the evolution of a business brings with it many different stages where you must change your focus and evolve your product vision.

The evolution of a business creates architectural debt

If we zoom out and look at the whole picture in a scenario like this, we see that the reality is much deeper and more complex than ‘simply writing sub-optimal code for the sake of velocity.’  We have technology needs that change with time, whether they are new features or entirely new systems/sub-systems of the core application.  Over time, features can drastically change their manifestation.  As the user group grows, inevitably, everything is more customizable than it ever had to be before.  That’s not to mention the architectural changes that need to be made in order to scale.

You see, it’s all about the altitude of our perspective.  Even if we attacked the new features and technical needs in the most optimal way as each of them came along, we’d still be in a situation where the architecture of the application would be sub-optimal after some amount of time.  Even if each new component worked perfectly (in the most elegant and optimal way), the way they fit together is likely to be imperfect because not all of them could have been foreseen.  It all depends on how far up we go in terms of altitude-of-perspective.  Eventually, if we look at a large enough series of time, there is no way to avoid the architecture being lacking in some significant way.   So we see here that the simple term ‘technical debt’ won’t do anymore.  So I’m coining a new one: architectural debt.

The simplest acid test I can think of for architectural debt is asking yourself this question: If I was to rebuild my application/platform from scratch today, would the architecture be exactly the same as it is now?  If your answer is no, that probably means that your business and its needs have evolved over the last few years, and you are in a much better place to think about it holistically today than you were when you started.  Welcome to having architectural debt.

Refinance your architectural debt

So, you have architectural debt.  Now what?  Well, that’s easy, right?  Just pay it down like you would any other kind of debt.  Well… not quite.  The world gets a little more complex when you are dealing with architectural debt.

Architectural debt is much more challenging to deal with because it involves a lot more ‘capital’ in order to pay it down.  It takes a much bigger block of effort because it’s not as easily chunked into smaller blocks that you can tackle within your normal workflow.  Worse yet, you are likely to have architectural debt in the first place because your business has been growing rapidly and its needs have been changing just as quickly.  So you have pressure to maintain velocity in developing new features.  Obviously, in an ideal world, you could just stop all new development and work on paying down your architectural debt.  Alas, this is not likely to be so in your case.

So what you have to do pay down technical debt is akin to refinancing your loan.  With a refi, you end up paying down all of your debt at once by taking out a loan at a lower interest rate.  You still have debt, but it is cheaper to pay it off in the long-run.  The technical equivalent of this is to re-architect the core of your application, which generally includes the data model and the most frequently used/accessed components.  You will probably have to leave most of the other components alone due to lack of resources that can be committed to the project.  So you’ll just have to write legacy adapters into the core (re-architected) part of the application so it can still effectively talk to the other components.  But all components written from this point forward should be using the new architecture.

With time, you’ll be able to pay down the rest of the debt by refactoring all of the other components of the application (and systematically removing the legacy adapters as you go.)  You’ll begin by refinancing your debt, and ideally, refactoring the other components of the application is like making ‘lower payments’ because of a lower interest rate.  It should be easier to do and a lot more pleasurable for the engineering team.  And eventually, you’ll end up being debt-free instead of bankrupt!

In my last post, I introduced the ‘technical debt’ metaphor and talked a bit about why it makes a lot of sense.  In this post, I’d like to dive into why technical debt is so important and what you should be doing about it.

Why is technical debt important?

Technical debt is often overlooked because it generally has symptoms that lay ‘beneath the surface’ to the average user or manager.  By the time the symptoms become visible to the real world, it’s generally too late.  Those who ignore the importance of technical debt do so at their own peril.  Here’s why it should be top of mind:

• You are likely to face challenges with technical debt at some point in the future.  That is, of course, unless you are already have accumulated some and don’t know it yet.
• It is a problem that you sort of want to have.  That’s because it is a problem that scales with success and growth of your organization.  The faster the outside world makes you go, the more likely you are to rack up debt.
• If you don’t deal with it, it will catch up to you.  And when it does, it’s likely to be a big problem, such as downtime, slow velocity, or low engineering morale.

However, if you are smart enough to actually take the concept into account and work diligently to ensure you don’t go bankrupt, you’ll be a much better company.   You’ll be more agile and lean in the future because you’ll have a codebase that is ready for change and quick iteration.  If your code and/or infrastructure become stale and brittle, then you are simply asking to eventually become irrelevant.

In my opinion, velocity is the key competitive advantage in any business: young or new.  If you don’t have the foundation laid to go fast when you need to, your competitors will be able to out-innovate you.

What should you be doing about technical debt?

Step 1: Acknowledge it

Now that we know how important technical debt is, we can look into figuring out how to stay ahead of it.  The first thing to do is acknowledge that it exists.  While this sounds sort of simple, it actually can be more challenging than you think.  Most organizations have cultural elements that impede progress in recognizing debt.  In many organizations, sweeping things under the rug is a great way to keep management off of your back.  If you admit that something out there is sub-optimal, you’ll often get hounded and reprimanded by superiors.  In many organizations, the working environment doesn’t exactly value honesty and openness.  Mistakes are embarrassing, so you are better off not bringing them up.

You cannot let this be your organization!!  Work to create a culture of honesty and open communication.  People shouldn’t be embarrassed of finding sub-optimal technical issues.  Instead, they should feel a sense of ownership and empowerment.  The best way to get issues like this on the table is to explicitly set aside time for digging into them.  I’ve had a lot of success with carving out time to talk about technical debt at the sprint/release planner level as well as bringing it up in team retrospectives.  If you don’t explicitly ask for people to think critically about areas for improvement, they may never bring them to light because they are so focused on driving velocity with the upcoming features.

Step 2: Pay it back

Now that your organization knows that technical debt exists, you need to start allocating time to pay it back.  The best way to allocate time to paying down technical debt is to build it into the velocity calculations of your existing iteration planners.  That approach works whether you are using story points for estimation or hours for estimation.  Let’s say that your team has an average velocity of 10 story points for each iteration.  But you’ve come to find that there are is some sub-optimal code sprinkled throughout the  codebase.  You can start by allocating 20% of your time to paying down the debt.  So the team can take 8 points of normal feature work and 2 points of technical debt work off the backlog.

The key here lies in staying consistent.  Whatever you do, try to keep it up and make it part of your normal team process.  If you decide to maintain a backlog for technical debt, or you want to build technical debt tasks into your main backlog, just be sure to continue revisiting it and re-prioritizing it (like you should be doing with all your other tasks).  And be sure to consistently spend some velocity, even if its a very tiny amount, paying down the debt.  Just like with any amount of debt, you don’t want to continually be running a deficit.

Occasionally, you may find yourself in a place where you can do a ‘big payback’ of debt.  That’s sort of like overpaying on your mortgage to pay down the principal — it can’t hurt.  Sometimes the urgency of feature velocity is lower than others.  Also, sometimes there are bottlenecks in other parts of the organization that give you some time to focus.  At ModCloth, we engage in a ‘feature-lock’ around Holiday time, which gives us the ability to spend a little more time on debt than usual.

Some takeaways and other insights

So we’re done exploring some of why technical debt is so important and what you can be doing to stay ahead of it.  Some things to keep in mind going forward are:

• This is one of the more advanced concepts of engineering and product development.  Don’t beat yourself up if you aren’t effectively managing it yet.  If you’re thinking about it, you are ahead of most of the game.
• Effectively managing your technical debt really falls under the bigger umbrella of staying relevant and agile.  Agility allows you to be ready for change.  Anyone that has been in product development for long enough knows that your product is likely to become more of a liability than an asset at some point in the future.  The degree to which you can keep your technology relevant is the critical factor in how long your product remains an asset.

Oh, the power of metaphor.  I have been thinking a lot about how powerful metaphors go a long way in creating effective communications and laying the foundation for solid teamwork.  One of my favorite metaphors currently is the term ‘technical debt.’  It draws an excellent parallel between the worlds of technology and finance.  Also, it is a very important concept that I think anyone in the world of technology should be aware of.

What is technical debt mean?

Technical debt is a metaphor that was originally coined by Ward Cunningham in 1992.  It likens the ‘cost of going fast’ in the world of technology to the ‘cost of buying something you can’t afford today’ in the world of finance.  Technical debt often refers to writing sub-optimal code for the purpose of shipping a product on time (or within the current iteration).  Like financial debt, the goal in taking out these ‘technical loans’ is to eventually pay them back.

I sketched up a quick visual in the form of a box that explains the effort needed to do a technical task.:

The area of the box is the total amount of effort needed to complete the activity.   The total effort of a task can be broken into two main parts: a) the part that makes it work and b) the part that makes it work really well (under the hood).  The issue here is that folks in the business care only about the blue box.  But, of course, technologists care about the green box.  Focusing on the blue box can drive a lot of business value in the short-term, but foregoing that ‘green effort’ does not come without a cost.

Why is technical debt such an excellent metaphor?

The power of any metaphor is driven directly by its ability to create a picture in your mind that quickly and efficiently gives you a model of how to think about something new.  The ‘technical debt’ metaphor is such a good one because it really does give us a clean, simple, and familiar framework to think about something that most of us don’t currently understand.  Let’s explore some of the similarities between technical and financial debt:

• They both trade now for later.  When people go into debt, they are borrowing money to purchase something now as opposed to ‘saving up’ to buy it later.  That’s concept aligns perfectly with aiming to get some code out the door quickly.  You could ‘save up’ and do it elegantly and nicely, but that would take longer.  Might as well ‘borrow’ and get it out the door now.
• They both build up over time.  People don’t get into money trouble overnight; and they often don’t get into technical trouble that way either.  It’s a slow and steady progression of taking some liberties that you should eventually rectify that really gets you.
• Neither is necessarily a bad thing.  Debt is simply a financial instrument.  Many people use it quite effectively.  In fact, for very large purchases, most Americans would not be able to survive without debt.  (Imagine cutting a check for your house!)  Technical debt is the same.  The goal is to drive user value, and ‘borrowing time’ allows you do that more effectively.  Debt only becomes a problem when it spirals out of control.
• Both can be paid down.  Just like you can make monthly payments to slowly chip away at your financial debt, you can incrementally pay back your technical debt.  The secret for both is the same: budgeting for it.
• You CAN go bankrupt.  In your financial life, a series of small gaps can turn into a really big one.  If that happens, you might find yourself in a situation where you simply can’t get there from here.  Technology isn’t much different — at some point, the gap between where you are and where you need to be becomes too great.

It’s importance and what you can do about it…

I have lots more to say on this subject, but I don’t have the time to write about it just yet.  Stay tuned though!

Why ‘Work-Life Balance’ is a bad phrase

We’ve been talking a lot lately about building a great business that endures here at ModCloth over the last several months.  One of the phrases that often comes up in this context is “work-life balance.’  The more I think about the phrase, the more I realize that it is framed incorrectly.  It drives people towards an unhealthy way of thinking.  So we should change it.

When I search the net for the definition of the word ‘balance,’ here are some definitions that come up:

• a state of equilibrium
• equality of distribution
• harmonious arrangement or relation of parts or elements within a whole
• the difference in magnitude between opposing forces or influences

All of these definitions get me to thinking the same thing: balance is about having the ‘right amount’ of something.  If you have too much or too little of something, you are inherently out of balance.  So the term ‘work-life balance’ makes me feel like my work and my life are somehow at odds.  They are opposing forces that I must find a way to balance.

Bottom line: I don’t like it. I want more from life.  I spend my time working because I want to — I enjoy spending my time doing it.  The things I enjoy should not be at odds with my life; they are my life.

So, it’s time to use a new term: Work-Life Alignment.

Why ‘Work-Life Alignment’ is better

Now we’re talking!  Work-life alignment jives a lot better with the kind of life I want to live.  The thing that I do for more than 10 hours a day should not have to be ‘balanced’ with my life.  It should be aligned with my life.

When I look up the word ‘alignment,’ I find:

• bring into proper or desirable coordination correlation
• alliance or union with a party, cause, etc.
• integration or harmonization of aims, practices

I spend my time working with excellent people who  challenge me everyday.  The skills I want to hone align directly with what I do for a living.  I also am fortunate enough to spend some time ‘working’ with my wife — on a business that she started and I invested in.  For me, my work happens to be a big part of my life.   The word ‘alignment’ captures that much better than ‘balance’ does!

When people ask me about ‘work-life balance,’ I have a hard time answering them because I think their question is framed incorrectly.  Next time, I’ll tell them that I don’t believe in work-life balance; I believe in work-life alignment!

As our business continues to expand, we have been facing some interesting new challenges and opportunities.  One that has been on my mind a lot lately is cross-site collaboration.  But no good solutions exist that enable us to feel a little bit more like we are in the same room.   I am tired of seeing startups attack geeky problems that no one cares about.  Virtual team communication tools pose a problem for a lot of folks, and I know that many of us are willing to spend good money on a solution.

Cross-site collaboration is hard.  Lots of things about that really bother me.  First, it’s 2010.  This shouldn’t be a problem in this day and age, but it is.  And I am no stranger to virtual teaming — I have been doing it for nearly 10 years (before it was cool).  What I have found over the years is that many of the very typical challenges with virtual teaming are actually surmountable.  Things like timezone, language barriers, and even cultural differences can be managed.

But the thing that no one seems to have a great handle on is collaboration.  Most people will tell you that they have no problem collaborating in their virtual teams — but they are wrong.  They aren’t collaborating in the way I am talking about.  Anyone can sit in a chat room, use a wiki, and contribute to a Google doc.  But those of us who have done as much ‘real life teaming’ as we have done virtual teaming will tell you that it’s just not the same.

And here’s why: the secret to great collaboration and teamwork lies in the unplanned interactions.

The amazing thing about being in the same room as some group of people is that you can just walk over to someone whenever you are struck with an idea.  And you have a clear sense of ‘presence.’  When you need someone, you can just look over to their workspace and quickly see if they are engaged with someone else, not at their desk, or on the phone.  Wikis, chatrooms, and the other standard virtual fare don’t get you even close to that sort of connection.  You lose the power of that ‘instant-on’ communication.

Ok, fine, so it’s frustrating and hard to collaborate virtually.. particularly when you are spoiled by great ‘same room’ interactions.  But that’s not what kills me.  What kills me is that there is a real business need, and the market is wildly underserved.  All the while, I feel surrounded by a number of geeked-out companies that are solving technical problems that don’t appear to be worth money to me.

As a funny aside, it turns out that I am not the only one who notices the ‘overgeekiness’ of startups here in the bay area.  While I love being a geek, I have come to learn that solving geeky problems is not always the best way to build a real business.  Anyway, a well known and well respected VC recently called these businesses “boys building bigger toys for other boys.”  Haha, I love it.

Ok, back to the point.  This collaboration and cross-site communication thing is a mildly geeky problem for which I’d actually pay money for a solution.  And no one has done anything about it!  Ahh!   Maybe the problem hasn’t been framed well enough.  So let me quickly build the case for why someone should really take a stab at solving the collaboration problem:

• The knowledge worker economy is becoming more global every single day.  Companies are able to acquire a lot more talent a lot quicker if they look outside their specific geographic region.
• People really want better communication tools.  Every virtual team I have been on has complained about how difficult it is to communicate and collaborate virtually.
• The alternative (travel and getting in the same room) is very expensive.  Any solution that is reasonable in cost creates serious value.
• In a lot of cases, for virtual international teams, it’s not even a money problem — there are logistics and long wait times associated with acquiring visas.
• Internet connectivity, which used to be a big barrier to high bandwidth communication, is getting better everywhere.
• The timing is good right now.  The companies that failed in the past were just a bit too early.  Collaboration wasn’t mainstream yet.

So, in some ways, the stars are aligning for a good collaboration tool for virtual teams.  Ugh, I don’t really like the term ‘collaboration.’  It sort of lumps this into the same category of SAAS web apps like Basecamp and ProofHQ.  That’s a whole different kind of collaboration and team management.  But that’s not the kind presence, instant-on, better communication tool I am talking about here.

The tool I am thinking about, of course, centers on video as the medium.  It’s something that helps groups and teams in different places feel as close to being in the same room as possible without actually being in the same room.  That’s what we need.  (And we can’t be the only ones who need it!)

Here are some thoughts on what would make a decent product:

• Video is crucial.  Resolution is less important, but adapting to the internet connectivity conditions would be nice.
• Another device is fine, and probably preferred.  People have enough to do with the limited screen resolution they have on their machines.  Another device with another screen that is separate from your existing computer would be great, for this reason among others.
• Hardware and software that play nicely together would be convenient.  It can’t be that hard to choose one or two ‘core models’ of hardware that the software works perfectly with.  I’d even buy them as a package deal.
• One-to-one communication is NOT ENOUGH.  (*cough cough* Skype.)  Really?  You think one-to-one video is enough to serve people’s needs?  I could write a whole different blog post about the silliness of this.
• Open standards would be great.  I am tired of closed systems like Polycom that only play nice with other systems of the same brand and cost a fortune.  One single standard that worked across brands would be fantastic.
• $83,000 is probably too much.  I know Cisco has great telepresence solutions, but I have a really hard time coughing up $83,000 per solution.  Someone has to be able to provide a solution for a more reasonable price point.

So that’s it.  That’s the end of my rant.  I hope that VCs and entrepreneurs alike wise up to the opportunity here.  The need to collaborate is not going away anytime soon.  We are in the year 2010.. and I still feel like we’re in 2000.

I have to believe someone out there can be crafty and combine commodity hardware with open-standard software to create a really exciting and affordable solution.  Whoever does is going to get a lot of orders from me!

In my last post, we just began exploring the idea of agile design.  The quick conclusion was that there are significant similiarties between design and development as creative processes.  Agile thinking can be effectively applied to both.  The big question is about specific implementation.  How would it work?

There are two ways that I have seen agility applied to design.  For lack of better terminilogy, I’ll call them the:

• two-wheel approach
• one-wheel approach

Let’s start with a quick explanation of what each wheel means.  The two-wheel approach treats design and engineering as two separate teams (or even two separate organizations).  In the two wheel approach, the both teams are working iteratively to push ‘shippable deliverables.’  For designers, it would be shippable designs.  And for coders, it would be shippable code.

The natural progression of work tends to be that the design is done before the development.  As such, the the design iterations generally drive the development iterations.  Once a design product has been marked as solid enough for implementation, it is ‘completed’ in the agile design cycle and it marks the beginning of an agile development cycle.  The lengths of the iterations don’t have to be the same across design and development.  In fact, I’ve seen shorter design iteration length have a better chance of success.

This is one way agile design and development can be done.

The one-wheel approach is primarily different in that it treats design and development as one ‘product development team.’  This is a cross-functional agile approach for which there is very little precedent.  In this approach, the team is all pushing towards one shippable deliverable together, and each person is doing their part side-by-side with folks of other disciplines.

In the one-wheel approach, the work is not as cleanly sequential.  What ends up happening is that some work is sequential, other work is parallel, and a lot of work ends up happening in mini-iterations within the iteration.  For example, a designer may produce a mock and pass it to a developer, but can be involved in ensuring that it is implemented in a pixel perfect way by the developer on the team.  As the developer has real-time feedback, the designer could very quickly re-mock and pass the mock over again.  As the UI of the app increases in fidelity, the designer can start producing unforeseen assets like icons and other images that are implemented downstream.

Another way to accomplish agile design and development.

Of course, the million-dollar question is: which approach is better?  The honest truth is that I don’t know yet.  I have used both and have seen pros and cons to each.

The advantages of the two-wheel approach are:

• Much easier to do when teams are distributed.  (Even moreso if they are distributed by function.)
• Enables cleaner divides in the organizational structure.  This is particularly useful if your organization is already entrenched this way.
• Easier to implement from a complexity and organizational change standpoint.
• Potentially more efficient in terms of people working on the thing they are skilled at all the time.  (Little to no downtime.. and designers are always designing and coders are always coding.)

The advantages of the one-wheel approach are:

• You get more happiness and buy-in because everyone is involved in the final implementation decision.
• When velocity really matters (you are under the gun), the micro-feedback cycles of a cross-functional team are significantly faster.
• Potentially better outcomes from having diverse viewpoints at the table.
• Potentially more scalable.  Having many cross-functional teams scales more cleanly than bigger and bigger functional teams.

What I am trying to figure out now is: are these approaches more or less appropriate for different circumstances or phases of growth?   I, unfortunately, don’t know the answer yet.  Of course, if you are not in a startup or not in a position to mold the structure of your organization, then the constraint of organizational structure can drive your decision.  (Most of the time, that will drive you to the two -wheel approach.)

The one-wheel approach has some potentially large benefits (like better product outcomes and more buy-in!), but it takes a lot more organizational buy-in.  Cross-functional teaming can be very complex to implement, particularly in organizations where different leaders of different organizations have strong visions for ‘how things should be done’ in their world.

I’ll try to report back after I know more!