Got a Career Plan?

I just ran across this article.

I was talking to a relatively young developer the other day. I asked him about his career plans. “Oh, I don’t do career planning myself. I wait until my manager talks to me.”

Oops. Your career is your responsibility.

The article then moves on to give some specific advice for growing your technical career.

I’m constantly surprised by how many people think that career planning is something that their manager will do. Oddly, when these same people become managers they very rarely help their reports with career planning. Maybe it’s because their manager didn’t help them? Maybe it’s because they don’t really know how to do it themselves?

What does this mean for you? First, take control of your own career plan. Second, if you are a manager, help your people with their career plans; it will make you stand out in their minds as an excellent manager.

Share it!

SCORE!

I spent yesterday working on the business plan for The Technical Management Institute. It’s mostly there (like 20 pages worth), except for the financials. Even though we are not looking for financing, I think it makes sense to put a couple of days into building projected: balance sheets, income statements, cash flow statements, and a break-even analysis. A call to a good friend of mine at FactSet got me some good pointers and information about what to include. Then this page at SCORE set me up with templates for doing all of these documents. Life is good.

Share it!

Hire Fast and Die

There are two emergent schools of thought (at least) about technical team hiring:  hire fast, fire fast (a play on the "hire slow, fire fast" adage), and no false positives.  FeedBurner founder Dick Costolo has this to say:

I buy the hire fast, fire fast line of thinking for Sales Reps or VP
Sales roles but I don’t buy it for Engineering, Marketing, Finance,
etc. The problem with hire fast, fire fast in the engineering
department is quite simple: you don’t end up executing on the fire fast
part of it and the bad hire infects the organization for an extended
period before you figure out how to remove them. Engineering goals are
more generally team goals, there can be lots of reasons code can ship
late, and performance criteria are more subjective than sales
performance criteria. The mediocre hire ends up becoming part of the
team and it just ends up taking longer to fire that person on the team,
by which point they’ve added more subpar work to the mix. So, I am a
subscriber, outside of sales, to the thesis that you have to interview
rigorously and that it’s better to leave an urgently needed role empty
than to bring in a "false positive" who will infect the organization.

Share it!