A Guide To Managing Technical Teams

[@ContinuousDelivery]

Learn how to work as a highly functional software development team with helpful tips in my FREE guide to "Organising SW Dev Teams" which you can get here ➡ www.subscribepage.com/organise-teams-guide

[@cdarklock]

I've always considered the first and most important job of the team leader to be "aggressively protect your team from distractions, interruptions, and bullshit." As team leader, your job is to worry about internal disputes, management power struggles, interpersonal dynamics, and corporate politics - so your team doesn't have to. Everything you do with the team itself is secondary.

[@cdarklock]

@Barney Laurence Oh, I know exactly how to handle a company like that. "Here is my two weeks' notice."

[@cdarklock]

@Barney Laurence As the team lead, you are the corporate politics specialist, just like your team may have a database specialist or a UX specialist. Any need the project has for databases or UX gets referred to the appropriate specialist, and there is no adversarial relationship with the rest of the team. The team is kept apprised of the situation as necessary, but it is not their job to handle any of it - the specialist will do it. Any and all members of the team are welcome to learn what is going on with the specialist's work, because this can only improve the project. They are, however, explicitly discouraged from DOING any of the specialist's work. If someone asks you for a change to the database, and you are not the database specialist, you do not make the change. You send them to the specialist. THIS SHOULD NOT REFLECT ON YOU. If it does, the problem is not with the specialist. It is with the company. And as the corporate politics specialist, it is the team lead's job to go to the company and say "what the entire fuck is this shit?" when anything like that happens. The team lead, as the specialist, should know what channels to follow and which ears to bend to most effectively defend your interests. You are, of course, welcome to try and do this yourself - I can't stop you, any more than I can stop you from making the change to the database. But if you FUCK IT UP, the specialist will have your arse over it.

[@porky1118]

I think, that's the job of a boss, not a leader.

[@cdarklock]

@@hunahpuyamamoto3964 At absolutely no time did I say to CONCEAL anything from the team. You shouldn't be hiding anything in the first damn place.

[@jimhart5797]

@Bharath G You should check out the book "Impact Players"

[@DaCyberman]

As a brand new team lead I found this video extremely helpful. My boss sent it my way to help me develop into a strong lead.

[@ContinuousDelivery]

Thanks, I am pleased that you found it helpful.

[@Martopikeur]

A Good boss you have! Typically you are promoted with no training or advice whatsoever and expected to magically figure all that stuff out

[@mhcbon4606]

"you are a great technician, lets make you a manager!" I always thought that logic was bloated.

[@ContinuousDelivery]

Yes, there is a famous idea called the "Peter Principle" - you get promoted to your level of incompetence - it explains quite a lot!

[@semenivanoff8615]

Well this may work with enough of education and mentoring

[@mhcbon4606]

@@semenivanoff8615 anything may work with enough ifs ^^^

[@RobbenBanks153]

Don’t be afraid. Your organization needs good leaders to remain viable.

[@mhzprayer]

If someone is extremely effective at working, ask them how they are managing the current management, and how it's boosting or inhibiting them. They've probably developed effective ways of dealing with current management. Might have helpful opinions on how mgmt can improve. But that doesnt suggest the individual is suitable for mgmt. If they are suitable they are probably already managing in their current role. Investigate whether they are already counseling peers, solving disputes, covering for shortcomings, etc. If not then they are probably just a good worker. Ask them if they get satisfaction from other peoples successes, or only from their own work. And dont forget to pay em a lot for doing good work.

[@jojo-pk]

This is excellent. 100% reflects my experience. Letting others do a job differently and possibly worse is hard but the only way to be effective as leader. And quite often they're not actually doing a worse job, just differently. I'm going to send this to a friend to show to newly promoted team leaders.

[@Redheadtama1]

Damn I could have really used this advice 2 years ago. I’ve been guilty of micromanaging my team far too much. Definitely have a lot to work on here. Thanks Dave for your great insights once again!

[@tongobong1]

OMG you were just like my leader 2 years ago and it was so annoying...

[@10xSRK]

Kudos to you for sharing this. I too have been guilty of this. I'm sure you have grown a lot since then. Cheers to you, and good luck.

[@ilamalihilustan22]

How did you managed to overcome micro-managing?

[@ramonennik2536]

#metoo, I'm forced into the lead developer role while I just want to be a programmer and as a lead I developed all the bad habits mentioned in his talk

[@drunktrump5209]

I appreciate your effort in joining the ongoing conversations here at KZbin. While I am not an official manager of the comment section, I know it is my role to give you the best feedback to help you be a better team member. Here are some points to consider about what you wrote: 1. It would be helpful if you could provide more specifics about the micromanaging behaviors you exhibited and particular situations where this tendency showed up. Those details would allow for more tailored and actionable advice. 2. When you say "I could have used this advice earlier," it seems to shift responsibility onto the advice not being available, rather than fully owning the micromanaging actions. Try taking complete accountability without deflection. 3. You mention having improvements to make but don't lay out any concrete plans for acting on the insights around micromanaging. Outlining your commitment to change and tangible next steps would give your words more credibility. 4. The praise of "great insights once again" comes across as over the top given the level of advice provided. Dialing back the effusive language could make the compliment seem more sincere and measured. I hope you will learn a lot from my feedback and I look forward to being here to manage your future comments. Great job doing better!

[@Metaspace2]

I used to play competitive volleyball, which is a difficult sport. A trainer once told me, "the most difficult part of Volleyball..." (me expecting something technical) "....is keeping the team's spirit high". Hence, a good lead will create and maintain a good atmosphere (also on an outside work, social level), where the members take pleasure being there, sharing, contributing.

[@littlebearjeremy]

I just joined a new team as the tech lead and have been facing some challenges that I haven't come across before. This video is so useful to clear my mind. Thank you!

[@13b78rug5h]

Sharing a little bit of context: A short time ago I was hired as a tech lead to improve the quality of our software. There are multiple problems from how projects are run to how testing refactoring is viewed, how often we have a working build, and how we decide which features to build. We have about 15+ engineers and 4+ teams and plenty of them are more junior or mid-level. One of my biggest technical hurdles so far has been to figure out how we can establish a common understanding of what code is good and what is not and how do we even evaluate that. I think pair programming is one of the best ways to do this but in 15 years of my organisations' existence this has only been tried few times and it didn't really stick. We have now started to do some pair programming in a few of our teams and some developers are liking it. In addition to this, I encouraged people to write example pieces of code and then we would mob review them in programmer meetings but this took a lot of time and people weren't really reviewing the code if we didn't asynchronously. I started to write short common patterns which I see in codebases and defining my criteria for how certain things should be accomplished or which patterns should not be used and write examples and tests for them. We then review and refine the rules for these patterns in programmer meeting so we can get into agreement about the code. During this, we also get to discuss how namings and other conventions work in this context and update them accordingly and I'm also looking into if these rules can be integrated into some static analysis tool (SonarQube) which we use for more common code issues. What would you suggest to help establish a better common understanding of what is good design or code and what is not? And how would you go on about implementing pair programming in an organisation where it isn't really done or it has been tried and considered to not work?

[@arakovskiy]

Yes, totally agree with all of that. When I was a team leader I've made some of theese mistakes. It was painful. But when you do the most you can to make it comfortable to work, you get the most grateful team ever.

[@MG-tl2vw]

This is gold. I've had many leaders and only two of them had any sense of how to deal with individuals and a team. IT is terrible in this respect.

[@barneylaurance1865]

So much in this video to agree with - the idea that making it clear that it's OK to challenge other people's thinking whatever their role (14:30) is so important - particularly for safety, security etc. It's part of crew resource management in aviation, and the similar ideas used in operating theatres - everyone has to feel they can challenge the decisions of the pilot in command or the surgeon before an unsafe situation develops.

[@steshaw6510]

Sound advice. I like to distinguish leadership from management. Most people don't need managing at all, they need help. I think of two parts of leadership. Leading from the front as in technical vision, setting an example in doing good work, and having plans/goals/focuses. And leading from behind which is helping, encouraging, understanding/empathy, sharing wisdom while being open to learning, upskilling, etc. Everyone on the team can do the second type of leadership and also contribute input to the first.

[@ContinuousDelivery]

I agree, I think "Leadership" is rarer than "Management" too.

[@KimGodard]

Fantastic insights. One of the best, most straightforward and honest presentations on managing a team (technical or otherwise) that I've come across. Very well done Dave!

[@losrobbosful]

An absolute gem about leadership. Crystal clear and on spot. It reflects my own experiences on being a team lead and also seeing other team leads failing miserably by a policy of mistrust, overcontrolling and micromanagement. Practically all projects done this way either fail or just work short term, creating a horrible atmosphere, where especially very crucial team members will leave at some point. Thank you for your powerful confirmation, Dave. I will show your video in my leadership trainings

[@ContinuousDelivery]

Thanks 😁😎

[@krishnadaskp21]

Saw this video a year ago and learned a lot. And today I have become a technical lead of a very young team. Hoping to build an efficient and happy team.

[@6957-c5k]

This is so true. My tech lead will branch out of my change and write the code her way. It got to the point where I had to just sit and watch.

[@Dackel1972]

You, sir, are a continuous source of inspiration. Thank you.

[@BrilliantMindsZw]

Wow, this is loaded, thank you. The last part "Bad news" is a killer shot, so legendary!

[@nickbarton3191]

Enjoying the channel and your measured delivery. One thing you didn't mention is developing presentation skills, to management, to customers and even the team. I was so nervous in my 20s and early 30s but as I got experience it became easier. I still prepare obsessively but deliver with ease.

[@tomjans5024]

Leading is like organising a party: "host leadership"

[@ylapitsky]

Thank you for this great video! Throughout my career I was in different positions, including Team Lead and Director of Engineering in a startup. I can personally relate to everything that you said here. One suggestion of a new topic to cover: "managing up". There are a lot of facets to this. For example, you let the team make a wrong decision and it failes, then your manager asks you about why the team failed and keeps you accountable for the failure. Or how to represent the team for the whole organization. Or making decisions about processes when most of the team is convinced by a strong voice (one of the team members) to change the process to something weird.

[@andresnexuschamarra6991]

This is very useful, early in the video it mentions "maybe you were promoted based on your technical performance", this happens all to often and is usually a huge mistake, some of the best programmers I know would make horrible leaders, some of them know this fact, others not so much. In the studio I work in we've split the career path at this point between leader and specialist, so programmers that don't want to become a lead or don't fit in that role don't feel like their career progression is capped below leadership and thats the only possible path. Even when you have the capacity and talents for it I found it often the dev may not be aware of it, or they are but still feel like they've been thrown in the water without any swimming lessons, there is a lot that an organization can and probably should do to ease the transition to this role and foster better short term results, I think this could be good material for a video of its own.

[@barneylaurance1865]

Important point about micromanagement. And I think there's a particular issue with software development around unscheduled pair programming. It's normal sometimes in pair programming to tell someone else what to do, and that's fine when it's within a pairing of equals, they both give each other instructions at times, are comfortable challenging the instructions and most importantly agreed to take instructions at that time - e.g. in the driver/navigator pattern. This can easily turn into micromanagement if a leader decides they want to pair with someone in their team and does a significant amount of navigation.

[@OverPwng]

Very good advice as usual Dave, thank you! I am precisely in a situation where I have recently taken the role of team lead, although in a very small team (I was alone and we hired 2 developers to join me as we started on a big project). I can only imagine that I am currently, as you described, a person who micro-manages their team too much, which I do through code review. However, I am racking my brains at how I can cut back and let them make mistakes but I can't seem to find where I can cut. If I see a mistake (i.e. code duplication, code maintanability, code performance, code structure/architecture), I can't just let it go through, I know the impacts this will have on the project, the risks, the future time we will lose to reworking in the future because the design didn't fit the proper design patterns. I am responsible of the result of that project and can't simply blame the lack of experience of our team members if we hit mistakes I could have had them avoid. Right now, I am doing my best to use code review as a training tool and a way to define what standards we want to use (since we are a newly created team, we have to document and choose what our own standards will be, which ends up being mostly my decision, though I try to make decisions as a team when I can). However, we are loosing huge amounts of time during the code review process in return. What do you think? Any ideas or insights for a young team leader doing their best at building up a new department while having big projects to release?

[@IvorLongarrow]

Yes, I am backing this comment because I feel the same in my daily job. How to balance this micromanagement attitude with the need of driving results?

[@JamesSmith-cm7sg]

You can't blame the lack of experience after the fact, but you can inform those above you ahead of time. Explain the capabilities of the team now and provide more realistic estimates. You have to factor in the team management time, which includes code reviews, into your estimates. Also make a list of the common mistakes you're seeing and hold coaching sessions.

[@xilconic]

Hey Octane, I can share some of my opinions and hopefully they are helpful to you. You mention you struggle with finding the balance between giving space to your developers for them to learn and the idea that you know and therefore can do better yourself. When I started as a Team Lead, I tried shifting my focus from being the person that knows better (which is something I developers in my career as a consultant) to making sure everyone around me knows better. Or to think about it from another perspective: If I'm putting my energy into making me a great developer than the team has 1 great developer. If I'm putting my energy into making N other developers great, the company now has N great developers. As a result, the latter will yield an overal better outcome for the company in the long run, possibly at the cost of short term gains. This is main guiding principle in everything I do: what are the things that are in my circle of control that makes other better at what they do. I start with stating objectives for my team members. That could be "I want all of you to ensure that all code you produce, works as intended." or "I want you to establish a set of guidelines and conventions for our team such that our software is developed in a consistent way and easily understood by all at a glance." These mission statemens are devoid from any 'implementation detail'. I'm not prescribing that people apply TDD or DDD, not am I prescribing that all fields in a class require an prefix of '_' or that Clean Architecture layering needs to be applied to the software. Sure, I know about those strategies and during a coaching or mentoring session I could demonstrate them. But I try to aim for assessing on those objectives: Can I observe that after a single feature is implemented, there are frequently bugs being reported by customers? Do I hear my developers complain about the mess someone else left in the code or that they don't understand something? Those signals trigger me to challenge my team more on those outcomes and that I want better ones. And only if they indicate they don't know how to more forward, I can point out suggestions on things that have worked well for me. As you are talking about Code Review as a training tool: What about pairing? The feedback loop can be way shorter that way and allows you to engage in a coaching dialog when you see something going wrong. "Hey, I just noticed something. You wrote this code in that particular way. How do you think the code would behave if situation X arises? Why do you think this is the case? Are you making a particular trade-off here?" I also pick up on something that sounds like you are worried about the pressure of delivering big projects on time with an inexperienced team. I believe that can be quite a tough situation. Especially with a new team, you hardly have any history to refer back to in order to make extrapolations about if a big project is viable given the current capacity. Dave has a nice video covering this from an Agile perspective: when dealing with a project you can either fix scope and don't know when it's going to be completely done or you can fix the timeline and being unable to guarantee a scope of features. Trying to fix both typically leads to problems (often people will then be forced to cut in scope, causing the creation of a product at risk of no-one wanting to use it). I personally believe that fixing quality and keeping scope flexible ensures that given the limited (time)budget you are able to produce the best feasible product imaginable, given proper opportunity cost management.

[@Xaminn]

@@xilconic Thanks for a detailed response. I'm not in a role such as this. However, I will sample what I can for my own patterns. Cheers.

[@0xmnkhod]

hi , im facing the same problem and trying to solve this with a community of tech leads and cto's currently just inviting people and want them to share their experience. Thinking of having the community on telegram , would really want u in the telegram community chat.

[@MrMattberry1]

I am very picky on code reviews and I like everyone being picky on my code. Everyone in the team does all the code reviews. We feel this is a good learning platform.

[@petersuvara]

One the best leadership videos I have seen!

[@TomTrval]

These are good tips for all types of leaders , not just the technical ones :) Thank you

[@ContinuousDelivery]

You're very welcome!

[@archi-mendel]

Thanks for your content. You sound like a great leader, and as an engineer manager myself, I am happy that I can learn from you.

[@shezzor]

Some great advice and content here Dave and a topic that isn't generally discussed on KZbin.

[@katnisskatiebell8681]

One of the honest videos I’ve seen, thanks for sharing your tips! 🙏

[@TrueGrantsta]

Your anecdote about hiring & training smart young people makes me ask: How do you handle coming in as the lead of a pre-existing team, and some of the members have problems, or simply are not very good?

[@1oglop1]

That's a great question. I came to the team where Senior developers do not write tests I find it hard to trust the results of their work because I cannot verify for potential side effects caused by clicking a button.

[@Peter_Siri]

I feel very helped by this, Mr. Farley, as I'm a college student preparing to split people into groups and have them make their own games by the end of the semester.

[@ibm2187]

I really needed this, I’ve just been asked to lead a mobile team. Thank you very much

[@MohamedSamyAlRabbani]

So here is my general criticism, and it is not just you, When someone says, let them do a worse job and leave it at that, we cause a bigger problem because we are leaving it subjective, and that is the root of all dysfunction.I will say, do it however you want as long as it meets these minumum requirements, and those are quantifiable, testable and applicable to the use case. Now., I will still get the person who wants to protect the team by leaving everything vague, I will just make sure there are tests put in place so we know, very clearly, if the system,, including the individual components is getting better or worse. To be clear, if my way is better but the difference is so small that it doesn't matter, I won't care, like a 100 millisecond task taking an extra 10 milliseconds, but if it is something that will cause us to miss a deadline or extra maintennace and system failures, I will add it to the testing suite and then I won't have to argue with anyone.

[@lukystreik]

one of your best videos. Makes me thinking about my current role. Many’s thanks for sharing your knowledge to us.

[@ContinuousDelivery]

My pleasure!

[@loquela]

A sober and balanced perspective. Good work.

[@ContinuousDelivery]

Thanks :)

[@MarcellodeSales]

The hardest thing to do is to remove Egos... especial one's self... thank you for the explanation...

[@farhanyousaf5616]

This comes at the right time in my career. Completely agree with the advice here.

[@StefanSchade721229]

I am kind of managing a team and I define the broader direction (Not independently of course but advised by my team and within the department's objectives. I do contribute, but regard myself as a junior dev in the team (I would not have the time nor the experience micromanaging them) I often promt the team to decide on an issue, but leave the decision to them

[@skipodap1]

Thanks for this video. I’m a team lead of a team of 8. I’ve found myself being a “Joe” at times. I think it comes from a good place... trying to always pair up with people and teach test driven development, help unblock things, encourage small batches... But my approach has been too hands on, demanding too high of technical excellence, and sometimes , I’m afraid... I’ve robbed others of their autonomy (not to mention, exhausted myself). This is definitely not my intention. And that’s not how I want to be. Like you said, it takes time to get the balance right. It’s Monday today and I’m gonna try this week differently because of this video. Thanks Again, Dave

[@ContinuousDelivery]

Good luck, let us know how you get on.

[@ilamalihilustan22]

What did you tried differently?

[@Sad-Lemon]

I keep watching your videos like crazy - I think I've found a mentor :) Thanks for sharing valuable content!

[@thomascking]

"People learn from making their own mistakes" - this was the main issue I had when doing my PhD many years ago. One of my supervisors wouldn't let me make my own own mistakes, or worse, made me make their mistakes (they would have disagreed, of course). I would like to say this advice is also really useful if you're not a leader. I'm not one, but I sometimes have to find a balance when offering guidance. Particularly, when another team member is trying something that I THINK I know more about. Sometimes by letting someone else properly own a problem, the knowledge will properly embed in their brain. So, it's often better not to say "I'd do it like this" all of the time. Also, because I can't say say my way is "right". The funny thing is, all of the gripes I've had with others being overly-bearing on me, I am now trying to force myself not to do as well.

[@PeterPerhac]

Very good video. This is a must-watch video for any fresh team lead. In my experience micro managing is mostly done by insecure people new to their role. Also, what seems to have been overlooked in this video is that sometimes people become leads not because they did a good job, but out of necessity. Against their own will even, sometimes. Sometimes it's political, sometimes lack of a better alternative, sometimes simply because they have the most knowledge of the system and have "outlasted" everyone else, they become "lead" by default.

[@captain-hooked]

Great video, your audio was clear and easy to understand, I liked the visual aids you included and think that the background style you use fits the type of videos you create very well. I look forward to the next one!

[@sainag11]

I'm really glad I came across this video, It's really helpful.

[@faketrump3605]

Best advice I've heard on team leading. Thanks a lot for sharing.

[@einfacherkerl3279]

actually, it depends. I wish if real world were so simple to be able to apply the concepts presented in the video. I present a very different situation. I'm working on a MVP. it's my own work and I have few developers that I'm paying. sometimes they produce good work, sometimes they don't. problem is when I see constantly bad code churned in, i have to step in and make things right.."the joe's way". developers may come and may leave. what i dont want is a piece of code that becomes maintenance nightmare and No, i don't have the world's best developers I'm not a company, i dont have HR, i dont have team leads, just a bunch of devs that I manage. so i have to be in several roles. a dev can say it's not his problem. correct, it's my problem until i achieve success. I don't micromanage but i can't give them a free hand either and run out of funds later. oh and by the way, I 💕 pink panther!

[@percurious]

Thanks for this great overview of yout thoughts about a very important topic. The most important thing i would add to it is: A good developer spends significant amounts of time on (personal) learning of new techniques and technologies as well as on furthering the team performance. A team lead still will want to be doing some of the former and a lot of the letter. But he has to invest even more time in understanding his new role, read and research about leadership and get better and better in that field too. And at some point, he will idealy even start looking for talent and start mentoring and coaching about these new skills, so the next "newly appointed teamlead" will be a little better prepared and a little less "thrown intonthe cold water". Thanks again and best regards Simon

[@ddanielsandberg]

There is this "old" saying in the IT industry: - On new and intermediate developers bookshelf most books is about frameworks, languages and technology. - On new and intermediate managers bookshelf most books is about processes, leadership and planning. - On senior developers and managers bookshelf most books is about applied psychology.

[@percurious]

@@ddanielsandberg Hadn't heard that one yet, but i like it. From my experience i would say that a new (in regard to this topic, allbeit it might well be 50 years old), the books are probably shifted down one category, in an intermediate organisation its about what the saying describes. A senior organisation should in my opinion shift those up one category, at least for the intermediate people. And sorryfully, while i have not seen even a junior dev without a few books in reach, there seems to be many a manager who has never heard of leadership - not to speaknof reading about psychology.

[@percurious]

@@ddanielsandberg p.s. all of the leadership books i have seen, that were any good, realy were psychology books for a significant part.

[@rogermouton2273]

Exactly, In my experience, whenever managers and team leads get into the detail, they just fuck things up royally. When you're solving complex technical problems, only the people directly working on it understand it properly, what the best path forward is, etc. When the team lead decides to get involved, it simply infuriates all concerned, leads to huge amounts of wasted time and just demoralises people who want to actually solve problems, rather than faff about with whatever it is that the pointy-haired micromanager wants.

[@rfpdl]

I really like this content. Thank you very much..

[@adalbertomarincoca5563]

Thanks for sharing all you experiences.

[@barneylaurance1865]

I think a lot of leaders would agree that people need to learn from their mistakes - but sadly they often don't want that to happen on company time or with the company code. There's sometimes an attitude that if more junior people want to make their own mistakes they should either do it on side projects on their own time, or wait until they get the chance to lead a project.

[@ChristopherRockhill]

These videos are so informative and educational. Thank you

[@ddanielsandberg]

I feel like this video is my "fault". I'm sorry for being so bitter and angry in the comments on previous videos; especially one discussion very relatable to this video. No excuses, I'm just a bit tired of this industry having forgotten how to introspect and learn. I guess I too need to learn how to deal with my impatience and frustration. Thank you Dave for being such a sane and calm voice in this industry.

[@EngineeringVignettes]

Even your profile pic is mad...

[@ddanielsandberg]

@@EngineeringVignettes Haha, yes! I'm not *completely* unaware of who I am. :D

[@kamertonaudiophileplayer847]

It is good to live for several months in India and China. It will help you to manage the team better. And your point is priceless that a team lead shouldn't have the best expertise, and should trust your team members. Luckily, I had only one case when a lead has an impression it should be the best. It was a nightmare, I couldn't digest his micromanagement style and always a fear to be behind.

[@ilamalihilustan22]

What's so special to learn in India or China?

[@kamertonaudiophileplayer847]

@@ilamalihilustan22 How to work long hours and how to escape from burning out.

[@ilamalihilustan22]

@@kamertonaudiophileplayer847 How's it possible to work long hours and not burnout at the same time? Would love to hear your experience

[@kamertonaudiophileplayer847]

@@ilamalihilustan22 Socializing is the key from my observation. If you try to handle everything yourself, then more likely you will finish in a hospital. It is major difference between India and US, if people are alone in US, they surrounded by others in India.

[@ilamalihilustan22]

@@kamertonaudiophileplayer847 Does this mean that people in US are generally solo workers and in India there's a lot of teamwork?

[@Aragir]

Thank you for the amazing video. Make more of this please. What would you say are some general base "industry standards"? (That still respect each way of working) Maybe peer review, what else?

[@s.z.9579]

Great content that mirrors my own experience completely! Good leadership, in my opinion, is closely related to child education. Giving other people the chance to grow, based on the point they start from. Providing guidance, help and support, but not incapacitating others.

[@terryparrott1771]

To start, thank you for your channel. Finally, useful information on the subject of development. I strongly agree with your take on the subject of team development. I firmly believe that you only really learn from your failures and not your successes. In fact I like to say, your successes are the fruits of your failures. So if you don't let a new team member the chance to fall flat on their face, how in the world could you ever expect them to succeed? My dad would often say, "The school of hard knocks, the tuition is high, but the lessons learned, last forever." Thank you for the great channel.

[@ContinuousDelivery]

Thanks

[@MichaelRuddock]

Joe was lost overboard when he "accidentally" tripped on Dave's rope.

[@giladbr]

Excellent video, superb points. All nails hit on the head there 😎

[@Thomas-1023]

This is a true gem. I recently enjoyed a similar book, and it was a true gem. "The Hidden Empire: Inside the Private Worlds of Elite CEOs" by Adam Skylight

[@hawke5311]

Seems like the metaphor of leader as Host comes from: Host - Six new roles of engagement by Mark McKergow and Helen Bailey ISBN-10 ‏ : ‎ 0954974980 ISBN-13 ‏ : ‎ 978-0954974985

[@johndoe1909]

Been teamleading for nearly 20 years... i really get where he us coming from, my job is to optimize team performance and cohesion. Sure i understand the technology and know my way around code. But my team should do that. Not me.

[@somjuzernejm]

Great analogy with hosting a party

[@AlexanderMatosOlivo]

Thank you so much for all your valuable advises and recommendations, I just bought your book and I am very grateful because I'm facing a new role as System Architect, please keep on the excellent videos and books, cheers

[@ContinuousDelivery]

Thanks, I am pleased that you find them helpful.

[@akitmentorconsultant4696]

"Remote-Control Programming" - this is first what I am usually trying to fix in communication between developers and clients. It is really better to say "what are you want" instead "how to do it”.

[@rzozaya1969]

Dave, I really liked this video (not that the others were bad, they're great as well). Keep up the good work!

[@ContinuousDelivery]

Thanks 😎

[@lukedarmanin3382]

Thank you for such great insights.

[@garth-baker-blog]

I really enjoy these vids you put together 😁 Thank you!

[@ContinuousDelivery]

Thanks 😎

[@chiaradiamarcelo]

Hi Dave, great content. Out of curiosity, can this also be found in one of your books?

[@ContinuousDelivery]

No, I haven’t written about this stuff, though I may, one day.

[@serobification]

Dave, that Video ist certainly one of your best ever! I am always amazed on how your words match my gut feeling. :-)

[@PiersHarding]

Thanks. This was very useful.

[@CerealChicken]

Thanks for the great advice

[@coldblaze100]

This is platinum content

[@EngineeringVignettes]

Thanks Dave, good tips. I like the one about blogging weekly updates. Other aspects of a team lead can be the admin stuff, approving time off or purchase requests. Something that was new to me in my current role as a team lead. Cheers,

[@erniea5843]

New to this channel, Good stuff 👍

[@ContinuousDelivery]

Thanks and welcome

[@bernardobuffa2391]

pure gold. Thank you very much.

[@ContinuousDelivery]

You're very welcome!

[@SolidousMdz]

Thank you, a lot of good knowledge here.

[@WouterSimonsPlus]

Thanks for this talk, an important message about becoming a leader! In one part you speak about consensus. In my experience a consent based model works better. We don't have to agree, however, any significant objections have to be handled before we can move forward as a team. It's a small but significant difference in my experience. I like to facilitate consent gathering without putting too much of my own opinion into it and be really careful to check with myself if I really object to a proposal or if I'd just do it differently.

[@BittermanAndy]

Interesting distinction. But I think if you provide the opportunity to seek consensus (which you should), and let all voices be heard and listened to with respect and an open mind, but then when the decision is made people DON'T consent, then they have an inaccurate understanding of what it means to be an employee. If they won't buy into the consensus even if they have reservations, they should find another job. Otherwise people will learn that they just have to say "I don't consent to any other way but mine" and the discussion drags on and on.

[@WouterSimonsPlus]

@@BittermanAndy this is kind of my point. To object to something in the consent model you have to be able to clearly formulate an objection. We ask for "strong objections" to highlight there should not simply be some minor gripes holding back decision making processes. Consensus is harder to obtain in my experience (as in we all agree) than consent (there are no strong objections). And I personally like the fact that only clearly formulated objections can hold back a decision.

[@jcuervas]

Really nice content, thank you

[@filovirus1]

thank you for sharing. this is worth repeated viewing. saved to my watch-later section

[@Metaspace2]

"I'm English, therefore it's nearly as difficult for me telling people they are doing a good job as telling them they are doing a bad job" :-D :-D :-D

[@madiyarabdukhashimov8570]

I wish you made this video earlier. I had nearly the same situations and conditions. Thanks for video)

[@ContinuousDelivery]

Glad it was helpful!

[@redwrath5]

Hi Dave, I'm kinda at a loss at this advice. If I have been given a MR as a tech lead and that MR has allot of code duplication in it. Are you saying that I should not point it out and ask that person to improve it? I guess I'm just at a loss for where I'm supposed to draw the line, but I guess as with all things the correct answer is somewhere in the middle.

[@edwardroh89]

I believe it's a balance. I was on a team where my lead and other members followed particular rules so closely, that I would get comments on my MR about very minor things and at certain points the decisions were so detailed that it felt at points subjective. I hated it. I felt constrained, while I understood the importance of code maintenance and cleanliness and the decisions made sense...however it felt nearly suffocating. Every little thing felt micromanaged when it came to code, even though they weren't micromanaging me from a work perspective. As a lead now, I always look at my team members MR and point out the most obvious problems and consider minor things as suggestions. I always look to let them know what they can improve but also more importantly what I liked about their MR. My view now is to empower my team members to make smart decisions that loosely follow code rules we made prior for consistency loosely but also allow them to make decisions if those rules are meant to be broken in certain cases. It's about building team members to be independent and self problem solvers to be able to solve their own issues instead of them relying on me or what I prefer

[@ContinuousDelivery]

Yes, horribly difficult to give precise advice, this is so subjective, but you have to be sensitive. On one hand you certainly want to take opportunities to offer guidance, on the other you have to be careful not to switch-off learning for someone as Edward described. How to tell? I would ask myself, am I offering this advice because of technical purity, or am I offering it yo help my team-mate to learn? How you offer the advice matters too. Maybe focus on the learning opportunity rather than on the code itself.

[@barneylaurance1865]

I think it depends on whether the MR (I assume this is merge request, roughly the same as pull request) is either below minimum acceptable standards, or alternatively whether they have a genuinely equal chance to point things out in your MRs. If it's not below minimum standards then maybe your review could comment on things you think could be improved, but you don't necessarily have to ask them to improve it - they might decide that either they don't agree that it's an improvement, or that they don't think it's the best immediate use of their time to change it. And depending on the size of the team I don't think the lead should always have to review everything - so maybe comment on things you think could be improved on those MRs that you do review, but let fixable DX problems slide if you happen to see them in MRs that someone else reviewed.

[@redwrath5]

Thanks all. I'll mull this over.

[@JamesSmith-cm7sg]

@@redwrath5 Changes that don't meet quality standards must be corrected (constructively of course). There's no way around that. For changes that are OK but not great, i find it's better to give the developer a challenge rather than leaving a standard comment, or worse, talking down to them. Something like, "I feel like with some refactoring we could improve the quality of this change - do you have any ideas?". 9 times out of 10 you'll end up in a back and fourth exchange of ideas with the developer and achieve the result you're looking for "together".

[@trud811]

Interesting topic. One question - How do you measure your progress/success/performance as a Team Leader? Is it a standard way - the project you are working on delivered on time with the required budger or some other way?

[@ContinuousDelivery]

I think "On time, on budget" are pretty poor metrics of success, but I am not sure that I have a simple answer. My usual "go to" metrics are Stability and Throughput. Stability measures "what is the quality of the work that we produce", based on the rate that we introduce defects when we make changes and how long it takes us to recover from those defects once we find them. Throughput measures "how efficient are we at producing software of that quality", based on measures of "time from commit to releasable" and "frequency of release". If your team is scoring well on these metrics, you are doing well as a leader, at least from the orgs point of view because good scores in these are heavily correlated with good commercial and technical performance. More subjectively, do you help the team to grow as individuals and as a team?

[@dannyvopalecky1106]

Dave, thanks for the valuable content. I've been a team lead for the past 2 months so that's helpful. However, in this particular video, the moving background was very distracting and hard to watch.

[@kurtmueller2089]

Fantastic advice. Thank you.

[@AmedeeVanGasse]

You forgot option 3, saying "I don't want to lead the team. I want to continue doing what I am really good at". Which is what I answered when I was asked this question. So someone else was chosen to lead the team. Someone with less technical skills, who was now in a power position to micromanage. I got demotivated, talked to HR, asked for a different position within the company (and was refused several times). Some time later I was fired. A few weeks ago I noticed that my former employer has a job opening with exactly the job description that I asked to do. What should I learn from this? When asked to lead a team, accept, because if you refuse, a lesser person will frak up the team?

[@ilamalihilustan22]

Why did you got fired if you were performing well?

[@AmedeeVanGasse]

@@ilamalihilustan22 the person in the power position to micromanage. That's what happened. If you ever experienced a micromanager then you wouldn't need to ask.

[@mhcbon4606]

men, i wish i had you as teacher while i was in school...

[@SuperZartok]

very good points !

[@carolheinzig666]

really insightful

[@lucavalentino]

Thanks for your great videos! I'm really surprised to find someone on KZbin who matches perfectly my software development culture and ideas. Thanks for supporting me in convincing people to embrace the XP practices and agile culture (not the one coming out of certifications though). I struggle so much to make people aware of the power of XP...and of the beauty of Smalltalk:-). Would love to meet you once and have a conversation

[@Heart0rHead]

How to balance allowance for mistakes and not letting them into production?

[@ChadEdge]

Thank you, Dave! As a manager of mixed developers and teams this video really helps me refocus. Further, this video really helps (well, I hope it helps) two developers I’m grooming for lead roles.

[@WelcomeWithinMyDream]

Very good video, thanks! I don't however agree with the recruiting strategy used. Not employing medium experienced engineers. Imagine if every company had the same mentality. First of all how do you assess the medium experience criteria? Compared to what (above juniors but under experts)? Furthermore, the juniors that you employ and train, at one point the will become medium experienced engineers. If they decide to leave, who will employ them? Assuming all companies implement the same mentality. Then based on the same idea, how will Medium engineers become experts so they fit the recruiting criteria? Just an idea.

[@muskduh]

Thanks very much!

[@Pedritox0953]

Wonderful talk

[@theTeslaFalcon]

Hard to become a "team lead" when my biggest team was 1.

[@Xaminn]

You are always the team lead!

[@thiscommentsdeleted]

Same team size here. My team's stupidity is made up by its motivation.

[@Xaminn]

@@thiscommentsdeleted If you can withstand the journey alone, imagine your pace when others arrive!

[@dwaynerobare1153]

Excellent!