About this talk
This talk focuses on establishing a productivity culture that can scale within engineering teams. The speaker, Aren, shares his experience working at Tesla, where he has progressed rapidly through various roles over the past five years. He emphasizes the importance of building effective workflows, fostering the right team dynamics, and leveraging AI technology in processes termed 'AI-gility.' Aren discusses strategies for enhancing team productivity through strong foundations, clear ownership, and meaningful communication. He also highlights the necessity of recognizing contributions and feedback in reinforcing positive behaviors, ultimately fostering a high-performance culture.
Full transcript
All right. Hello everyone. Good morning. This is weird because it's not interactive, right? So, uh can you hear me right now, everyone? Perfect. Good morning. Happy Friday. Um so, it's going to be a nice experiment for me because this is the first time I'll be speaking in English in a conference. So, good luck for me. Um so, today I'll be talking about uh a productivity culture that
scales uh within the perfect engineering team, great engineering teams. And before jumping onto the um actually, I can use that I want to introduce my myself real quick. Uh my name is Aren. I'm originally Turkish. Um I've been living in in the Netherlands for more than 6 years and have been working at Tesla uh for 5 years exactly. I celebrated my fifth Teslaversary last week. So, it's
a big achievement, big milestone. Um I describe myself as a multi-disciplinary professional blending quality, creativity, and aesthetics. Um I wanted to put two different QR codes. One is for the professional uh ones if you want to uh connect later. And the other one is uh about my Spotify account because since we are talking about AI, right? Uh I'm really interested into music and then by using some
AI tools with the uh help of AI tools actually, I created two albums uh recently. So, if you if you are interested, you can take a look at this one later on. So, I'll just give you some uh seconds so that maybe you can scan the QR codes separately. I hope it works. Then, um I'll continue with my um career at Tesla. So, I start my Tesla
career 5 years ago as a software engineer and currently working as an engineering manager within sales domain at the moment, sales applications domain at the moment in IT department. So, 5 years, I got three promotions in total. So, right now I have 11 direct reports under my org. So, some of them are here already supporting me. So, thanks for joining this session. And um yeah, it's an
amazing journey because when I joined Tesla, I was the only one in in the development team. As you can imagine, like that that was really frustrating at the beginning and I was mainly connecting with US folks waiting for PR approvals all the time. So, it was a really challenge challenging moment, but right now we have our own domains. We are taking care of everything by ourselves. So,
it's a it's yeah, it it it's become really amazing right now. So, in case you're interested in career opportunities at Tesla, you can visit this website and I also want to make a quick announcement about Tesla full self-driving. As you may know, our FSD has been approved in the Netherlands for the first time in Europe. So, that's a big big achievement for all of us and I'm
I'm super excited. I I had a chance to try it a couple of times in here and also in San Francisco with robot taxi experience. So, it's really smooth. I strongly recommend you to give it a try. So, if you're interested, you can also scan the QR code to enroll, but be be be quick because I heard that there are really some like few spots left. Then
finally, we can start with the presentation. So, I want to start with a one-way question. So, my first question is when you hear productivity, what comes to mind? So, I started also preparing the presentation with that question. So, then lots of words, right? Quality, quantity, efficiency, time management, delivery, ownership, and so on. So, so many related words, and I think this gives us a clear picture, right,
about what we are going to talk about today. And my second question is, since we are talking about productive teams here, right? This is this year's theme, actually. That's why I chose this topic. Do you really think that the team you are working with is productive enough? So, you don't need to answer to that question right now because maybe yes, no, I don't know, maybe. Maybe at
the end of the session, you have a much better answer. the problem statement. Why we are here today. As tech teams grow, productivity most of the time declines, not because people work less, but because we keep adding more and more, and then at some point those practices, workflows no longer scale. So, by adding more people, more tools, more meetings, more hand-offs, more processes, actually we are losing
time, quality, speed, ownership, clarity, and also I think I I mentioned quality already. So, in this session we'll take a closer look at those high-performing engineering team teams, and then how they shape this productivity culture by building effective workflows, reinforcing the right behaviors, and following those routines after a while. the first part is, give me a second. So, the first section is people and culture because people
first, everything else follows. It all starts with who you work with, right? Um when I think about my own team, for instance, I can simply tell that it's a dream team because we have the same uh energy, same passion, same vision with different perspective. This is pretty important because especially if you're a hiring manager and then there is no team at all. So, you're supposed to build
this team from scratch, right? And these are the uh things, these are the parameters maybe you should pay attention to as extra. Technically strong people, culturally aligned, like really eager to learn something, you know, passionate about the new technologies and also maybe the company itself and also strong communicator. That's also pretty important. That's why tell that I I'm working with a dream team and it's not just,
you know, uh uh a random uh you know, a statement. It's really the fact. So, maybe this is the right section is not applicable to all companies, but at least for Tesla, we are talking about different regions and different cultures, right? Because um we are rolling different um multiple regions and it means that there is a non-stop 24-hour uh of operations all the time. So, that's why
we talk about time zone differences, async collaborations, language and communication styles and differences, working styles and pace, and empathy as infrastructure. So, at the beginning, this diversity may look like a challenge, but once you achieve it, it's going to be a strength within your team. So, that's pretty important. The next slide is relevant to the previous one. Stay together, grow together. So, when you think about your
um think of your daily routine, 1/3 of our time in a day is spent with our teammates, right? In in the office, during the calls, or maybe while chatting about different threads, etc. So, it's a big portion of time, actually. So, then it's really better to be surrounded by right people, right? Because otherwise, it can be a waste of time. You cannot improve yourself or, you know,
there is no good communication at all. So, that's why staying together is also the you know, the extension of this uh expectation. So, there are of course some advantages of working together long-term. Because the longer a team stays together, they the more they compound, right? So, they they share the context already, their instincts become sharper, and then we don't need to explain ourselves at at at some
point, right? So, and then we can make some faster decisions. So, we know like each other already for a couple for a for a couple of years, maybe. But, it doesn't mean that say that there's a working for 30 years, and these are the best, right? No, I'm not telling this because there is a big difference between, you know, productive team versus, you know, like repeating the
same old uh maybe style. So, long tenure is not equal to high performance, but how can we make sure that this team, right? Can still perform better. So, we can talk about some rotations by adding some refreshers, right? To the team by hiring some new people, bringing in some new energy. But, the goal should be right people, long arc, and not not permanent stagnation. That's pretty important.
Okay, this is one of my favorite uh slide. Shortest path communication. Um if you look at the traditional hierarchy in most of those companies, right? We follow this hierarchy. So, as an individual contributor, I'm supposed to reach out the lead, and and the lead reach reaches out to manager and so on. And especially since I'm coming from Turkey, this is really a waste of time. I can
simply tell you that because most of the time we, you know, show some respect. Hey sir, good morning madam. You know, like we lose time because we are not like focusing on onto the actual point and then we spend time just to make people happy, you know, appreciated for no reason. So, that's why I call it as shortest path. Say that I I need to fix something
immediately today, right? I don't need to follow all the hierarchy or chain command. I can simply reach out to whoever I need. Simple as that. I'm not saying that I'm, you know, in a daily conversations with Elon all the time, but in case it's really necessary, I I know that I could reach out to him immediately. So, that's maybe a, you know, like a an example, but
it's also possible. So, hierarchy means accountability, but not a communication filter. So, there is a slightly uh slight difference between these two approaches. Um my next slide is about giving freedom and then getting ownership. So, if you look at the right section, right? Um within the the uh the current situation right now with latest technologies and the the the changes we are experiencing, the leadership shift is
about actually the modern engineering leadership is about not managing every single thing. Instead, giving some freedom or unlocking some potential by, you know, following uh not following, but allowing your teams to do some things uh within your control, right? So, managing versus control or just, you know, following uh your your team's activities is also different. That's why if you can create an environment and remove blockers, then
you'll see uh your team will perform much better after gaining this, you know, uh ownership and then we can also call it as account we can also make it accountable. This is an interesting one. AI-gility. Maybe you heard of this term already. If not, it's a combination of AI and AI-gility and it becomes AI-gility. It's nowadays methodology actually. So, I I designed all the things with Claude.
So, if you look at this fake AI assistant uh screen, I'm saying that hey, I act as a team member, okay? And the the answer is sure, I'll help design the feature, write Oh, this is easier this way. Write and review the code, generate tests, and flag risk already. What are building today? So, we are experiencing this already, right? What AI-gility means that the collaboration culture that
unites human insight with the AI's foresight. So, simple as that. So, it's not a tool only when we get stuck to, you know, to to reach out to. So, it should be one of the team members or the collaborator within our team. By by following the Agile methodology actually, we are reacting faster, right? For for those changes. And if you can adapt this AI-gility into your routine
and then it's going to move faster for sure. If you look at the modern engineering workflow, so, for all those stages, we we are using AI, right? So, from planning to designing, development for sure, testing, PR reviews, documentation, and deployment, and operations, and maybe more. So, maybe the planning design part can be a bit, you know, unstable at the moment, but starting from maybe development till maybe
documentation, it works smoothly, right? So, why not taking AI as a as a as a team member, right? Considering AI as a team member. the last slide of this section is about culture journey. So, I tried to summarize all the culture and it's both ways. It's not just from individual to the organization wide. It can be the other way around because everything started in individual culture, right?
So, imagine I'm the only one in the team and I'm hiring more and more people. So, at some point my individual culture will also influence the new team member at some point, right? And then by following those routines, we can also other team members and then the cross teams as well. So, first you do some individual conversations and then you reflect those decisions or you know, ideas
to your team to your entire team and then maybe not only engineering team, then you start talking about the same idea behind with product team and this may become a organization wide culture or So, I joined a company after a while, right? And in the meantime the the company culture is already there. So, should I also start from scratch and then you know, build my own individual
culture? No, I can follow the same but from the other way around. But still we can influence each others, right? So, that's the the idea behind. So, the slogan is actually culture doesn't stay within borders. It travels if you let it. End section two. So, workflows and product We talked about people and culture. So, everything started with people, we said, right? And the second section is about
how work how work flows through the system. So, first of all, what is a workflow process? So, basically it's a series of repeatable standardized steps performed sequentially or in parallel to achieve a business a specific business specific task. So, it can be anything. And [snorts] without the clear workflows, right? Roles start to uh blur, errors increase, and then uh an uncertainty um actually arise. So, to avoid
such um you know, challenges, actually we can focus on some workflow. Doesn't need to be complicated. As soon as, you know, uh it it starts working, then we can build more and more processes. So, productive teams design the system so workflow. But, there there is a common trap here. So, we we talk about adding more and more and more, right? And then, instead of adding more, because
these are affecting the slow deliveries, uh losing the focus, etc., actually with a shift, right? From moving from unconsciously adding complexity to intentionally design the system so that the works flow, basically. That's the idea behind. And what productive teams do? They uh there is a clear ownership, strong foundations, fast feedback loops, and consistent high-quality delivery. >> [snorts] >> Um so here um I want to talk about
uh thinking big, building small, and then iterating fast. think at scale, but build for now. So, I think you're familiar with con- code principles, right? Like YAGNI, KISS, DRY. There are more, but I especially wanted to scope this so that I can give some real examples, because um if you focus on uh what needs to be built at the moment, right? Then, you can also keep it
really simple, because you know what to build and when to build. But, it doesn't mean that uh we don't what we we want to repeat ourselves again and again. That's why I also wanted to add DRY uh principle here. So, staying curious is good, but um being reactive is not preferred because uh, sometimes we just have this uh, formal, right? I Okay, so there are new technologies,
we need to adapt it, etc. But maybe it's not the right time. So first, try some small experiments, and then if you really see that it solves a real problem, then you should adopt it. Not keep trying, okay, adding more and more and more. At some point, I mean, you destroy the whole system already. On the right side, okay, we talked about principle, and what about the
practice, right? So maybe you know chunking method. Basically, you break large complex tasks into smaller manageable units, okay? And then each chunk creates focus, reduces overwhelm, and gives the team a clean checkpoint. So first, we define some next uh, few chunks, not the whole feature, and then focus on a single task. So if you look at this uh, image, so how to unit task instead of multitask,
focus on a on a on one thing at a time, and that's it. Simple as that. You don't need to do multitasking just because, you know, this is a this is the new hype. Strong foundations. So here, we are talking about strong foundations idea, but it's not a pure technical foundation I'm talking about. So doesn't need to be a clean code, okay? So we are talking about
the system where your team members move can move through this with speed and confidence. That's pretty important. So how to achieve it, actually? So imagine a clear architectural um, that everyone understands. Or technical debt uh, maintained intentionally, not all the times skip, right? Or shared standards or conventions across the uh, teams, and building some reusable components, libraries, and internal tools, and then documentation is also part of
this uh, strong foundation idea. And why it matters at scale because weak foundations compounds, right? The bigger team, the uh the the more expensive the friction. So, imagine you have some new engineers in your team and then if you want a a smooth onboarding, right? Then the system should be legible. And also if you're talking about some rotations, then only when the code base is stable approachable,
then the rotation works as expected. So, that's why I wanted to summarize this step by step. So, strong foundations and then it helps with fast deliveries, consistent quality, and then we achieve the productivity that scales. Separation of concerns, not separation of people. So, as engineering teams organizations, sorry, scale, different teams go deep in different problem areas or spaces such as applications, infrastructure, data, security, operations, and so
on. So, the goal is not to have a single team knowing everything, right? That's almost impossible, especially if we are talking if we are talking about big big companies. So, the idea or the goal is to have some different teams, right? Knowing where they own that and also how the work connects so that when I need something, right? I know who to reach out to. So, I
don't need to be expert on security, but if they give me a platform, for instance, right? Then I can simply use it, but if I'm still stuck, I can still reach out to them. we are talking about vertical versus horizontal mastering, actually, but that's pretty important because otherwise you will try to do everything by yourself, but it's a yeah, waste of time, energy, and then if you're
not patient enough, it's going to fail for sure. Um build once, benefit everyone. So, I call it one to many efforts. So, there are so many uh examples I can give. So, to summarize, uh so say that you repeat yourself all the time, right? So, different teams are following si- uh similar approaches, and at some point you have this feeling, "Okay, so I see that this tool
can be reusable, right?" So, then why not building some reusable tools, solutions? So, build once, use everywhere. Or can be shared libraries, templates, even internal documents, right? need to do everything from scratch all the time. So, to give you a a real example from Tesla, so we have I I'm going to give you two examples. One is uh Tesla design system, it's called. So, it's one tool,
but it's used by many teams and many applications, even inside Tesla cars uh on on the screen uh itself. Or, if you visit our website, we also use the same uh design kit. Or, uh if you when when we generate invoices, for instance, right? We also use the same design principle. So, one-time effort for many purposes. So, that's a real example. The second example is uh for
instance, um onboarding tasks, right? So, we created a Confluence page, and then we see that actually we don't need to repeat ourselves. So, as as long as we keep maintaining those uh documents, internal documents, it's just one one-time effort, and then I can reuse those internal document over and over again. So, that's the idea behind. Um I have 7 minutes left. I think it's still enough. Uh
the next one is rotation builds ownership. To sorry. So, this is maybe my one of my biggest bets, because I really tried to do a rotation within the team. So, first of all, it takes time, but the result is that a team where everyone has knowledge, confidence, and then no one runs from responsibility. So, we gain confidence, right? We do more and more collaborations, and then delivery
is becoming faster with high quality. That's also important. So, if you look at the right part, so there are some steps, right? And I also put a pro tip because it's also similar to the change curve. Maybe you heard of this uh before. So, at the beginning, there is this uh shock moment, right? Hey, okay, I'm just a back-end developer, so that's not my job. We start
reacting, right? And then there is this resistance or uh you know, frustration, and then they feel, you know, discomfort, so they are questioning, etc. But at some point, they start to explore, right? Okay, what are the options, right? So, what what else I can improve myself? And then at the end, they they get the or they build the ownership. So, that's pretty important, and I'm glad that
I followed this approach, and I can simply tell you that it's working really smoothly. Yes, it takes time, but I can I can guarantee that you can you can try this approach. meetings that matter, that's also cool slide, and time that's productive. So, let's start with Elon Musk's uh statement, right? One of six rules for productivity. Maybe you you heard this uh before or you saw this
on Twitter X uh Twitter. So, it basically the idea is that if you feel like you're not adding value at all, then feel free to just walk out of a meeting or just drop drop off a call. Simple as that. Because otherwise, it's a waste of time, right? And then you don't have any idea why you are in this call, and then after after a maybe hour,
you're like, okay, I wasn't needed at all. So, if that's the feeling, just just leave immediately. So, you're not needed. Okay? but that's just one example. So, we are talking about uh maybe regular meetings, right? So, I put some real examples except the market lunch, obviously. But, these is these are real example. We have daily stand-ups. We have some market lunch, but it's more scoped. Okay, so
we are not like inviting everyone within the domain, okay? But, if you look at the Friday, I think that's pretty interesting because the full day for self-improvement because that's also part of the job, right? So, we keep working non-stop like from one sprint to another. So, there is no way that I can take a break, right? And then how come I can improve myself, right? As expected.
So, that's why some companies follow no meeting days. Some people prefer self-improvement days. So, in my team after release, right? So, I of course like evaluate the situation. Okay, everything is fine. No hot fixes needed for instance. Then I announce saying that, "Hey, I make an announcement. Guys, product team, for your information, we will use this Friday for self-improvement session." That's it. Means no meetings, no interruption,
and then I can focus on my, you know, POCs or demos, etc. Some people don't use this time efficiently, you may say. Then I also have bi-weekly calls with the team. Then of course I ask for the results, right? So, can you show do do me a demo so that I can see that you actually spend time on this improvement day. Otherwise, it can be just, you
know, chit-chatting or watching Netflix, whatever, right? That's why that's one of the maybe recommendations I can give. The last section, okay, I think we're on time. Recognize and reinforce. So, recognition is not soft, first of all. It's a multiplier. Feedback closes the loop. I like this slide also. Recognition reinforces what works, right? But, the feedback actually tells or helps the team adjust what doesn't. Simple as that.
So, there are four steps you can follow from observation to discussion, from adjustment to reinforcement. So, if you follow those steps, you'll see that the feedback loop is working better and better, okay? So, there are different types of feedbacks, obviously. One of them is individual. So, say that I I'm having a one-on-one with one of my teammates, right? And then I want to talk about some behavioral
changes or some expectations so that I can, you know, promote this person in the future. This is a type of feedback, right? But what about the team? So, when it's about team, then we are talking about some regular things for alignment, some collaborations, and also some about some small friction. But when it's domain, then we can simply give an example from retros, right? Simple as that because
I don't know like how often you you apply those retro sessions. So, for some domains, we do it um maybe quarterly or maybe every month or, you know, every 2 months, but sometimes, you know, we just forget. But that's also pretty important so that you keep giving feedback regularly, and then I know how to keep how to change it or how to continue doing anything, okay? Um
the that one is interesting. So, last year, there was a um research, and it basically says that if you show an appreciation and recognition to your teammates weekly, okay, then they become more productive, and this is the number, 2.6. Let's call it three three times. That's amazing. So, when I looked at our own, you know, daily routines, I realized realized that we are really doing this. So,
can we say that I made an announcement saying that guys, we went live with new market, it's going well, so it's working smoothly, etc., then I see bunch of heart heart emojis. So, that's kind of a recognition, right? Doesn't need to be like, "Hey, I'm going to give you a promotion. I'm going to give you some extra stocks, right?" Doesn't need to be that fancy, but still
small small appreciations really important. And then, how can you do it? Before explain, maybe I can also talk about pro tip. People remember how they felt when their work was recognized, right? Because otherwise, you keep doing amazing stuff, but no one is doing anything, right? No one is reacting to your achievements or, you know, say They They don't celebrate it at all. So, let's not follow this
approach, but kudos to you, kudos to me. Public shout-outs in team meetings or chat channels possible. Private recognition when it's individual, right? A personal message matters, and we have a shout-out page, for instance, in Tesla. So, whenever I want to give a shout-out, I go to website, I put some comments, and then also when I receive such feedback, I feel really amazing. So, that's it. Just words,
but it gives you a great feeling. That's pretty important. And also, celebrate quality decision. Doesn't need to be when you ship a fancy or, you know, a really complex feature only. So, keep doing keep, you know, appreciating the overall effort, and this will also uh increase the productivity. Uh summary, the formula, productivity culture that scales, right people and AI agility, ownership and foundation, small iterations and flow,
and then feedback and recognition. If you can follow this formula or apply this formula, you'll see that the productivity within the team will increase like crazy. And one small question, your turn. So, pick one thing from today, if you can, because today's Friday. I I put this week, but next week can be one conversation to have with your team, one habit to change in how you work
together, also possible, or one collaboration to improve with a teammate or another team or one quality win to celebrate this week. So, please give it a try and then maybe you can also evaluate how productive your team is. So, that was my very first question, right? And then I thank you everyone for listening to me. So, have a good day. Thank you. >> [applause]
