5 ms·

Ironically I think these types of exercises are part of the problem at major software companies; terrible efficiency and over hiring. Because you need to “brag

Ironically I think these types of exercises are part of the problem at major software companies; terrible efficiency and over hiring. Because you need to “brag” to get rewarded, everyone ambitious has a list. And each list is nearly impossible for middle managers to evaluate. Someone may solve a hardcore engineering problem that has no business impact. Another person might redo some docs. Someone may create a design system version. Lots of token achievements, but not real work. Real work should stand on its own and competent managers should be able to identify it. Mediocre managers rely on lists, so then people start showing up to work and making lists.

bananapub 3y ago
> everyone ambitious has a list. And each list is nearly impossible for middle managers to evaluate. have you worked at one of the megacorps you're talking about? everyone has a list, because their manager gets them to write one, and it's very possible for managers to evaluate them because that is their job and they are largely reviewing their direct reports while getting bollocked by their peer managers.
mhss 3y ago
> Ironically I think these types of exercises are part of the problem at major software companies; terrible efficiency and over hiring. They're not the problem they're a consequence of the problems. > Because you need to “brag” to get rewarded, everyone ambitious has a list. And each list is nearly impossible for middle managers to evaluate. This will be read mostly by your manager not a middle manager. It's up to your manager then to represent your accomplishments to middle managers and above. Good thorough middle managers will still be able to assess them though. > Another person might redo some docs. Someone may create a design system version. Lots of token achievements, but not real work. Competent managers can distinguish between those, if you don't have competent managers that's the problem, not the "brag doc". > Real work should stand on its own and competent managers should be able to identify it. Mediocre managers rely on lists, so then people start showing up to work and making lists. No because even competent managers have often a wide span at large companies and cannot be involved in the day to day details for all the work their team does and things can fall through the cracks. This would only be solvable by having first line managers have less reports or less manager overhead so they can be immersed in their team's work. I have done both, but at large companies is often not possible to be immersed in the work of all of your reports, no matter how competent you are. As mentioned in the article, even you often forget what you have done last week.
- jdudkeidnn 3y ago
  > Competent managers can distinguish between those How do you do this without deep knowledge of what your reports are doing?
  - mhss 3y ago
    You can have deep knowledge of a given technology, but still not have an understanding of the details of what your reports are doing at some point in time in a given project. The brag document should include enough detail for the manager to understand (e.g PR, design links that the manager can review to assess what you did). It's in your best interest to keep your manager appraised regularly on 1:1s so it's easier for them to catch up and the disconnect doesn't go for a very long time.
    - jdudkeidnn 3y ago
      > still not have an understanding of the details of what your reports are doing at some point in time in a given project What’s preventing the manager from asking? More generally I think this is handled by standups (really any daily report of “here’s what I’m doing”) or some type of ticketing system. > The brag document should include enough detail for the manager to understand (e.g PR, design links that the manager can review to assess what you did) These should all be present in some type of ticketing system / wiki. What’s preventing the manager from using those? Fwiw, on the other end I think managers are overworked too.
      - mhss 3y ago
        > What’s preventing the manager from asking? More generally I think this is handled by standups (really any daily report of “here’s what I’m doing”) or some type of ticketing system. Nothing, however the level of detail is different. Daily stand ups are good to spot blockers and "take it offline" when there's a problem. If reports do not raise problems and the manager doesn't smell one, they won't go deep into understanding what you're doing. If you have many reports is hard to go deep into everything every day, particularly if you have a fullstack team or a variety of projects not closely related. Ticketing system would be ideal if everyone was an stellar communicator, and devs, including myself (and I've been told I am a good communicator by managers when I was an IC) often won't update tickets every day with all the nuance required to understand your work deeply. Managers at large companies also are juggling many things that is impractical to do a full sync with everyone every day (hence the need for weekly or fortnightly 1:1s). Information contained in a ticketing system also will often be filtered for "public" (anyone in the company) consumption, and there will be information (this other team is being unresponsive on chat and docs and I had to book meetings with them, etc) not reflected there. It may also often contain the 'outcome' of an investigation or status, not how you got there (more verbose communicators may include both, but that's rarely the case) which is also important to assess your work.
tail_exchange 3y ago
If rewriting your docs and solving these hardcore engineering problems have zero impact, then you shouldn't do them in the first place. If these changes are important, then they do have impact, but the engineers may not know how to communicate it. Learning to communicate impact is difficult, but it's a really good skill to have. Do these doc changes/engineering problems help reduce KTLO? Does it reduce on-call toil? Is it going to bring security patches? Is it going to make the system more efficient and save money? Are these frequently asked features? Do you have other people (preferably seniors) who can vouch in favour of these changes? All these things are measurable and can be communicated as impact. There are instances where a change has 0 impact and it's still nice to have, for example, fixing a typo in the internal docs. But these changes are usually very easy to do (take less than 5 minutes), and it won't affect your other tasks. On the other hand, spending several days fixing typos everywhere may seem like a great idea, but if nobody cares about them and it does not move any needles, then you are just wasting the company's time and money. The effort you put in these no-impact changes should be a defining factor for prioritization.
closeparen 3y ago
Tech firms and their systems are enormously complex and interrelated. Most business impact doesn’t accrue neatly to one person. To the extent that it does, you have just bizarrely chosen to aggregate a large number of independent startups under one roof vs. build an actual organization with specialization or economies of scale. At best equal to the sum of its parts, when it should be greater than.
faeriechangling 3y ago
>Mediocre managers rely on lists They’re just a data structure… and a useful one at that… competent managers work in diverse ways. Schedules are made up of lists of information, do 10x managers not use schedules?

bananapub 3y ago

> everyone ambitious has a list. And each list is nearly impossible for middle managers to evaluate. have you worked at one of the megacorps you're talking about? everyone has a list, because their manager gets them to write one, and it's very possible for managers to evaluate them because that is their job and they are largely reviewing their direct reports while getting bollocked by their peer managers.

mhss 3y ago

> Ironically I think these types of exercises are part of the problem at major software companies; terrible efficiency and over hiring. They're not the problem they're a consequence of the problems. > Because you need to “brag” to get rewarded, everyone ambitious has a list. And each list is nearly impossible for middle managers to evaluate. This will be read mostly by your manager not a middle manager. It's up to your manager then to represent your accomplishments to middle managers and above. Good thorough middle managers will still be able to assess them though. > Another person might redo some docs. Someone may create a design system version. Lots of token achievements, but not real work. Competent managers can distinguish between those, if you don't have competent managers that's the problem, not the "brag doc". > Real work should stand on its own and competent managers should be able to identify it. Mediocre managers rely on lists, so then people start showing up to work and making lists. No because even competent managers have often a wide span at large companies and cannot be involved in the day to day details for all the work their team does and things can fall through the cracks. This would only be solvable by having first line managers have less reports or less manager overhead so they can be immersed in their team's work. I have done both, but at large companies is often not possible to be immersed in the work of all of your reports, no matter how competent you are. As mentioned in the article, even you often forget what you have done last week.

jdudkeidnn 3y ago
> Competent managers can distinguish between those How do you do this without deep knowledge of what your reports are doing?
- mhss 3y ago
  You can have deep knowledge of a given technology, but still not have an understanding of the details of what your reports are doing at some point in time in a given project. The brag document should include enough detail for the manager to understand (e.g PR, design links that the manager can review to assess what you did). It's in your best interest to keep your manager appraised regularly on 1:1s so it's easier for them to catch up and the disconnect doesn't go for a very long time.
  - jdudkeidnn 3y ago
    > still not have an understanding of the details of what your reports are doing at some point in time in a given project What’s preventing the manager from asking? More generally I think this is handled by standups (really any daily report of “here’s what I’m doing”) or some type of ticketing system. > The brag document should include enough detail for the manager to understand (e.g PR, design links that the manager can review to assess what you did) These should all be present in some type of ticketing system / wiki. What’s preventing the manager from using those? Fwiw, on the other end I think managers are overworked too.
    - mhss 3y ago
      > What’s preventing the manager from asking? More generally I think this is handled by standups (really any daily report of “here’s what I’m doing”) or some type of ticketing system. Nothing, however the level of detail is different. Daily stand ups are good to spot blockers and "take it offline" when there's a problem. If reports do not raise problems and the manager doesn't smell one, they won't go deep into understanding what you're doing. If you have many reports is hard to go deep into everything every day, particularly if you have a fullstack team or a variety of projects not closely related. Ticketing system would be ideal if everyone was an stellar communicator, and devs, including myself (and I've been told I am a good communicator by managers when I was an IC) often won't update tickets every day with all the nuance required to understand your work deeply. Managers at large companies also are juggling many things that is impractical to do a full sync with everyone every day (hence the need for weekly or fortnightly 1:1s). Information contained in a ticketing system also will often be filtered for "public" (anyone in the company) consumption, and there will be information (this other team is being unresponsive on chat and docs and I had to book meetings with them, etc) not reflected there. It may also often contain the 'outcome' of an investigation or status, not how you got there (more verbose communicators may include both, but that's rarely the case) which is also important to assess your work.

tail_exchange 3y ago

If rewriting your docs and solving these hardcore engineering problems have zero impact, then you shouldn't do them in the first place. If these changes are important, then they do have impact, but the engineers may not know how to communicate it. Learning to communicate impact is difficult, but it's a really good skill to have. Do these doc changes/engineering problems help reduce KTLO? Does it reduce on-call toil? Is it going to bring security patches? Is it going to make the system more efficient and save money? Are these frequently asked features? Do you have other people (preferably seniors) who can vouch in favour of these changes? All these things are measurable and can be communicated as impact. There are instances where a change has 0 impact and it's still nice to have, for example, fixing a typo in the internal docs. But these changes are usually very easy to do (take less than 5 minutes), and it won't affect your other tasks. On the other hand, spending several days fixing typos everywhere may seem like a great idea, but if nobody cares about them and it does not move any needles, then you are just wasting the company's time and money. The effort you put in these no-impact changes should be a defining factor for prioritization.

closeparen 3y ago

Tech firms and their systems are enormously complex and interrelated. Most business impact doesn’t accrue neatly to one person. To the extent that it does, you have just bizarrely chosen to aggregate a large number of independent startups under one roof vs. build an actual organization with specialization or economies of scale. At best equal to the sum of its parts, when it should be greater than.

faeriechangling 3y ago

>Mediocre managers rely on lists They’re just a data structure… and a useful one at that… competent managers work in diverse ways. Schedules are made up of lists of information, do 10x managers not use schedules?