Becoming Principal Engineer: Is Your Mindset Blocking You?
Understanding the common pitfalls and how to overcome them.
Maybe you have all the technical knowledge and experience needed to be promoted, but your mindset is holding you back. In my previous text, I invited you to reflect on whether the staff or principal levels are what you want. If you read it and still think it is for you, stay with me.
Today, I’ll share the main beliefs and behaviors engineers fall into and must change to be promoted.
👴 You’re relying on tenure.
🌱 You’re relying too much on your manager.
⚖️ You're off balance with technical and non-technical aspects.
🎯 You don’t go beyond your primary responsibilities.
🤚 You don’t embrace criticism.
👴 You’re relying on tenure.
Longevity in your current position does not guarantee promotion. If you want to move up, learn about the next level. Find out the responsibilities and goals you must achieve to get the job. Talk with people in the same position and with people in roles you would interact with more often. Understanding what they expect, see, and lack in those levels will help you to discover what you need to focus on.
Once you fully understand the expectations, it's time to develop the skills you need. Think about things that will help you develop these skills and how you could start doing them. Maybe you need a course, a mentor, or an opportunity to practice.
🌱 You’re relying too much on your manager.
The higher you go, the higher the level of abstraction you need to deal with. It includes your development. If you expect your manager to say everything you need to do to move to the next level, you will get stuck. At this stage, you must optimize for self-organization and self-direction. You must be able to identify where you are and ask for what you need to move one step ahead. Be self-driven and own your career development. Start as early as you can, and remember to communicate your goals.
⚖️ You're off balance with technical and non-technical aspects.
Do you think of business and technology as separate entities? If so, you have a problem. One doesn’t exist without the other. Technology alone doesn’t make a product or feature; a good idea without technology won’t create anything.
After years, two maladaptive patterns arise among engineers. I call them the business savior and the technical knight.
The business savior understands the importance of having a business going on. However, they focus too much on immediate delivery and sacrifice quality; business people might love them until the “no” arrives due to technical limitations. Meanwhile, the technical knights have been ready to put a sword into the saviors’ hearts. It isn’t difficult to understand. The knights are the ones who need to deal with the mess that was left behind.
The Technical knights are so disappointed with technical debts, spaghetti code, and poor architecture that they feel they must protect it from the business. It leads them to think about the perfect solution from the beginning, developing things that are not necessary because “they won’t have time to fix it in the future”.
Engineers who balance technical and non-technical aspects don’t overengineer. They use workarounds as the last resource. Avoiding refactoring to save time or solving problems with workarounds slows the team down over time due to the number of technical debts. Overengineering adds complexity you don’t need, which will have the same output.
Communicate the risks of not prioritizing a technical project to the business, negotiate smaller improvements on the regular development cycle, and leave the code better than when you found it. Don’t forget cross-functional requirements when defining scope. Product managers often focus on the feature from the customer-facing perspective. Usually, you must be the one who thinks about performance, security, accessibility, and so on. Revisit the architecture and application design constantly. There’s no bulletproof solution. The product will change over time, and the code should adapt to the new needs.
🎯 You don’t go beyond your primary responsibilities.
Don’t hide yourself behind a role. If you can contribute to something, do it. Restricting yourself to the code prevents you from showing that you can expand your impact. You must be flexible, act out of your primary responsibilities, and be outcome-oriented. You must provide solutions, and if you don’t question the status quo, it will be hard, and you will end up providing more complex alternatives that will require more time to develop, which is a waste of money and time.
Here are some examples of things you can do.
Lead projects from the beginning until the end. Seek opportunities from ideation. Do not step in only when the decision about the “what” is already in place. Remember that “until the end” means fully released and sometimes with data to track results.
Be a voice on the solution definition. You’re not only there to listen and say “yes” or “no” from a technical perspective. You must also be able to understand the problem and provide smart solutions.
Be active in cross-team initiatives. Often, projects touch more than one team. Take the opportunity to be the focal point person. Participate in broader technical discussions. If you’re not invited, volunteer.
🤚 You don’t embrace criticism.
If you don't take criticism in a positive way, it’s bad, and it will become worse as you move forward. It could be enough for your manager to step back with a promotion.
Think about what criticism means to you. Does it make you feel insecure? Does it make you think you're not ready for the role? It is time to look at it from a different perspective. Embrace the criticism you receive and make it a growth opportunity. It is the best way to speed up your path to success.
Many people think they are open to feedback when they are not — they just don't realize it. Read one of my previous texts, Feedback: Is Your Brain Tricking You?, and check if that is your case.
Don't wait for people to tell you what's not going well. Be active and seek feedback that will help you grow. Don't underestimate feedback because people often don't provide you with good ones. The quality of the feedback you receive is also your responsibility. Learn how to seek feedback that helps you grow. You will be surprised once you change your approach.
Your mindset needs to change, and you also need the right skills. Some things become more important than others. What’s nice to have becomes a must-have, and new skills will be required for your next level. In my next text, I’ll share the competencies you need to move up.
🔖 Related Content You Might Like
Seniority vs Experience vs Competency by Nicola Ballotta. Even if it focused on the hiring perspective, in this text, Nicola brings essential aspects that you could use to grow your career.
How to Self-Manage Even if You Have a Manager (Your Future Self Will Thank You) by Irina Stanescu. Irina shares amazing tips on how to self-manage. It will help you accelerate your growth and make you less dependent on your manager.
That's all for today! 🎉
I like getting feedback and connecting with people. Feel free to reach out—I'd love to hear from you! You are also welcome to suggest topics for future posts.
See you next time 👋
It has been a pleasure reading your texts every week, Dani. In this one, I think you covered important things to be aware of as a Principal who thinks not only as a technical leader but also as a product problem resolver. And you did it amazingly. Thanks for sharing your knowledge.
Thanks for the feedback, Gabi! I'm happy to know you're enjoying it ❤️