On Not Being Hands-on

Perhaps I just have to get over not being as hands on as when I was a graduate student. In my last several one-on-one’s with Sift’s CTO the biggest feedback has consistently been:

“I want you to think big, and look forward. You can bring 10x the value to Sift by setting the design vision for where we need to go.”

The other side of the message is to not get caught up in the weeds. Trust the rest of my team to work out the execution/implementation kinks.

“Just be available when they need clarification. We’ll iterate as we go along.”

This all makes sense. I am definitely not adding as much value when I am jumping in trying to write markup or UI code. My team (bless them) is far faster than I am at it. Yet I often find myself drawn into the weeds, helping push pixels and smith words. Why?

The struggle I haven’t been able to articulate until now is this: I think with my hands. Or, better put, I think through making. Working through the exercise of drawing rough sketches again and again is how I learn about the solution space.

In my role at Sift, however, I need to recalibrate which level of abstraction I am thinking/making at. Figuring out implementation level details is not a judicious use of my time. The team needs me to synthesize strategy, customer needs, product opportunities into project proposals, and then to communicate a high level outline. My deliverables are no longer detailed designs or functional code, but documents and sketches that provide my team with clarity to move forward.

So I suppose I have to strike a balance, where I am just hands-on enough to work through ideas, but not so much that I duplicate work the rest of my team can handle.

Not quite sure how to reconcile that yet.