O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a navegar o site, você aceita o uso de cookies. Leia nosso Contrato do Usuário e nossa Política de Privacidade.
O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a utilizar o site, você aceita o uso de cookies. Leia nossa Política de Privacidade e nosso Contrato do Usuário para obter mais detalhes.
No, really • I dunno.
They handle… – Project Management! – People Management for part of the team! – All Management so I don’t have to! – Architecture!
If you don’t know, you’re
set up to fail • Inevitably, this person is going to not read your mind exactly the way you wish they did • How do you know whether they’re incompetent or just confused? • How do you hold them accountable when you don’t know what they’re SUPPOSED to be doing?
“They’ll define the role themselves!”
• If you hire someone who has done this job before and you have a shared context, that might be ok – IE, you both worked for Google, and you hired a senior manager at Google to be a Director of Engineering
A bad, but common, case
• HR hires people with random titles based on what you said you needed to hire • “Frontend Engineer” • “Lead DevOps” • “iOS Specialist” • Pay people directly based on experience and whatever HR magic formula
The Engineer Ladder: What •
The list of job levels and the description of what goes in each of those levels • BEST PRACTICE: Above Senior Engineer, has a separate path for “Manager” vs “Individual Contributor” • A device to create clarity on your team and, if done well, limit bias
The Engineering Ladder: Why •
Gives you a framework for hiring, paying, promoting • Forces you to become more clear in what you expect from people • Forces you to push that clarity into your hiring process and possibly hire better • Gives your team a growth path that helps them imagine their future with you
Creating an Engineering Ladder •
Step 1: Ask your friends for theirs – Step 0: Make friends with people who have teams big enough to justify a ladder • Step 2: Be realistic about how it applies to your team – You may not need all the levels. You may need more levels. • Write it up. Get feedback. Rewrite it. • Share it.
I’m afraid everyone will be
clamoring for titles • They probably will when you roll this out BUT • This gives you the chance to make it clear to them what success looks like! • Give them something to work towards! • Give you both a framework for talking about how they are succeeding and how they are not
Expect some anxiety • Ladder
rollouts do generate anxiety around upward mobility • On the flip side, with no ladder, people that care about upward mobility leave for a better title elsewhere
I’m afraid people will think
they should be promoted who aren’t ready • Well then, that is why you need to be very clear about what you expect at each level • People will want to be promoted with or without a ladder, if you have any sort of leadership • They’ll also want bigger pay, more options, bigger projects • How do you determine who gets what?
Your vibe is a function
of your company values and culture Do you know what your company values are? It is very possible to design a ladder to reflect and reward those values WHAT ABOUT MY VIBE?
I’m the CTO, this isn’t
my job! • Like hell it isn’t • If you are very lucky, you might find a VPE to do this for you – I would not hold my breath • This isn’t rocket science. If you can architect a system, you can architect a team.