5 ms·

A huge missing part of the "Employees" section — which is great as a focus, by the way — is specifying how your management works. Especially in engineering org

A huge missing part of the "Employees" section — which is great as a focus, by the way — is specifying how your management works. Especially in engineering organizations, a consistent problem is moving people into management positions based on their skill as an individual contributor or tenure. Both are orthogonal to people-management skills and, though good to have from a team respect standpoint, far less useful. Is it a priority of yours to avoid those problems? If so, it would be great to see it listed out. How do you organize teams to be optimized for Employees? Especially as you grow, I would imagine managing people towards their goals and those of the company is going to be a larger and larger part of that employee happiness. edit: There is also nothing on employee growth. If that is a something you value, it would be cool to see it in there.

edawerd 11y ago
It's definitely a priority here, and more so as we continue to grow. This particular engineering value was intentionally left a little vague because prioritizing the people in the company can mean so many different things, and we wanted to purposefully leave it a little to interpretation and our best judgement.
- chralieboy 11y ago
  It sounds like the purpose of these values is to provide guidance. From your piece: > It’s a framework that we can turn to whenever we’re faced with a difficult decision, whether it be about how to best architect something, how to prioritize our time, who to hire, or how we interact with each other. Why would you then leave a growing priority vague and up to interpretation? Isn't that exactly the type of miscommunication and lack of guidance you're trying to avoid? P.S. I do think the exercise is great and don't want to sound unnecessarily critical. Especially for such an important part of companies (people) and common issue in engineering organizations (management), though, it seems like one of the first places you should put a stake in the ground in terms of action, guidance, and specific commitments.
ryandrake 11y ago
Most places I've worked had no career path above Senior Software Engineer that did not involve moving into management, which as you point out, is not necessarily a skills match with "that smart individual contributor who you'd like to reward". I've heard some larger companies "solve" this by providing some title advancement past "3rd Senior Engineer from the left". But is it satisfying to you folks on these tracks? When you go from Senior Software Engineer to Staff Software Engineer to Super Staff Software Engineer to Super Duper Staff Software Engineer, do you consider it to be real career growth? Do you find that this is truly a _parallel_ path with management, or does it eventually plateau (i.e. the management path ultimately ends up reaching farther)?
- fingerprinter 11y ago
  Outside perhaps 'architect', what does a reasonable progression look like? I struggle with this personally so very curious what others think.
  - ecoffey 11y ago
    While Management usually the only thing equated with "soft" (hate that word beeteedubs) skills, moving up the IC ladder also requires good inter-personal skills. Above senior you are allowed and expected to go "heads down" (by yourself or a small group) and knock out solutions to technical problems. However you are also expected to identify cross-cutting problems, rally the right people, coherently frame your arguments, etc to move the "implementing solutions to technical problems" needle (even if you don't directly write a lot of that code). Management also get's the "fun" things like "let's talk salary!" or "you need to improve along X, Y, Z axis!" :P Just my two cents :)
    - fingerprinter 11y ago
      Oh, I agree with everything you just said. I was just wondering what it looks like from a career progression standpoint. If it's just titles, it's tough. What you said about those cross-cutting problems and all that is spot on and that is basically what I see sr. engineers and architects. However, how do we or should we even further delineate career progression and responsibilities? And what does that look like? What is beyond those things?

edawerd 11y ago

It's definitely a priority here, and more so as we continue to grow. This particular engineering value was intentionally left a little vague because prioritizing the people in the company can mean so many different things, and we wanted to purposefully leave it a little to interpretation and our best judgement.

chralieboy 11y ago
It sounds like the purpose of these values is to provide guidance. From your piece: > It’s a framework that we can turn to whenever we’re faced with a difficult decision, whether it be about how to best architect something, how to prioritize our time, who to hire, or how we interact with each other. Why would you then leave a growing priority vague and up to interpretation? Isn't that exactly the type of miscommunication and lack of guidance you're trying to avoid? P.S. I do think the exercise is great and don't want to sound unnecessarily critical. Especially for such an important part of companies (people) and common issue in engineering organizations (management), though, it seems like one of the first places you should put a stake in the ground in terms of action, guidance, and specific commitments.

ryandrake 11y ago

Most places I've worked had no career path above Senior Software Engineer that did not involve moving into management, which as you point out, is not necessarily a skills match with "that smart individual contributor who you'd like to reward". I've heard some larger companies "solve" this by providing some title advancement past "3rd Senior Engineer from the left". But is it satisfying to you folks on these tracks? When you go from Senior Software Engineer to Staff Software Engineer to Super Staff Software Engineer to Super Duper Staff Software Engineer, do you consider it to be real career growth? Do you find that this is truly a _parallel_ path with management, or does it eventually plateau (i.e. the management path ultimately ends up reaching farther)?

fingerprinter 11y ago
Outside perhaps 'architect', what does a reasonable progression look like? I struggle with this personally so very curious what others think.
- ecoffey 11y ago
  While Management usually the only thing equated with "soft" (hate that word beeteedubs) skills, moving up the IC ladder also requires good inter-personal skills. Above senior you are allowed and expected to go "heads down" (by yourself or a small group) and knock out solutions to technical problems. However you are also expected to identify cross-cutting problems, rally the right people, coherently frame your arguments, etc to move the "implementing solutions to technical problems" needle (even if you don't directly write a lot of that code). Management also get's the "fun" things like "let's talk salary!" or "you need to improve along X, Y, Z axis!" :P Just my two cents :)
  - fingerprinter 11y ago
    Oh, I agree with everything you just said. I was just wondering what it looks like from a career progression standpoint. If it's just titles, it's tough. What you said about those cross-cutting problems and all that is spot on and that is basically what I see sr. engineers and architects. However, how do we or should we even further delineate career progression and responsibilities? And what does that look like? What is beyond those things?