Recommended
More Related Content
What's hot
What's hot (19)
Similar to My team is awesome
Similar to My team is awesome (20)
Recently uploaded
Recently uploaded (20)
My team is awesome
- 1. My Team is Awesome and Yours Is Too Realizing your high performance team through simple changes
- 2. What is this talk The lessons we learned from participating and running other teams The approach we took towards running a team over a year and a half period A case study of the outcome from our approach
- 3. How did this come about Presented with a unique situation around team dynamics and company culture No one had in depth knowledge of the project or subject matter We were presented with a situation with high expectations and little oversight to run the team
- 4. Team dynamics No one on the team had been there longer than three months Most of the team not had started at the time of the project There was no established culture or processes to form a commonality among the team members.
- 5. Why is this important Most successful teams tend to have experience together. This team needed to self organize before beginning a significant portion of the project. Ultimately, the team started out behind schedule
- 6. Foundations
- 7. Foundations Team culture vs. Company culture Personal motivations Communication Personal necessities
- 8. Necessities
- 9. Communication Outside of physical needs, this is the most important
- 10. Motivations Everyone has different motivations In order to have a successful team, every person needs to have the feeling their motivations are being attended to Motivations change over time
- 11. Team Culture "I'm not looking for the best players - I'm looking for the rights ones" - Herb Brooks It’s separate from Company Culture Teams should regard it as “ours” Be possessive
- 12. Implementation
- 13. Play to the team's strengths Everyone has things they either like to do or they are excel at. People who spend their time thinking and working on problems that interest them will do a job 100 times better than those that are paid.
- 14. But don’t let strengths become weaknesses Just because someone is good, doesn’t mean that is what that person should do. Don’t pigeon hole people into a particular role. They get bored They don’t grow Reinforces the “no fail” culture
- 15. Kill the “No Fail” culture
- 16. Practice What Hurts The difference between an Amateur and a Professional No one wants to admit what they aren’t good at The team needs a level of comfort to admit their failures
- 17. Headaches, you need to get rid of them
- 18. Headaches, you need to get rid of them The single biggest necessity of a high performing team Frees people up to do what is really important Shortens the ramp up time of new people Especially, less senior team members
- 19. Common headaches The wrong tool for the job Repetitive tasks that can be automated Policies, Procedures, Stupid Rules
- 21. Repetitive Tasks Bruno “btco” Oliveira
- 22. Tools (equipment not people) Adequate development machines Appropriate Source Control and Continuous Integration Stop broken code in source control The right framework / language Should help remove repeated difficulties in code
- 23. New Skills
- 25. Team Dynamics
Editor's Notes
- For a while, I didn’t really know how to give this talk. On one hand, I have a great team. In which case, us being successful was about us, and when it ended that would be it. On the other hand, I thought how we did it was what made us successful, and we’re just passionate about what we do.
- What we were doing for the last year and a half. We all talked and figured out how we wanted to be treated, and the rigorously applied those ideas. Our ideas aren’t really anything new. They’ve been borrowed from our experiences other places.
- Unbelievable -> yes. talk about how they accidentally won the project. Didn’t expect it. Didn’t know how to handle it. We were lucky in being presented with this opportunity. Don’t mean this from not being able to use the lessons on other teams, but the ability to observe the outcomes of what we did without a lot of extraneous variables coming into play.
- We were put in this strange situation where we building a team from the ground up with no rules. No one knew each other at all Explain that every person (except one) of the team had either been laid off or fired from their previous company. They didn’t go out and recruit “the best” Looking over at my coworker, (dev manager other company etc.) “how are we going to do this?” - Joking his idea was for all of us to quit before the end of the project, so we avoid the impending disaster.
- None of us knew each other. We didn’t know our capabilities, or how we acted. There was bickering and arguing about how to do things in the beginning while we were all trying to figure out what was going on and get to know each other. Ultimately, what came out of this was how we self organized and how we wanted to function.
- If you don’t have the foundations, nothing else will work. “Just need some bullet points, so we can knock our problems and become a high functioning team” — doesn’t work. You don’t have to be there immediately, but you have to get there eventually.
- Separated these into 4 areas
- Created in 1943 You want your team to be at the top. This is important. And it’s a recurring theme. -> We’ll reference back on this later. To be at the top you need the other foundations. Brene Brown Without this people just down as a defensive mechanism to avoid being hurt. Studies show that this prevents them from being happy too. Being vulnerable is what allows teams to function well together and be happy as individuals Talk about Pay. It’s Important. It’s the easiest thing to correct, and the easiest way to lose a team member. Talk about the Armatis story -> Took job, company gave him low pay and a horrible project. Quit after 4 months. Never threaten an employ (“we should be lucky we have jobs”) -> empty threat, if they didn’t need you, they wouldn’t employ you.
- Communication is key. When you communicate with your team members, it should be about them. This is a common oversight. Don’t just get a status report. In order to negotiate with them about anything, you have to understand where that person is coming from. Small problems become big problems As a PM, Dev Manager, Team Lead -> even if talking to staff about their needs isn’t your job, it’s your job. Even as a junior member, it’s still your job. Getting to yes -> Talks about understanding the other sides’ motivations working with team members is a negotiation. They do things for me, and I do things for them.
- People aren’t resources, people are people. Just because you want them to do something doesn’t mean that they want to. Hate the word “Resources”
- Now talk about Herb Brooks and why he said he needed the right people. Melding with the team. The phrase, “People quit their bosses” I’m going to amend that. “People quit their teams too.” Teams that don’t have their own culture, or something that emotional binds their teams together are more likely to quit. Corporate culture is top down. Team culture is bottom up. It’s organic. There is no real way to force it into being something. You can influence it, but you can’t make it. Companies should actively try to get teams to form their own culture. It’s what keeps them together. Simple things makes this happen. Buy shirts for people. Outings. etc. But the team has to want this. Bottom up philosophy. We’ll talk at the end about how managers can help with that (Cesar).
- these are the things that you actively do on a team to affect how it works.
- This is why hackers will always beat law enforcement in the cyber wars. Hackers don’t want to win, they have to, because that’s what drives them. Understanding and using the team’s abilities is the easiest way to get them to excel. This sounds like a “duh” moment. Most places don’t do it. They are more concerned with immediate need rather than long term benefits. People are often reduced to a title. Talk about Dave and how he loves UI, we didn’t know that, because he was just a “developer”
- mention searching for bobby fischer person -> Joshua Waitzkin -> why study bjj, “because I wanted to be a beginner again” It’s very easy to pass assign the same type of task to the same person. It’s often justified as a time saver or emergency The bus factor too. Part of having a good team is having one that can cover itself in the event of an issue -> pete simpson Emphasize the “No Fail Culture” -> going to talk about this in a second
- A no fail culture is probably the worst thing you can have within team dynamics. It stops everything. It’s all based on fear. Generally stems from lack of experience or confidence, and it definitely forces a lack of trust. Stress levels go up, which will ultimately trump motivation. There are always problems. Anyone done theatre or performance art? There are always mistakes. It’s just that people don’t know it, or if they do, it’s quickly recovered. Every team fails, the question is can you recover gracefully?
- The amateur practices until he gets it right. The professional practices until he doesn’t get it wrong. Admitting you’re bad at something requires a level of vulnerability. -> Maslow’s self actualization. The team needs to feel they are a whole, and not just individuals. Remote communication is really hard. We had 2 options. Don’t work remote (which hurts the personal motivation / needs of the team). Fix the problem. Now we all have to work from home.
- These are a number of things that teams just live with. They’ve normally gone on for so long that people just accept them as fact. Literal headache, but one none the less. How changing CRT monitor to 75hrz made us no longer have headaches. -> frank pineau
- You need to constantly look at what makes people frustrated, even if they don’t know it. If something new comes up, you need to take action. Third part really important -> MENTION JUSTIN AND HOW HE HAD TO LEARN LESS.
- These are things I’ve run into, your team may have different ones, but these seem to be a common theme. Explain in further detail later, in reverse order
- We’re all adults. Longer lunches Coming in late It’s really about Autonomy. Autonomy is one of the keys to employee satisfaction. The moment this gets removed, you risk losing an employee. Either mentally where that person just slows down, or the person quits. Command and Control is common among new managers or I should say inexperienced. If you have to control every action someone does, you have one of 2 problems. Why are they working for you, or more likely, why are you there manager? — Communication can help with this. It needs to be addressed.
- Most developers hate repetitive tasks. They become boring and that is a problem. Boring leads to not paying attention and possible mistakes, and frustration. It’s also a waste of time. Which is the one thing that most teams don’t have an abundance of. Anything that can be automated should be automated. One person doesn’t have all the knowledge - bus factor Ensures that it’s done right every time, even under pressure Crimson tide -> when he forces a drill in panic
- get into argument about cost of faster / better machines some people thinks this makes developers more efficient because they have to develop on worse hardware than what is used in production Source control, keep developers non working code segregated from everyone else. I should be allowed to break things, as long as it doesn’t affect everyone else. What we do is inherently destructive. We spend a lot of time tearing things down and rebuilding. If we didn’t, we wouldn’t have need for regression testing, unit tests etc. Application development is a long game. Spending time to learn the right tool, can and does pay dividends for years to come - potentially.
- Kubler - Ross change curve -> time to learn, understand and integrate a new skillet -> originally developed as the stages of grief, but expanded to understand the stages of anything new. The red square is where most people/teams/organizations give up. See this in agile implementation Once bitten twice shy. You have to push past this. Talk about Dave’s panic -> Didn’t know angular or functional programming. Wanted to use Webforms. Spent time learning, and now really good at it and influencing other teams. It may take longer to learn, but in the end it can pay off more If the team is so behind that there is not flex to learn new things, the project is already doomed. Talk about the 2 weeks off rule -> use it as a measure to see how screwed the team is. Don’t go overboard with it though. - temperance
- Ax grinding Know what you are getting into Every technology on the team was used by someone else at some point. We may have stretched, we didn’t know all the answers, but we knew enough to look for the answers. Don’t test brand new ideas on major projects it’s better to spend time on a small project to test it out first. Even if you are doing this in parallel. Restructure your work on the main project so that you have time to test your ideas, before you have to live with them. It’s much easier to throw a test project away, and rework code on one that is going to continue. (In agile this is called creating a spike).
- The single most important thing I learned in school about teams Roman Civilization Julius Cesar stayed with his troops When they suffered he suffered with them (the rain, the cold) When he was victorious, they were victorious with him Everyone on the team needs to spend time together (and not about work) This absolutely is true for leads, managers etc. Colocation helps, because people automatically spend time together Not forced