Comment by antonvs
1 year ago
> But it’s really important that one person on the project has an end-to-end understanding of the whole thing: how it hangs together technically, and what product or business purpose it serves.
In the before times, we called this an architect. We're too agile for that now, apparently.
No, in the before times, we called this a project manager.
The project manager worked closely with the architect, but the architect focused exclusively on the high-level code/engineering part, not the end-to-end understanding of the whole thing that involved management, partners, corporate processes, approvals, etc.
(And note the distinction between project manager and product manager, two entirely different jobs. Project managers stereotypically use Gantt charts to focus on timelines and contingencies and processes; product managers focus more on user needs and product-market fit.)
Now, that responsibility has been dumped on Tech Leads, who have neither the power of the Project Manager, nor the responsibility of the Product Manager.
And depending on how your company selects Tech Leads, they might not have the technical ability of an Architect, or hell, even a senior engineer.
That's because they're an engineering manager in tech lead clothing.
It's so the company can say they have more engineers and less management, but still fill all of the roles that they need managers to do.
(I've written elsewhere how you can run without engineering managers - see https://www.ebiester.com/agile/2024/03/31/a-world-without-en... - but the roles that need to be filled don't stop.)
2 replies →
As a Staff Eng, I strongly related to this. At big tech in Silicon Valley, the Tech Lead archetype does tend to do all the Project Management and, depending on whether your team can afford a Product Manager (eg. Infra team), some or all of the Product Management.
IMO, it's a little unfortunate from a productivity perspective that you have a high performing Engineer also running daily/weekly syncs, doing stakeholder management, and doing upwards management for resourcing. From a personal learning perspective, it's great though. You, as Tech Lead, learn and hone a broader set of skills and not only the Architect or Senior Engineer skillset.
I thought this was only happening in academia
>And note the distinction between project manager and product manager
And then there's the product owner.
Agree on the role distinctions, but the best people in any of those roles will be able to see/do some of the important factors in the other domains and ask questions like "so what does success for this project look like?"
> Project managers stereotypically use Gantt charts to focus on timelines and contingencies and processes
...and dependencies between teams/stakeholders. :)
Ok, the before-before times then.
When a company does not want to pay (or empower) a principal engineer, they hire legions of junior engineers to cover up the gap. People who focus on the joy of shipping than on the pesky questions of "shipping what?" and "who will maintain it?"
Many of us here owe our jobs to the deliberate weakening of technical authority and expertise. That debt probably blinds us to those management decisions, and the need for architects to balance them out.
Oh how I wish I had a legion of junior engineers. Or even a squad.
My company has an aversion to hiring. It's so expensive to hire people, you know! There are no young engineers to teach the ropes to. There are very few senior people do everything.
Needless to say nothing happens fast, good, or cheap. And we don't ship projects, they mostly just bob up and down in the harbor.
oh how i wish I had a single junior engineer.
my company hires like crazy for new things, but the maintenance of critical things are just the same humans who always take care of it.
and then we get asked to work on the new things too, and it's like, uhhhh...
That's not just an architect. It's an architect, a construction worker, a bricklayer, a plumber. That person might not do everything but needs to be able to dive deep as low as required.
who says an architect doesn't build things?
Most architects.
2 replies →
Architect? That sounds like a lot of money. We're just gonna stick some rando as the product owner and call it a day.
Let's one up by getting a rando on board as "business analyst" but expect him to do product owner stuff.
Learn on the job, sink or swim, YOLO! (you only learn on-the-job)
You look like a straight shooter with upper management written all over you.
2 replies →
The main requirement is for the person to be on the project and have skin in the game. An architect will often have more of a bird eye view and not be actively working on a specific release. They might also not care about the business side.
IMO depending on the org, the matching role would be either a release manager or a project lead.
Architects these days have only a very narrow view of how the actual product works. But that’s also because we outsource so much shit.
Rather systems have become bigger and more complex to the extent that most cannot be understood fully in both dimensions of breadth and depth.
This is a great article. Reflects my experience both in big and small companies. Anyone can be the "Project leader", doesn't need to be a TPM, PM or ENG. It isn't an org chart role, it is a role you are fulfilling. I have seen many different org chart roles succeeding or failing at it.
This also allows companies to bake it into a role without commiserate pay increases and even sometimes without modifying responsibility only adding on to them.
Don’t be fooled folks, if you aren’t being paid more for leading and taking visible ownership over things you’re being cheated
This is a very snarky/bitter view of it. In my career I have done fairly well and have been promoted after the fact a couple of times. People who don't take these opportunities rarely move up to bigger responsibilities. At big tech is usually expected that you are already performing at a level above for a certain period of time before being promoted
In my team, this role is covered by the tech lead, who also takes on the responsibilities of project manager, scrum master, and business analyst (team members help with business analysis).
don’t remember architects had a truely intricate knowledge of the business metrics. It was more of a technical role.
I think this is a change in business climate today - all senior+ engineers in many companies are now expected to have knowledge of business metrics, and that expectation goes up with staff engineers (the new architect name)
I think this expectation has always existed, but engineers have been able to get cover for not understanding or participating. Now it is harder for engineers at any level to cover which means they have to understand the business and participate to a larger degree. This may just mean being more proactive in raising issues affecting metrics through to influencing what those metrics should be.
> In the before times, we called this an architect
agile and ITIL both