Yeah, I think TFA gets a lot right about doing software engineering in large orgs.
We call this role something like "lead developer" and it's as much about people, relationships, logistics, and documentation as it is about technical systems — but like TFA says, it's also your job to have the best holistic understanding of the technical system. A lot of more junior engineers are likely to work on a large project, and they will inevitably need guidance to satisfy the constraints of other parts of the system. You are responsible for knowing those constraints and, as much as possible, preventing mismatches when different components come together.
Meanwhile, the non technical staff (whether it's a manager or someone from the sales team, documentation team, customer support team, etc) are going to need someone who can explain the technical system to them in plain language. "Can it do this? How fast? Why can't it do this?" You tend to become their main interlocutor.
It's kind of your job to anticipate problems before they happen, to look into the future so you see what's coming and solve it in advance, and then to show up all the time when something needs help around launch, which it always does. It's very undefined but there's always something that needs doing.
This role doesn't sit well with some engineers who think their job is basically about coding and staying within their lane — those engineers don't get to be lead dev too much, because they don't do well with the organizational side of things. (It depends, of course, whether there is a hands-on project manager who can pick up a lot of that slack, but where I work, we don't always have that.)
(Context: I have worked in a large tech company a little more than 3 years and shipped some things. And before that I shipped a lot more things in smaller places – I like to think that shipping in small shops was a good prerequisite for shipping in large ones.)
We call this role something like "lead developer" and it's as much about people, relationships, logistics, and documentation as it is about technical systems — but like TFA says, it's also your job to have the best holistic understanding of the technical system. A lot of more junior engineers are likely to work on a large project, and they will inevitably need guidance to satisfy the constraints of other parts of the system. You are responsible for knowing those constraints and, as much as possible, preventing mismatches when different components come together.
Meanwhile, the non technical staff (whether it's a manager or someone from the sales team, documentation team, customer support team, etc) are going to need someone who can explain the technical system to them in plain language. "Can it do this? How fast? Why can't it do this?" You tend to become their main interlocutor.
It's kind of your job to anticipate problems before they happen, to look into the future so you see what's coming and solve it in advance, and then to show up all the time when something needs help around launch, which it always does. It's very undefined but there's always something that needs doing.
This role doesn't sit well with some engineers who think their job is basically about coding and staying within their lane — those engineers don't get to be lead dev too much, because they don't do well with the organizational side of things. (It depends, of course, whether there is a hands-on project manager who can pick up a lot of that slack, but where I work, we don't always have that.)
(Context: I have worked in a large tech company a little more than 3 years and shipped some things. And before that I shipped a lot more things in smaller places – I like to think that shipping in small shops was a good prerequisite for shipping in large ones.)