On Thu, Apr 15, 2021 at 05:59:35AM -0700, Marc Petit-Huguenin wrote: > > Good point. Yes, I think they all gave me the impression that they > > were glad of the mentoring, found it useful as first-time > > attendees, and didn't find that they were unwelcome. But they > > didn't find the IETF to be a "must do" for the future. > > That's also, I think, an important point. Staying at the IETF, > i.e. taking on new work beyond the initial reason someone joined, is > quite difficult. The life cycle of an RFC nearly always spanned > different employers for me, which means that I had to finish the > work without a sponsor. Worse, Internet interoperability is rarely > deemed critical by employers, and so is the first budget that get > cut-off -- and again forcing to choose between abandoning the work > done or continuing without sponsor. So when I mentor someone at my company, what I find spending the majority of my time is spent offering advice on how to manage the considerations of internal company dynamics. In the open source world, for example, a lot of it is about how to justify a project which contributes to open source in a way that doesn't harm your career. The fact of the matter is the easist way to get promoted is to show $XXX million dollars in increased revenue, or decreased cost. And while it is *possible* that a particular open source development effort might result in that, it's much more difficult to show that the open source development effort was a direct cause in growing revenue or decreasing cost, at least in an easily demonstrable way that can be considered by a promotion committee with very tight word count constraints on your promotion packet. I would submit that there is a similar issue with standards work. Sure, standardation might improve a product's value in the eyes of the customers --- but was it really what made your company make an extra $XXX million? It's hard to make that case, and how you need to make that case is very dependent on internal company dynamics, and not something where an external mentor could help all that much. If many IETF'ers do standards work out of a passion to make the world a better place, and continue their work across multiple employers (which is very similar to many open source engineers), then it may very well be that the most useful mentorship is from someone in the company they are currently working for, or someone who has extensive experience from inside that company, even if they aren't working there any more. This doesn't help engineers who are working at a smaller company (or from lesser developed countries) where there aren't any current IETF participants who can give them that insight, however. > But most of them disappear when they got a first job, mostly because > the pressure of a first job is incompatible with participating in an > organization like the IETF. After all these years, it is nearly > impossible for me to convince a new employer to reserve some of my > time for the IETF, so there is no chance someone could get that in a > first job. How can we change that? Agreed, that's a hard problem. The best answer I have at this point is that if you're lucky, your company will cover travel expenses, but you may have to spend a lot of time contributing to "public good projects" (either IETF standardization or open source work), effectively on your own time, and hopefully that will be an investment in your future career or promotion prospects. It will likely be only "brownie points", especially early in your career, but hopefully in the long run, it will be part of your own distinctive "brand" as an software engineer. If anyone has a better answer, I'd love to hear about it! - Ted
