241–250 of 259 posts
Share new and fresh ideas with them and be attentive when they share time-tested techniques and horror stories.
The horror stories will teach as much, if not more, than all of the above.
Assume that, for the people on your team, work is a #4 or #5 priority. And there's nothing wrong with this, as long as they're giving you a solid 80-90% effort during working hours. If you ask them to put work ahead of family or faith or rest, or if you somehow expect more than 100% effort from them, you're going to drive away the ones who have other options. And the reason they have other options is because they're…
The truth is that the "best ones" are often obsessed with their work and endure painful tradeoffs in their lives, for example their family lives, because of it. People who do great work tend to think about their work all the time. No one thinks about their fourth priority all the time.
I have observed an inverse correlation between consistent, unasked overtime and ability.
1. Checklists make everything easier. What needs to be in the checklists should be the most common issues that come up during code review or have been related to defects that made it past the dev environment.
2. Good agile documentation means all business rules/application behavior requirements should be in the story/task and in a centralized wiki. This makes it possible for new team members to familiarize themselves with application behavior quickly, and that list of behaviors is also the documentation on what needs to be tested so QA can implement integration and regression tests.
3. Every major code review needs an organized explanation of code changes per business rule. I've got my team using a OneNote where they initially write down each stories business rules at a high level for non-technical people in a list format and add sub items that describe an architectural overview of changes like design patterns and technologies used, and an addition sub level briefly describing code changes. I also have them provide links to an articles they used to make decisions or that describe design patterns used rather than needing to rewrite them. This rarely takes longer than an hour for a large story and it provides a semantic map between business logic and technical terminology for non-technical people and a sort of historical stream of consciousness that can be looked back at to get a feel for the history and direction for a given project.
4. Assess how team members are doing with technologies they use and get them whatever training they need.
5. No matter how experienced a developer might be before they join your team, new team members should always start out by getting the project to run and fixing bugs. Expecting too much too fast is a guaranteed way to lose high quality talent.
6. Always keep your ego out of everything and if someone is getting defensive about code, remind them that there is no such thing as perfect code. There is always room for improvement, and the focus on any changes or development/architectural decisions must always be about the potential future cost of each decision. Principals like Dry and Solid are important, but over implementing them will always result in difficult to maintain code. Abstraction is only good if it doesn't lock you into a design pattern that might not apply to the future state of all application behaviors you might need in the future. Also, reflection based code is cool to implement and a huge pain to get right let alone maintain or update.
7. Always beware implementing anything you're excited about. Code should always be focused on efficiency and maintainability, never on how cool or familiar a specific tool is. This is sort the same as keeping your ego out, but more about keeping your excitement out of things.
8. Developers should talk to customers, and logging should be implemented in ways that enable analyzing feature usage and user feedback. Many feature request come from managers, but the end users are the people that really need to feel like your software improves their lives.
9. Beware any list that has a psychologically pleasing number of items because it is definitely padded out or shortened to reach that number.
So, a few (sorry, not that few) notes:
* Too much information around You will feel lost in a sea of information. There's an infinite number of posts, blogs, threads talking about tech lead. You will want to read everything before doing any action. However, it's impossible, and you'll quickly feel overwhelmed with all that info.
* Listen your team and know their pains More than knowing everything about tech lead, what's really important is to know your team and where you're going. 1on1's with everyone will bring the knowledge for that. They will tell you their frustrations and pains. These will be the first insights on where to start your job.
* Delegate and communicate Just because you're not coding, it doesn't mean you are not working. To me, that was a big issue. So, in order to sort it I try to communicate regularly so that the team has visibility of what I'm doing. Also, most of the times you will have too much on your plate. Feel free to delegate. I'm pretty sure that you will have volunteers for certain areas (in my case, infrastucture, front-end,...)
* Iterate fast Iterate and fail fast. One of the biggest pains I felt was the fear of releasing something which was not perfect or that I was not secure of. However, it will never be perfect. Your team is not like any other team described in blogposts. Teams are always different, which mean different approaches. Instead of waiting too long for releasing something almost perfect, release, fail and improve more often. Be aware that if you iterate once each quarter, at the end of the year you have 4 iterations and 4 data points. If you iterate monthly you will have 12 iterations. Way more precision to fine tune your team.
* Are we engineers, or are we humans? (terrible pun with The Killers song) Each person of your team is different, each one of them has a different life with different problems. We all have our own different battles in life and sometimes we need to spend energy and focus on other things rather than work. Keeping that in mind some are more shy, some not. Some will think that they own you something, that they are behind schedule and hurting the team. Usually these people won't feel comfortable about talking their pains. Be their leader and help them. Actively listen each one, give them space and support when necessary.
* Align expectations Make sure that there's a common goal, and that everyone understands it in a crystal clear way. At Whitesmith, more than knowing how to master a couple of techs, our team must be critic about the product. Our good engineers will then find the best tools for the job and then you can step in to define boundaries on which tech is better for that specific problem. But it depends a lot on the company. Question yourself what's your most common project type and what's your best set of tools. Do you want to be really good at just that? Or do you prefer to be more flexible and allow other tools? Define standards, some role models of your team so that people know where the team is going and consequently where they are going too. It kind of reminds me of Ryanair. All planes are 737 to minimize differences, processes and overall complexity.
* Growth aka learning, enineering manager, space for your team to improve Give your people space to grow. Try to find time for them to learn something new. However, it's also important to find a place for this knowledge to be applied. Learning without a purpose and not being able to apply it regularly, seems to be almost as furstrating as not growing at all.
Sorry for the long post. A lot of things coming to my mind atm. Feel free to reach out and disagree. That's actually what I do as a tech lead with my team. Also, I've been told the book "The Phoenix Project" is a really nice read for tech leads.
All the best!
Earlier quoted context omitted.
The truth is that the "best ones" are often obsessed with their work and endure painful tradeoffs in their lives, for example their family lives, because of it. People who do great work tend to think about their work all the time. No one thinks about their fourth priority all the time.
I've never met someone who consistently put in 10+ hour days and also was good at what they do. I have observed an inverse correlation between consistent, unasked overtime and ability.
Earlier quoted context omitted.
I like the part about writing things down. There is a lot of mental organization that needs to happen when you write it down. It also forces you to make decisions.. which is also hard.
A related aspect of organization and making decisions is meetings. Meetings, other than 1 on 1 meetings/collaborations, are best for making decisions, NOT for sharing information. Information sharing relevant to the decisions to be made should happen before the meeting via group emails (or possibly through a software tool like Jira) with questions and responses. Written information is easier to reference, quicker to…
Earlier quoted context omitted.
I think there are probably almost as many definitions of tech lead as there are companies. In my case the tech leads in the company are responsible for turning high level requirements from the rest of the company into actual actionable work, and feeding back up to senior management places where we could improve the existing product by refactoring/introducing new features. Alongside that we do line management for the…
This sounds like a Product Owner to me. Indeed, all these types of roles are pretty much interchangeable depending on the exact structure of your teams.
Earlier quoted context omitted.
>I think every organisation has people of different aptitudes, intrinsic motivation and interests. Building a team of superstars is meaningless. It's the management version of "make it better" or "it doesn't work" type feedbacks that don't give any necessary insights to actually do it. Building a team of people technically superior to you? In what way. Does your devops guy need to be an expert in language design? I'm…
Building a team of collaborators with a baseline of technical aptitude and a willingness to learn is what most people should strive for.
What I meant to say is, your philosophy of building teams is for inferior managers. People who cannot perform above the baseline.
Normal and high performing managers always strive for hitting something above the baseline. Not to be insulting, but logically if you think this way than you must be inferior. Just speaking out of pure logic, no malice intended.