DevDays Europe 2025

Panel Discussion: Intersection of Leadership and Technology

48:06 · 20 May 2025 – 23 May 2025 · YouTube

About this talk

This panel discussion, moderated by Max Cora, focuses on the intersection of leadership and engineering within high-performance software teams. The panelists, consisting of experienced engineering leaders, share their insights on modern challenges in leadership, such as managing diverse teams and technologies. They emphasize the importance of communication, psychological safety, and fostering an environment that encourages curiosity and learning. Key topics include the balance of implementing new technologies while maintaining team morale and productivity. The conversation also touches upon metrics for assessing team performance in relation to profitability, stressing the value of understanding both people and processes in leadership roles.

Full transcript

[Music] it's panel time folks and I absolutely adore these moments cuz it means that I get to step back and just employ someone else to kind of be my uh my controller my moderator in fact this panel is going to be an interesting it's be about the intersection of leadership and uh my Champion to moderate this is of course going to be the one and only Max

Cora I'm going to bring him now uh Max pleasure to have you here but you know I I was just saying off camera usually in person You intro one person at a time you bring them in I'm simply going to drag them all on stage disappear myself and let you uh run around the room and intro each of them and let talk about themselves but just to

reminder folks if you do have any questions Max has said he's going to keep an eye on the chat so as the conversation goes on if you see someone you want to jump in drop a question there and he will facilitate it to the team but I'm going to disappear now Max the floor is yours and I'm going to bring in your guest thank you very much

um and welcome to this panel discussion um I have a fantastic audience in a fantastic team to discuss the topics so far I've seen also in the other panels we have always some um nice amount of uh questions coming in um so with that um I said my name is Max I'm the founder of liquid reply and a cloud native Advocate running a small company of like

14 people um building with our customers together different Cloud native environments and solutions um and different Open Source Products and I'm also a little bit active in the open source space um as a cncf Ambassador and Linux Foundation Europe Advisory Board member but more importantly are my guests and I will give a short round of introduction starting with Anton thank you Max yes my my name is

Anton I've worked as an engineer for or an engineering leader for about 20 years and uh had a engineering leadership related career for the last 12 of them shipping various products from um SAS ones to uh b2c ones always distributed systems uh complex stuff currently I work as an Eng director at canonical the publisher of auntu um and I deal with everything related to the back end

of The Snap Store and chub if that uh makes if that rings the bell to anyone uh that's it about me sounds fantastic one question for you how would you describe the challenge of leadership in one word can I use two distributed systems we maybe maybe I have Dash in between thank you very much um jumping over to gregos hi hello G for the last four years

I built from scratch devop operations and support competence Center including building the team H and recently I jumped over to to to other area of building the products and also once again I'm building the team from scratch thank you very much and also for you one question how would you describe the challenge of leadership also in one word will say people fine thank you I will take

that James over to you um hi everyone um my name is James bokit I'm the technical delivery director for a UK based Hands-On Tech consultancy called open Credo so my background is in uh is is in Tech I was a Java developer for sort of 20 odd years and so had various leadership positions technical lead and then to which kind of brought me to my current role

which is kind of um everything from kind of making the tea and doing the pre-sales all the way through to kind of making sure that stakeholders and teams are happy and I think that um it's interesting kind of being a a consultant here as well because I end up having to build and bootstrap lots of different teams with lots of different mixes of people over over over

time as well so so hopefully I've got a a mix of perspectives that I can help with thank you James and also for you if you can pick one challenge of modern leadership what would it be um I I think that modern leadership and actually I don't think this is this is very different to to traditional leadership is that it's just messy everywhere you look customers is

messy Tech is messy people is messy it's um uh it's a bit of a hack because my my answer to your sum it up in one word was going to be messy actually as well so sounds good and sounds like we need a cleaning service maybe we can find some some good starting point here um to you yes my name is Muhammad asan and I am a

software architect working at sco at the moment in Sweden I have a background in software engineering as you can imagine for about a decade now uh I'm an author of two worldwide published books and I am also a Google developer in angular so I I do a lot of open source projects a lot of content creation courses and I've been involved in working with a lot of

teams that had included uh engineering leadership roles as I've worked with a lot of teams uh in that regard so yeah that's my short not short perfect and also to you like um what would be your one pick for modern challenges uh I think it's it's a it's sort of debate between communication and transparency but I think they both sort of fall within together so I think

communication would be my choice MH cool thank you and thas it's very nice to meet you all uh in this panel discussion and very nice to meet everyone on the on the audience um what about me um I spent almost 20 years in engineering world uh I was Java engineer uh back then working in the banking industry uh then move to various different roles more agile oriented

more leadership oriented right now I'm um I'm a general manager of Grant par Poland which is the um the technology hub for a bigger company global company William Hill evoke 888 we have three three three names as of now um so that's that's about my you know career background in my uh free time I love you know public speaking so that's why we are here and I'm

here with you guys because I love to share the knowledge with with with others and um yeah and maybe the last last thing that it's almost done already I'm uh about to finish my book about the AED transformations in the organization so what what I've seen since you know those 20 years during those 20 years I try to describe in the book fantastic awesome if you would

like to hear more about it you can drop him a uh message in the pine platform and also to you um what would be your one word to describe the challenges of modern leadership we talked about uh people we talked about communication I will describe the one word that the challenge relationships MH perfect nice thank you and with that um thanks for the introduction I would like

to move a little bit over before we go deeper down into what we actually would like to discuss on this panel um I think we need to Define what actually means a high performance software engineering team because maybe people can understand something something different in that um does anyone of you have a a very strong opinion or Bel has a a common description you see please feel

free yeah thank you thank you Max um building on my one actually two- word uh challenge of modern leadership which is distributed systems I mean both the software systems and the so so to say People based systems because um a highy performing team to me is a well performing system that can handle um failures so to say and uh bad inputs and so on and so forth

and and uh uh just like like a software system that we would consider resilient this team would be resilient to whatever weather they encounter right um yeah we can go into the details of this you know all the layers of uh knowledge sharing of uh prop properly distributed responsibilities roles processes uh clear and defined and so on and so forth but on the surface this would be

a team that could handle practically anything reasonably related to their area of responsibility that you throw at them does anyone of you would like to add something to it toas yeah yeah I would like to add the three three points that for me are critical so the goal of the team the team needs to know where they are heading to you know what's the automatic goal that

they would like to achieve then they need to collaborate um together so you know this communication aspect that we've we discussed um the ways of working agile develop ways of working doesn't matter which one but um it's important for the people to build relationships and collaborate together and the third aspect is the ownership of the um the feeling that we are making business profitable because uh sometimes

engineering teams they are you know keen on imp implementing new new new technology new tools new practices uh also New ways of working right but they are not so focused on the fact that they need to or they need to produce the products which earns money for the company so those three goal collaboration and the ownership perfect thank you if if I could add to that as

well I think there's kind of an external measure and maybe an internal measure as well so I think the external measure is is um is as much as you were saying tomash is you know are stakeholders happy and stakeholders are happy generally if if the company is making money really um and that's you know the company is rolling forward and shipping great products and they're staying they're

staying online and up upright for for as long as possible they got maximum up time but I think there's also an internal metric as well you know it's no good shipping great products if everybody is under the C and is absolutely crushed by deadlines and pressure and working 8 days a week and 25 hours a day so I think there's there's those internal metrics of are people

smiling are they happy are they you know doing their best work do they feel that they're doing a good job do they feel that they're growing and they have they got opportunities to grow as well so I think there's um it's such a multifaceted problem it's it's quite fascinating from that perspective no we are talking about this all around the people and Corporation and so on as

as you heard we didn't touch even the technology that we are using yes because the first are the people in my Bel me if we even do not have the sufficient technology competences to deliver it is more important to have the team that have the spirit as thas said understands the goal and also can see that what we are doing is not only doing because they ask

us for but we are the creators of the uh of the product we are creators of the value inside h I would like to pick on that in one second but first also to the audience uh do we miss something what is in your world in high performance software engineering team let us know and drop it into the chat um we happy to to learn a little

bit about your perspective um greig I would like to add to this a little bit of question towards to you um because you mentioned the technology um so which impact have the emerging Technologies um on engineering teams and the leadership of those teams what do you see there so this is this is important which technology we are using and if that suits the team and the needs

of the product but as I said I will not focus on the technology emerging Technologies and so on I will focus more on how it is important for the leader to understand what he or she should build yes to build the spirit to build the team to integrate the team to have the common understanding of what we are delivering and that's I think for now with the

all of the diversity that we have around all with the different perception of of of the different people from different ages what are they attitude to work and so on how to integrate it and have a Boost from that not to have a problems uh from diversity well M what do you think what what which impact do we see here also from the iming Technologies on the

teams uh I I think there are a lot of interesting sides to it um on on one one side we see that the Technologies are making the lives easier but then also having a lack of those also result in teams uh to I would say to the point but they get frustrated if we not using uh latest Technologies and we are using Legacy Technologies but I think

even I I think as a result it's probably not the technology that it causes it but rather the communication on what what is valuable to the end users because you could live with existing Technologies but if the if the whole team has a clear idea of the impact that they're creating and that they're not um yeah it doesn't have to be the technology that drives value or

satisfaction to the team but rather the value that is being generated uh and the users that have been benefited I think that that's a challenge what I usually see that the hype that usually gets created whenever there's a new tech uh and then you know rushing towards it and I think it then becomes the sort of responsibility of the leadership to talk about it openly uh and

you know give ideas and listen to the others and then come up with a solution that makes sense to everyone but I think that that is something that I see as a challenge quite often is there something from your side which you could recommend to the audience thinking about this diversity aspect and the um advancing of Technologies so what I mean is um what you I see

frequently in very diverse teams not in terms of gender but also like in terms of professional background but also of age um we see often that um the more experienced folks are a little bit like hold themselves back to adopt to new technologies while the youngsters are running behind every new technology how do you what would be your tip to say like hey this is how you

can catch them back and allow somehow both of Both Worlds yeah that's that's that's an interesting challenge one of the recent things that I also faced was uh facing the same thing that some of the senior Engineers were too reluctant on even using an existing library for example from outside and just implementing their own solution because it gives you more control but then I I think the

discussions around uh what brings value to the customer is is going to be the key and then also having a sort of cost benefit analysis of everything so when it comes to diverse uh Technologies I think what I've seen or what I've recommended to the teams as well is to see the competence that is within the team the goals that we're trying to achieve and then having

a clear discussion with posts on you know what everyone thinks is the pros and cons so we have so many different ways of uh of sort of putting out our thoughts I think it becomes a bit difficult when it comes to remote work but I think if we can get in person and then discuss them with those posts and have everything in front that clearly gives a

understanding of okay this is what we're talking about and this is clearly you know what could bring more value and is a possible a potential solution MH interesting one toas what do you believe or do you see that there is any impact from our all-time favorite topic of AI into the team performance and also teams yeah our beloved beloved topic of AI right is everyone is talking

about it so the question is actually how we use AI tools right we obviously can use uh tools like co-pilot to help us coding and so on so that's definitely it has an impact on the on our daily work but at the same time I think that you know this human aspect that people needs to speak to people and needs to figure it out what to do

in the product in order to generate the revenue and generate the money will be still there so we this part is very difficult to to to to automate and now obviously with the emerging Technologies um all the youngsters as you said all the youngsters would like to use all the fancy tools and so on so I observe something like impa impatience right that they would like to

jump straight away to another tool another tool another tool but in the end of the day what I observe is that they are the you know they are finishing the day or finishing the Sprint with unsat or unsatisfied because either they were not able to implement new tools because of some you know lack um lack of approvals or um they tried and this tool was you know

this AI F was promising much but then in reality it didn't work so well so I think that you know we also need to explain the youngsters that um sometimes I mean the main goal is to have profitable product right so sometimes even the old Java tech tech stack for example can be useful if the if it generates the revenue M to all of you what would

be a reason strategy to handle exactly such kind of a problem on the one hand side to focus on the outcome of the team because I think that's a motivational Factor if the team is successful in delivering new features it's like giving the right we feeling and pushing forward it can be a good driver but on the other hand side keep the motivation High um to yeah

learn something new try something new but without putting the the performance into danger for fre um yeah my perspective on this is um that luckily in our uh engineering world uh modern engineering world we have to you know have to update our software and under lying Technologies and so on um I think dialing this uh a little bit D the scale of the initial adoption of the

newer things uh down to uh let's say proof of concept or something like this helps a lot so like um if there's an emerging technology um that hasn't yet been battle tested and that's that's we want what we want uh to use something that's been battle tested um we can work on a proof of concept uh choose a small service in our I don't know uh zoo

of microservices uh to try it out with and so on um and then if it proves um it's worth this then we're like okay that looks good maybe we can try another service and so on do a bit by bit um and like the worst thing I think we can do is uh saying oh okay this new emerging technology looks very good judging by the tutorial let's

migrate everything so that's that's not how it should be uh but trying things out should be an um an essential part of the uh engineering team's agenda in my opinion so to summarize you need to Define within your regular process and real your team capacity some space for actively working on it and not focusing on the on the other outcome but learning is also I think a

very active and very positive outcome right yes uh trying things out uh and actually that can be SE can be viewed as uh something that we're doing for our product not necessarily learning for the sake of learning but learning uh something that our general product that the team is responsible for uh May benefit from it may not as a result of learning because it it's deemed not

useful but how do we know if you don't check it out y James yeah I think there's there's um there's a healthy dose of of pragmatism that that has to be applied as well um sorry to be the party pooper but I think as an engineering leader as well you've to it's such a balancing act because everyone loves new and shiny and you want new and shiny

stuff um but and that's that's great and that's to be applauded and people should move forward absolutely however you don't want so say say you've got I don't know you got rabbit mq or something in your in your architecture and someone some bright spark goes hey we should use Kafka yes you should use Kafka big fan but you're gonna need to kind of go okay let's check

this out yeah is it work yeah it's a great piece of technology right now the hard work begins where we've got to if we are going to adopt this we need to wholesale move over to it otherwise we've got two messaging infrastructures and you can't have two you know nobody you know the balance of uh the benefit of of having people motivated and say hey we tried

something new and shiny and I got to get that into the product great but the the the downside of that is if you end up with loads and loads of sort of half bited decisions and sort of half done pieces of migration work you know you're just instantly drowning in technical debt and that's really demotivating so I think um things like um architecture decision records and kind

of getting people bought into the process as well I think that's good because actually um no technical decision especially if you're changing direction comes for free and so you have to make sure that everybody's on board to pay the cost which is the migration or whatever it might be yeah y absolutely I think we we elaborated a lot on the on the one side of the co

about the the technical impacts um but when I ask you about the challenges uh everyone point out the human factor um to summarize it somehow in this this way so um Muhammad which strategies can you recommend for for team lead to build and maintain a strong engineering culture oh that's a tough one uh yeah I think one of the things uh that I usually see is as

we started talking about it uh someone mentioned about the deadlines and you know the constant Rush of delivering things I think that is something that that is usually the case or the cause of frustration in the engineering teams and that usually comes with again it falls with a lot within a lot of buckets but one of them is communication being open uh when when you see that

you know you can't really deliver this in x amount of time so I think that's that's one of the keys when you're open you can discuss within your engineering teams and one of the things that has worked for me very well is having this sort of you know checkin with in each individual on having their own sort of path that they want to go within the team

and they can you know forecast three months six months whatever that is and let them Drive their whole journey as they're growing and they can be realistic just like uh Google does their okrs that we don't really have to achieve them but it's good that we are least go with an aim and I think that usually drives the Innovation and that when you have that then you

usually keep in mind that okay I'm working on these features but I also have these goals for my technical growth as well and then as anthon mentioned there could be some sort of proof of Concepts there could be some hackathons in which you can try out different things but I think it's really essential for everyone to be open about it and when we talk about diversity having

architecture decision records that as mentioned but then also having sort of a tech radar that can bring a bit of diversity within the organization so people can try out things that they really like as long as it doesn't go far beyond what the architecture doesn't allow or you know the practices that we shouldn't be following so I think it's it's a combination of several engineering practices including

this technical growth uh that each individual is driving having an architectural decision record plus the tech radar are and then the possibility to be open to sort of manage this with with your you know uh TL or your manager on how you're growing as an individual alongside shipping products very interesting Greg what would be your take on to say like hey how we can build and maintain

a strong engineering culture I think it differs from the point where the team is yes based for example of the sdlc software development life cycle it will be different for the team that is creating the product from the very beginning the first second year will be something fresh for them but after that it's it will start becoming more and more boring yes it will be the same

task repeat it all of the time and the case is how to stay with the same attitude of the team yes how to grow the competences and what was said some proof of concept some going out of the box uh trying different or trying to do something I will say not exactly how we should do it in this technology but maybe some find some other P perspective

for that it is important because it will drive people to learn it will it will drive people to find out new opportunities and it will build the final value of the product so it depends on the level of the team and the majority of of the product that we have H that's a very interesting part because I think um what we what we see nowadays is like

that um a lot of people checking their CVS have like one and a half to two years in the CV before they rotate the company right um which is kind of interesting because you usually say someone needs around six months is until they are fully into company fully into product so someone after then in addition of one year one and a half years leave again um what

does it tells us so um I often find out that talking with these people who frequently go through the companies they exactly um are on the point which you described they're bought out right they have understand how the product work what they're working on what is the benefit of the product and when they reach this point of like oh I understand what which value do we generate

but I have the feeling I don't add anymore too much value to it even so it's incredible value what they do like keep the stuff life right if you have a platform with millions of users or it's critical for for some parts or um whatsoever but but nevertheless um when people get the feeling they're bought out with a topic they're working on and and topped it um

then they're are searching for something new even if they are happy with the company even if they're happy with the team that they just strive for something for Relevant um from from one of you is there anything where you will say like oh I have have some some good experience some good strategy to to overcome this yeah I would love to add that actually this what you

mentioned is a good segue to the hiring strategy because for me it's all about um starts with the with a hiring strategy because when I build a effective engineering team first things first I need people who are curious because they will if they are curious they will be you know searching for new Solutions new uh features new opportunities to develop our product then I need the people

who are willing to learn so they are curious but not just curious to you know Implement new technology in that sit to try out but to deeply learn about this technology so curiosity and learning and the third bit is about relationships again right so this human aspect how to work together because we don't have people who work just by themselves we have teams and we if if

you are talking about teams we need to um hire team players who are willing to exchange the knowledge and produce this overall outcome so the hiring strategy for me is about those three three pillars MH any other take I think I think it begins with hiring as well but I think also the the um the day-to-day work for people matters as well so if you've read um

uh read the book drive by uh Daniel pink as well so he says that um motivation comes from autonomy Mastery and purpose and that really resonated with me you know so autonomy um uh treat everyone like a grown-up uh my my head of people has a great phrase and she says you know um trust and track rather than command and control which I think is a really

nice way to kind of like hey yeah this is this is the way I want to I want to hire grown-ups and I want to treat them like grownups yeah and Mastery um if I take you back to the agile Manifesto yeah what it says uh continuous continuous attention to technical Excellence improves agility and I think that um you know fostering that culture of learning and that

that um or culture of curiosity um get people to conferences like this one right uh you know meetups lunchtime sessions hackathons mob programming if you can do that you know even you know or pair programming right so um and maybe even align some of the business incentives around that as well is to to you know you you know you'll have your career ladder but you know but

perhaps there is um somewhere where you need maybe you need some more kubernetes knowledge or something like that actually kind of rewarding people for getting those uh qualifications um and then finally kind of purpose you know doing something that matters I think we've all probably had some time in our career where you know you did a piece of work and it never got into production that is

just that just sucks for a programmer it really does you know so actually doing something that matters that they can and it's a little bit easier for a consultancy because people are paying a day rate for my folks so um it has to matter otherwise they're wasting their company's money they can they can they can point to an invoice at the end of the month that they

wasted but um but actually giving them something that matters that they can see that they can be proud of that actually makes a difference as well and I think that that probably comes down to your prioritization as well you say well actually I've got to do this first because it's most important to my business the people doing that are therefore most doing the work most important to

my business or to my to my to my value stream yeah if I yeah if I just just little bit I I actually fully agree with James and uh I think there's there's a way people uh kind of simplify their um assessment whether they should look for a new job or still stay uh and uh I think it's a famous one uh like learning and earning right

so if it's both it's the best company ever if it's one of them it's fine they'll stay if it's none of them well why stay so yeah so um considering that perspective as well I think is is important to to keep people at your compan absolutely and all of your answers Suites very well to the question which we got from the audience how to increase the retention

of um giving also two very concrete examples where on the one hand side an engineer is looking into working with AI and looking for a project and because the company doesn't have the engineer is talking to other companies to maybe satisfy his needs um while the other example is practically similar thing just with salary asking for a higher salary 10% increase the best thing you can do

is 5% increase um if that person would apply somewhere else it would definitively get at least 10% um salary increase I think um you provided already some some perfect answers to it and uh I like the the addition from from year an saying like if the company can be provide the learning and the uh Act Right payment for you it's a good way it's a good environment

right um if you lose one of both maybe you can consider it um I think I would my I would also answer to this question a little bit that um you should not forget that in some perspective our engineering Market is a little bit toxic I would say right um especially if you see the the payment differences between us and Europe for example European engineer earns comparable

to all the countries we are living in an extreme high amount of money usually double than what every else in the country is earning in an average if you go to us you can earn there again the double of that money right so it's attracting people from all around the world um and I think that that in some way praks also the um the strategies how and

where we can engage with engineers and keep them motivated because at some point it always gets really this feeling and taste of like money money money um with that looking into the times we're running very very good um is there any practical advice you can give um to to the audience building on top of all what you have said a team which really delivers a high performance

but also maybe delivers a satisfaction yeah I have again three three aspects I like those triangles the first one for excelling you know this um this setting up the team is about the resilience so how the team is resilient in front of the challenges and I'm I'm talking not only about you know like production issues which are the main the main challenges in the team from the

engineering perspective but also how they are resilient in terms of organizational changes for example that they need to switch a place um in the organization structure or they need to you know reshuffle the people if they are resilient or not if are if they are in this mood of complaining that everything outside of team is bad or if they are sort of elastic to to adjust the

the change so that's one the the other one is psychological safety so everyone I guess is talking about psychological safety after uh covid because one of the reason is because we work remotely and it's more tougher to provide this psychological safety in in the environment and what the third one which which helps is uh being for able as a leaders so if we are vulnerable and show

that hey I have some weaknesses and that's okay because I'm a human being the other people will you know mimic this this habit and will not be stressed about their um their um challenges that they have right so it's it's for me it's all about you know being a human being MH very cool thank you um looking into the audience we have one other question about is

it very difficult to measure if it team uh is profitable when the team do not do direct sales what substitute pkis would you recommend to GA on this metric I can uh I think I can take or start answering this one it's all about the metrics that we have right so if we Define our metrics in the development team just to track our process we will not

figure it out if the process if the product is profitable or not but if we instead of tracking or not instead but on top of tracking like cycle time lead time and so on track also the performance of our product uh the availability time the um request or the new users per per week per day it we may connect those with the financial aspects obviously this not

in our hand the financial aspects but we can speak with the finance team or the business team and then connect the metrics that are all about our users and the fees they pay into our uh system well I think Al the economical side there's there's one very simple thing in it right if you have a digital product and your company runs it every month in the end

on at least the pl zero or something positive numbers it's still fortable enough to keep your business running but if it goes below that it's a problem please I may a little bit uh I think if we're talking about a an a specific engineering team within a tech department uh being considered uh um yeah I think I think that doesn't make uh a lot of sense to

you know to go down on that level on uh in not in all cases anyway in some cases it may because it it this is the team building a very specific product and they need to care about the profitability of that specific product and so on uh that uh actually Taps into a a rather big uh discussion like whether a tech department or Tech teams in general

should be considered cost centers or profit centers right so and when they are considered cost centers uh then uh less there's less opportunity to you know to grow it and so on and so forth there are many many more hurdles talking to the you know to to the finance department and so on and so forth usually if they're considered profit centers meaning uh they're viewed through the

lens of okay how how much does the product that this theme builds uh earn then it's much easier uh U to to grow it right because uh the product is more successful the team can be bigger or we specifically invest uh in this team because the product uh will be then we expect the product to become successful because of that because there's a road map to deliver

and so and so forth so yeah uh it is it may be challenging for some teams to become uh to be viewed as profit centers but I would generally recommend to to do the best you can for them to be viewed as profit centers because that kind of you know uh expends the the the spectrum of possibilities perfect so running soror I just wanted to add one

one one more thing to it so I think the only correct metric for productivity is the number of lines of code kidding of course kidding one thing quickly I want I think one of the things that that could be looked into is the quality uh that of as aetric as in how many how many incidents are there and how how many Innovative initiatives have been taken so

maybe those two can be a good one all right we're running out of time so we make a little closing round I have uh two questions um everyone of you have around about 20 to 30 seconds to answer it um to close and make your final closing statement um either you can answer what are your taking with you from this panel discussion or what would you like

to give to the audience as a recommendation or what they should take away I will start how and how I started in the beginning and going with Anton thank you Max thank you everyone for uh participating um I want to probably leave uh the audience with with one uh statement uh as with high performing software uh to get a high performing team uh especially in the uh

various and diverse environment that we are in currently do spend time designing it as you don't build uh software without thinking of a design uh you shouldn't do that with teams either if you want them to perform on a high level that would be it for me Craig yes I believe that as the team is building the application the leader is building the team and this is

really important I will take that all of us believe that people are very important uh in case of delivering the value at the end of of our development and I want to refer to the question about the the salary rise yes I had an engineer in my team that was able easily to have at least 50% more money from different company even in the same building but

he was so happy to work with the people and it was not going to work more meeting with the friends so having the team High motivated can also uh leades people to appreciate what they have appreciate the team that they have and the development that they they they can gain within the team um James what is your takeaway or giveaway um I've used a bit of both

actually so it's it's I think I think we've all focused on the people part and I think that's really necessary I think that technology problems can usually be traced back to a people problem somewhere along the lines so I think investing in your people and investing in time with your people and maybe even surveying those people and kind of understanding kind of what's what's what's driving them

what's motivating them and what's demotivating them uh you know annual surveys and things can help and but I think that it's a it's a much more inexact science and and so many of us have got a technical background um you know give us a command line any day over over kind of people it's a lot easier to deal with a command line and make that do what

you want and and and get the best out of it so I think that it's something that as engineering leaders you need to constantly invest in yourself so that you can invest in your team and be a servant leader um and It's Tricky uh so I'm glad people have come to the panel discussion because they're in the right place because they're obviously on that Journey well M

yeah I think the one thing that I would love for people to do especially leaders is to Model Behavior Uh whatever they want to inculcate in the culture or in the teams for example if I want everyone to participate in the hackathon I will sit between them and participate in the hackathon myself uh and similarly other values as well so I would love to share that yeah

fantastic and last but not least to much for me it's this intersection world because I when I imagine intersection is engineering and the leadership and the in in front of the intersection there is a human being so this is we all talked about it right that we are not machines we are human beings that love to work to with each other they love to connect to each

other so I think that that's that's the takeaway for me and I hope that for the audience as well to pay attention to the our colleagues and to to to build relationships with them thank you very much thank you very much to you all um also to the audience it was a fantastic round I hope you could take away something with you and if you have still

open questions reach out to the speakers and panelists and I think you can reach them to Pine or any other social media platform and with that I wish you a very nice afternoon enjoy your lunch it's lunch break um I got to I got informed I have no idea how long it is but you will find it in your program and then have a great rest of

the day stay safe see you all soon bye bye cheers everyone thanks cheers Daye [Applause]

From event

DevDays Europe 2025

20 May 2025 – 23 May 2025

All event videos
Back to Watch