Taro Experts

I would preface and say that there's still a big demand for DBAs within the tech industry overall. It's not as high as 10 years ago before the rise of managed services and cloud, but I would still consider it a viable career.

Now to answer your question, I would lean towards Data Engineering. As a DBA you are naturally exposed to a lot of queries and interact with the data model on a daily basis. Plus you understand best practices around "operational excellence" such as performing backups, IAM, security, ACID properties, etc.

All these skills are highly transferrable to data engineering. To make things easier, you could even niche down to a particular area such as performance tuning queries or data modeling. When I was in tech consulting, there's a huge demand for these roles, especially in large enterprise. I haven't met a single company that is really happy with how performant their queries are or their data model design.

Data integrations should come naturally as well since the DB is usually a data source or the destination itself.

To get a 30K overview of data engineering, I highly recommend Joe Reis' book "Fundamentals of Data Engineering". You can find it on O'Reilly platform.

Hope this helps you make a more informed decision. DM me if you'd like a quick POV on the other career paths (I've spent some time in each and hired lots of people into these roles).

If you want to build it - just do it!

Personally I tend to do just enough reading of a book/documentation/tutorial to get started then jump into a project - I may have a slight bias here :)

Then when stuck, or just not making enough progress read a bit more to get unblocked.

Most people here are talking about focusing on social "influence." I disagree. If you have a project that is well thought out, made simple, and well reasoned via an ERD that is 80-90% of the way there and several reviews from other people, there will be no shortage of people eager to jump on it for an easy win, especially if it has high impact.

Social influence just gives you an edge but is not a substitution for proper engineering.

What you've described is the "what" of software engineering, not the "how". That is, you are overindexing on information. Overreliance on this is very dangerous because you will never be able to fully comprehend all the intricacies of a constantly evolving codebase. What was true 6 months ago may not be true today.

I have never met even a Staff Engineer who could 100% tell me with absolute certainty what is happening across tech stacks that he has never worked on, only a rough general mental models for how they interact with each other.

It is only when you work with the code itself that you really understand what information is true and what is false. People may be mistaken. Documentation may be outdated. They are good starting points for information but you should weigh the accuracy of the information with the source.

There is what you think you know. Then there is what you can prove.

So I will tailor my answer on how to achieve this.

Consider that the job of a senior engineer is be able to solve "known" problems but the solution is "unknown". In most cases, this usually is a product or a feature that requires participation from both mobile, backend, and other tech stacks.

Work backwards: what kind of work should be expected?

1. The project should have a solution that is sufficiently de-risked and well reasoned. Why is it the best possible solution out of all other solutions? Why should things be implemented your way versus other ways?

2. Each part of the solution should be discrete, well laid out, and step by step such that anyone can do it. These usually correspond to Jira tasks.

   However, unless you've specifically interacted with that code, you're probably not going to be able to do this. What is most likely to happen is that you will have to consult with several experts in tech stacks that you are going to be making changes in and asking for their opinions. What components need to be modified, how the system at a high level interacts, what significant changes have been made in the past x months that you should be aware of, etc. You may need to also see a sample example of each of the interactions for clarity.

3. Hypothesize and iterate. Research is par for the course. You will have an idea of a solution. It will probably be wrong because you didn't know a few details that someone else will bring to your attention. Then you will need to improve your solution's design over and over again until it is the right one. This is what the ERD process is. It is a high level overview of how different systems, code, and contracts interact with one another. This is what you want to be able to visualize and understand. Yes its kind of a PITA but to be honest, clarity of design and thought and consensus about what is important and how to do things and checking for what you do not know is going to save you a lot of grief later on. Especially when avoiding crashes.

4. When in doubt, delegate. For areas you are responsible for, your knowledge should be deep. For areas you choose to delegate, you should have the right rough broad strokes and let someone else fill these in. It is not necessarily important that you know how to work with a custom in-house architecture on the mobile side if you're a backend engineer. All you need is for the mobile engineer to craft a feature that does xyz behavior when abc payloads are sent from the backend.

5. If all else fails, sometimes put the team on your back. I've been in projects where people who are responsible for their portion do not deliver or, at least, need you to figure out something for them. Do what is necessary to find the piece of information or general strategy. I find that finding example diffs that are similar to what is expected is a very good way of communicating this. Chances are, in a mature codebase, standards have been set and features don't differ too much from one another. You can probably dive into the git history and pull up a change similar to the one you are thinking.

Your relationships with people are not nearly as important as your ability to execute and deliver. Or rather, your relationships with people are meant to allow you to execute and deliver on projects. Influence is leverage but if you cannot even deliver or execute, there is no sense in applying leverage or influence. Why should people do what you say when you do not have a clear plan or vision for how the product will be made?

At the end of the day, your solution should be mostly right. There will always be small hiccups not accounted for but they should not move the solution roadmap too much unless you're dealing with something very bleeding edge or you're looking to perform a task where both the problem and solution are unknown (and therefore, nobody has any context on).

Adding to the list provided by Rahul:

• Be attentive in meetings and contribute by asking good questions and providing suggestions
• Conduct knowledge sharing sessions on your work or other things you think would be beneficial to the team.

This isn't always necessarily a bad thing, it depends on your company culture. I would say unless you have good evidence, give the new manager a try. If it ends up being a bad fit, transfer teams, but don't do so until you're sure that the current manager is poor and the alternatives are good.

From my experience, if it's a manager without experience, you get more autonomy. They have less experience, often less expectations, and rely on you more to take charge. This is a great opportunity to better advocate for work you want to do and push back on things like timelines and priorities you think are detrimental to your work and organizational goals. It is also easier to stand out since other team members may not be able to make use of the opportunity as much as you are.

However, if the manager is purely HR related and doesn't overlap with your actual work and priorities, then my point is less relevant.