Hello everyone. Today we continue the series of publications from Oleg Melnik. In previous publications, you can read about who is techleadand also about what does the team lead do…
Technical Lead at Proxify, as well as lecturer at OTUS
In organizations that use a waterfall process or teams operate in silos, work is usually transferred between teams. For example, the business team defines and delivers requirements, the solution architecture team defines solutions and projects, the development or delivery team implements the solutions, and so on.
As you can imagine, due to the less interaction and collaboration between the various functions, the desired result may not be achieved, and refinement usually occurs because each team focuses on its own area and does what is asked of them.
In Agile organizations, the team is cross-functional and has all the skills needed to generate ideas and launch. This is a team that starts by understanding the problems and ends up finding solutions. In a team of 3-10 people, how do we agree on solutions, how do we collaborate and help each other succeed, how do we grow, etc.?
The Product Owner approaches problems in terms of results, not solutions. It helps create a culture of engagement and collaboration (the development team doesn’t do what the businesses tell them to do) and helps it find ways to solve the right problem.
Usually, the Shaping Team only has a lead developer. This means that other developers have less room to grow in areas such as technical leadership, design, and problem solving expertise. It also creates a single point of failure and makes the team less resilient, for example if the lead developer goes on vacation or leaves. To address this issue, the role of the lead module specialist is created, and this role is rotated among all developers.
We have been working with leading experts for over a year and this approach has produced very good results, creating equal growth opportunities for all developers and helping to build trust and cooperation, as well as share knowledge / skills.
We also encourage each developer to get involved early in the task generation process before deciding on implementations to understand problems, brainstorm ideas / solutions / options, and provide early feedback. It is clear that all people are different, so individual developers decide for themselves whether they want to participate in the discussion or not.
The Shaping Team then develops solutions based on the feedback received and meets to finalize the solution.
What does this mean for my role as a leading specialist, does it still exist?
Yes, I still exist and my role has not changed, but now I have a better chance of success given the feedback I received earlier. We hope to improve team performance through early feedback.
What separates good engineers from bad ones? What will make my organization the most successful? How can I learn to better manage a team of engineers? Reflecting on these questions, I realize that everything starts with me first and with the example that I set for my team.
A good engineer takes initiative
Bad engineer waits for instructions
A good engineer constantly strives to become better.
Bad engineer is smug
Good engineer creative person
Bad engineer is chaotic
A good engineer is disciplined
Bad engineer is unpredictable
A good engineer asks questions
A bad engineer is afraid to sound stupid.
A good engineer answers questions
Bad engineer takes offense
A good engineer puts the team first because he knows that team success will bring personal success.
Bad engineer for himself
A good engineer builds relationships
Bad engineer builds a wall
A good engineer learns from failure
Bad Engineer Denies Failure
A good engineer aims to create the best product
A bad engineer focuses on creating the best technology
A good engineer creates what the customer needs
Bad engineer implements what the customer asked for
A good engineer gets to know his client
A bad engineer despises his client as stupid, stupid, or incompetent.
A good engineer has an ego and knows when to test it.
A bad engineer lets his ego make decisions for them.
A good engineer recognizes other good engineers
Bad engineer wants to be recognized
A good engineer is constantly learning and developing
Bad Engineer Solves Yesterday’s Problems Using Last Week’s Methods
A good engineer is a teacher and makes other engineers better
A bad engineer is a black hole
A good engineer owns the problem and its solution
Bad engineer points out problems
A good engineer is a leader
Bad engineer thinks he is alone
That’s all! This series of publications was prepared on the eve of the start of the course Team Lead… Learn more about the course you can follow the link…