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
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.
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.
@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.
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.
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!
#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
I appreciate your effort in joining the ongoing conversations here at RUclips. 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!
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.
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?
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.
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!
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!
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.
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.
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.
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.
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.
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.
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.
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
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?
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.
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.
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.
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!
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?
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.
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.
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.
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.
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.
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
"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.
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.
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.
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
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!
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.
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.
"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”.
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.
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
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.
@@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.
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
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.
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
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?
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.
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.
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
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.
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,
When I promote a team lead, it’s not because I want them to do anything else, but usually to recognise the leadership they’ve already demonstrated. Sometimes getting the new leader to keep doing the same things that got them promoted, rather than “being a team lead” is a challenge!
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 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.
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 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.
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?
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?
I've often thought that a team lead should be a person who has a good understanding of the work and can slice it up manageable pieces to individuals that can be completed in a month or so. I dislike being placed on a very large team and more or less be told to make myself useful. That doesn't feel like anyone is leading.
Great video! 👍 I've a lot of similar experiences and views, even if not from the same field. Having a deep knowledge about something and then trying to lead relatively inexperienced team members around that "something" is a horrendous experience, at least for myself. Constant fighting with myself that should I say something or not, especially when I'm seeing wrong paths taken. It's not that I don't like to teach, in fact I like it very much, but I can only feel it inside me how annoying I'm becoming for them. Also I find myself not giving enough positive feedback, which definitely is something I need to work on harder. Thankfully I've also got to work with relatively experienced members and get to just enjoy the ride. Members work with their tasks and your biggest task is to keep theirs tasks going towards the common goal and observe for technical conflicts. That's something I'd like to get used to more. Also I love it if everyone in the team wants truly to be even a little bit challenged about their decisions. So much learning will happen in such team for everyone. Oh, and I think it just clicked me what you meant by not recruiting "medium-level" experienced people. I think I understand very well what led to that decision :)
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.
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.
@@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.
Thanks for your great videos! I'm really surprised to find someone on RUclips 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
I'm kind of the leader in my team, since I'm the only employed programmer, and everyone else is an intern. I normally let them do, what they want. When I see, they are doing something stupid, I'll tell them, how I would do it, or how they could improve the code. If they don't fix it, I'll probably fix it myself some time later, at least when I have to work with the code. It doesn't make too much sense to force a programming style onto them, when they will just stay for a few months. It will just slow them down.
![Jack Harlow - Hello Miss Johnson [Official Music Video]](http://i.ytimg.com/vi/Q86_nlRoIGw/mqdefault.jpg)
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
"you are a great technician, lets make you a manager!" I always thought that logic was bloated.
Yes, there is a famous idea called the "Peter Principle" - you get promoted to your level of incompetence - it explains quite a lot!
Well this may work with enough of education and mentoring
@@semenivanoff8615 anything may work with enough ifs ^^^
Don’t be afraid. Your organization needs good leaders to remain viable.
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.
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.
@Barney Laurence Oh, I know exactly how to handle a company like that. "Here is my two weeks' notice."
@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.
I think, that's the job of a boss, not a leader.
@@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.
@Bharath G You should check out the book "Impact Players"
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.
Thanks, I am pleased that you found it helpful.
A Good boss you have! Typically you are promoted with no training or advice whatsoever and expected to magically figure all that stuff out
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.
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!
OMG you were just like my leader 2 years ago and it was so annoying...
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.
How did you managed to overcome micro-managing?
#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
I appreciate your effort in joining the ongoing conversations here at RUclips. 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!
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.
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?
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.
I agree, I think "Leadership" is rarer than "Management" too.
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!
Leading is like organising a party: "host leadership"
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.
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!
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.
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.
You, sir, are a continuous source of inspiration. Thank you.
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.
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.
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.
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.
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.
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.
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
Thanks 😁😎
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?
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.
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.
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.
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!
Wow, this is loaded, thank you. The last part "Bad news" is a killer shot, so legendary!
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?
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?
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.
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.
@@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.
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.
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.
Some great advice and content here Dave and a topic that isn't generally discussed on RUclips.
Joe was lost overboard when he "accidentally" tripped on Dave's rope.
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.
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
one of your best videos. Makes me thinking about my current role.
Many’s thanks for sharing your knowledge to us.
My pleasure!
These are good tips for all types of leaders , not just the technical ones :) Thank you
You're very welcome!
One the best leadership videos I have seen!
"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.
The hardest thing to do is to remove Egos... especial one's self... thank you for the explanation...
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.
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.
I really needed this, I’ve just been asked to lead a mobile team. Thank you very much
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.
This comes at the right time in my career. Completely agree with the advice here.
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
Good luck, let us know how you get on.
What did you tried differently?
A sober and balanced perspective. Good work.
Thanks :)
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!
One of the honest videos I’ve seen, thanks for sharing your tips! 🙏
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.
Even your profile pic is mad...
@@EngineeringVignettes Haha, yes! I'm not *completely* unaware of who I am. :D
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.
"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”.
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.
Thanks
Best advice I've heard on team leading. Thanks a lot for sharing.
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
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.
@@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.
@@ddanielsandberg p.s. all of the leadership books i have seen, that were any good, realy were psychology books for a significant part.
I keep watching your videos like crazy - I think I've found a mentor :)
Thanks for sharing valuable content!
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
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.
These videos are so informative and educational. Thank you
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
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?
This is platinum content
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.
Thanks for sharing all you experiences.
I'm really glad I came across this video, It's really helpful.
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.
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
Thanks, I am pleased that you find them helpful.
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.
Great analogy with hosting a party
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,
Hard to become a "team lead" when my biggest team was 1.
You are always the team lead!
Same team size here. My team's stupidity is made up by its motivation.
@@daveogfans413 If you can withstand the journey alone, imagine your pace when others arrive!
When I promote a team lead, it’s not because I want them to do anything else, but usually to recognise the leadership they’ve already demonstrated.
Sometimes getting the new leader to keep doing the same things that got them promoted, rather than “being a team lead” is a challenge!
I really like this content. Thank you very much..
Unfortunately, most companies do not want leaders. They want efficient administrators speezing as much juice out of their resources as possible.
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.
What's so special to learn in India or China?
@@ilamalihilustan22 How to work long hours and how to escape from burning out.
@@kamertonaudiophileplayer847 How's it possible to work long hours and not burnout at the same time? Would love to hear your experience
@@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.
@@kamertonaudiophileplayer847 Does this mean that people in US are generally solo workers and in India there's a lot of teamwork?
"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
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?
Why did you got fired if you were performing well?
@@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.
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?
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?
I've often thought that a team lead should be a person who has a good understanding of the work and can slice it up manageable pieces to individuals that can be completed in a month or so. I dislike being placed on a very large team and more or less be told to make myself useful. That doesn't feel like anyone is leading.
Great video! 👍 I've a lot of similar experiences and views, even if not from the same field.
Having a deep knowledge about something and then trying to lead relatively inexperienced team members around that "something" is a horrendous experience, at least for myself. Constant fighting with myself that should I say something or not, especially when I'm seeing wrong paths taken. It's not that I don't like to teach, in fact I like it very much, but I can only feel it inside me how annoying I'm becoming for them. Also I find myself not giving enough positive feedback, which definitely is something I need to work on harder.
Thankfully I've also got to work with relatively experienced members and get to just enjoy the ride. Members work with their tasks and your biggest task is to keep theirs tasks going towards the common goal and observe for technical conflicts. That's something I'd like to get used to more. Also I love it if everyone in the team wants truly to be even a little bit challenged about their decisions. So much learning will happen in such team for everyone.
Oh, and I think it just clicked me what you meant by not recruiting "medium-level" experienced people. I think I understand very well what led to that decision :)
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.
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.
@@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.
Dave, I really liked this video (not that the others were bad, they're great as well). Keep up the good work!
Thanks 😎
makes me wonder how mid level or senior people can get hired on technical teams.
pure gold. Thank you very much.
You're very welcome!
I really enjoy these vids you put together 😁
Thank you!
Thanks 😎
Thank you, a lot of good knowledge here.
men, i wish i had you as teacher while i was in school...
Thank you for such great insights.
Hi Dave, great content. Out of curiosity, can this also be found in one of your books?
No, I haven’t written about this stuff, though I may, one day.
Really nice content, thank you
Thanks for your great videos! I'm really surprised to find someone on RUclips 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
I'm kind of the leader in my team, since I'm the only employed programmer, and everyone else is an intern. I normally let them do, what they want. When I see, they are doing something stupid, I'll tell them, how I would do it, or how they could improve the code. If they don't fix it, I'll probably fix it myself some time later, at least when I have to work with the code.
It doesn't make too much sense to force a programming style onto them, when they will just stay for a few months. It will just slow them down.
Thanks for the great advice
The key idea is that the lead should "amplify" the team.
Thanks. This was very useful.
Dave, that Video ist certainly one of your best ever! I am always amazed on how your words match my gut feeling. :-)
Fantastic advice. Thank you.
How to balance allowance for mistakes and not letting them into production?
I wish you made this video earlier. I had nearly the same situations and conditions. Thanks for video)
Glad it was helpful!
Excellent video, superb points. All nails hit on the head there 😎
I was expecting Viera and Keane once you started talking about captains :)