So I have you take a quick look at my profile, and feel free to connect me through LinkedIn. So why this topic?Over the years, I've had opportunities to lead engineer teams of all sizes across different stages of growth. Through these experiences, I've spent a great deal of time reflecting on what it would take to build a high performing engineer organization. So today, what I'd like to share is a simple but powerful framework that I have developed and applied in my own leadership journey, whether I was stepping into a team of one and scaling to 10 or leading the team from a 10 to a 100. This framework has consistently helped me focus, prioritize, and drive results. I hope it will be help you for to you as well. One important note, the talk isn't just for engineers or engineer leaders. It's for everyone who works alongside them, product managers, designers, operators, and founders alike.

Because in today's world, as you know, every company is a tech company, building a high performing technical organization is no longer just a responsibility of engineer leadership. It's a shared responsibility and a foundational element of any successful business. So what exactly is the engineering triangle? Well, the idea actually started about seven years ago. During a conversation with a close friend, he asked me and said, Julia, you have just joined a new company as a head of engineering. What exactly do you do? Are you still writing code? Are you following a run book from the CEO at the time I was reporting to the CEO? Or are you there to make the biggest or the coolest technical decisions for the company? All fair questions. But instead of giving him a long technical answer or listing out all the projects I was managing, I paused and a visual came to mind.

That's when I first pictured the triangle. And my answer to my friend, you know what? My job is to hold the triangle close to my heart and help move the triangle upwards for the organization. So now let's take a look at the triangle. It is made of three essential sides, and the first is business delivery. In a start up world, speed to market is everything. Whether or not you have reached product market fit, your ability to do delivery is one of your biggest competitive advantages. That's why in every leadership role that I have held, I've spent at least one third of my time working on this side of the triangle, sometimes even 50% of my time. So when we talked about scaling, we're not just referring to headcount growth. We are talking about scaling business outcomes.

What that means is that as you grow, you cannot afford to lose momentum. And I know many companies when they were two people company, their deliver speed is pretty decent, but when they get to 20 or 100, immediately felt like, why are we not delivering as fast as we used to be? So how do we drive delivery while scaling up teams? Now I have a few concrete lessons that I, again, collected through my own journey and fellow CTOs to share, and let me dive into this quickly with you. First, take a look at your delivery process. Whether you're using Agile, scrum of scrum, even Kanban, making sure that that process can support a two people team, a 20 people team, or a 100 people team.

For example, if you're already taking 10 meetings to agree on something, then if you add another 20 people team, that just not gonna work. Make sure you optimize your delivery process first before you add a lot of people on the team. Number two, invest intentionally in engineering onboarding. Again, I'm gonna say that again, engineering onboarding. Many companies have done a fantastic job onboarding new employees. But at a corporate level, new employees got excited about the company mission, the mission. They love the culture. They love the perks, etcetera. But when it comes to engineer onboarding, you know, there was a general kind of expectation that engineers can learn. You know, they're smart. They just they're gonna onboard themselves. The reality is as leaders in or cross functional leaders, if we put in just a little bit of intentional effort, we could make a huge difference in onboarding new engineers.

You could see a a huge change in the ramp up speed. So a couple of things I have done. Number one, targeted documentation. So not documentation in general, target documentation. For example, when I onboard a group of engineers, often I make sure I have documentation describing what they need to know immediately, what they need to know three months down the road or six months down the road, they don't need to learn everything upfront. It's gonna take a long time and they're gonna get lost, and they will go forget about the things they learned last week. So the targeted documentation to teach them in what sequence that they should learn how they should learn the technology ecosystem is is quite powerful. Secondly, we need to develop a internal engineer onboarding team, and we need to actually set aside bandwidth for that. Often, I will put together a team.

The team is made of people who have the most institutional knowledge, including why we do certain things in a silly way, but we did it, but people need to know that. Including people who are critical in our development cycle, you know, could be who is in charge of quality, who is in charge of access to different systems, who is in charge of, you know, access to the cloud, etcetera. So making sure you are intentional in building that team and make sure that team members understand it's part of their job, their critical deliverables, and I think also help the engine onboarding significantly. The third action I've taken is certainly just aligning the business problems with the concrete technical tasks for new hires and help them get as close to customers as quickly as possible. Because often the new hires do understand what the companies are doing, what the main product's doing, but they might or might not fully understand the concrete tasks. So, often, what I have done is, you know, I make sure when the new engineers get started, I make them understand what is important for this week for his team, what is important for his team for this month and this quarter?

Because having that type of what's the most important mindset really helped them develop critical thinking, helped them make decisions for us so they could make the most impactful business decisions for us early on versus just follow whatever they were told. The other patient item that I've taken is and you see my last two roles is really connect engineers with the customers. Even they don't fully understand the the product yet, the technology yet, even our tech support team yet, but I will make our new hires shadow our tech support teams or custom success teams just to observe the type of questions we're getting, the attitude of the customers, the frequency of certain problems.

I think having that foundation, that customer pinpoint foundation will also naturally shape them, how they want to contribute to the teams and to the business. Number four, many engineer organizations have KPIs. I strongly suggest you also create onboarding KPI. For me, there's one KPI that I created for onboarding for my last two roles. Basically, just to measure how quickly a new engineer can deliver the first PR. For me, I almost mandate a new engineer to deliver the first PR within two weeks, meaning from the moment we're discussing what needs to be done all the way to deploy that PR into production, I give them two weeks of time. And a lot of onboarding material, training sessions, or structure to support that as well. So why is that important? Because having walked through that journey once very quickly help him understand all the tools, resources, constraints, and the things he has to keep in mind or she has to keep in mind to be productive.

Also, through that journey, he or she will very quickly understand who he needs to talk to on what to be able to deliver all the way through and deliver quickly. So it's again, it's a very powerful onboarding. In addition to that, it helped build kind of the mindset. Speed is the key. It will require every engineer to deliver the first PR within two weeks. That without saying, this company is running fast. That is the label. That is the culture. Last but not least, you know, most engineers love to be part of the community. The minute their piece of code is already in production, even it's not for high profile p feature, maybe even not a feature that will be eventually used by the customers at all, still, you are not part of the community because you contributed to the community code base. I have one more point here I hope you could see, which is if you do see you suffer with velocity, especially after you added, you know, a a number of new developers or engineers, make sure you don't just sit back and wait and say, you know what?

After they ramp up, I should be fine. Do take the time, deep dive into the problems, investigate why things are taking longer. Often, you will get really meaningful feedback from both the new engineers and engineer leaders and turn the top one and two areas into very actionable tasks and monitoring those tasks aggressively. Because these are the ones that will actually prevent you adding 20 engineers or engineers. And the only difference is that addressing them now versus addressing them later, and the later means you are paying 20 x of the prices. So now that we have covered business deliverables, let's move to the second side of the triangle, technology uplift. Now personally, I don't use the word technical debt very often, though I've worked in the tech industry for twenty years.

And the reason behind is, you know, tech is a fast evolving industry. Just look at what AI has changed. And, startups are fast moving businesses. We look two fast moving trends. You know? We don't have time to regret, to get frustrated about the older decisions that we have made. And a lot of times, the decisions were made based on the business context, then based on the technical limitation or research limitation then. But what it is important is how we could speed up removal of these critical bottlenecks, technical bottlenecks, while we're adding people. I'm gonna say that again. How we speed up removal of a critical tech bottlenecks bottlenecks when you add more people. The reason this is important because a lot of times you notice if you have a a huge pile of technical debt and then you hire more people.

Without correcting them, more technical debt is created because you never truly get a chance to improve your tech before you onboard everybody. So what I'm gonna share next, actionable items are on when and how you actually provide yourself to get into that situation. So driving technology innovation while scaling up teams. First, before I add a group of engineers to the team, the first thing I do is I actually sit down with a couple engineers. You don't need to sit down with your superstars, just engineers who produce code consistently and say, okay. Tell me if you have to write a piece of code to satisfy a feature, what are some of the technical bottlenecks that could slow you down? I'll give you a couple examples. These are technical bottlenecks, not process bottlenecks.

Two companies ago, I led a, you know, a team, and everybody was training me, Julia, it would take me three to five days to build a local environment. And that was also the year I knew I need to hire at least 30 engineers. Can I afford 30 times five? A hundred fifty days of setting up computers so that they could run the current systems or the current code base. No. I cannot. That is too expensive and too slow. So immediately, I know before I even onboard the 30 engineers, I need to first correct this bottleneck. It's a techno bottleneck. I need to centralize, automate, and speed up how we set up local environment. Second, as soon as the size of your team has exceeded 10, personally, I would recommend you start developing critical engineering standards, such as what is your unit test coverage, what is your monitoring requirements, you know, things in that nature.

And the the reason behind is simple. When you have a team of 10, then you try to hire another team of five. If we don't start thinking about standards early enough, very likely the five people will bring in new standards, new way of thing of doing things to the organization. Let's say monitoring, you know, we might ended up five ways of doing monitoring, and eventually, we're only gonna go with one of the five. You then immediately, that four ways become work you have to correct, and you could call them technical debt. And having variation of different ways of doing the same thing as you all know could also cause a lot of confusions, area of businesses or technology nobody understands, and such an it make it incredibly hard to move team members around. So don't ever look at standards as something like, well, we don't have time for that. You're gonna pay a huge prices if we don't do that early enough.

Again, 10 is the number. It's the number of team members that you have that I when you see that number get to 10, I strongly encourage you to set aside time to do the standardization for your critical engineering practices. Not everything you have to do engineering, critical ones. Number three, do also take a look at your architectural and resource constraints. Now a lot of times, people talk about architecture, infrastructure constraints all the time, but they talk about it based on the context of what happened if our business world to x, y, and z? What happened if our customer base is doubled or tripled? They don't necessarily look at it from an internal standpoint of view. For example, if you have a team of 10 people, you're already struggling with your test database.

Everybody has to get on it, have to fight for data, have to fight for, you know, time for using a database, already performing very slow. How's it gonna look like when you add 20 more engineers? So looking at all your tech stacks, all your tools, all your resources internally before you add a lot of engineers is also very crucial to make sure you could truly gain the power of adding people or the value of adding more people. Otherwise you could immediately create another bottleneck, then it's very hard to correct. Number four, and four or five are related. And it's it's a situation that I, personally run into a lot and also I've heard a lot. You know, often when you actually join a company or a tech company, people will say, okay, we have a V1 of the platform. It's working well. It's in production.

It gives build the business for us. It gave us the product market fit. Then you have a newer system. You call that v two or modern system. It also does similar things, but better, and it's better, but both are in production. How do we navigate a situation? How do we help new engineers navigate a v one, v two situation? So that's point four and five. Number one, if you have the luxury, do rotate your new engineers and make sure they could work in both ecosystems. Don't just divide and say you guys work on the old and you guys work on the new because both are important. Because what happen is when you add more and more engineers to a latency system, you are adding resistance to change.

Now to mention people suddenly get demoralized, especially new employees, they get demoralized. They might not want to stick with a company for very long. When you get a chance to rotate the team members, especially new team members, even sometimes they struggle with the technical, you know, proficiency because not every system is built in the same architecture even with the same tech stack. Still, just that exposure of how it's like working that environment will actually motivate them to wanting to migrate the old to new or standardize both platforms even more. And you need that new fresh set of eyes, new ideas, and new pushes to make that a reality, you know, replatforming. As you all know, replatforming, it's, you know, not something that everybody can do and do it really well, while meaning efficiently and cheaply. Now if you do, if you are committed to a new replatforming, what I highly recommend is take the time to truly decompose very complex life systems into the smallest actionable tasks.

That's just part one. The part b is equally important. Look at a task and see which tasks can be done in parallel, which tasks must be done in a sequential way. Because in tech, as you know, there's a dependency. A lot of times, it's a dependency over dependency. So make sure you have a very good understanding of that at a detailed level. That's a foundation to drive the platform project in a efficient manner. Now the reason I want to highlight the four and five here is when you grow a company, you are guaranteed to are required to innovate technology. You are guaranteed you have to solve some of the complex problem at migration, but you also know you cannot do just that.

You still have to make sure the first side of the triangle, the business is not slowed down. So how you feed into your technical actionable deliverables into your business road map also incrementally see the result. That's the success for that the secret for success of skilling up a company. If you could do could not do that, often you have to put a business on hold, which is gonna cost a lot. You might lose the marketing opportunities, or you're gonna put the tech on hold, which either eventually that it just not gonna support a business at at all or you just have to keep doubling the team to support both systems. So, again, the key is making sure you could incrementally drive tech innovation.

And the foundation to do that is to truly understand the smallest tasks and either sequence them or parallel them and feed them into your business deliverable timeline road maps very creatively and have very strong ownership and hands on approach to manage those deliverables.

Whatnot? Let's take a look at the third side of the triangle, which is people and culture. Without saying at end of the day, whether you have the coolest technology, coolest business model or not, it is the people and the the team who are making everything possible. So when you're scaling up teams and build a sustainable high performing culture, what are some of the things that I've learned that that you could do? Number one, design a scalable and adaptable team structure. You know, whether you use the scrum teams or you call them pod, you know, make sure that structure is easy to comprehend so people always know what to expect, who to talk to, and also plan to see that that structure might change because that pretty much all tech companies change the team structures frequently.

Number two, develop a robust timing strategy. You know, what does that mean? Hiring is hard. Even there are many layoffs, hiring is still hard because the hiring means you're gonna find the best people quickly. And it's hard to shortcut that finding the best fit. So often what I recommend is you actually develop a robust talent strategy and which is made of how you hire, where to hire, and when to to which lever. For example, when to hire FTE, when to hire a contractor, when to hire remote employee, when to hire nearshore, when to hire offshore, even when to hire part time employees or consultants, all that should be built in together as part of your timing strategy. Number three, certainly at the end of the day, engineers love to work in the environment in a culture that innovation is highly valued, innovation is empowered. So do putting intentional efforts and putting intentional practices to encourage innovation. Over the years, I've done mini sprints.

Every three three months, I will set aside three days regardless how large the engineer work size I was leading, making sure every engineer's schedule spends three days working on technology. They could work on anything they like. They don't have to work on technology that is relevant to that company. At the end of the three days, we have people do presentations because we want them to feel that they're still appreciated and empowered to create, to innovate. And as you all know, some of the best engineer I product ideas came from engineering. Otherwise, if they lose the ability, lose that freedom to do that, you know, they could just be day in day out developing features, they could get, you know, demoralized pretty quickly. And sometimes without noticing their behind on the technology, and quite often, we discover new tools, new capabilities that, you know, we never heard of through these mini sprints.

The last few points I want to highlight really quickly, to build a high performing engineering culture, we have to shift in our focus and shift our messaging a little bit. You know, quite often in the traditional engineering product world, you know, when we talk about piece of deliverables, it's always, is it two weeks? Is it five weeks? Is it too slow? Is it too fast? I think if you shake the message, it's always around, we're here to solve the problem for this set of customers. How can we solve it quicker, better, more creatively than our competitors? I think that will generalize analyze developers to take on that challenge. So shift the focus more a conversation focus from debating on the timeline and make it more of a problem solving type challenge that we are all part of. And I often say that, you know, when you build an engineering culture, you also need to highlight a customer service culture between engineering because at the end of the day, we're not building technology just to build technology.

We're all building technology that will be consumed by a set of customers. And to serve our external customers well, we really have to also promote strong customer service culture internally. What does that mean? How do we talk to our team members? How do we serve our internal team members' needs? How quickly we can answer questions? You know, all of these small things, they highlight the customer service oriented culture and mindset. Last but not least, something that I've done just over the last three years, every six to nine months or so, I sit down with my engineer leaders, and we do what we call the competitiveness assessment. So the narrative is really around, okay.

If our investors giving us $10,000,000, give our competitor $10,000,000, and we have the same product, same level of product maturity, same customer base, same number of customers pretty much. If we want to be able to acquire more customers, generate more revenues by the end of the year, what can we do to become more competitive? The exercises really just help help engineer, managers, or leaders to think about how we continuously pushing improvements and strive for excellence. Because when you work in a high pressure environment, very often that people gain to the cycle of day in and day out, you know, trying to get things done and trying to prioritize a million things, and they get used to the engineers on their team, they build relationships. Sometimes we forget to step back and say, wait a minute. How can we continue pushing the bar higher? What are the things that we need to really take another look at and correct?

So that's everything that I have done with building in terms of building the teams and culture. And with that, I think we have completed the three sides of the triangle. Now I do want to emphasize my beginning statement. The framework is not just about a visual presentation of the three sides. Our deliverables, regardless of your role, is to help the organization move the triangle upwards. To move the triangle upwards, you have to first hold the triangle as a triangle. You cannot have three separate lines. Again, if you only spend time on one side of the triangle, you know, very quickly, you could end up losing either a lot of businesses or a lot of money by because of ignoring the other two important aspect of engineer organization. So I hope that's the key message that you get to take away from this presentation. Now, before I wrap up, I want to share something personal.

I'm currently writing a book called The Engineer Triangle, where I dive deeper into each side of the framework using real world stories, both successes and failures, from my own experience and from conversations with fellow CTOs. If you are faced similar challenges or have success stories or even questions, I'd love to hear from you. I'm actively gathering stories and love for all of you to be part of the book or even the broader community. Now having said that, I've been working on the book for almost eighteen months, and I've decided just last month to extend it for another year because AI has changed the landscape in ways no none of us can ignore. It would not feel right to end this session without reflecting how AI is reshaping engineering, especially how we think about scaling teams and measuring productivity. Now I'm certainly not an AI expert. Just like many of you many of you, I'm learning, experimenting, and trying to keep up.

But here are a few early reflections from my own learning and also conversations with other fellow tech leaders. Number one, the most popular question I'm getting from a CEO or investors in a start up community, and I know many CEOs got this question is, can AI reduce the number of engineers? Can you let one through your team go and still be able to produce the same amount of code? On paper or based on everything we have read, the answer is yes. But in practice, I personally struggle to find a good set of companies that can do that successfully and consistently. Maybe we're not far from that reality, but at least in the New York area based on all the companies I have talked to, I have not seen a a large number of companies who could deliver that.

Number two, we're still lacking AI KPIs for engineering. You know? I know almost every engineer on my team is using AI, but how do I measure that? Do I expect them to be 20% productive because I know they're using AI tools? Do I expect them to have a better code quality because they're using AI tools, or should I mandate that 40% of code base must be generated through AI? So I'm yet to see what standards that will come to the industry that we could adopt broadly. But one thing we know for sure is that if you are not done any AI, you're definitely already behind. It doesn't matter what role you have, whether you're engineer or you're even you're a CTO.

Number four, we still need a lot of standards and guardrails across the company for AI, And there's uncertainty still not there because, as you know, many of the tools are not even around for more than two years. We don't really know whether these tool the the tools available today will still be around two years from now. And how does a company adopt AI tool, you know, from a cost, security, scalability perspective? So even the timing of adopting the tools, it there's still quite a bit of uncertainty. But, again, having said that, if a company is traditionally struggling with change management, I highly recommend you go live with AI project, or I to to production, not just in a piloting mode. It doesn't matter what vertical you pick, but it's engineering or marketing or design. Because AI transformation is no longer a matter of why or whether that will happen.

It's really just a matter of when. So the it's no longer a tech transformation. It's a organizational transformation. It's a business transformation. If traditionally you struggle with change management, very likely this transformation will hit you hard, and you'll be left behind. You'll probably become less competitive. That's why I strongly suggest for companies who want to improve change management or have struggled in the past, just pick a vertical and go live all the way and see how that's like for your organization. Last but not least, AI has turned everyone into engineers, and many engineers have become product leaders and business owners. I live in New York almost every week. You know, when I go to tech events, you know, I run to engineers and say, oh, I just started a company because I use x, y, and z to build this this app. So it is a wild world out there. It is a crazy time, but let's also, you know, embrace it and have some fun.

Well, thank you all so much for being.