Process and Structure aren’t four-letter words

Why do people hear the word “process” and see themselves caught in a flood of molasses, moving slowly toward an ever-stickier goal? Why do people hear the word “structure” and think they’re going to be chained in place and performing jerky, robotic movements?

I try to school myself not to say these words. Not because I don’t believe in them. But because “them’s fightin’ words” for many people.

The moment I try to systematize something as simple as talking to a user, or plan for a second on how to engage users, if I use the “p” word or the “s” word, ears shut off and people hear 20-page status reports and if-then cases that run to 400 pages of instructions on how to brush their teeth or something.

No No No No NO!

I’ve spent many, many years as a musician, and one thing that I’ve learned is the value of jamming and the value of rhythm.  And that’s all Process and Structure are – the bones of the framework for the jam session.

Process is the rhythm around which the awesome project is built.  Rhythm can be heavy or light, but it needs to be there or things go nowhere.

Structure is the rules for what key to be in, the overall chord transitions, the tradeoff points between melody lines.   Structure can be heavily mathematically precise or loose and flexible, but, like gravity, it needs to be there or the jam session is just chaotic noise and wannabe soloists playing over each other as they jockey for position and attention or even just something interesting to break the boredom of noisy inertia.

My history is about not supplying too much structure or process.  It’s centered around light weight and trust in my teammates and shared goals that mean that none of us need overspecification and 400 pages of what to do if the cap is on the toothpaste or the lights are out when you get to the sink – you’ll figure out the best way.  Besides, the 400 pages of instructions don’t cover how to suppress new-vocabulary-word expletive education for the nearby minion when you’ve dropped the tot-lok magnet on your toe while trying to get the toothpaste out of the kid-proofed drawer. Oops, make that 401 pages of instructions. And counting.

Simple process: Remember to brush your teeth on the way to bed as part of the regular routine.  You know how.

One line and done.

When someone proposes a big, over-controlled structure to make a decision, the response shouldn’t be to pick it apart, and debate the merits of squeezing toothpaste from the middle versus bottom for hours on end, then move to rolling versus flattening as the tube empties.   Way too easy to get lost in the details and a permanent state of low grade hostility (“I am not even trusted to know how much toothpaste to use!”)  that substitutes for progress.

Instead, it’s back to what is the goal, and why is someone proposing that the toothpaste be kept in a drawer, neither in the front nor the back, but right in the middle, just left of center.  What’s the requirement here?  Off the counter?  Find in the dark so no brushing teeth with antifungal cream? These rules and over-detailed process specifications hide the bones of a very short, light statement that treats everyone as competent and allows for different brushing techniques.

How to extract that nugget from the overdescribed rules?  Here’s the simple, lightweight framework that I use:

First, are the goals clear?  Everyone know which end of the field we’re aiming for and what counts as a score?  In this case, WHY matters as much as WHAT, because you’ll never think of every.single what.  So the more every person knows what winning is, and how we know when we’re there, the more each one can test any decisions against “is this getting us closer to done and won?”

Second, what are the boundaries and what happens when we hit them?  If we all trust each other, where are the fences and issues where we need more visibility?  Is it when we do integration?  When we add new dependencies?  When the interfaces change? When performance testing shows significant difference from expectations?  What do those boundaries look like and what actions do we take when we get there?  Send an email?  Run some tests?  Ask for another set of eyes?  Put it under source control?

Third, what are some typical and hard situations where we need a structure or framework?  The typical, easy cases, well those are used to build the bones of the structure.   What do those workflows look like among all the individuals?  What’s the goals of each of their steps?  Those are the ribs of the structure.

The really hard cases are the ones that we test it with.  Within the framework do we come up with a way to handle the hard cases, all the way down to ugly details at ground level?  Does everyone agree that that way is acceptable, that even if there might be more than one possible way to cope, the framework drives to an acceptable means to address the issue?  We’re not looking for the best way here, just good enough and that the framework makes it easier to do the right thing and harder to do the wrong thing.  Honestly, when a real difficult situation comes up, it most likely won’t be exactly like the ones under discussion here, so the real goal is to make sure that the structure encourages the right process and acceptable solutions for things as they’re encountered

Fourth, what kind of communication and checkpoints do we need?  Even with connection points and fences and actions, it’s still worth checking in now and then to make sure that the framework doesn’t need some tuning.  These are the fine points of process.  I’ve found that demonstrations and discussions centered around actual use cases are much better than theoretical discussions.  Decide whether you need synchronization (meetings) or async discussions.  Use these lightly, and multi-purpose – tune process and build team – people are MORE important than the individual artifacts, because they’re going to be making many decisions outside the discussion, so these sessions are really about building understanding.  The goal is to have openness and trust that everyone’s working toward the same purpose, so these checkpoints are about making that happen more directly.  And “do we need this?” is always one of the first questions that we need to ask.  And adjust as needed.

This gives people the room to be themselves.  It means that no one is playing retroactive lawmaker, coming up with 50 steps to address yesterday’s minor issue that won’t ever happen again.  It means the team guides itself to efficient execution because there’s room to do it right and guidance on what “do it right” means.  And when that breaks down, there’s a way to deal with that which doesn’t involve acrimony.

Done right, process is as liberating and freeing and energizing as the best jam sessions.  People cover for each other and transition seamlessly and breathlessly, as a single living organism moving toward the same goal.

User Experience Driven Development – An Overview

I attended a talk last week about some pretty cool big data analysis. Part of it included a demo about how the conclusions were drawn – again, very cool  Unfortunately, the speaker also included the same comment a couple of times, “Of course, we need to  improve the user interface.”  Lots of words and a few boxes and highlights in what looked like a pretty standardized template, like the MadLibs games we would play as kids asking for a noun and a verb and a color and an animal and a food, filling them in and reading aloud a story about “One day I went camping in the chandelier  and we roped a red hamster and fed it pickles.  If you were familiar with what was being asked, you could get an understandable answer out.  If not, much hilarity ensued.

Now, first and foremost, I am a software developer.  I do a bunch of things, and I once wrote a post on another blog about how important it is for me that the project management pieces fit together as nicely as the actual software architecture, so I have a foot in both worlds.  But really, from the top I take a technical view of things, and while I am a writer, my favorite medium for writing is a software language, and my favorite entry mechanism is a programming editor.

So my favorite thing to do is to play with data, to build connections between different subsystems, to massage the data and the sources to make connections.  However the output looks. “We can fix that later.”  Or I could’ve said, “Of course we need to improve the user interface.”  Because I’m an infrastructure kind of person.

At least I was.  And then we tried a different way and got some pretty amazing results. And now I’m a convert.

The project was a manageability project, focused on applying data warehouse techniques to performance and manageability data.  Correlating log records, performance data, configuration data, health check output, and workload information to build a tool to allow at-a-glance management across the entire software stack and standardized across various data manageability frameworks.

We knew we had lots of data, but needed to turn that data into information.  Not much different than any other sensor analytics or BI problem, actually.  But with lots of objects to manage in a big data world, lots of workloads, lots of processes, lots of entities, there was no shortage of things we could do with it.  The real answer, was…. what makes sense?

The answer that we came up with was that we wanted to provide the tools for the various big data administrators to tell their stories.  To compare performance from last week, last month, last quarter, last year.  To predict when they would run out of headroom in their clusters based on workloads.  To see when workloads were outliers.  To be able to tell why things failed last night, looking at the log records and health check results from their Hadoop distro.  To handle the “Why is my query running long?” question when an user calls in after an ad hoc query – was it a disk failure or a crazy query plan?

That is, we had to focus on our users and what experience we wanted them to have.  How to make sure the tool fit their needs like a perfectly balanced hammer or screwdriver or saw.

So we started talking and walking through some scenarios based on our own past experiences in this domain.  Not individual use cases (though we sometimes did get to that level), but more workload tasks and “playing” with the data, working through “If I were debugging a problem, where would I look.”

This is trickier than it sounds, because each person uses different  keys to hint at what’s going on when they’re on a fishing expedition to figure out what’s going on.  Dietrich Dörner calls these “supersignals” in one of my all-time favorite books, The Logic of Failure. Frankly, I read this book, devoured it, really, and it changed my life in lots of ways. Not just for the projects I was working on at the time (not the one I’m talking about here) but also on the team dynamics and ecosystem in which we operated.  I still refer to my marked-up dead-tree copy, as well as the version on my tablet.  Amazing book.  HIGHLY RECOMMENDED….

Supersignals are each individual user’s way of dealing with complexity, “the existence of many different independent variables in a system.”  As Dörner says,

Complexity is not an objective factor but a subjective on. Supersignals reduce complexity, collapsing a number of features into one.  Consequently, complexity must be understood in terms of a specific individual and his or her supply of supersignals.  We learn supersignals from experience, and our supply can differ greatly from another individual’s.  Therefore, there can be no objective measure of complexity.

This is why one person looks at the log records first, then workload data for a particular job, and then the memory usage to discover an obscure problem with data ingest, while another person looks at transaction rates and disk IO rates before discovering the same thing.  And a third person looks at CPU rates and disk space usage and takes much longer to arrive at the same conclusion – it’s the set of supersignals they’re use to.

For situations, like this, you simply cannot prescribe a single precise workflow for arriving at at explanation of a particular scenario when you’re looking forwards at an issue.  (The answer is generally pretty clear with hindsight though).  Instead, the UX goal is to make it easy for each person to access data his or her own way, in the order she prefers to be able to suss out the factors that help explain and resolve the current situation.  Want to monitor logs by time?  Sure, easy.  Watching workloads throughput over time and for a particular application?  Fine! How about health checks at the server level ?  No problem – watch those too!

But sniffing out places where the issues are causing your antenna to twitch is only one piece of the puzzle.  The other piece is giving the tools to make it easy for you to tell your story (or, for this project, the big data administrator to tell his or her story ) to other people – other administrators, or managers, or even CxOs wanting to know whether there’s a big change in IT budget needed to handle upcoming trends, or when to predict the next quarterly rollup.

The UX for explaining these things to others is just as important as the UX for finding issues.  Both of these sides of the tool have to fit naturally with the way you think, like a chisel in a sculptor’s hand.

So we took a UX-driven design strategy.  We started with “what data is available, what tests could we do, what issues do people often see here?”  But we didn’t stay at that point very long.  Instead we jumped quickly to something very different:  We asked why would I care about this data? In what scenarios does this feed my need for information, and how  do I use it there?  Translated to different units?  Grouped across all activity? Isolated into a discrete chunk? Over time? One-time?  Associated with similar workload I recognize because they look like this? And so on.  What is that experience like?” is the question that drove us . Once we’d worked through that, the what of the actual implementation details was trivial.

This approach resulted in sketches and wireframes and mockups and “how do you connect the data?” and “when and how do you move from this topic to that?”  and “what kinds of charting make sense for this?” and other similar questions for anyone we could find who had any interaction with the subject at hand.  That meant lots of  fast user review and lots of informal feedback. Short cycles and lots of prototyping with show and tell.  And lots and lots of discussion about what might and might not work, where everyone’s feedback was critical.

As the wireframes and mockups were solidified, UXDD led us next into demos and discussions that invited people in, talking about how problems that they see would manifest themselves in different ways, sometimes ambiguous, so “that hints that we should go look at the event log to see if there is anything from this component.”   A radically different style of demo and discussion than what I’d typically used in the past, because suddenly it was real and personal and shared ownership, rather than instructions and canned scenarios and something akin to a scripted presentation spiel.

We learned a really important lesson here, one that was picked up from another great book, Sketching User Experiences:  Getting the Design Right and the Right Design by Bill Buxton.  The biggest advance was that we needed to have sketches when getting user input.  Not final, fancy drawings and screens with color and fixed positioning and fonts that looked like we’d invested lots of time in them, but obvious sketches and rough outlines.  If things looked too done, too formal, we found that we didn’t get real feedback and contribution.  At best we got “OK, that would work” or critiques of color choices or maybe small screen layout hints.  People didn’t want to criticize something that they thought was too “done” for their input to matter.

So we intentionally made things look sketchy for these discussions – no shading or detailed data, obviously fake-data graphs.  And especially not anything that suggested we’d invested a lot of time and effort in something  We’d bring up a drawing tool  and just start drawing circles and arrows and numbers and lines together on the fly, from a basic “nothing invested here, just to get us started” template. We didn’t want people to hold back and with a sketch, it seemed that they had no problems suggesting changes.  Sketches converted our discussions into a shared development/discovery process, rather than “can you comment on this?”. This actually turned out to be a pretty critical breakthrough for getting great feedback to refine our various screens.

In effect, we refined our UX for having a UX design discussion based on the style and depth of feedback received.

Those discussions also drove the infrastructure design for additional data acquisition, frequency, retention knobs, etc.  We took the thinking and feedback and worked backwards to figure out what kinds of data we needed, for how long for both decision making and retention, what it might be combined with and on what dimensions (not just temporally, but also things like workflow and cluster, and business grouping).  Then we worked to make sure that those associations were easy and natural to do.  Like breathing.

While the final details for the user interface for types of data or new services or new connections were being tested and finalized, we were busy hardening the plumbing and data acquisition.  Then, with it all integrated together, we could again examine the UX and play with the data to figure out whether there were additional ways to extract information from data, and talk more with our users to see what they could do now that they couldn’t do before.

This integration phase was the key, because it was only then that we’d discover disconnects between human thinking and what the cluster and its component entities did, everything from timescales to data that needed more translation before being human-friendly and query-read.  But the flexible architecture we chose made that level of change pretty easy.

In this way, the product advanced in leaps and bounds, with a breathtakingly fast turnaround.  And it led to fast understanding and a sense of ownership from our user community too. In the space of a half hour or so, it was easy to take users from “what is this?” to “can I have this now because I need it to answer the questions my boss just asked me about our resource usage, even though you didn’t show that exact scenario…”

Had we followed the more traditional use case driven design, “A user wants to debug a problem with a disk,” well, the result would most likely have been much less flexible. Do A, then B, then C, which will prompt action D and if that doesn’t work, step E.  And displays that, once you know what they mean, you can make sense of them, kind of like detailed weather models with lots of interpretation required, rather than intuitive understanding. These kinds of things are great with hindsight and with high predictability.  But many real-world problems aren’t like that, and it’s the hard ones that challenge you.

The technology in the talk I attended last week was pretty darn cool, but that coolness was lost in a sea of words and numbers, so that the important information, the actual value from the system, wasn’t visible.  It was technology but without an immediately compelling story that invited people in.  After the talk, I could see how I might use it conceptually but I couldn’t detail it out and integrate it into my big data worldview.  Why?  Because the interface made it appear that my involvement was entirely an afterthought, rather than the purpose of the exercise..

If the technology had started with the UX, and their related emphasis on why and how before worrying about the what of the technology, I could’ve been sold….  And for startups in this space, that’s the real key to traction.

Thanks to Gunnar Tapper for reviewing an early draft of this post.

Teams – Breaking Up

This is a tricky post for me to write, but one that needs said. Or at least… one I need to write.  Sigh.

There’s a lot written out there about how to form teams.  How to get them to really gel and be high functioning.  How to streamline the environment so they keep rockin’ and rollin’, having fun and delivering cool stuff. People call those teams, “The best I’ve ever been on!” and “When I look back at my career sittin’ in the rocking chair on the porch at the Old Developers’ Home in the afternoon sun, that’s the one I’m gonna smile about most!”

I’ve been on those teams. I’ve been incredibly lucky to have been on more than one of them, actually, with people I would drop everything to work with again.    When the whole team has their heads in the game and we’re demo’ing and debating at show-and-tell sessions, there is no better feeling in the world. I’ve generally been the person who – in addition to my architecture and implementation tasks – has been the one who focused on the gelling and rocking and rolling, giving high priority to what I call “the teaminess thing.” Someday I’ll write about that and add to the universe my grab bag of tricks to help facilitate this because every single product designer should know that exhilaration, as often as possible.

But that’s not this post.

This is about what happens when the great project with that great team ends, either because it comes to a close or due to an external event.  What if that ending is happy?  What if that ending is unhappy?  Abrupt?  Tapering?  How do you do that well?  What happens to the team psyche then?  What happens to the individual members?

And most importantly, can you recreate the magic?  Or find new magic?

I wish I had the answers, the definitive answers, the guaranteed-to-make-each-team-better-than-the-last answers.  If you have them, please share.  Seriously. Because I’ve had success and gone onto greater things.  And I’ve had some very challenging times too, where it’s clear that the next-thing project just isn’t going the way I want my career to go and it’s time to move.

Meanwhile, here’s my take.


When the wheels come off of a team that’s tightly knit and focusing hard on delivery, the first thing that hits is shock and denial.  Maybe there’s warning signs – funding evaporating, corporate rumors of layoffs and budget battles, even discussions of spinoffs and or acquihires.  Maybe one or two key people bolt due to uncertainty or their dream job.  At that point, a team lead’s and team members’ antennae are twitching wildly, maybe hearing lots of rumors about what’s coming next.  But nothing concrete and definitive yet, except noises to calm the troops, lest the race horses and plow horses that make up a fabulous team get spooked.

And behind the scenes, lots of discussion about what might happen and whether it’s good or bad for “the best project I’ve ever worked on.”  As Rands says, “In the absence of information, people make shit up. Worse, if they at all feel threatened they make shit up that amplifies their worst fears.”  Every single team member has those fears and expresses them in his or her own way, and in a distributed team, those fears aren’t as visible.  So lots of one on ones and group discussions and comparing notes and DMs and Skype sessions.  Leads to more Fear, Uncertainty, and Doubt.  And that FUD causes more disquiet, just as managers go quiet other than “Hang tight.”

Searching for a lifeline amidst the rumors becomes a roller coast ride for as much of the team as is in on the secret.  A good, gelled team is a great hire, and companies and groups live for getting 4-6 high performance developers who work well together, especially if they’ve demonstrated that they can deliver.  Meantime, politically sensitive team members are also putting up feelers individually and in pairs.

But the gelled team is a loyal team, and no one wants to break up that magic so there’s a lot of magical thinking and denial too.  In the choice of technology or team, a tight knit team tries to find ways to work together across this transition, and at the same time imagining that things can continue if only certain features are delivered.  Or even serious denial that anything is going on and the team turtles into its shell, ignoring the environment and just continuing as if nothing is wrong.  At the same time, sharing lots and lots of rumors, and people start to think “What’s next?” and put out feelers..

Your job as lead or manager here is simple:

  • Be open and honest about what you know and don’t know.  Don’t spread FUD but do listen to rumors and assess the team’s concerns. Go for as much reality as you can, for good and bad.  Make time to talk to everyone, from most senior to most junior.
  • Acknowledge that the team is its own life, its own culture, separate from the software that you’re working on.  Try to ascertain how loyal people are to that team versus technology.
  • Be open that there’s a very real possibility that not every team member will cross the transition as part of the team.  And so the team will change, no matter how tight things are.
  • As lead, your job is to protect the herd as best you can, looking out for them individually and as a team, advocating for the continuation where possible and working to help folks transition if needed.  Look for ways to have the team continue together and actively represent the team in that process.  Play fairly with external opportunities for the team and for internal new projects, but focus on protecting the team psyche because it’s much harder to get back to fully-gelled and running comfortably at high performance than it appears, so focus on maintaining the communication and energy that make that happen:  Keep up the rhythms and rituals and humor and happenings that make this team special.  Even if the jokes become bittersweet at times.

If things back down from this stage and the team can continue its project, great!  The dedication and loyalty shown here further binds the team, making it more resilient if the issue resurfaces.  If the rumors start getting more concrete and leaning towards change, the openness that the lead fosters helps the team and its individuals cope with the impending change.

I’ve been the team lead here, worrying about getting everything done, even as I see our project coming to a very ambiguous close.  It’s hard, it’s a crapshoot that you’re aiming for the right thing given that you have no crystal ball, and even when you talk with other team leaders, it’s not clear you’re doing the right thing.  Looking at yourself in the mirror is painful as you ask whether you’re doing the right thing when you don’t have all the information either, especially if you’re pushing folks to complete something before the world ends, and you don’t even know whether it ends with a whimper, a bang, or a wormhole to the next thing.


At the point where rumor starts to become reality, the theoretical transitions break the old bonds.  If you’re lucky, the old project wiggles through and keeps going, with many or all of the existing team members intact.  If not, then the change is much more radical.

Each of us comes with a default reaction, an initial setting of how we view the world.  That setting can be overridden by logic and reason over time, but the first reaction is purely fright-flight-or-fight, often based on a glass-half-empty vs glass-half-full life perspective.  And so, as the rumor to reality transition occurs, this lizard-brain reaction becomes the first thing that each individual has to deal with, both privately and publicly.

And as team lead, you have to modulate your team’s reactions, public and private, while dealing with your own initial reaction.

What goal is the team striving for?  The answer to that might seem to be cool technology, but in my experience, actually the answer for what a really high-performance team is working for most often is itself – the high performing team does not want to let itself down. That sense of “we face the world together and we’re doing this as a team and I want to live up to everyone else’s high standards” binds a truly gelled team more tightly than any management incentives could.  Maintain that, and even if the team does get broken up, the loyalties and strong feelings remain.  Lose that, and the team shatters like a bad teenager breakup. But maintaining the sense of “we did not let ourselves down” is incredibly hard in the face of a startup failure or project cancellation.

And further, everyone’s role is uncertain, which causes a lot of jitter across the whole team, those looking forward and those who had blinders.

If the rumor mill stage distracted the team, or if it focused down hard to deliver and position for an uncertain future, this phase mostly has the temporary effect of blowing the team out of the water.  Even if the team is continuing, so much is changing rapidly, that very little gets done that can be directly used for the future.  Too much uncertainty.

And often, too many goodbyes.  Team members are letting go and perhaps flying apart.  Maybe some or all will work together in a new spot, or have different, parallel roles.  But the future is so uncertain beyond the next moment that there’s nothing reliable to hang a hat on and derive comfort.

No matter how optimistic a person is, no matter how pessimistic, the actual transition point is a shock and a blow, complete with the full on cycle of grief:  denial, anger, bargaining, depression and acceptance.   A good thing is changing, and while change can make things better, regression to the mean suggests that this high-performance team backs down the old performance scale at least for a while, if it even continues in some semblance.  And that’s hard for everyone to accept.  The gelled team looks to itself for standards, dontcha know.  But now, everything’s changing.

If the team mostly stays together, with only a small amount of dissolution, then the lead’s role (in fact everyone’s role) is to look to its collective health.

If the team is breaking up and everyone’s role is changing, then essentially the old project is so radically changed or dropped.  And that hits a team with strong ownership hard, even if the project or product was reasonably successful.  When the project is stopped prior to a successful conclusion, it’s even harder. Perhaps the company is dissolving because the concept didn’t get the traction that the believers in the company thought it should. Perhaps the project didn’t quite get everyone over the wall and into the next thing and there’s survivor guilt and mourning combined.  The product might be cancelled for technical reasons or political reasons, causing everyone on the team to question the project underpinnings.  The product might be facing a retirement itself, leaving others to wonder uncertainly about what’s next after a period of being a comfortable expert.

At the same time, the team’s leadership is faced with its own mixed emotions at the end of the project.  A gelled team finds that the team’s loyalties are as much to each other as to the product, and now both are being blown apart, and the leaders are forced to examine what led to this result.  Asking hard questions and focusing on preserving the high points and building them into next steps for everyone – hard, very hard.

No matter how successful or unsuccessful the project was, for a gelled team, this is the hardest phase.  Used to operating collectively, the team has its own life and its own style with each member’s contributions as essential as breathing for the whole. And now that’s ending.  Emotions are ragged, people react in surprising ways and each member faces the reality in a different ways.  This is where people say things you’d never expect.  Sometimes incredibly poignant and highly complimentary as people appreciate the beauty of a gelled team and their colleagues.  Sometimes incredibly rude or hurtful or angry as they lash out at the disappointment and unfairness.  Sometimes things that can’t be unsaid, which just causes the team further pain.  Why?  For some people, sharing that pain is the way to dissipate it, to release it to the environment.

Be kind to one another in this phase, and try to understand and even forgive the hurtfulness and anger.  I almost wrote “be unfailingly kind”, but really, that’s almost superhumanly hard.  Be kind to yourself as well as others.

The team lead needs to talk with everyone, one on one and as a group and to encourage others to connect. The team is people first, project second, and is at its most rawly human at this moment. It’s a tall order for the mourning leadership, but it’s time to:

  • Acknowledge what was:  This team was a rare thing, so understand what and why  and look for things to replicate,  And celebrate and remember, ideally with something tangible, even if it’s just a drink in the local watering hole or a virtual coffee break for a distributed team, or a memento, light-hearted or serious, that symbolizes the project for everyone who contributed.
  • Accept that things change: Change can be good or bad, but it’s a constant.  Right at this point, each change can be like scraping open a skinned knee, over and over again.  Quote Dory and “Just keep swimming, swimming, swimming”
  • Laugh and mourn and look ahead and backward as needed:   Communicate to the team and to each individual what s/he means to you and to the project.  Remember the high times.  Talk about what might’ve led to a different outcome and acknowledge that you did the best you could (or if you didn’t, come to terms with that – together).  Tell one another that it is hard and a roller coaster, and that this is one last hurdle to get through together.
  • Make sure that the connections are solid, even as the team flies apart:  Set up parties and summaries, write recommendations, share contact information, ponder who belongs in your “If I ever start that company, I’d call this person up” list and tell them that
  • Nudge that transition toward the future for each person, with openness and honesty and respect for each person:  If you see someone struggling, offer a hand.  If you’re struggling, speak out.  But turn toward “We’re here.  It’s now. What’s next?”  rather than trying to recreate a past that doesn’t exist any more.

Here’s where you notice people struggling deeply.  The more heavily invested in the project, the harder the transition. We’re all humans, even as we write kick-ass software.  If someone seems to be having trouble coping, no matter your role on the team, take a few minutes to talk with them.  Point them to additional resources in the community if it seems warranted.  Acknowledge the change and hang tight.  You’re still connected by common humanity, as well as a joyfully shared past. And perhaps a future too.

Even if the “now” part really, really sucks.


After the cataclysm and the shock of the team being blown apart comes the next thing.  And that’s a restart.  For many gelled teams, losing that sense of connection is harder than seeing the project dissolve.  Especially if the next thing that comes along isn’t as great as the previous team, or just takes a while to really get rolling.

It’s a truism that often highly gelled teams in larger environments are sometimes broken up in an effort to spread the magic.  If you take four great people who can complete each others’ project-sentences and propel each other toward the stars, and you spread them into four different teams, well, that’s four times the magic, right?


When you take a high-performing team and spread its members among multiple teams, either at the same company or in different companies, you’ve lost way more than you’ve gained, both short term and long.  A high-performance team feeds off itself to be much greater than each individual part.  When that team and those bonds are dissolved, individual and group productivity both go down again, way down.  The supports, the mutual pushing to excel and delight in discovering together as a team is gone.  Even if individually, each of the players was and is a star and everyone is local and bulding on each other, the collective magic is now dissipated.

It can be rebuilt over time.  But “over time” is not “immediate.” As the team members start over in new gigs, singly or in small groups, it’s just… different.  There’s new stuff to learn, different people to learn from and connect with and bond.  But it’s now people speaking a slightly (or majorly) different language, with different culture and different jokes and different speech and habits, and they aren’t yet your peeps the way the old team was.  Of course the high performance team members can usually pick these up, and if they’re stylistically compatible (a big if), they can grow.  But meanwhile, there’s more of that mourning and feeling like you’re a stranger in a strange land.  And when the change was incredibly abrupt or forced, well, that’s when you ponder a career change going away from something rather than to something.   Because the new gig isn’t your home yet, and the old home was so fantastically awesome and probably not replaceable.

But the key here is to force looking forward and connecting.  The new team might be better than the old team or it might not.  But you never know until you commit because the only way to create a high-performing team is to get to the point where everyone on the team is fully committed..  As a wise person once said, “Commitment is a self-fulfilling prophecy.”  That’s your very first step in the next phase of your journey – allowing yourself to go all-in at the next gig.  When you do that, you know you’re ready to fully begin.  Even if the tentative beginnings come in the form of two steps forward and one step back.

If you’re a team lead on a team with a new member coming off a project like this, your job is to:

  • Expect some fits and starts, even if the new member is pro enough to not say anything.  Every time a new member is added to the team, there’s a period of adjustment and rebalancing.  It’s harder here because the new member is dealing with what’s missing, as well as learning the new ropes and culture and style, which could be high-performing but very different.
  • Give the new team members something to commit to.  Not something vague and nebulous, but concrete and forward looking.  And a team of people to do it with.  It’s hardest when the members of the blown up team are isolated on singleton projects or an isolated thread within a team project. At this point,  connections are the most important thing for folks coming off a great team. Having lost his/her old connections and identity/role, it’s important to show that new ones are possible.
  • Support and experiment to adapt culture in both directions.  As team lead, it’s your job to experiment to get the best out of your team, sustainably.  Try new ideas, encouraging open honesty from all parties.  While the new member(s) can’t go back, they can bring the best of the previous project’s style with them as stuff to experiment with.  Encourage positive, open honesty about what works and doesn’t, but give everything a fare shake.
  • Balance innovation with respect for existing team members:  A team member coming off a high-functioning team project, whether voluntarily or not, should not be set up as the “fix” for team issues.  That’s threatening to the new team, both hierarchically and to each team individual, as well as a huge hurdle of heroism for the new member.  Been there, done that, and between the pain of the layoff that blew up my old team and the resulting “I’m still here and they aren’t” survivor guilt, and the challenges of the team that I was dropped into, it was was hard and did not go well at all.  I moved on pretty quickly from that one.  Which leads to
  • Accept that the new team member might move on more quickly than other new members.  Why?  Because s/he knows what a gelled team is like, and is trying to reproduce that.  Or because s/he knows that the new gig was a landing place to figure out the real next step. Or cultural incompatibility.  Or because of team chemistry.  Or just needing time to breath if the switch was sudden and unexpected. But don’t let this linger – encourage commitment (ideally to your project) rather than twisting.  Twisting just drags everyone down.

And if you’re the team member that is in the new gig, you need to:

  • Be prepared to roll with differences.  They speak a different language here.  Learn it and learn the culture before you speak too deeply and publicly of a glorious past.  Especially if you do so in contrast to the present.
  • Look before you jump in with suggestions, cultural changes, etc.  Build the connections that enable you to do this without criticism, and without sounding like a One True Believer in The Old Ways ™.    Because this team was already working well for itself – no need to change that immediately when you’re the only one used to the new ways..
  • Decide quickly if this isn’t the right gig for you.  Coming off a project rebound is hard, so if the first position doesn’t work out, analyze it quickly and look for a second place to go.  But be fair to your current teammates by being honest with them about the process.
  • Be kind to yourself. This is really hard, and frankly, if it was that great of a team, you’re probably still feeling a bit of mourning.

Moving on

Had dinner with an old colleague from the most recent iteration of “best project I ever worked on” last week, while I was down at my company’s headquarters for some new work responsibilities.  The latest project ended abruptly when some of us were spun out to work on a project that I hadn’t previously worked on; unfortunately the awesome project we were working on didn’t get spun out with us.  Still, a  few of us from that team were included in the spinoff because we can adapt and deliver fast as utility infielders. So I’ve been floating, putting together stuff for training, setting up IT procedures, etc. for a startup.  Learning a lot, but the old team, the best I ever worked on, was split in multiple directions and the ones who are in the spin out aren’t working together in the same way as before.

It was great to see him, to hear what was up at the previous company, and to get his impressions of what was happening there and for his career after the changes.  We reminisced about old times and the fun that we had, even as folks on the team disagreed (sometimes vehemently) and then boom! we were off doing something.  As he put it, “We worked long and hard, but we knew why we did it, we wanted it to happen and be great, and we had fun doing it.”  No better testament to a great project than that – makes my day!  I offered to help in his career planning and made some suggestions of things he could explore, and talked briefly about the new company.

But in the end, it was clear to both of us that it’s time to look ahead, not back.  Yes, that was a great project, one of those “highlight of your career” moments.  But it’s done and no going back.  Take the lessons and skills and apply them to new situations, because the future is ahead of us, not behind.

Next time I’m in town, I’ll look him up and I hope we can have dinner and we can talk about what’s new as well as what was.  And I look forward to hearing that it’s great things for both of us that we’ve moved on to other things, things which can be even better because we can apply the lessons from the previous project and build on those to do something even greater.  And who knows, we might work together in the future, since he’s one of the guys on my short list of people I’d call if I start a startup.  Meanwhile, best of luck to him and to every member of that awesomely amazing team, and if there’s anything I can do to help or just to listen, let me know.

Small Victories on the Path to Humanity

In the middle of a meeting today, a small group, just a couple of us I had one of those “Doing my part” happy-dance moments.  We were talking about the staffing needed for a particular project, understanding the availability.  And one of the attendees said something about how many people we need.  People.  Yes, People.

If you’ve been in this business very long, you know that sizing projects with people is something of a rarity in most parts.   Projects get staffed with resources.  As dehumanizing a term as ever existed.   Resources are managed like office supplies, with counts of how many pads of paper or pens or binder clips are needed per month to keep the notebooks humming.  Resources are managed like reusable grocery bags, stuffed and emptied at the pleasure of someone, then tossed in the back of the car for the next shopping trip need.  Resources are managed by spreadsheet, where some bean counter assesses how many board-feet per quarter-acre, and what sort of Resource Management (I’ve even seen this term applied to people managers!) is required to get the most value from this renewable resource sector after it’s been thinned or clearcut.

Those thinnings or clearcuts are called layoffs or RIFs or WFRs and are done with all the heart and soul of a forestry resource management plan or office supply spreadsheet when you start calling people “resources.”  Much easier to stomach than laying off real people with real lives and real families. Resources are nameless and faceless and so “safe” to think about abstractly.  Even if they’ve been to your house or helped you move.

My rule of thumb is very simple: If I see you in the coffee room and I know your first name, know that you have a newborn twins or a new car at home, have met your partner, know that you have a kid off at college, that you acted in a theater guild production over the weekend or just came back from a trip and showed me the pictures (I always love vacation pictures :)) you are most decidedly not a resource to me.  You might be very helpful, but you’re a person, a person with hopes and dreams and ambitions and things you find fun and things you procrastinate on and things that you gut through.  And I will treat you as such, because I work with people and that’s incredibly important to me – acknowledging our common humanity.

If I worked at a big company and met with the CEO in the coffee room, I am content to be a “resource” from her perspective.  I wouldn’t be asking her how her  weekend was, or that new car that she bought, or whether the new baby was keeping her up at night.  Instead, our coffee-room chatter would be a bit more formal (I’m rarely fully formal), about industry trends and directions, company initiatives, or even how fast the parking lot fills up in the morning.

Besides, I will forever be on record for saying and with apologies to Mr. T., “My momma didn’t raise no resources.

I’ve been fighting this battle for years, always using “people” in my own speech and answering back with “people” when other folks ask me if there are any resources in my area that could be applied to a particular project need.  Not rudely, but in the same way that I always lead my examples with a female pronoun/name first (“first the sysadmin does this, then she does that), then the next example is male, and I alternate, and I substitute person-hours for man-hours.  Use any of these and dollars to donuts, my next time speaking comes back with conversation that includes s/resources/people/g and s/he/she/g and s/man hours/person hours/g .  That’s just the way I roll.

Mostly though, it’s not been making much progress.  Between Microsoft Project’s use of “resource” to describe the person working on a task (bleargh) and the culture of resource that surrounds me, it’s hard to effect a change.

But when one of the folks in the meeting used the word “people” rather than resource when discussing how we’d do the work we were discussing, and pointed it out and that he was doing it based on my history of trying to move the needle back to working with humans with hopes and dreams, well, it made me very, very happy.  And when the other person in the meeting heard the discussion, she picked up on the distinction too.  Dare I hope for another footsolder in the battle against dehumanization?

In one small corner of the software developer universe, humans are coming back!  People. Not Resources.

Thanks, folks, for making my day and for explicitly letting me know that (at least at that moment) I’ve made the world a bit better of a place for people, not resources.