Hacker News new | ask | show | jobs
by jacques_chester 3862 days ago
Where I work we have a role called "project anchor". It comes with no extra pay, no special perks, no particular enumerated powers.

The anchor does not determine product features or direction, that's the product manager's role. The anchor doesn't hire, fire, reward or punish other engineers, that's the engineering manager's role.

The anchor isn't necessarily the strongest engineer on the project, either.

Anchors are mostly there to break ties and hold project context over a longer time frame. A founding anchor has a strong influence on the project's technical direction, but it's not a fiat power. You still need to discuss it with your peers.

And it works pretty well, because the only reason you get asked to anchor is due to the feedback of your peers.

Then again, our hiring process has a notorious bias against rockstar jerks.

1 comments

Is there more info around about this style of project management? My google-foo is not getting any hits
I work for Pivotal Labs. Our starting point is XP for engineering, Lean for design and product management. Daily standup, weekly IPM, weekly retro.

Lots of people know us mostly for Pivotal Tracker, which is built to support our daily and weekly workflow.

On any given engagement, we always argue for a minimum team of one product manager, one designer, two engineers. We used to be a purely engineering shop, but (before my time) the thinking grew to include all three roles in each project. Previously anchors were also de facto product managers, which is a tricky and exhausting doubling-up of duties.

When this happens now, we call it "super-anchoring" and it's seen as a project smell. I've had to act as a super-anchor once or twice; it's how I learnt that having a separate product management role is essential to a healthy project.

I like how we work. As an engineer I trust product managers to worry about what to build next and why, I trust designers to be across the user's needs and UX flow and conceptualisation. They trust me to pick a simple, robust engineering solution without gold-plating.

Anyone can give input, of course. I've had PMs make great engineering suggestions. I've seen engineers with UX breakthroughs. Engineers in an IPM ask all sorts of fiddly questions that will typically lead to product changes.

We ultimately own our own roles and get final say on them. It works because it's built on mutual trust and respect.