6 ms·

At staff/principal level, my experience has been less about learning a new technology and more about organizational and customer needs. - Experiment and learn

At staff/principal level, my experience has been less about learning a new technology and more about organizational and customer needs. - Experiment and learn - Drive tech alignment across teams and orgs - Focus on the key decisions - Kill stupid things early on. If you fail at this, you essentially fail at the job - Be the eyes and ears to look around corners… we’re shipping some product X. We have product teams, TPMs, software managers basically a small army of friction: competing priorities, territorialism and empire building, and then the doers who you really need to help make this product happen. Are the right people working in the right problems? Are we solving them in an efficient way, using the right tooling or tech? - Partner up with the other passionate people in management. Define the tech vision and architecture so devs can continue building without burning out or running into stupid obstacles that demotivate them - Help define the culture. Mentor. Figure out what people are good at and advise the managers on who is best suited to a problem: function of their skills, growth areas, need of business, etc - have strong opinions. Don’t sway with the wind. To summarize: your focus is resounding impact. Sweat the details but only the important ones. If you need to learn a language or how something works, do your own research and go consult with other smart people in the space. Don’t pretend to know things you don’t. Be up front and ask a junior person to help you make sense of what it is you have, why are things the way they are, and how we got here.

thrwya123 4y ago
Really great answer! Thanks for it. As a freshly promoted staff engineer I am also interested in some more details, because it is not easy to find some good resources on this topic. > Kill stupid things early on Can you give some examples of stupid things? > have strong opinions This is one of the things I hear a lot, but again, what are those, any examples? My opinion could be wrong and I can't keep it strongly, especially when surrounded with smart people.
- AnimalMuppet 4y ago
  Stupid ideas often take the form of "let's spend six months of the team's time on this thing that only 3 people in world will care about". The way you kill such things is 1) by telling the truth about how much it's going to cost to do, and 2) by asking for evidence that the idea will pay back the effort required. (I mean, to some degree all development is done on faith that there will be a market there. But an idea that will take 6 months for the team needs a more solid basis than an idea that will take an afternoon for an individual.)
  - thrwya123 4y ago
    > 1) by telling the truth about how much it's going to cost to do, and 2) by asking for evidence that the idea will pay back the effort required. You are making 2 hardest questions sound easy. 1. Sometimes you need to seed optimism to get buy in and sponsorship, even though it might cost higher. 2. Not everything pays back in short term. Of course product team might care about 10% increase in revenue in short term, but 10x idea might disrupt them. That's the reason Blockbuster lost to Netflix, Rackspace lost to AWS
  - thrwya123 4y ago
    > Stupid ideas often take the form of "let's spend six months of the team's time on this thing that only 3 people in world will care about". This is obviously stupid, my gut feeling says OP wanted to say totally different type of stupidity, because your example not only stupid thing, but complete incompetence of how products are delivered, unless those 3 people are willing to pay 30B$ each.
- birdymcbird 4y ago
  >”Can you give some examples of stupid things?” “We see a need to build X. Its fancy and shiny new technology. It is right thing to do. What problem does it solve? Dont worry about that. We are going to strong arm a few teams to adopt this, even though it costs money to build and support. Sure, we can make investment in Y instead but dont want to because solving Y doesn’t let us increase head count or write promotion documents. Plus, X is very complex. It guarantees job security for people who understand it. Let’s not worry about what happens if these people then quit and make this thing everyone elses problem” Its not always outright nefarious reasons but there’s always an incentive structure incentivizing wrong behavior because it benefits individuals or is cool or fun thing to work on, without having meaningful impact or business value
- kingkongjaffa 4y ago
  > Can you give some examples of stupid things? X department (usually marketing/sales) is asking for Y thing without understand that Z thing is actually the thing customers want to solve their root cause. You have to stay on top of the 'signal strength' of feature requests. If one customers asks for a thing then okay maybe note it down. If 10 customers ask for the same thing ASAP, then clearly go make it a priority to go build the thing. > have strong opinions Being a subject matter expert / domain expert you can start to see an understand the 'shape' of the market, the customers, the problem being solved. You get a sense of the how/what/why that will really be impactful. Some products are built with huge leaps forwards that 10x the previous experience. Others are build with 1000 tiny improvements that make for a delightful UX. Both are equally valid. Having strong opinions means balancing those two operating modes. Figuring out when to bet big/when to refine/when; when to say no to little thing #342 because it's actually not helping anything.
malandrew 4y ago
Brilliant answer. This echos what I tell people about what you do after the senior level role. Senior means you’re leading usually one service or a small cluster of services with very few engineers involved. It’s largely a technical problem from junior to senior. After senior, you’re primary goal is addressing the human problems in the system.

thrwya123 4y ago

Really great answer! Thanks for it. As a freshly promoted staff engineer I am also interested in some more details, because it is not easy to find some good resources on this topic. > Kill stupid things early on Can you give some examples of stupid things? > have strong opinions This is one of the things I hear a lot, but again, what are those, any examples? My opinion could be wrong and I can't keep it strongly, especially when surrounded with smart people.

AnimalMuppet 4y ago
Stupid ideas often take the form of "let's spend six months of the team's time on this thing that only 3 people in world will care about". The way you kill such things is 1) by telling the truth about how much it's going to cost to do, and 2) by asking for evidence that the idea will pay back the effort required. (I mean, to some degree all development is done on faith that there will be a market there. But an idea that will take 6 months for the team needs a more solid basis than an idea that will take an afternoon for an individual.)
- thrwya123 4y ago
  > 1) by telling the truth about how much it's going to cost to do, and 2) by asking for evidence that the idea will pay back the effort required. You are making 2 hardest questions sound easy. 1. Sometimes you need to seed optimism to get buy in and sponsorship, even though it might cost higher. 2. Not everything pays back in short term. Of course product team might care about 10% increase in revenue in short term, but 10x idea might disrupt them. That's the reason Blockbuster lost to Netflix, Rackspace lost to AWS
- thrwya123 4y ago
  > Stupid ideas often take the form of "let's spend six months of the team's time on this thing that only 3 people in world will care about". This is obviously stupid, my gut feeling says OP wanted to say totally different type of stupidity, because your example not only stupid thing, but complete incompetence of how products are delivered, unless those 3 people are willing to pay 30B$ each.
birdymcbird 4y ago
>”Can you give some examples of stupid things?” “We see a need to build X. Its fancy and shiny new technology. It is right thing to do. What problem does it solve? Dont worry about that. We are going to strong arm a few teams to adopt this, even though it costs money to build and support. Sure, we can make investment in Y instead but dont want to because solving Y doesn’t let us increase head count or write promotion documents. Plus, X is very complex. It guarantees job security for people who understand it. Let’s not worry about what happens if these people then quit and make this thing everyone elses problem” Its not always outright nefarious reasons but there’s always an incentive structure incentivizing wrong behavior because it benefits individuals or is cool or fun thing to work on, without having meaningful impact or business value
kingkongjaffa 4y ago
> Can you give some examples of stupid things? X department (usually marketing/sales) is asking for Y thing without understand that Z thing is actually the thing customers want to solve their root cause. You have to stay on top of the 'signal strength' of feature requests. If one customers asks for a thing then okay maybe note it down. If 10 customers ask for the same thing ASAP, then clearly go make it a priority to go build the thing. > have strong opinions Being a subject matter expert / domain expert you can start to see an understand the 'shape' of the market, the customers, the problem being solved. You get a sense of the how/what/why that will really be impactful. Some products are built with huge leaps forwards that 10x the previous experience. Others are build with 1000 tiny improvements that make for a delightful UX. Both are equally valid. Having strong opinions means balancing those two operating modes. Figuring out when to bet big/when to refine/when; when to say no to little thing #342 because it's actually not helping anything.

malandrew 4y ago

Brilliant answer. This echos what I tell people about what you do after the senior level role. Senior means you’re leading usually one service or a small cluster of services with very few engineers involved. It’s largely a technical problem from junior to senior. After senior, you’re primary goal is addressing the human problems in the system.