What do you expect from a tech lead?

I've been thinking about the role of Tech Lead. It is one of those titles where I think everyone "knows" what it means but most of us haven't tried to define it.

It goes without saying that a tech lead has to be strong technically, but I think what makes or breaks a tech lead is whether they have strong leadership characteristics. I see those characteristics falling in three categories (Self / Team / Business):

Self
Has an active desire to work with people
Possesses "confident humility"
Can accept a position with less than 100% of time spent working on code (sometimes a lot less)
Knows where the gaps in their knowledge are
Is not concerned with "looking good"
Can delegate work

Team
Can facilitate conflict resolution and team decision making
Wants team and individual members (including self) to grow and learn
Wants team members to succeed and actively works to ensure they receive recognition for it
When necessary, can combine their own experience with the thoughts of a team and render a decision
Understands that people have different learning styles (visual, tactile, auditory, etc)
Shields team from outside influences, so they can get their work done (much as a scrum master does)

Business

Understands the value that IT provides to business
Can speak to technical decisions in a way that addresses business partners' priorities
Understands and accepts that business may only wants to pay for "good enough" solutions, not "best" solutions.

What do you think? Do you agree/disagree with the characteristics I've identified?

What are the units for Story Points?

A co-worker and I were discussing estimation on agile software development teams (Yeah, I know - #noestimates. That was off the table here). I asked him what a story point represents. He said "effort", which PMBOK defines as "measurable work units", and pointed me to a post by Michael Cohn:

"...story points are about time—the effort involved in doing something. Because our bosses, clients and customers want to know when something will be done, we need to estimate with something based on effort. Risk, uncertainty and complexity are factors that may influence the effort involved."

My friend went on to write the following formulas:

(SumOfRemainingEpics + SumOfRemainingStories) / Velocity = Forecasted Duration (+/- uncertainty)

and

Forecasted Duration / Team Capacity = hours

I wasn't so sure that this demonstrated that story points are about time, so I re-wrote his formulas adding units (and dropping uncertainty):

SumOfRemainingEpicsAndStories(points) / Velocity(points/week) = Forecasted Duration(weeks) 

and

( (SumOfRemainingEpics(points) + SumOfRemainingStories(points)) / Velocity (points/week) ) x Team Capacity (hours/week) = hours

Management wants estimates of duration which we calculate according to the first equation by dividing points by velocity (Cohn mentions this too). In either formula, points cancel out. What that says to me is that units of story points don't matter. We can estimate in complexity, risk, time, or elephants! The upside of this is that non-timebased units for points prevents management from translating stories directly back and forth between points and hours, which can cause friction between the team and management