My Tiny Phoenix Project - Karen Cohen - DevOpsDays Tel Aviv 2018
•Descargar como PPTX, PDF•
0 recomendaciones•66 vistas
Do you know that developer who has all the answers? They’re a knowledge base, solve problems fast, and know the deepest darkest places in the system. When team members use them as a crutch, it hinders development velocity. In this talk, we’ll find out how we can restore team velocity.
Recomendados
Recomendados
Más contenido relacionado
Más de DevOpsDays Tel Aviv
Más de DevOpsDays Tel Aviv (20)
Último
Último (20)
My Tiny Phoenix Project - Karen Cohen - DevOpsDays Tel Aviv 2018
- 2. I’m Karen Cohen. I help people & systems work better together. @Karen_Meep Hi
- 3. D E M O With Wix you can create a stunning website.
- 4. DMITRY IS WONDERFUL! A B C D He KNOWS EVERYTHING Fixes problems FAST Is ALWAYS AVAILABLE Sets coding standards @KAREN_MEEP
- 5. THINGS ONLY DMITRY DOES A B C D Knows ALL THE THINGS Reviews ALL COMMITS Understands and modifies the hard parts of our code Design and architecture @KAREN_MEEP
- 6. THE TEAM IS WAITING A B C code review (6 weeks) question in slack (2 days) f2f question (4 hours) @KAREN_MEEP
- 7. OUR CLIENTS A B C Give up Bypass our systems Complain to management @KAREN_MEEP
- 8. DMITRY IS SAD A B C Repeating questions No breaks No growth @KAREN_MEEP
- 10. We have to change Funny picture of Dmitry in a bottleneck @KAREN_MEEP
- 11. @KAREN_MEEP
- 12. @KAREN_MEEP
- 13. Guideline #1 Never come empty handed @KAREN_MEEP
- 15. LEADING PRINCIPLES Culture change A B C Make room for mistakes Make time for learning Be patient (with me, yourself, the team, the process) @KAREN_MEEP
- 17. @KAREN_MEEP 1 “I feel more involved with design work” “I feel confident when I speak with Dmitry” “I got to know more parts of our code base” Dmitry: “No significant change”
- 18. Guideline #3 Everyone does Code Reviews, and learns how to do them better. @KAREN_MEEP
- 19. 3 MONTHS Dmitry smiles more, has better attitude All team members do code reviews, gain confidence Dmitry still in the loop for harder problems
- 20. 6 MONTHS Team members correct Dmitry! Rejoice!! Team members lead projects, answer questions Inspiring other teams by our team work Dmitry takes on challenging side project
- 21. WE’RE NOT DONE YET #ThereIFixedIt @KAREN_MEEP A B C Onboarding Informal code reviews Regression
Notas del editor
- I work for Wix. With wix you can create a stunning website and run your business online. I’ve been working there for about 5 years and A year ago I became an engineering manager for a server infrastructure team, about 7 ppl, part juniors part seniors. The team is considered one of the strongest in our R&D, we were the first team to implement an on-call rotation. The first person who I noticed was Dmitry.
- Dmitry is wonderful technical leader, he has a solid computer science background and a great understanding of our domain as well as the product. Dmitry knows EVERYTHING, he solves problems very fast and he is always available, be it vacations or sick days or 4AM when he’s pushing code to our repo. Not only that, but Dmitry also sets coding standards for our team, things like styling and best practices, which are extremely important as we work with Scala. The problem is that there are things that
- Only Dmitry does. So ONLY Dmitry knows all the things and answers all the questions, and ONLY Dmitry reviews code. In fact, he reviews all commits made to our repository. So he knows how EVERYTHING works, inside and out, but again, he’s the only one knows. Dmitry is the only one who can understand the hardest parts of our code. If you’ve ever written in Scala, you know that people can sometimes abuse that syntactic sugar and make code that looks very pretty but is SO hard to understand. So Dmitry… he understands it all. Dmitry is very involved in the design and architecture of our systems, whenever we want to make a change - he’s the one we go to. The rest of the team
- Works very hard as well, BUT they’re highly dependent on Dmitry. They don’t consult with one another and they’re afraid to make own decisions. So they would constantly find themselves in situations where they’d be waiting for him. Waiting for him to review code, waiting for him to answer a question on Slack, or waiting for him to come to the office to discuss something face to face. And our clients, well…
- Some would give up on getting their feature on time, some would give up on the entire feature. Some would bypass our systems, finding some hack, and others would complain to our managers to get their stuff prioritized for Dmitry to do or review. The worst part about all of this was that
- Dmitry was very sad and frustrated. He never felt like he could take a break, He wasn’t working on any problems that were difficult for him, meaning that he didn’t get to grow in his position, and he was constantly answering the same questions over and over, day after day, with no hope of it every changing. It reminded me of the character Brett, in
- The Phoenix Project. Brett is that guy who knows everything and fixes everything and can’t ever take a break. If you haven’t read this iconic book yet, go read it now. Anyway, after a few months of observation on how the team works.
- We needed to imagine where we want to be
- Move fast Share knowledge Learn and grow Happy Dmitry
- people have to understand how their day to day and personal growth is going to be affected by it. 1:1 with Dmitry 1:1 with team each team member We decided that we’re going to treat this as an agile process, meaning that we’re going to start with fixing what we know we need to fix, collect feedback and adujst accordingly. Together, we decided on two guidelines that everyone on the team will start to follow
- This does a few things: It forces people to do the research, most likely they’ll figure out the solution on their own. Therefore building their confidence. It reinforces ownership and accountability. They used to ask Dmitry what to do, then say things like “Dmitry said this will work, Dmitry said that’s what we need to do”. It’s *MY* solution, not “Dmitry’s solution”. I’m not doing this because ‘dmitry said so’ I’m doing this because it makes sense to me. If a team member does end up speaking with Dmitry, the conversation becomes efficient and more intelligent. What I asked of Dmitry was to switch to a coaching mode - ask more questions, give less answers. After enough conversations like this, team members will start to ask themselves those questions on their own, they’ll put more trust in themselves and Dmitry will trust them more as well. The second guideline was to
- Escalate gradually. Meaning, if you haven’t arrived at a conclusion on your own, the next person you should consult with is another team member and only after you’ve done that - you should try Dmitry. This does a few things: Builds knowledge sharing and trust across the team. Remember ONLY Dmitry knows all the parts of our system, so we wanted to get rid of that notion. It creates a quicker feedback loop. And most likely they’ll get their answer or the confidence in their solution and won’t even need Dmitry. Now, these two changes have a cost to them. And this is also something that we had to discuss.
- We had to make it OK to make mistakes. Our company has tools for experimentation and rollback and the culture to support it, but the culture in the team wasn’t a very forgiving one. So we had to have talks on it being OK to break things. We had to make time for learning and research. Meaning that we had to explain to our clients and our managers that some things will take longer than usual because we’re going into this process. And the most important thing is that we had to be patient. This is going to take hard work from everyone and we’re not going to see results right away. If we’re speaking about results, there’s the question of how we measure this process. This is where my
- Journal comes in. I started by documenting how things were before we started. The things I documented were: How people were feeling, their abilities (what they can and cannot do) and how the team was working as a whole. This proved to be very benefitial, not only because I get to give this talk, but because it allowed us all to react based on facts, not feelings. After a month we did a retrospective and here’s what people reported:
- Juniors felt more accomplished and confident in their work and contribution to the team. “I feel more involved with design work” “When I go to Dmitry I have a specific question and a solution in mind, I feel more confident because I have already done the research” More appreciative of Dmitry’s hard work: “I got to know parts of our code base that I hadn’t seen before” What about Dmitry? He didn’t notice much change. But because other people were positive about what we were doing he was more open to the posibility that things COULD change. What happened after this retrospective was also great,
- A team member suggested that another change, that everyone would do code reviews, not just Dmitry. Seeing as how everyone was new to the process and didn’t know what to look at we knew there’d be a learning curve there as well. We decided that if Dmitry finds an issue after your code has been reviewed, he will correct the reviewer and the reviewer will pass it on. That way we train better reviewers. We had one team member that REALLY wanted to get better, so he went over all of his code 6 months back and made a presentation about all his repeated mistakes, then presented it to the team like a quiz. Dmitry made a similar quiz and presented it to all of the server developers in the company, people really enjoyed it and he got great feedback. After 3 months
- The team members reported that Dmitry has begun to smile!!!! And that his overall attitude is much better. Dmitry was in the loop for the harder problems, but was slowly stepping away from the easier stuff. When people come up to him with questions he still verifies some basic work has been done before jumping in to help. Dmitry is upset because people still need him, he expects full independence, that’s not how this is going to work, needed to do some expectation setting with him: You are the tech lead, you are still involved in harder problems because we want your expertise there. They will not be independent from day 1, this is a long process. Dmitry is instructed to gather and rely on data and actual events when trying to understand whether there is an improvement.
- Team members correct Dmitry, this is by far the biggest celebration I’ve seen people have for winning an argument. They now have enough confidence that they lead their own projects. Not only that, the way of working where they have to come up with their own suggestion first has also entered into other areas, and not just with Dmitry, also with me. I had one guy who always used to come to me to help break down big tasks into small ones, but when I offered my help he said “I want to try on my own first and I’ll get your feedback afterwards” Around that same time we started working on a new project, the team member who was leading it came in with some crazy research: 4 alternative designs, pros cons, the works. At this time, Dmitry had enough mental capacity to initiate many big changes in our system AND take on a challenging side project so he finally gets to grow. Now all this is GREAT, but
- There’s still a long way to go. We can easily go back to how we worked before. Any new person joining the team has to be onboarded to these principles. People can easily go back to being lazy. There’s constant upkeep to maintain this new culture that we’re trying to build :)
- I hope you’ve enjoyed our story and that you’ve taken away some tips on how increase the bus factor in your team. I’ll be around today and tomorrow if anyone wants to talk or ask any questions. Thank you.