¶ Intro / Opening
One of the biggest challenges with an event like this, especially with leaders Actually rolling the season coding is a sense of imposter syndrome and a need for safety there. Because if you've got, I don't know, S V P of engineering or a CTO coding
You have to be fearless about presenting what you've done. So I think that that's something to think about not just with leaders but with anyone who's taking part in an event like this is making it safe to fail and being able to celebrate that as well.
¶ Welcome & Hackathon Vision
Hello and welcome to the Engineering Leadership Podcast brought to you by ELC, the engineering leadership community. I'm Jerry Lee, founder of ELC. And I'm Patrick Gallagher, and we're your hosts. Our show shares the most critical perspectives, habits, and examples of great software engineering leaders to help evolve leadership in the tech industry.
James Tayek, who is a longtime member of ELC, good friend of mine, and local leader for ELC South Bay, came to us while we were planning ELC annual. He came to us with a wild experiment for the conference, a hackathon designed specifically for senior. engineering leaders. The result of this unlocked something incredibly exciting for our community. It inspired deep conversations on the evolving AI native workflows, vibe coding, and the future of engineering leadership.
In this episode, we tackle a little bit of a different topic. We are deconstructing the entire operational playbook. From the expectations and planning that set up success for a hackathon to designing best failure awards and all the way to structuring async collaboration so that busy leaders can actually participate.
We explore how getting hands-on is the cure to overcoming imposter syndrome and why rolling up your sleeves is now a prerequisite for leading effective engineering teams. Let me introduce you to James. James is a longtime and dedicated local chapter leader for ELC South Bay. He helps organize all of our different events, meetups, and conversations happening in the South Bay area. At Coursera, James leads the engineering team responsible for Coursera's core learner experience.
including their generative AI coach solution aimed at delivering a personalized, supportive, and effective learning journey. So if you've ever thought, well, I think we should run a hackathon to spark innovation and change and evolve the way that we're building in our organization. This conversation right here is your blueprint and operating framework to do just that. Enjoy our conversation with James Tayek. This is a really
special topic that we're deconstructing together. You, James, came to ELC with an idea. And it was this experiment of what if we hosted a hackathon at ELC annual? What would it, what would it be like? What if we did that? The result is that You launched ELC's first ever hackathon at the conference.
You got 14 extremely busy competing priority engineering leaders to build and ship a fully functioning application using different AI coding tools. And for some of them, this was actually the first time that they were able to get immersed in some of these new tools. And it so it wasn't a talk, it wasn't strategy, but it was people actually building, which was a big deviation from a lot of the thing the things that we do. So
So I think just to set the stage for what we're going to talk about is we're going to deconstruct this story a little bit behind the hackathon. Uh we'll get s into some of the operational lessons about like leading a program like this. But then more so your perspectives on what it taught you about leadership. how and how the experience is really changing how you think.
about helping leaders right now in this sort of shifting AI moment. So I wanted to give that context because this is an extremely special moment. And then this is a like a capability or like a learning program that can be extremely accelerating for a lot of different parts of building the business and teams.
¶ Impact and Unexpected Discoveries
So why don't you bring us into the results? What actually happened at the hackathon? Yeah, so at the actual event itself, all of the ideas were, you know, the actual projects were being submitted. I was looking at this, all of these projects And it was just incredible. I saw forty as you mentioned, fourteen engineering leaders built working apps. They ranged from Internet of Things displays for the next train coming um to time allocation optimizers.
for planning, which was much more of a a leadership management type app, and a whole range of different um working apps that people had built very fast. Um, and then what we did, we had uh an event where we actually got everyone to s stand up and talk about it and what their experience was and what they learned from it. Yeah, you know, it was pre energizing session with a lot of engagement. The energy was incredible and I learned a lot through that event.
I think, you know, the biggest thing for me is moving from talking about tools to actually rolling our sleeves up and understanding them and building with them. And being able to have credibility with our team is a big part of that. And having empathy for the engineers that we're leading, um, and understanding what the actual benefits are of AI, what the pitfalls are and what we need to do to understand how we can get the most value out of it.
There's like one specific moment I want to zoom in on because I remember when you and I were kind of talking through the shape of this and how to make it work and how to launch it. I think you and I were kind of talking about like how we didn't really know. We didn't really know what was gonna happen after we sent out the invitation for people. And so I was guess maybe can you bring us into like the moment where like you're starting to get the first responses?
Or like the the first people saying, I'm so interested into this. Like, do you remember that moment of once we s extended the invitation of like we're doing this hackathon, sign up if you're in? What was that like? Yeah, so it was quite scrappy. I was running the whole thing, sending emails out to the email list of participants. And then I started seeing people registering and being interested in and and then starting engaging in a forum that we created.
And a lot of people started commenting in there, asking more questions, and it was fascinating to see that it come to life so fast. That was the time when I really noticed that it you know, you know, there was engagement happening. When you and I have been kind of discussing the the impact of the hackathon or like the way that it can impact people participating, like Some of the things that we've talked about, like the actual
modality of participating in the hackathon wasn't necessarily the most a significant unlock, but there there were things around it that really created a bunch of impact. So I was wondering if you maybe talk about some of the dynamics around the hackathon that you saw impact people.
So things around like preparation or maybe what you thought people were gonna struggle with, but maybe was different. So like bring us into like where were where were some of the interesting insights around the hackathon?
¶ Leadership Questions: AI & Role Shifts
Yeah, I think that, you know, there were things that I expected to happen. So people would learn AI coding tools, working demos would be built. The big thing was the community energy and the connection. So relationships forming with people who were actually building together, who were leaders. The diversity and creativity of the s of the solutions was interesting because a lot of people seem to focus on
Problems in their lives. That was what was interesting. Whether it you know, if they're a parent, it was I'm inundated with messages f from the s the school and from other parents. How do I manage all of the activities that my child's doing? How do I manage trip planning, things like that. I thought that was really interesting because it to me that spoke to the need for leaders to be able to not just automate their work, but also their life outside work.
because we're all so busy and it can be very overwhelming. And that I it was just it was interesting to me that that was a place where people were really connected. You know, when they saw this thing come up and the opportunity to roll peop their sleeves up and build things, ideas were coming up.
from day-to-day life for things that could be automated and then they were demoed. The other thing that came up was that people were asking really interesting questions. So some of the questions that people were posing was how micromanagery should I be with the AI agent? Which I thought was really interesting as a leap, because it's the same question we have about our people. And I think the answer there is not.
You know, the the idea is that we can delegate things a bit, but we have to keep some oversight there and accountability for what's going on. Will engineering leaders need to code more? Was another question. Well hopefully not, right. Or maybe not, hopefully not, but you know, the idea is that we're able to think a bit more strategically because we let go of some of the more low level tasks that AI can help with.
How do you maintain AI generating apps was a bit of a worry about once it starts taking on a life of its own, how you know what's going on, which I think is a problem that people face when they start using AI to have the oversight. and how technical we need to be in the AI area.
For that one, it's really job role shifting. And we yeah, we had other talks about this, the blurring boundaries between roles, whether that's products, design, engineering, and then engineering managers and engineers is another kind of boundary that can blur a bit once we Start to
Be able to answer questions more quickly about code bases. That's something that I've been using AI for a lot. So I can quickly understand a code base where before it would take a lot more questions and time to understand how that code base is working. I think those are some of the things the the you know, the kind of feeling of what how's my job changing um through doing this exercise?
¶ Overcoming Imposter Syndrome
Well, and and I think like it became a moment to really viscerally probably feel that shift. It's like as soon as you start to experiment and build and like go through the process of using some of these different tools, like you can't help but change your mindset. One of the customers are not asked is like where you notice people struggling. When you were when you were looking at like the the workflow of like
Like opening up launching the hackathon to then people submitting, to then the talk at the conference. Like what were some of the observations you made of like where maybe there were challenges that had surfaced that were that were interesting to you? One of the biggest challenges with an event like this, especially with leaders Actually rolling those legs of encoding is a sense of
imposter syndrome and a need for safety there. Because if you've got, I don't know, SVP of engineering or a CTO coding You have to be fearless about presenting what you've done. So I think that that's something to think about, not just with leaders, but with anyone who's taking part in an event like this, is making it safe.
to fail and being able to celebrate that as well. So if if it doesn't work out, what have you learnt? And what where what do you do with that learning? So I think that that was a potentially bigger struggle than the technology itself and the tooling, which
I think w once you start, uh we we provided a guide and some I I actually made some videos of things that I'd built to just show people the way a bit. So there wasn't really a problem with people once they'd started working on this stuff. But I think there's there's that feeling that I got a bit.
I wanna dive in a little bit more about like process-wise, like cause that that that sounds like that is such an important condition when you're introducing something like this that can be risky from a perception standpoint. Like maybe you are perceived as SVP of engineering and you are now participating in this hackathon and you are now at risk of looking back.
or like maybe quote unquote not doing it the right way. I'm wondering if we could surface that that topic where, you know, people struggled with what do I build or had a lot of questions about the tools and stuff that he they could use. So maybe can you introduce us to what you observed from that dynamic between tools and problems?
¶ Problem-First Ideation Strategy
What I tried to do is seed ideas for the event, for this one. And I think On the whole, that worked pretty well. But a problem that I have noticed with AI tooling in general is that people are thinking a lot more about what tool should I use and asking what tool should I use, not so much what problem could I solve with it. So I think that for anyone organizing any kind of hackathon event, what I'm now recommending is that you spend time in advance seeding the actual ideas and
Trying to help encourage people to frame the ideas in terms of who the customer is or the user, what the problem is and the and the outcome if this is successful. And perhaps
A high level overview of the solution vision without being too prescriptive so that you give creativity to the builder to actually build that thing and come up with their own way of solving the problem. That to me has been a real unlock because I think what you can then do as well in in your business is Help help encourage people to align that to your strategy, uh the work that you try to prioritize on your roadmap.
then the outcomes are going to be a lot more impactful. But I I do think and no the thing I've seen is that within an engineering products environment, we have the framework already a lot of the time to do that. As soon as you start moving outside product engineering, I've noticed it can get a lot harder if you ask people, well, what problems do you want to solve with tooling, with automation, with AI?
It's very hard for people to understand sometimes where to s even start with that. Because I think as engineering product um professionals We already have a good s understanding of what is possible, but for people in other functions, it's really hard for them to see that sometimes and step back.
I there's one thing interesting, right? It's that sometimes if you ask people to say ideate on things that they want to automate, they'll say, Well, I'm too busy to do that And then I'll say, Well, what's the thing you're doing that's making you too busy to do that?
That is the idea. Or y it could be the idea, right? That those are the things. And I and this might sound obvious, but I think it hits all of us a bit that we spend time doing things that are low value, that We should be delegating to something that's automated and stepping back and actually going through some kind of structured process to identify those ideas is really important.
Yeah. I think what's a really interesting observation, like what you're talking about, was like kind of the environmental shift. So like within our teams and organizations, like we're kind of already conditioned to start from a problem and then and then build around that. It but then it was funny is like when you kind of talk about like kind of some of the energy and excitement around introducing a structure like this or like oh we're gonna build the AI tools, like how fast you can forget.
That's the pattern that you need to jump into. And so I do think like this idea of like, if you can help people with problem identification upfront, whether that's by like, reinforcing a framework or as like you're talking about, like seeding some ideas to give people a place to start can help accelerate or like remove some of that like blank page.
fear of starting to build with some of these tools. Cause I definitely have like fallen into that trap where I'm like, well, I don't even know where I would want to start. And helping provide some of that direction can be really powerful. Yeah, and that's where I I I can really help as well. Because if I think about organizing a hackathon where I want to involve marketing sales, people team, HR, if you ask
AI to give you some examples of things that typically are things that people could automate, then you'll get a really good list. And I've so I've been using the tools to actually generate idea examples to then help people connect the dots between a s a framework and actually something more concrete that could help them. So if people are, you know, spending a lot of time running campaigns in marketing, uh, where you could automate a lot of that, then here are some ways that you could do it.
We have so uh we often have so many tools. I think it's applying these kind of principles to those to to figure out how to use them and then going to the tool and finding the match. But these are the I mean we we know this as engineers and product people, but often we forget how important it is to lead with the problem.
¶ James's Personal Learning Journey
So I want to zoom out a little bit because I think your journey to getting to wanting to make this event happen is really interesting here. And then from here, there's an interesting look at then like the structure that that you chose and why you made certain design choices. Cause I think that'll also it'll frame, I think. as people are listening who want to do something like this and introduce this in their organization, it'll equip them with like context on why I would do this and then
how to to design it and execute it. So why don't you bring us into the journey that kind of led up to ELC annuals hackathon? Like what were some of the milestone moments or stories that brought this up into focus?
I think this year with the huge acceleration in the tooling for developers and coding that seem to be really gaining a lot of traction. I think you know, the main question I had for myself was how do I stay relatable, relevant, and helpful as an engineering leader and how do I make sure that I'm looking after my team and helping them adapt.
to these tools. So what I decided to do back in August was start rolling my sleeves up every evening after I put my kid to bed, just building something with AI every day, something simple. So if for my son, a solar system explorer, just some simple apps. And I realized very quickly how they started getting more advanced and this was really fascinating. So first thing was trying to do for myself. And then I attended uh a build-a-thon, which was run by Android, um, where we had to build five apps.
in five hours and it was really intense. And I looked at it and thought, wow, I there's no way I can do that. But I I went along, I partnered up with someone and we made it to the semifinal. It was really, really intense. And it just gave me a lot of insight very very fast into how to use the tools through doing this and building full stack apps very quickly using cursor, claud code, et cetera. Well it sounds like the constraint of that, like
changed your perception of what's possible. Like the forced time pressure in this like impossible goal probably forced you into expanding, well, how do I make that possible? Yeah, there were thing you know, I think there was a challenge which was to build a multiplayer code editor, for example. I looked at that and I thought, well, I don't know how I could build that in, you know, an hour and then roll my sleeves up, started looking at it w using clawed code and being able to very quickly
Set at the back end, WebSocket server, front end part of it. And and it was working. And I and I was just amazed how quickly I was able to plug in APIs. And to be able to troubleshoot those kind of problems that quickly using prompting and have it actually build this stuff. And also the other thing that you can do is you can actually build the documentation at the same time so that you know what's
going on and you can explain it. And as a hackathon, that's another element that's really important is being able to talk about it at the end. Uh and if you're building five apps in a day, that's really challenging. So yeah, the constraint of having to actually do something in a short space of time is a massive unlock, I think, with a with a hackathon event because it really forces focus.
on solving a problem. Uh, in the same way as an incident does. So if we're you know, if if you're being called into an incident, I remember seeing a talk. where someone said you can learn more in an hour of being on an instant call than you can in a year of being on a team because you have to really roll your sleeves up and understand everything. That to me is one of the best ways to learn these tools is to really set yourself a quite aggressive target, to get something working and shipped fast.
I think that's exactly right. Like the underpinning dynamics that I'm taking away from what you're sharing is like Creating these structures of like forced adoption and like accelerated timelines and accelerated like manufactured intensity can really accelerate learning and shifting your mindset and understanding what's possible. Like for me, as you're sharing this, like all of these structures just helped explain. Expand what you could do.
¶ Hackathon Design: Take-Home & Recognition
So Let's zoom up to the hackathon and like let's deconstruct the structure a little bit. So we kind of have like the why this worked really well was because it was to sort of like force time for people in maybe a more aggressive timeline to do something they haven't done and kind of unlock their way of thinking and like walk away with a pretty cool, pretty cool artifact. So bring us into like the structure of the hackathon and why it was structured this way. About Two weeks before the event.
We figured out how we're gonna do this and we we decided that a week before I would put together a list of challenges and send out a pre-vent email to everyone who was attending the hackathon and ask them to complete a form to register.
And participants could choose from selected projects or join their own. And the goal was that we said up front, we're not gonna work on this at the conference. The idea is that the weekend before the conference You build something and here's the tools that you can use and we sh you show up to the conference with this build.
And the deadline was the day before the conference to actually submit a a link to the working demo and a video. That was the the format. And then while that was happening, you know, I was welcoming people to ask any questions if they were stuck. how they were doing and we s I started to see submissions over the weekend and then they kept coming in and so then we ended up with fourteen just before before the day. So I think that was the most surprising s part of it that people
spend their own time over the weekend. They were very excited about doing this. And also I said that you know, I'd love to see people actually demo this at the event in the format that we set up, which was an hour long in the event. Um so that was already for the day of the actual conference. So we've got the the pre event email sharing project ideas, uh structuring in a way where people are going to build async.
And and so I think like the way you described was like a take home assignment approach was like you give people the ideas, you have them work on it at home, and then people are kind of building it and submitting it async throughout that. Live at the event, people shared their projects and then afterwards.
You also created a a pretty cool artifact that really like honored and recognized people for their contributions. Can you talk about that artifact a little bit as like the capstone? Yeah, so what I did, I gathered together and created a Hall of Fame. published this and shared all of the demos and everyone's work to a single page.
Everyone could see what ev everyone else built and comment on it as well. That meant that everyone you know, everyone felt recognized for what they did as well. And I think but it was also quite fascinating for everyone to see what el everyone else had actually created.
Yeah. We'll we'll have a link to the Hall of Fame included in the show notes so people can kinda check it out and learn.'Cause it is it was really fun. Like I think Within that first weekend, that moment you're talking about like I remember texting you and being like, I can't believe like the the sheer breadth of the projects was was so much was so energizing.
¶ Evolving the Hackathon Model
Okay, so that's the structure. Obviously we learned a lot through that process. And I think you've really spent a lot of time like distilling like what worked and what you wanted to shift. So you now have run or are in the final stages of running this for a second time with Coursera. So can you talk a little bit about the pivots that you made in this? second iteration and you know some of the the nuances or changes or insights that you're applying doing this now a few different times.
I think what's really important is the overhead of the event being efficient. So what I've done is I've now created a portal with everything in it, the registration, the challenges, um, how to actually submit everything and the guide all in one place. You know, this is quite common for hackathon events that that are more mature, but I think
If you if you're thinking about this, then it's a really good idea to make sure that you do that. And you can even build it with AI, right? That's the other thing, is trying to put your money where them where your mouth is and actually use AI to build some of the tooling around running the event itself. And I've also used it as well for the idea generation. So we're very keen to make sure that the ideas are coming from the ground.
bottoms up, but validated by um some leaders to make sure that they're actually aligned with what our strategy is. So the the the approach that I've taken to that is actually guiding people to understand how to make a pitch, how to align it. So that we minimize the overhead of any validation once it gets to the leadership team because people have already put a lot of thought into how to pitch a particular idea they've got and how to make sure that it is impactful.
The the thing about um um one of these AI events is if you're uh or a hackathon is that there's the learning part of it through discovering these tools and what their potential is, but then there's also the potential outcome of what you built being of value. And I think that if you can make sure that the value of what's being built is maximized by having good planning and alignment at the beginning, then that
is a lot more satisfying because if it it's great if if the participants can actually prototype something that can then lead to productionisation later. So that's another part that I think is an element that um that we're taking seriously as well. I think that's a really great insight because I I have heard uh you know for a couple companies that I've heard of introducing a hackathon type format, uh I think like I was talking I was talking with folks at Breck.
And you know, they did a hackathon, and like one of the things of that hackathon led to uh a big part of their their launch. And so I think that it that is interesting. So like Can you talk a little bit about like if that alignment at the beginning around the ideation period is important, is there a time frame recommendation or what would you recommend as like a way to help people get that alignment ahead of time? What I've tried to do is a month before, run the ideation for two weeks.
And then monitor what's coming in and then encourage and pivot as it's happening. So I think that's the important thing about running, you know, like the visibility and the transparency around the ideas coming in, the rate of them, and then what I've been doing is sharing back. a visualization that shows the ideas coming in and then using social proof to help other people and encourage others to also send in their ideas. So I think that that
part of it. And also noticing where the challenges are, where where people are struggling. So the thing that I noticed is, you know, as I said earlier, the product engineering function are used to doing this more than other departments.
And then I found that I need to reframe things a bit for non product engineering people to provide more examples, et cetera. And then I saw an increase in the number of ideas coming from other functions as well, which I thought was really interesting. I think it's really that's really great. So if you had a recap, for somebody who wants to to roll implement something like this.
Uh is there like a final level of lessons that you'd want to really amplify? Like in terms of like your takeaways from having done this now a couple different times for ELC and for Coursera? Like what would be some final lessons that you might really want to point people to? The most important things are make sure that your seeding ideas
from everyone and giving a framework for how to pitch those ideas. The second thing is you need to make sure that you're setting everyone up for success you're building by making sure that they understand what tools they have access to and that you've tested them.
You also the big challenge I think with hackathons can be the deployment of the end results to a place where everyone can see it. So I think it's really important to test that out and make sure that it's Uh s it it can be done safely and it can be done in a way that everyone understands and there's not that much friction, especially if you under a time crunch.
So within the organization, a lot of the time I think tooling that's a bit more slow moving in terms of releases and everything. So being able to prototype fast means that you have to be able to have a place where you can Safely share the end result so that everyone can see it and the judges can see that result. And then the other thing that we talked about was just making it safe for people to try new things and fail. Make sure there's some kind of incentive to do that.
The difference in terms of building and prototyping things that will potentially be throw away thrown away versus building things that are very much like production ready needs to be really clear. And that's something that you need to set the expectation around at the beginning is look, we're not trying to fully integrate everything into, you know, the whole of our platform. We're trying to deliver things fast to get
A sense of what's possible that we can productionise later. And that isn't always clear to people who are not used to doing that. Make the ideation clear, easy, and aligned. Then you've got just make make the tooling so easy that people can jump in. So like that it's super clear what's available or like have a point of view on maybe the the recommended tools. Then you have this element of
psychological safety or having the ability to like fail and do something or a point of view on what you want the end point of these projects to be, whether it's like if they get thrown away or whether they applied like what the end goal is. All of those, I think uh the I think it's a really powerful, powerful framework there.
¶ The Future: Cross-Functional Hackathons
There's a few next steps that you're that you're working on as well. So like when you're thinking about like the future of maybe this modality, like how is this evolving? What's next for you when it comes to the future of hackathons? Or what are you thinking about with like the future of a hackathon?
So to me the future of the hackathon is that it's not just engineering being involved. It's a lot more cross functional. More of an organization can get involved in hackathons, which is something that You know, we've tried to do a Coursera quite a lot. We framed our hackathon as makathon and involve as many people as possible. That isn't always practical.
A lot of the time people are scratching their head wondering, well, how can I get involved? This is very technical. But with tools like um Replit.
Um there's Figma Make, um there's Google Gemini Build. The game it's just changed so much that people in different roles can be really involved in these hackathons or prototyping sessions and produce something that is able to supplement or even replace a PRD or a long document with something that's much closer to development and allows people to move a lot more quickly coming out of the event.
So I th I think that's the main thing I'd say that is a huge shift is just being able to have people who are crossing f different functions a lot more involved in building.
¶ Rapid Fire & Concluding Thoughts
All right. Great. Great. Great. Great. I love it. James, you've guided us through the inspiration behind this hackathon, some of the major lessons. uh how it was designed and how to implement or execute this for for folks listening in from the community. We've got a couple of rapid fire questions if you're ready to to wrap up wrap up with that. Yeah. So first rapid fire question, what are you reading or listening to right now? What I'm reading at the moment is I've gone back to book
I read in the past and that is Thinking Fast and Slow, which talks about, you know, the brain and the different modes of the brain, thinking fast and reacting fast, and then the more deep thinking. And the reason why I'm reading that is because I'm very fascinated by the human mind and the human brain and just what differentiates it from AI and what we need to cherish about it.
and actually have val you know, there's a lot of value in the this thing that's evolved over millions of years. And I think it's really important to understand as much as possible about it. That's what I'm reading about at the moment. And also Um, Dopamine Nation is another book that I'm reading at the moment to just understand. You know, I think it's really important for all of us, we're the especially those of us involved in technology, to take a step back and take a break from it.
and understand the importance of being able to use mindfulness techniques. and methods to actually be able to um reduce the amount of dopamine hits that we're getting all the time. I love it. Next question, James. What is a tool or methodology that's had a big impact on you? I think the biggest one is cloud code recently. The ability to be able to automate a lot of what I do very quickly. and bring together different things that were in different places and quickly move on
a plan or being able to convert something into a format that makes sense to other people is just really powerful. And I think Claude the reason why I say clo claw code is I think for engineers it very much fits into how we think about things versus some of the other tools that are much more UI driven. I think that's what stands out at the moment to me. Love it. Next question. What is a trend you're seeing or following that's been interesting or hasn't hit the mainstream yet?
I don't know, I I keep coming back to the value of um what's unique about us as humans and the importance of valuing emotional intelligence. And really caring about what it means to lead and be good to other human beings is really important. And I think that, you know, that one of the things that's interesting is we can be very polite to uh when we're talking with Chat GPT. and think that we need to use our manners and everything when actually it doesn't really care that much.
But people that we but we love and the people around us are very important to be looking after and I think that
the thing that I'm really fascinated with at the moment is how things are evolving so fast and how important it is that we really value each other. And I don't know if it's a n a new thing or it was it's just Just something that is very top of mind for me at the moment and you know, slowing down and thinking about that and thinking about where you actually put your attention and how you build trust and all of these things as levers in this world where things are changing so far.
I think it's a great thing to surface. James, I I know I don't know if I got a chance to tell you this after the hackathon, but um I just want to say thank you for for being an accelerator and bringing something that I think really helped impact a lot of people and change their paradigm.
It became a moment where it actually accelerated a lot of my adoption and experimentation around a lot of these different tools. So um I just want to on behalf of the community for people who maybe haven't had a chance to share it with you yet, just thank you for helping catalyze, I think, a moment of really big insight for people. This has been a ton of fun. Thank you for joining us.
Thank you, Patrick. It was an absolute pleasure doing it. And I'm I always enjoy working with you and Jerry and seeing what you're doing on your team as well. So thanks very much for um helping me, you know, be part of that.
If you're listening to this and you're wondering, how can I connect with other engineering leaders in my city? Pull up your phone right now and go to elc.community, click our chapters page. You can see that on the menu on the left. Find your local chapter and click join. We're hosting
virtual and in-person events all the time. And this is the best way to help you get involved, expand your network in your city, and support your leadership and career growth. So pull up your phone, head to elc.community, join your local chapter and get involved. A huge thank you to all of our local leaders. to make community happen and thank you for listening to the Engineering Leadership Podcast.
