• Forming, Storming, Norming, Performing…

    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…

  • Creative and engineering .. how different are they?

    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.

  • Focusing on architectural debt

    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!