Debugging Teams: Better Productivity through Collaboration

by Brian W. Fitzpatrick

Bus factor (noun): the number of people that need to get hit by a bus before your project is completely doomed.

if you wanted to talk, you would say “breakpoint Mary,” where

Mary was the name of the person you wanted to talk to. If Mary was at a point where she could stop, she would swing her chair around and listen. If Mary was too busy, she’d just say “ack” and you’d go on with other things until she finished with her current head state.

Humility You are not the center of the universe. You’re neither omniscient nor infallible. You’re open to self-improvement. Respect You genuinely care about others you work with. You treat them as human beings, and appreciate their abilities and accomplishments. Trust You believe others are competent and will do the right thing, and you’re OK with letting them drive when appropriate.4 Together, we refer to these principles as HRT. We pronounce this as “heart” and not “hurt” because it’s all about decreasing pain and not about injuring people. In fact, our main thesis is built directly on these pillars:

Almost every social conflict can ultimately be traced back to a lack of humility, respect, or trust.

It’s not about tricking or manipulating people; it’s about creating relationships to get things done, and relationships always outlast projects.

Criticism is almost never personal in a professional software engineering environment — it’s usually just part of the process of making a better product. The trick is to make sure you (and those around you) understand the difference between constructive criticism of someone’s creative output and flat-out assaults against someone’s character.

Remember that in order to be heard properly, you first need to listen to others.

The first mistake most team members make is to assume the team leader curates the culture of a team.

every member of your team participates in the culture and bears some responsibility for defining, maintaining, and defending the culture.

but many people will go to great lengths to avoid soliciting criticism. In some cases this is due to insecurity, but in most cases that we’ve seen it is because a person thinks that they are required to take action on any criticism received, even if they disagree with it.

Traditional managers worry about how to get things done, while leaders worry about what things get done…(and trust their team to figure out how to do it).

“In a hierarchy every employee tends to rise to his level of incompetence.”

“Above all, resist the urge to manage.”

“Sometimes you get to be the tooth fairy, other times you have to be the dentist.”

Ignoring low performers is also a way to keep new high performers from joining your team, and a way to encourage existing high performers to leave.

importance of preventing destructive outsiders from trashing the cooperative culture your team has worked hard to build.

consensus-based development, high-quality code, code reviews, and an environment where people feel comfortable enough to try new things and to fail fast.

It’s the behaviors you want to filter out, not particular individuals.

Lack of Respect for Other People’s Time

Their damage is most often in the form of wasting the team’s time. Rather than spending a few minutes of their own time reading fundamental project documentation, mission statements, FAQs, or the latest email discussion threads, they repeatedly distract the entire team with questions about things they could easily figure out on their own.

Ego

describe anyone who is incapable of accepting a consensus decision, listening to or respecting other points of view, or reaching compromises.

Entitlement

Something is wrong with a person who puts all her energy into complaining about the inadequacies of the software but is unwilling to directly contribute in any way.

Paranoia

sometimes an inappropriate sense of entitlement leads directly into open hostility toward a project. Many times we see it escalate into complete paranoia. When an existing team disagrees with the visitor, the poisonous person will sometimes start to throw accusations of a “cabal” and conspiracy.

Perfectionism

Unfortunately, when it came time to design new software, he could spend the rest of his life tweaking and improving his design. He was never satisfied with the plans and seemingly was never ready to start coding.

Make it clear that bad behaviors will not be tolerated.

Once a good-enough solution is found for the original problem, point the perfectionist to a different problem that still needs attention.

Remember that your job is to build great things, not to appease every visitor or repeatedly justify your existence.

stronger your emotions are, the more likely you are to waste hours or days writing passionate replies to someone who doesn’t deserve such attention.

Always start by giving the person the benefit of the doubt, despite the angry or rude language. Does the person have a real point? Is there something to learn from the person’s experience, or is there an idea worth responding to? Very often the answer is “yes” — that despite a poisonous person’s vitriolic prose, some wisdom really is buried in there. Always bring the argument back to a technical discussion.3

it’s not worth compromising your culture for the short-term gains

“Yeah, there are only a few crazy people out there; the Internet just makes it seems like they all live next door.”

When you fail, take responsibility, don’t seek to assign blame, and document what happened and what you can do to avoid that same failure again. Lather, rinse, repeat.

If your manager makes a decision that you disagree with, don’t be afraid to argue with her or question the premise upon which she made the decision.

Fear of failure is one of the most common traits of bad managers.

If your manager doesn’t want you to take risks, there is little opportunity for you to inject your own ideas into your product and you’ll usually wind up implementing (by rote) the product someone else designed.

Oftentimes the insecure manager will insist on inserting herself into any interaction you have with people outside your team, thereby preventing you from speaking directly to other teams without “going through the chain of command.”

It boils down to this: is your manager serving you? Or are you serving your manager? It should always be the former.

trusting the office politician can be a seriously career-limiting move.

It’s a simple fact that most companies are not engineering-focused. That is to say: engineers are a means to accomplish business goals that are typically not technical. This means the people running the company probably don’t understand the technical underpinnings of their system, just the demands set upon them by the business, and so they wind up creating unrealistic demands on engineering.

If you focus on the way things should be in your organization, you’ll usually find nothing but frustration and disappointment.

“It’s impossible to simply stop a bad habit; you need to replace it with a good habit.”

“offensive” or “defensive.” Offensive work is typically effort toward new user-visible features — shiny things that are easy to show outsiders and get them excited about, or things that noticeably advance the appeal of a product (e.g., improved UI, faster response times). Defensive work is effort aimed at the long-term health of a product (e.g., code refactoring, feature rewrites, schema changes, data migration, or improved emergency monitoring). Defensive activities make the product more maintainable, stable, and reliable. And yet, despite the fact that they’re absolutely critical, you get no political credit for doing them.

a team should never spend more than one-third to one-half of its time and energy on defensive work, no matter how much technical debt there is. Any more time spent is a recipe for political suicide.

collaboration isn’t just about working with your team; to make great things, you need to actively collaborate with your users too.