A Guide To Managing Technical Teams
Вставка
- Опубліковано 15 чер 2021
- Software engineering is not just about the code. Managing Technical Teams is a different skill to software development. It is not about telling everyone else what to do. Leading software development teams requires a mix of technical and social skills. Technical Team Managers, Technical Leads, Project Management and software development leaders of all kinds share the goal of amplifying the effectiveness of the team as a whole.
In this episode, Dave Farley of Continuous Delivery offers his advice on leading software development teams. How do you make the step from developer to manager? How do you deal with difficult situations and conversations? What are some of the commonest mistakes that people starting out in team leadership often make?
-------------------------------------------------------------------------------------
📚 BOOKS:
📖 Dave’s NEW BOOK "Modern Software Engineering" is now available on
Kindle ➡️ amzn.to/3DwdwT3
(Paperback version available soon)
In this book, Dave brings together his ideas and proven techniques to describe a durable, coherent and foundational approach to effective software development, for programmers, managers and technical leads, at all levels of experience.
📖 "Continuous Delivery Pipelines" by Dave Farley
paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble
➡️ amzn.to/2WxRYmx
-------------------------------------------------------------------------------------
Also from Dave:
🎓 CD TRAINING COURSES ➡️ bit.ly/DFTraining
📧 JOIN CD MAIL LIST ➡️ bit.ly/MailListCD
to get regular updates, advice and offers from Dave and Continuous Delivery!
-------------------------------------------------------------------------------------
CHANNEL SPONSORS:
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ www.equalexperts.com/
Harness helps engineers and developers simplify and scale CI/CD, Feature Flags and Cloud Cost Management with an AI-powered platform for software delivery. ➡️ bit.ly/3Cfx3qI
Octopus are the makers of Octopus Deploy the single place for your team to manage releases, automate deployments, and automate the runbooks that keep your software operating. ➡️ octopus.com/
SpecFlow Behavior Driven Development for .NET SpecFlow helps teams bind automation to feature files and share the resulting examples as Living Documentation across the team and stakeholders. ➡️ go.specflow.org/dave_farley - Наука та технологія
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
Leading is like organising a party: "host leadership"
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.
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?
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!
You, sir, are a continuous source of inspiration. Thank you.
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.
Some great advice and content here Dave and a topic that isn't generally discussed on UA-cam.
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.
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.
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!
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 UA-cam. 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!
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 comes at the right time in my career. Completely agree with the advice here.
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.
Best advice I've heard on team leading. Thanks a lot for sharing.
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.
Thanks for sharing all you experiences.
One the best leadership videos I have seen!
I really needed this, I’ve just been asked to lead a mobile team. Thank you very much
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!
As a sbd who was briefly a leader in a team (not technical tho) I gotta say all of it is very good advice and pretty universal, not only for tech teams
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,
One of the honest videos I’ve seen, thanks for sharing your tips! 🙏
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.
Joe was lost overboard when he "accidentally" tripped on Dave's rope.
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.
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.
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 keep watching your videos like crazy - I think I've found a mentor :)
Thanks for sharing valuable content!
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.
These videos are so informative and educational. Thank you
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!
Thank you, a lot of good knowledge here.
Great analogy with hosting a party
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!
Thanks for the great advice
I'm really glad I came across this video, It's really helpful.
Fantastic advice. Thank you.
Thanks for your great videos! I'm really surprised to find someone on UA-cam 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 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.
Thank you for such great insights.
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
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 😁😎
"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.
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.
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 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.
really insightful
The hardest thing to do is to remove Egos... especial one's self... thank you for the explanation...
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.
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?
pure gold. Thank you very much.
You're very welcome!
I really enjoy these vids you put together 😁
Thank you!
Thanks 😎
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.
A sober and balanced perspective. Good work.
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.
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
Really nice content, thank you
I really like this content. Thank you very much..
Dave, I really liked this video (not that the others were bad, they're great as well). Keep up the good work!
Thanks 😎
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 :)
Dave, that Video ist certainly one of your best ever! I am always amazed on how your words match my gut feeling. :-)
These are good tips for all types of leaders , not just the technical ones :) Thank you
You're very welcome!
one of your best videos. Makes me thinking about my current role.
Many’s thanks for sharing your knowledge to us.
My pleasure!
Excellent video, superb points. All nails hit on the head there 😎
Thanks. This was very useful.
This is platinum content
Excellent!
Thanks very much!
Brilliant!
Great video. Thanks
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 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.
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
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?
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
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.
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.
thank you for sharing. this is worth repeated viewing. saved to my watch-later section
Great content!
men, i wish i had you as teacher while i was in school...
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.
Wonderful talk
very good points !
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.
I wish you made this video earlier. I had nearly the same situations and conditions. Thanks for video)
Glad it was helpful!
New to this channel, Good stuff 👍
Thanks and welcome
"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
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
thank you
"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”.
I was expecting Viera and Keane once you started talking about captains :)
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?
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?
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.