Twinge Acquisition

As a manager, you manage both yourself and your team, and the simple fact is there will always be more of them than of you. Unless you’re the guy managing a single person (weird), you’ve got multiple folks with all their varied work and quirky personalities to manage.

Rookie managers approach this situation with enviable gusto. They believe their job is to be aware of and responsible for their team’s every single thought and act. I like to watch these freshman managers. I like to watch them sweat and scurry about the building as they attempt to complete this impossible task.

It’s not that I enjoy watching them prepare to fail. In fact, as they zip by, I explicitly warn them: “There is no way you’re doing it all. You need to trust and you need to delegate.” But even with this explanation, most of these managers are back in my office in three weeks saying the same thing: “I have no idea how you keep track of it all.”

“You can’t, and I sure don’t.”

In addition to trusting those who work for you by delegating work that you may truly believe only you can do, you must also understand the art of evaluating a Spartan set of data, extracting the truth, and trusting your Twinges. When you listen to and act on your Twinges, well, you look like a magician, but when you ignore them, the consequences can be far ranging and damage the project as well as your reputation with those involved.

Twinges: Built on Experience

Before I explain the cost of ignoring a Twinge, let’s first understand why rookie engineering managers aren’t listening to me. Remember, I’m talking about engineers here: a class of human being that derives professional joy from the building of things—specific things. Things they can sit back and stare at—look there!—I built that thing.

The building of things scratches an essential itch for engineers. It’s why they became engineers in the first place. When they were six, their dads handed them two boards, a nail, and a hammer, and they started whacking. Blam blam blam! Even with the nail awkwardly bent in half, the wood was suddenly and magically bound together: a thing was built. At that moment, this junior engineer’s brain secreted a chemical that instantly convinced them of the disproportionate value of this construction: “This is the best wood thing in the world because I built it.” And then they looked up from their creation and pleaded, “Dad, I really need more nails.”

Dad handed them three more nails, showed them where to hold the hammer, and demonstrated how to hit the nail. More whacking. Blam blam biff! This time the nail wasn’t bent; this time on the last hit the nail slid effortlessly into the wood. This engineer in training had now experienced two essential emotions: the joy of creation and the satisfaction of learning while gaining experience, perfecting the craft.

Engineers are wired to learn how to build stuff well. And as they continue to do that, someone eventually thinks it’s a good idea to promote them to the ranks of management. These new managers initially believe the essential skills of building that made them successful as engineers will apply to the building of people, but they don’t. It’s their experience that matters.

Management is a total career restart. One of the first lessons a new manager discovers, either through trial and error or instruction, is that the approaches they used for building products aren’t going to work when it comes to people. However, this doesn’t mean all of the experience is suddenly irrelevant. In fact, it’s that experience that creates the Twinge.

A Manager’s Day : Full of Stories

As a manager, think of your day as one full of stories. All day, you’re hearing stories from different people about the different arcs that are being played out in the hallways and conference rooms. As these stories arrive, there is one question you need to always be asking: do you believe this story? Before you make that call, there are a couple things you need to know.

First, this story is incomplete, and you’re OK with that. Here’s why: for now, you need to trust that those who work with you are capable of synthesizing a story. Part of their value is their judgment in presenting you with the essential facts, and until they prove they can’t synthesize well, you assume they can.

Second, and contradictorily, while I believe that folks don’t wake up intending to construct lies, I also know that for any story you’re hearing, you’re getting the version that supports their chosen version of reality. As a story is being told to you, the opinion of the storyteller is affecting both the content and the tone. Their agenda dictates what they are choosing to tell you. Again, malevolent forces are not necessarily driving the storyteller. They are hopeful and they want to succeed, but this story needs judgment, and that’s where you come in as a manager. I’ll explain by example.

A Familiar Nail

“OK, Project Frodo—we’re two weeks from feature complete. Our task list is down to seven items, but as you can see from this chart, the work is spread out among the teams. I’m confident we’ll hit the date.”

This sounds like good news. This sounds like the truth. Nothing in those three sentences is setting off any alarms in my head, but I’m a manager and it’s my job to sniff around.

“Is the design done?”

“Yes, except for items six and seven.”

OK, so it’s not done. “When will they be done with design?”

“In a week and half.”

“And you can get the tasks done in the two days after we receive the designs?”

“I, uh . . .”

Sniffing around pisses people off. Sniffing around is often interpreted as micromanagement, a passive-aggressive way of stating, “I don’t believe you can do your job.” While there are a great many managers out there who pull this move as a means of pumping up their fading value, this is not what I’m doing—I’m trying to figure out if this story is familiar.

I’ve built a lot of teams that have built a lot of software. I know that what we receive as a complete design is usually 80 percent of what we actually need, because I’ve been the engineer staring at the Photoshops in the middle of the night with two days to feature complete, thinking, “It’s sure pretty, but what about internationalization? And error cases? You know that’s work, right?”

It’s not that I know all the intricacies of Project Frodo, and I don’t want to know them. It’s a team full of personalities, tasks, and dependencies that I could spend my entire day trying to understand, and I’ve got two other projects of equal size that are running hot. As I’m listening to this story, I’m listening hard and trying to figure out . . . have I seen this nail before? I have, haven’t I? I don’t remember when, but I do remember the Twinge.

Do you remember every success and failure? No. You can recite your greatest hits over a Mai Tai, but I don’t think you can actually recollect them all. However, this doesn’t mean you don’t remember the experience. I’ve long since given up trying to understand why one story rings true to me while another triggers the Twinge. My belief is that my brain is far better at subconscious analysis, pattern matching, and teasing out apparently essential details from the noise than I’ll consciously ever be. My belief is that my experiences drive my sometimes subconscious instincts, and this is why I’ve come to trust the Twinge.

A Twinge Catastrophe

A Twinge is your experience speaking to you in an unexpected and possibly unstructured way, and while I’m not saying you should base your management strategy on these amorphous moments of clarity, I do want to explain their importance in the organization.

This storytelling—the careful selection of facts, ideas, and data—is going on everywhere in the company. Everyone is building a story about what and how they’re doing, and they’re often optimizing in their favor.

While many of these stories involve the mundane day-to-day operations of the company, some of these stories are terribly important. While it might not sound like it right now, that story Bob just explained about a small performance issue on one server is actually a massive performance debacle in the making. Joe’s story about that annoying interaction design problem is actually the description of the absence of a feature you don’t even know you’re missing.

When these seemingly benign stories are not judged, when they are not questioned, the story is over. Bob’s conscience is clear because he gave you a heads-up. Your conscience is clear is because you listened to Bob’s concern, and, yeah, you had a Twinge, but Bob’s delivery record is impeccable, so Twinge be damned, it’ll sort itself out in the end.

Your failure to heed your Twinge is a management failure.

It gets worse. This story optimization is happening at every layer of management and in every group of people. Each time an unheeded Twinge story jumps from one person to the next, a lie is being propagated throughout the organization. And if the story started in your group, it’s your fault this misinformation is running amok. Now, there are other people in the building who might get a Twinge and save your team’s collective professional ass, but again, if it’s a story that originated in your group, the responsibility is yours.

Just Another Nail

New engineering managers wrestle with the gig because they miss building stuff. The powerfully addictive act of building is no longer part of their day, and they bitch, “You know, I don’t know what I actually do all day.” Finding other ways to scratch this itch is a topic for another chapter, but for now, one of your jobs is to listen to the stories and map them against your experience. And when there’s a Twinge, you ask questions, and you need to believe the asking of these questions is a form of building.

As a manager, when the story doesn’t quite feel right, you demand specifics. You ask for the details of the story to prove that it’s true. If the story can’t stand up to the first three questions that pop into your mind, then there’s an issue.

You don’t run a team or a company on a Twinge. The ability to listen to random stories and quickly tease out a flaw in the logic or the absence of a critical dependency is just one of the skills you need to develop as a manager. Like building, both the discovery and the asking of these questions are arts; they’re just more nails you need to figure out how to hammer.