[bob1029]

> An architect? A big part of my work is to improve systems and platforms. Listen to problems and propose solutions. But I don't feel like the guy who does a plan which must be blindly followed by others. I don't want to be a gatekeeper who says what can be used and what can't.

The only area where I feel like you need to be super careful is around architecture. How many chefs can bake the same cake before you have a total shitshow on your hands? In my experience, this depends on the complexity of the cake. The more complex, the fewer chefs can be involved at the same time.

The last place you want design-by-committee is when you are trying to model a very complex problem domain. Have your elder council determine the types, facts & relations for your solution, then let the team go wild on top of it. The people developing the schema should understand what normalization is and why it's so critical to long term success. 100% of business apps can start as excel spreadsheets documenting types, facts & relations. There is zero excuse to not start here [0].

Without some common understanding of what the fuck you even call things (and how they are related), you don't need to have a bunch of distributed design meetings about logic & UI that will be built on top of those concepts.

[0]: "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." -- Fred Brooks, The Mythical Man Month (1975)

[lumost]

From a practical perspective, most companies large enough to support PEs as described here, are going to have misaligned hacks that made sense once upon a time but are no longer sensible.

A big part of a PEs job is to keep the train moving despite nonsensical design decisions, organizational politics/empires, and legacy code bases/use cases that no one wants to touch. A good PE will help incrementally resolve/improve the above situations.

[bob1029]

> A good PE will help incrementally resolve/improve the above situations.

100% agree. What I posted above is an idealistic perspective in which you get to greenfield an application from zero. Most real world situations involve some degree of legacy domain implementations which must be bridged into the future.

Being able to rebuild the ship from the inside while it is sailing to the new world is an incredibly valuable skill set. Many developers get frustrated and demand a total rewrite (I used to do this). It would be really hard to make forward progress if you start off with a new ship in Spain every time you encountered the slightest bit of friction.

[Diggsey]

Unfortunately what you're describing never actually occurs in practice, unless you're simply rebuilding an existing piece of software, which has only technical improvements (ie. better performance, fewer bugs, etc).

The cases where you are starting from zero are also the cases where you don't understand the problem domain to a sufficient degree. You can try to get clients involved earlier, but that is very dangerous:

- It's hard to get a sufficient diversity of early users.

- Clients are incapable of prioritising what's important. Everything feature they think of (even the things they won't actually use) will be essential to them if you ask.

- The actually essential features will be so obvious to them that they won't even think of mentioning them.

- They don't understand abstractions: any concept you try to define with their help will become amorphous and therefore useless.

- Engineering is fundamentally subtractive: with zero code a product could eventually do anything. As you add code, you are restricting what it can do so that the results are the "useful" ones. For example. when you create a "user" table with an "email" property, you are restricting users to have one email address. You cannot make progress without these restrictions, but if you actually spell out those restrictions, you'll get massive pushback.

This is why so many engineers like building things for other engineers - because they can be their own client.

It's also why it's impossible in most cases to go from zero to a well-architected product in one go.

[jameshart]

This is... kind of precisely the distinction between technical leadership in a medium sized team vs in a really large team. It's one of the hardest challenges I work with senior devs to overcome as they move up to larger and larger scoped roles, up to principal engineer positions. Because what they have learned that got them that far stops working as they develop into more expansive roles and responsibilities.

Basically, the problem solving approach of 'I'll go away and work out how we're going to do this, then bring back a masterplan', while it offers a good path to successful project delivery early in your career, does not scale.

What worked for you when you were building a system with one or two teams working on it for three to six months is not a viable approach for systems which will have five to ten teams working on them, over multiple years.

You have to adopt approaches that decentralize decisionmaking - else you'll become a bottleneck; you have to adopt approaches that are adaptable to information that will be uncovered later and to requirements that will shift; you have to adopt approaches that acknowledge that you are never going to be 'full stack' enough to be able to make smart decisions about every single part of the solution - the mobile apps, the backends, the financial system integrations, the frontend caching, the analytics and reporting... and you need the expertise of different teams to deliver that.

You basically have to unlearn the pattern of 'let an experienced person set out the whole plan' that has been successful for you so far as you move to higher level leadership roles.

As a principal/staff/whatever in a big engineering org, your role is much more about making sure that the right people are having the right conversations and negotiating the right boundaries and not getting caught up on artificial constructs they think are being imposed by you from above. You need to leverage all the intellectual capabilities of the senior engineers on every team, not tie their hands by thinking you know more than them.

Same as as you become more senior, you shouldn't be writing critical code - eventually you also get too senior to be making critical architectural decisions.

[jerf]

There's some sort of PE analog to the Brooks quote I've been working on, but I'm not quite there yet. Something like "Show me your solution and conceal the org chart, and I shall be mystified by your decisions. Show me the org chart and I won't need to see your solutions, they'll be obvious."

It's not quite as determinative, though. See the data and you often really don't need the code, but even understanding the org chart isn't enough. You also need history, and some other stuff.

Still, there is a general analog, in that it's a big danger in this role to think that it's about the produced architecture rather than the structure of the business, which "capturing in data and shared terminology" is a very good starting point for.

[kevinmchugh]

You're getting close to Conway's Law

[jerf]

Well, that's part of what I meant by "it's not quite as determinative". Conway's law constrains solutions but it doesn't determine them; it's not a 100% guidepost the way "letting me see your data" almost does 100% show what the code needs to be, at least at some level of abstraction. I feel like there's some stronger formulation that may more strongly narrow down how the architecture has to look than just the org chart.

[marcinzm]

The issue is that at a certain scale no one person is smart enough, knowledgeable enough or has enough time to actually design a system properly with all the necessary detail. Those who try create an even worse mess than a design by committee.

>The people developing the schema should understand what normalization is and why it's so critical to long term success.

I'd expect everyone except a junior engineer to understand this if the system they work on support normalization well (ie: map reduce hates joins for example). If only your most senior engineers understand basic concepts then you have much more serious issues than design by committee.

>100% of business apps can start as excel spreadsheets documenting types, facts & relations.

Except in a large system no one person knows what all the types, facts and relations are. So you either delegate the work and listen to feedback, or you end up missing critical information or having the wrong information.