- The same ‘agile’ principles that make your project team more effective as a whole will make you a better teammate as an individual.
- Agile principles are about letting go of fear and control, and optimizing for transparency and trust.
- This is true enough in good times, but it’s *especially* true in harder times.
- Your own limits and challenges in life are no different than the limits and risks that the team encounters. Be as transparent about yourself to your team as your team is to the project’s stakeholders.
- Embrace the inevitability of risk, and activate your brain’s optimism module.
- Renovating a house while you build software is going to provide you with far too many opportunities for recursive learnings about agile project management from all possible perspectives.
Fairly recently, I failed. Fortunately, it wasn’t a messy, catastrophic, collective failure of an entire project, or blowing through $200 million of my investors’ money, then selling off the company for scrap. Rather, my project team succeeded in doing what it set out to do, in spite of the fact that I failed to be a good teammate for them. We didn’t fail together; I failed them.
The proximate cause wasn’t hard to identify: I was totally, completely overwhelmed. Tons of work, and tons going on at home. (Among other things, we gut-renovated an apartment, which is pretty much a full time job, even when you’re paying other people to do the heavy lifting. Cancel all your other commitments if you should ever be so foolishly inclined.) And then the previous, particularly important project suffered spectacular scope-creep and nearly went off the rails, resulting in a bunch of 80-hour weeks and working through most of Christmas vacation.
And so I showed up to this specific project with my gas tank pretty empty. No doubt about it. But that’s not *why* I was a bad teammate. It’s just the set of stressors that exposed some underlying weaknesses: habits that were flawed but manageable under normal circumstances, but which became totally non-viable when things hit the fan.
The thing is, you can be overwhelmed and still be a great member of your team, albeit with a decreased output, or with a need to rely more heavily on other people, or without your normally sunny disposition being quite as sunny. But you have to make the right choices and have the right habits in order to do that. That’s what I’m here to talk about.
Why write about this on a blog that’s mostly about software engineering?
- We’re all on teams. Even if it’s just you and your life-partner, it’s a team. And software dev tends to scale to at least 3-4 people, if not many more. Being a good engineer is inseparable from being a good teammate (at least if you like working with great people and accomplishing meaningful things).
- It won’t shock anyone to say that engineers tend to have certain personality traits. Some of those traits privilege the intellect over the human and the social. I’m generally perceived as being on the pretty highly social end of the engineer spectrum, but that doesn’t mean I don’t err on the other side at times, especially when I’m uncomfortable. Engineer brains therefore may have some things in common that make us – probablilistically rather than deterministically – prone to similar errors.
- I’ve been spending my spare cycles thinking about how I got here, and how I can improve. And at work, we use agile/Agile principles to build healthy teams and healthy products. And while observation bias is always a risk when you’re making correlations like this one, I can’t help noticing…
- There are *all kinds* of parallels between the underlying reasons why we build software in an agile way, and the reasons why I irritated a group of people I like and admire, and made my team less effective. I’m convinced that the principles behind agile project management aren’t just for use in building better project teams. Those principles make for better teams, only because they first make the members of the team into better professionals, better teammates, and possibly even better humans.
PRODUCT = TEAM
If you’ve been doing software for more than a month or two, especially anywhere near the startup industry, you’ve almost certainly seen that little gem at least once: “product = team”. Like any other overly-clever description of a complex system, it leaves a lot out. The team isn’t all that goes into a good product. But you’ll almost certainly not get a great product without a great team.
The default interpretation of how to react to this maxim is: “hire the best people you can get your hands on.” And that’s not wrong. Talent and insight go a long way towards getting a great product. But professional sports, for instance, is littered with examples of teams (especially large-market teams) that bought up all the talent in sight… and then failed miserably. While other teams (often small-market teams) somehow fused a bunch of formerly inconspicuous players into a glorious whole.
Now, the latter case can be partially explained by saying that those teams were just better at recognizing hidden talent: cultivating the gems that were out in plain sight. Which is not wrong: the Oakland A’s under Sandy Alderson and Billy Bean used the emerging science of Sabermetrics to get better talent for less money.
But that doesn’t explain the conspicuous flops: teams that bought the best talent that money or insight could buy and then frittered it away. How do teams like the Yankees and Redskins so often underperform their operating budgets? *Because a good team is more than just good players.* Whether it’s because you’ve got a genius coach who brings you to it reluctantly, or because you make it part of your culture like the New England Patriots, the teams that win consistently are the teams that decide to do it together.
Software is no different. Agile methodology tells us we need more than the best solo practitioners: we need to organize them and support them in the right way. We know agile is about iteration, and rapid cycles. But in order to work that way, we need close coordination, colocation (preferably), transparency, and high communication. To get an agile process, you first need an agile team.
But you don’t get an agile team without agile people: folks who are willing and able to work that way. We can have all the standups and retrospectives in the world, but if the individual people in the team aren’t invested in making those ceremonies work, nothing happens. Similarly, if you don’t have trust and transparency between those people, the team never learns to admit their weaknesses, acknowledge their strengths, and optimize for both.
Which is where we’ll come back to moí. When I exceeded my safe operating limits earlier this year, I most certainly did not lean on my team. In fact, I withdrew from my team. I cut my investment in communication and coordination, and hunkered down. Because, I reasoned: “if my time and energy is severely constrained, I need to focus on the essentials, and what’s essential is shipping code.” No, no, no, no, no.
The result of that choice seems inevitable in retrospect: poor morale, poor cohesion, low trust, and unnecessary extra work for my colleagues to keep up with my poorly-communicated (and occasionally ill-conceived) decisions. All of which made all of us less effective and wasted time, which was the exact opposite of what I was after. Why would I do something so clearly, predictably ineffective?
The Illusion of Control
If you can’t control everything else that’s going on around you in life, certainly you can at least pretend that you’re a little island and be the king of it for a while?
Agile principles teach us that the opposite is true: ‘Control’ is both an illusion and an anti-pattern. In fact, a ‘manager’ may not be needed at all on a project, as long as everybody is working towards the same goal, in close coordination. If a project manager isn’t needed to make a team effective, what does that tell us about what a single person can accomplish by hunkering down and trying to ‘control’ the success of a team by focusing exclusively on their own output? Duh.
For the individual member of a team, your ability to drive success without focusing on team communication and cooperation – plus commitment to building real relationships of trust to enable all that – is a fiction. As is your belief that you can’t admit you have limits: limits to your experience, limits to your knowledge, and limits to your ability to absorb everything that life throws at you.
Transparency, in a team environment, is about letting go of that illusion of control. You can’t call the shots yourself, and you can’t hide from problems and weakness. So, opening up about them, letting go of them, and asking for help with them is really, truly the most reasonable path. Which doesn’t make it easier. But it’s the right way to go.
Fear vs. Risk
(Bear with me for a second while I go full nerd. It’s only a second, and I’ll bring it right back to the topic. Promise.)
Neuroscience has taught us many interesting things about humanity lately, not least of which is the fact that neither our physical brains nor our minds/personalities are unitary or monolithic. Rather, what we perceive as consciousness appears to be the result of a bunch of signals coming from different and competing parts our brains, which get integrated into something that nominally resembles conscious thought and intention.
fMRI now allows us to see inside the human brain while it thinks, and to know that different kinds of thoughts clearly have distinct homes. Happiness & sadness, math & language, agony & ecstasy, logic & analogy all appear to come from different discrete structures in the brain. And while one part of the brain may be more active than another at a given time, the other parts are still there, and still working. So, consciously or otherwise, a prioritization takes place, whereby the person that I am makes use of one part of the brain or another part, in response to a particular situation.
This is a powerful piece of information. Because it means that we maybe have a choice about how to think about things. In response to a problem, which part of the brain do we want to privilege? Which kind of cognition and response is going to be most helpful in a given situation? Which kind do we want to avoid?
The enemy, brain-wise, is the fearful part of your brain.
“I’m worried about this piece of complexity” is about fear. “I’m going to point out a possible risk, optimistically” is what’s actually analytical. Let go of the fear about the risk. It’s just another thing. The team will sort out the risk, or they won’t. But you can neither control the risk, nor make it better by worrying about it. Keeping your spirits up, your energy positive, and your team motivated, gives you the best possible chance to deal with risk and win the day. And chances are the risk is not as great as you imagine in the first place, and you’ll discover that by talking it out with your team. And if it *is* a big risk, exposing it puts both you and your team in the best possible position to understand it and deal with it.
But fear comes from the idea you can control the risks if only you think hard enough about them. That it’s on you. That you can both anticipate them all, preventing surprises, and you can figure out solutions through internal worry. No way.
First, let go of the idea you can figure out every risk in advance. You can’t. You have to have faith not only in your ability to solve for risk, but also in the certainty that you don’t know about all the risks. They will come in their own time.
Second, let go of the idea that you can even understand all the risks right now, let alone solve for them. Some of the perceived risks will fade away the second you stop over-clocking your fear chip. Some will take a backseat when you accept that your concern about them is based on a lack of information early in a project; and that better information, like wisdom, will come in due time.
Last, have faith in your team and your process. Surface a risk during standups or planning sessions. Get it out into the light of day, and let other people have a gander at it. Shockingly often, either their additional information or their different perspective will either eliminate it or mitigate it. And if it’s still a Thing, your team will be able to deal with it far better together than you can by fixating on it alone.
This, I think, is the second-most important key principle of Agile. The first principle is the simple beauty of iterative development. If there are risks to your plan, then consider changing the plan. And in response to learning how to improve your plan, then change the plan there, too. Either way, the agenda is driven, frequently and incrementally, by a focus on whatever it takes to be successful.
But how do you do that? Why doesn’t everybody do things that way if it’s so damn obvious? Fear. Agile (and being a good teammate) is about letting go of fear, and embracing transparency and trust instead. When we share our ideas with both customers and stakeholders as early as possible, we’re letting go of our fear that they won’t get it. When we let go of those huge binders full of contracts and specifications, we’re letting go of our fear that the people paying the bills will try to blame us when the business-case goes all pear-shaped. When we share our personal limitations and challenges within the team, we’re letting go of our fear of anger and personal rejection by our teammates. When we stop trying to solve all problems ourselves, we’re letting go of our fear that other people won’t see it the same we do. And we do all those things for the same reason: it reduces risk, and increases the likelihood of successful adaptation and eventual success. Plus, the truth is this, human beings are pretty likely to join you on your journey if you simply invite them to, even if it’s hard for them. It’s when we conceal things, and make people feel left out, that they turn against you. And not unjustifiably.
Fortunately, we don’t just have the option of avoiding the fear center; it’s relatively well proven now that we can instead cultivate the part of the brain that makes joy.
Concealment of your situation is about more than the illusion that you can control a situation long enough to fix it. It’s also about the illusion that you can conceal the problem in the first place. You’re generally showing your cards far more than you imagine. Silence itself is suggestive of a problem. And if your problem is something that more than one person knows about, people will talk. Spend some time in a political capital and you’ll learn quickly: there’s always a leak. You’re far better off admitting problems early, and getting help to solve them. This is why agile dictates not only that teams meet with each other daily to acknowledge problems with the team/project, but also that leadership and other stakeholders are in the loop at least every sprint. Sprint reviews aren’t just for talking about what’s going wonderfully; they’re about transparency about the challenges as well.
One of the great truths of working in an organization is that managing up or sideways isn’t so different than managing down. But there’s this odd assumption: that for some reason it’s perfectly normal to tell the people ‘below’ you what you need from them to reach the team’s objectives. That’s comfortable for most people. So why do we hesitate to do the *exact same thing* with peers and with our own leadership? You’re just telling people what you need from them to reach the goal, same as you would do with the people whose paycheck you sign.
But… my leadership doesn’t want to hear about my problems, you say. They just want results. Sure. Who doesn’t wish that other people would solve all your problems for you. But this is one of the most fundamental aspects of agile: you can’t just wish complexity away, and you can’t just ask other people to take on all the uncertainty and risk. Not only will all that uncertainty and risk fester while you’re assuming it’s someone else’s problem, but you won’t even get what you really wanted.
This is why fixed-price construction contracts are both hideously expensive and hideously risky. This is why I should have known that my own home renovation couldn’t and wouldn’t be a turnkey kind of deal. Getting a good product, and keeping risk under control means being involved early and often, accepting bad news, and providing additional resources when necessary to solve the problem.
Safe as Houses
Getting good software is just like building a house: first, the software team doesn’t understand your business the way you do, and your home-builder doesn’t understand how you live and what your taste is. In both cases, you’ll need to re-explain at appropriate moments througout the process. Second, your software specifications won’t cover everything that’s actually needed, just like you won’t know to specify to your builder all the things that are actually needed for your plumbing and HVAC systems to work. And just as your builder will suddenly discover a pipe that’s in a bad place, or a brick wall that needs shoring up (both of which will require more money), a software team will discover the missing data, or the business problem that has more moving parts than expected. All of which requires that information flow ‘upward’ and ‘sideways’ as early and often as possible, and that nobody on any of those vectors pretends this shouldn’t be happening.
This works for you as an individual as well. Your house renovation is going to take more out of you than you expected. Admit it early, so the team can adjust. Your ability to estimate how long your own work will take is just as optimistic as your assumption about what your renovation should cost.
But fear and stress makes us do dumb things. In my case, the more stressed I got, the more aggravated I was by being asked for the routine and perfectly appropriate “what are you working on today/this week” kind of data. Because… well… what I’m working on is just, gosh-darn-it, far more important than wasting time telling you what I’m working on!!!
When I stopped and examined that frustration, what I realized was that I often actually had *no idea* what I was going to be working on that day. All I knew was that I felt like it was far more than I could handle. And I was frustrated more by not knowing what I needed to do than by the request that I explain what I needed to do.
That’s no accident. The agile planning cycle is as much for your own benefit as for your team’s and project’s. There are (at least) three huge advantages to stopping and figuring out what to tell your team about your plans for the day or week:
- Planning helps. Thinking through what *you* actually need to do, and how it fits together with other things, will make you dramatically more productive, leveraging what little time you do have. No amount of panic and adrenaline will improve on that. (Usually, it’s worse.)
- Coordinating helps. The other people on your team are asking so that they can avoid duplicate work, integration problems, etc. Sometimes, they can simply tell you that something doesn’t even need to be done. Either way, the process saves you work, saves them work, and saves the energy wasted on aggravation.
- Downloading helps! That storm cloud above your head is composed largely of imagined things, of things that are real but beyond your control, and of fear. Making an achievable list of things you can actually get done today filters out all the crap. You can still be as motivated as you want to be about getting those things done, but stop worrying about the other stuff, and just focus on what you reported as your to-do’s for TODAY.
Another note on fear: all the stuff I feared might disappoint my team, like my not doing enough work, my not being smart enough, my not knowing enough… none of that ever seemed to happen, or has ever seemed to happen. What DID happen were the problems caused by worrying too much about those things, and not trusting my team.
Side-Note: Tactics for Clearing Your Mind
I feel like this is perhaps well-trod ground among the nerd set, but it’s worth mentioning again: We do agile project-planning so that we can clear the mind’s explicit, conscious backlog, and allow it to focus on what’s important. The next level of abstraction down is the unconscious backlog. The only way I’ve ever heard of to get to that is with meditation. (Hypothetically, therapy’s another option, but that’s expensive, time-consuming, and doesn’t have anywhere near the proven success rate.)
Give meditation it a try. When the things you’re worrying about are getting in the way of being a good teammate, 10 minutes of meditation will usually pay off in spades.
(Interesting side-side-note: the people who seem to get the most out of meditation are the opposite of what might be the stereotype: it’s the intense, hard-charging folks rather than the mellow hippies. One of my oldest friends from high school was crazy-intense when we were kids, now produces video games that cost more to make than “Titanic”, and has become one of the most grounded people I know, while still being seriously metal. He says it would be impossible for him without meditation.)
Side-Note: The Ego Monster
Let’s talk about ego for a second: not only are you not in control of your situation, but you’re almost certainly smarter as part of a team than you are without one. Which means that even if you’re a pretty smart person, the best thing you can do about your smarts is decouple them from your ego so that you treat people they way they outght to be treated. And be prepared: when you get stressed, you may otherwise. make some sloppy, snap decisions about how to spend your time, and organize your relationships. Here’s a hint: taking a capable-seeming newcomer, who happens to be junior to you in age and experience, and making assumptions that they should be coming to you for wisdom and guidance… that’s not a winner. Anybody with a healthy ego and genuine talent is going to seek your advice only after you’ve earned that privilege with patience and humility. People like learning when *they* are ready to learn, not when you’re ready to teach.
Even if you’re Linus Torvalds or some similar deity of the nerd pantheon, there’s no such thing as a team that doesn’t need you to put the team’s needs and interests ahead of your own. There may be situations where you can *get away with* putting the team’s needs second. But none where the team has net greater productivity because of it. (If the other people on the team are such idiots that you can outproduce all of them operating at their best, then quit now and move on. No, really.)
Whether you’re a leader of a team, or just a contributor, your point of greatest leverage is in doing things that maximize the capability of the whole unit. And if the organization has made you officially a leader, it’s an obligation and not just an opportunity. In that case, your own work should nearly always come second to your responsibility to leverage the work of your teammates. But even when it’s not the case: your team is a multiplier for whatever it is that you think you bring to the table. The time and energy that you invest in collaborating with your team (or at least the first 80% of it) is going to pay off in spades, even if it doesn’t feel like it right now.
If somebody’s on your team and not going away tomorrow, they’re worth supporting and fighting for: “All for One, One for All”.
You never have to think critically about your own behavior if all your experience is success and ego-stroking. I’m definitely a better teammate because one of my teammates stepped up and pointed out what wasn’t going well. People who will tell you the truth about yourself can be the best friends you’re going to have. To M.S., I send my sincere thanks for being candid and constructive.
So, see if you can find that fearful, pessimistic part of your brain, and start noticing how much of an effect it has on your thinking. And then shut it down for a while. There are other parts you can cultivate. You’ll enjoy it.