No matter how important an objective is for your company, you can’t suddenly assign a thousand engineers to work on it using systems built for 10 engineers and still expect results. In recent years, we've seen tech companies often invest 30% or more of their engineers in platform teams, intending to allow product engineers to move faster. I find this trend interesting and a clear indicator of where our industry is heading. However, simply increasing the number of engineers in platform teams won’t automatically solve the scaling challenges. You still have to build the right tools, processes, and culture that enable those teams to drive efficiency and innovation across the organization. Without a holistic approach and a product mindset applied to platform engineering, companies are essentially throwing money into a black hole, hoping for results that may never come. My experience at Thinkific shows that when we align platform investments with company priorities, create specialized teams, and build a strong platform engineering culture rooted in high agency, extreme ownership and continuous improvement, incredible things happen. You enable faster shipping, fewer bugs and outages, and most importantly, a resilient, scalable infrastructure that adapts as your business evolves. Start early and treat platform investments as an ongoing priority. This will set your teams up for long-term success, allowing them to focus on delivering value rather than battling technical debt and inefficiencies.
Fernando Botelho’s Post
More Relevant Posts
-
Embarking on the path of Platform Engineering often feels like navigating uncharted territory. I've personally experienced the challenges of establishing this domain in environments where its value is yet unrecognized. But the journey, though demanding, has been incredibly rewarding. My aim in sharing this is simple: to offer hope and guidance to those facing similar hurdles. Embracing Platform Engineering is more than a technical shift; it's a strategic move towards organisational growth and innovation. This journey has taught me resilience, the power of strategic thinking, and the importance of aligning technology with business goals. The positive impact on efficiency, product development, and market competitiveness is undeniable. To those on a similar path, keep pushing forward. Your efforts are laying the groundwork for transformative change. #PlatformEngineering #BusinessGrowth #Innovation
-
Working in the world of software engineering, we've all encountered that precarious balancing act between delivering features and addressing technical debt. The trick is, both are crucial for a successful product - but how do we prioritize one over the other? Imagine a world where our product managers and engineering teams could align seamlessly, where tech debt wasn't seen as a hindrance, but as an opportunity to improve developer productivity and product quality. The key to unlocking this harmony lies in treating tech debt work just like feature work. By having metrics that measure its impact, articulating clear definitions of 'Ready' and 'Done', and maintaining operational excellence initiatives in our backlog, we can present a compelling case to our PMs and senior leadership team. Embracing this mindset has the power to transform the way we view tech debt, moving it from a tough sell to a welcomed necessity. If you got value from this, please follow me! I write daily about engineering management, team dynamics, and processes needed to build engaged and successful teams. #SoftwareEngineering #TechDebt #Management #Leadership ----------------------------------- Check out the full article at https://lnkd.in/gbAhctXQ
-
Matt is spot on. CTO shouldn’t be the goal for those who want to be the best engineers. It shouldn’t be the goal for those who thrive managing people and processes the VP track is a better fit. When I think architect I think a well paid distinguished engineer who is an expert in coding and architecture. When I think of VP I think of the process focused people person. CTO is about creating vision centered around technology for products and organizations.
Product Driven - Founder of Full Scale - CTO for 20 years, Bootstrapped a company to a 9 figure exit, Podcast host, Creator
The best engineers become architects, not CTOs. The best managers become VPs of Engineering, not CTOs. The best at building products become CTOs. The best at building products and coming up with product ideas become Visionary CTOs and startup founders. Building software is about building products, not about writing code. To be a CTO, you need to think more about the product and less about the code. Check out my latest article about the CTO Career Path: https://lnkd.in/gTccaWUi
-
Non-technical founders always have this problem: If you are looking to assemble your own technical team, Although you are not technical, it’s possible for you to be the founder and head of a technical product. 3 things to know before assembling your own technical team: 1. You need to bring in a strong technical presence, or maybe learn to be one yourself. This is definitely needed. You need someone who is mature enough to assemble the best talents for you if you don’t have the time and resources to do that yourself. Your job is now left to just find that presence, and sort of, everything will add up so easily. 2. Get people who are product-driven and experienced in product development. Product-driven, meaning they care more about the product being complete and working well than they care about using the latest technology. They are also mature in product development in the sense that they don’t get you into unnecessary technical debt, for example. 3. Lastly, get someone who doesn’t crack under pressure. What I mean by that is: -You will have stakeholders -You will have product and feature requests -Customer feedback You need someone on the technical side to go; no, this is not possible. No, this is going to branch out the product so much. Someone who can make the right decisions on where to move technically when under pressure. How you build your product is as important as how you market it.
-
-
Non-technical founders always have this problem: If you are looking to assemble your own technical team, Although you are not technical, it’s possible for you to be the founder and head of a technical product. 3 things to know before assembling your own technical team: 1. You need to bring in a strong technical presence, or maybe learn to be one yourself. This is definitely needed. You need someone who is mature enough to assemble the best talents for you if you don’t have the time and resources to do that yourself. Your job is now left to just find that presence, and sort of, everything will add up so easily. 2. Get people who are product-driven and experienced in product development. Product-driven, meaning they care more about the product being complete and working well than they care about using the latest technology. They are also mature in product development in the sense that they don’t get you into unnecessary technical debt, for example. 3. Lastly, get someone who doesn’t crack under pressure. What I mean by that is: -You will have stakeholders -You will have product and feature requests -Customer feedback You need someone on the technical side to go; no, this is not possible. No, this is going to branch out the product so much. Someone who can make the right decisions on where to move technically when under pressure. How you build your product is as important as how you market it.
-
-
💡I vividly remember (to this day and probably all throughout my career) one of my past experiences as a Technical Lead taking over a project without sufficient support or clarity on how to navigate it and how this proved to be a significant hurdle. 📉 Despite my best efforts, I struggled to ask the right questions and seek the assistance needed to steer the project towards success. This was one of the toughest lessons I l've learned and it highlighted the importance of proactive communication and resourcefulness in leadership roles. 🙏🏻 Needless to say I am endlessly grateful for having experienced that since it has helped me develop a completely different approach to new challenges that allows me to look forward to new beginnings instead of dreading them. #LessonsLearned #LeadershipGrowth #GrowthThroughFailure #LeadershipLessons #ContinuousImprovement
The problem with starting as a new engineering manager: We think we should know everything. The developers know more about the tech than us. They have all the context to make great decisions. Instead of feeling inadequate: - Be open about your ignorance. - Ask for options. - Request clarifications. - Get their favorite option. - Dig into their reasoning. - Align them with the business. - Make the final decision. You don't have to be the smartest person in the room, but you need to understand how the different paths you can take may affect the business. P.S. Enjoy your weekend ✌️
-
By harmonizing data-driven insights with an understanding of team dynamics, engineering executives can foster a balanced, innovative, and productive environment. Learn more about this in the latest article from our CEO, Alex, in Forbes.
Council Post: How Engineering Leaders Can Achieve A Balanced View Of Team Success
social-www.forbes.com
-
Over 7.5+ years Building Robust and Scalable Distributed Systems for Enterprises | Tech Enthusiast and Startup-Minded Software Engineer | Techpreneur
I agree somewhat with the statements. While I acknowledge the importance of shifting focus from code-centric thinking to a more product-oriented mindset for a Chief Technology Officer (CTO), I believe that a successful CTO should possess a balance of both technical and strategic skills. It's crucial for a CTO to understand the intricacies of product development and be able to align technological decisions with overall business objectives. In essence, a visionary CTO should not only excel in building products but also possess the ability to bridge the gap between technical excellence and strategic product innovation.
Product Driven - Founder of Full Scale - CTO for 20 years, Bootstrapped a company to a 9 figure exit, Podcast host, Creator
The best engineers become architects, not CTOs. The best managers become VPs of Engineering, not CTOs. The best at building products become CTOs. The best at building products and coming up with product ideas become Visionary CTOs and startup founders. Building software is about building products, not about writing code. To be a CTO, you need to think more about the product and less about the code. Check out my latest article about the CTO Career Path: https://lnkd.in/gTccaWUi
-
This is good advice for any one stepping in to a tech leadership role. Surrounding your self with competence and trust is key to successful building.
The problem with starting as a new engineering manager: We think we should know everything. The developers know more about the tech than us. They have all the context to make great decisions. Instead of feeling inadequate: - Be open about your ignorance. - Ask for options. - Request clarifications. - Get their favorite option. - Dig into their reasoning. - Align them with the business. - Make the final decision. You don't have to be the smartest person in the room, but you need to understand how the different paths you can take may affect the business. P.S. Enjoy your weekend ✌️
-
Engineering managers need to balance things. When helping software engineers on the team prioritize tech debt, Nick answers Graeme's question about the value of engaging work. As engineering managers, we need to represent our team members. So if we're helping to get important work prioritized, we need to work with the engineers to be able to represent the value their trying to convey with the product owners. ---- 👀 Check out the full video on our channel! 🗣️ Share with your network! #softwareengineering #engineeringmanager #engineeringmanagement
Fostering AI Leadership | Architect at Databricks | Ex-Microsoft Director | Harvard Grad | Jiu-Jitsu Black Belt | Startup Advisor
1moWay to go, Fernando Botelho! Platform investments are the foundation for sustainable growth and innovation. We can't just focus on the 'shiny new features' and forget about the basics. Systems and tools are the cornerstone of delivering productivity and quality while reducing tech debt.