Get the data model right
I once wrote that you should ramp up in a new job by first figuring out what most important data is, then figuring out where that data lives, how it gets there, and how it flows from there. That's more important, and more illuminating, than architecture diagrams or starter tickets.
I still think that's true, and in fact true more generally. You should also start with the data when you're designing a system. Most systems, fundamentally, manage data. The representation of that data is usually more fundamental than any other design decision for the system.
Some engineers start with the "boxes and arrows" representing subsystems and data flow. You could do a lot worse (see below), but it's usually a mistake to try reasoning about data flow when you don't know what the flowing data is. Let's say you're building a hat-management application: if someone orders a hat, is the order considered an attribute of the hat or is it a separate item? Will it happen that a line of hats has several versions, and if so, is the version or the line more fundamental? The answers to these questions will usually determine some of the questions about when and how data needs to flow through your system.
It's perhaps even more common to decide on tooling first: this might be a language, a database, a queueing system, or some combination of these and other things. Many forces push people to want to talk about these: These decisions often determine who will and will not be in their comfort zone for a project. Moreover, lots of us have tools we like best, and those preferences are often tied to one's sense of professional identity.
These pressures also tend to lower the quality of discourse: involving someone's future comfort, prior preferences, and sense of professional identity are great ways to make them think less clearly. Even if you can avoid this trap, you're left with the fundamental problem: different tools work best on different kinds of data. You're thus likely to make mistakes if you try to decide on tools first. It does sometimes happen that a given tool has advantages that make certain data models possible (or compelling), but you're a lot more likely to overlook important data questions by focusing on tools than vice versa.
So, as tempting as the alternatives might be, I think the best default is to think through the data model before the tools, architecture, or anything else. To be clear: this is an engineering opinion, not a tip for navigating politics. In fact, in organizational settings, you're likely to face pressure not to do this: enshrined system-design processes tend not to do this, and many engineers view data modeling as secondary. There's a lot to say about why that's the case, and how to deal with it, but that's another post.