Duration 34:24
16+
Play
Video

RailsConf 2019 - Congressive Management Techniques: Gardening Your Team by Jennifer Tu & Zee Spencer

Jennifer Tu
Co-Founder at Cohere
+ 1 speaker
  • Video
  • Table of contents
  • Video
RailsConf 2019
April 30, 2019, Minneapolis, USA
RailsConf 2019
Request Q&A
Video
RailsConf 2019 - Congressive Management Techniques: Gardening Your Team by Jennifer Tu & Zee Spencer
Available
In cart
Free
Free
Free
Free
Free
Free
Add to favorites
187
I like 0
I dislike 0
Available
In cart
Free
Free
Free
Free
Free
Free
  • Description
  • Transcript
  • Discussion

About speakers

Jennifer Tu
Co-Founder at Cohere
Zee Spencer
Co-Founder at Cohere

I cultivate organizational cultures of continuous delivery and learning in software teams. I love helping people grow both personally and professionally while they deliver incredible software products.

View the profile

About the talk

RailsConf 2019 - Congressive Management Techniques: Gardening Your Team by Jennifer Tu & Zee Spencer


Ugh. Management. Agile was supposed to free us from that, right? Self-organized, cross-functional teams who get stuff done without that old-guard hierarchy. In this fauxtopia, some developers were more equal than others. Can we get the healthy parts back without the Lumberghs?

To bring back healthy engineering management we first must de-mystify and de-stigmatize the concept of management. In this talk we will: * Explore the context of management * Learn the responsibilities of management * Discuss the techniques of management

As a developer, you'll be equipped to understand, empathize with, and influence your boss. As a manager, you'll build a foundation to help you better serve your team.

Share

Hello everyone. My name is Jennifer's who my friends are she her pronouns are he or him? We are co-founders of coke hear others are 32 found her over there and I'll we come here is a tiny consultancy that specializes in Education and Training for product and Engineering teams of programmers who ended up in engineering leadership roles of a typist in a programmer. I can do 200 words per minute sustained Jennifer is the one with the fancy MIT CS degree. So if you have real programming problems talk to her. Yeah. Yeah. They are we going

to talk to you through six areas of engineering leadership. The first is the phases of group development jumped all you want to tell us how to hire a second how to develop your people is Third how to bring them together into a coherent team and then how did navigate conflict and then how to grow a leader culture? Which is a lot, but before we start we're going to get ready to Garden. Imagine your organization is a garden there is soil and benches and plants people are working in it and coming to

see it and there's some things we can't change. We can't change the amount of sunlight the location the rain what kind of garden people want to see or if someone secretly sprays Roundup on the Roses every Thursday during your weekly deploy. And then there were something so we can change one thing we can change is to accept where we are. That means we accept all of these conditions that they just described and we accept that there are some of them that we can't change and then some of them that we can't change as quickly as we would like. In addition to

accepting the conditions and constraints. We also need to accept our responsibility. We are responsible for the state of the garden and for the states of the team of gardeners redirect. That means we are responsible for their job satisfaction their job Effectiveness. How much of that Maslow pyramid that they are getting? Once we've accepted our garden conditions and constraints and responsibilities. We are free to get ready to Garden or should we focus First Tee first we focus on trust and Trust in particular between people trust is the fertilizer not poop fertilizer.

It looks like poop some easy. It is fertilizer. I'm from Michigan. We understand agriculture. When we build trust between people paying for the work the people organizing the work the people doing the work in the people benefiting from the work responsibility for the garden becomes easier. Now most of us were programmers before we became managers and could be really tempting to just try and build trust by jumping in and doing the Dirty Work of shipping, but this doesn't help our team get better at tending the garden instead. We build our team lead to work

without us. We do this by Shifting the focus away from how work is done and maybe even what work is done to why and more importantly by who what is the people doing the work what motivates them going back to the the morning? Keynote? What does the meaning and happiness great managers know the performance isn't individual. It's systemic exceptional work is done not by exceptional people but by organizations whose environment is designed to empower people just has an excellent Software System keeps working even when

no one is at the keyboard management. Excellent is achieved when team fries without us. Let's jump into our very first topic done the stages of engineering of Team development. tuckman's stages of group development asserts that groups go through 5 overlapping phases forming storming norming performing and eventually Morning is where the group meets we learn about the opportunities in the challenges and we agree on some of the gold and how to tackle that work. An example of this might be having a spring kickoff storming is when the group starts to notice the wear

and tear caused by working together. This is a scary place to be it can be tempting to just get through the storm by protecting your team or stakeholder from the consequences of their decisions and behaviors is an opportunity to learn more about the team that you know, if you stay in the stage for too long that will slow you down, but if you try to skip it entirely that's going to prevent you from building the effective team you're looking for. So here's an example of swimming after the kickoff to developers start working and

at the next stand-up they really said they were working on the exact same ticket and they were working independently and reproducing each other's work. So they they feel kind of frustrated about that. That is the point at which they've begun to enter the storm. No normally happens at the group works together to survive the storm. They began to establish habits and structures for working together, but they're not really fine. I'll just yet they're still working on the details of what those habits in Norms will be this is the essence of the norming stage are two collaborators

decide that when they started tickets, they will claim it and tell each other what they are working on. Asbys habits and structures stabilize teams enter the Performing stage less time is spent on habit-forming and more time is spent on the work the difference between norming and Performing is that when you are norming you are making major big changes when you were performing the team is making small adjustments. So for our team that I started talking with each other about starting new work at the daily stand-up. When they are performing they make a small adjustment that if

they begin in the middle of the day, they send the group I am. And that building new habits and never really goes away. What you can do is you reintroduce read or me and this is caused when we noticed our rough edges. We're creating opportunities for change. We're making it safe to make big changes without re-entering the storm. For example our team may decide not now that they're going so fast. And so well with all this low effort communication that they want to speed things up. They want to automatically push their patches directly to production. That's a big change that I can

see why you'd call that morning. Would you consider that Norm us change? So that's an example of adjourning Jennifer has gotten sick of my pun. That was 1-1 pun too far while say that we wound up actually increasing our Revolution off and we're splitting in forming two brand-new teams. So we better example topic number to adding new team members. In other words hiring more people this way more work than we have people who can do it and we have the funds to pay someone to do more of that work.

When you first begin hiring one tempting approach is the higher the best and the brightest, but does that actually accomplish your real goals? Our job is not to hire the best and the brightest our job is to enable the team to get the required work done. And that means there's a secret First Step required to building a great team. Find what the team needs. Are you is your team doing a lot of Greenfield work? Don't hire someone who's really super experienced and hasn't done Greenfield work since they left school, or if you do don't expect them to perform at

the same level as someone who's been doing nothing but bring field work and if we have a team with a wide range of skills, we probably need to hire people who can both mentor and be mentored so we can develop our cross functional ability. So instead of looking for the best and the brightest you are three things that sweet that you might want to look for instead. First Look for what? The business need your company is trying to solve whatever that is is that's the first thing you need to be telling everyone. We need you to join our team cuz will we need to decrease

our per user per month hosting infrastructure costs? That's boring that's really boring, but it'll free up $10,000 a month and increase our financial Runway by 10% and then we have another person for you to do more work. Whatever this business needed write it down and then Sherrod widely come back to it at every decision point in your hiring process. That means if he's got this candidate in your kind of on the fence about them read your business needs a loud again and ask yourself. How is this candidate going to help me achieve that business

need and use this question and answers that come out of it whenever you're struggling with that decision. Sending you want to think about is what skills or abilities are needed to meet your business need and this goes Way Beyond your text back. So I think Beyond nose rails stinky on nose rings really well and think about what this person need to succeed. Do you need someone who can build a spec or do you need someone who will take creative Liberties or maybe you need someone to food nose in that moment. Which of those two is most important is your workplace stabled or is it

changing someone who thrives in a stable environment May really struggle in an ever-changing one? Let me pick some time looking at who is successful in your in your organization at bringing value and think about what non technical abilities are using that allows them to use their technical abilities. Did you hire someone who can write the code but can't pick the most valuable work to prioritize whatever business need to hire. This person for is not going to get fully met. Kind of related to this is the third one. Think about what concerns you have in your existing

team. Maybe you have a team that exclusively pairs. So a candidate who doesn't enjoy parenting isn't going to be a good fit there. Maybe your team values kind feedback and the candidate really like give unfiltered direct feedback. That would be incompatible. Think about how your engineer's interact with each other or with cross-functional co-workers. What will add to this and complimented and not conflict with it? And this is going to be individual to each of your teams. That means be honest with yourself about for your team is if you wish you had a

team that would pair together all the time, but no one on the team is really into it. If you hire was at wishful thinking of all I have is fantasy team and my husband always tears. Your new hire it's going to feel bait-and-switch and everyone's going to end up feeling really frustrated. That means be honest with what you have and play with a team that you have. You can change that change slowly over time, but you can't pretend it's nothing it's not. Once you taking these three steps and know what you need out of your future higher now, you're ready to start talking to candidates.

When you talk with your candidate tell the candidate what you're looking for. Tell the candidate who will succeed in this job. That can be kind of scary because you might be thinking I want to tell the candidate when I'm looking for them. They'll tell me what I'm looking for. For example, do you give good feedback great feedback. I care about being kind and making my own kind and making my feedback specific and actionable. Sound pretty good. Because I asked a yes or no question that included the answer. I was I was looking for was able to tell

me what I wanted to hear and it sounded good, but I didn't learn anything about his feedback. You don't have to answer interview questions this way though. You can tell people what you're looking for and then ask for specific stories from their experience and digging for details qualified candidates will be able to come up with these stories. So examples of questions are tell me about the last time you gave someone feedback what happened. Tell me about a contentious pass report request that you are a part of. How the candidate answer these questions tells us if a candidate

gives good feedback. When we don't tell candidates what we're looking for we miss out on compatible can candidates who don't guess correctly what to share with us. And we also miss out on opportunity to show our soon-to-be newest hire what it is that our team values so that way they can celebrate what we are made of. That's all the time we have in this talk about hiring an interviewing come talk to us after because there is so much more that we can be that can be said here next section is growing your people. Now this may come as a complete surprise to all y'all but programmers we're not

experts at people. But that's okay. We can learn from psychologist neurologist social scientist as JJ $20 philosophers and we can learn all about how the invisible and visible invisible and visible Norms shape our behavior and thinking fast and slow Daniel Kahneman describes thinking as two systems system one or fast and system 2 or slow fast thinking is our gut reaction system is responsible for the vast majority of our behaviors occurs as we analyze and make a decision. One way to develop people is to help them

identify and adjust when they're fast thinking is overriding their slow thinking or when slow thinking is blocking their hard-earned fast and can wisdom. Let's talk to four options on how to do this. First we can ignore it. Ignoring is a great option for small stuff may be a team member spends more time noodling on a feature before they get into the code base or maybe they jump into code immediately into start time before even getting to a whiteboard. It can be hard to tell when someone is using their time effectively, especially when someone's habits and

preferences are different than yours. It was only costing an afternoon or two here or there by Fix-It micro optimizations will cost you trust and make the team less effective. trust people to self optimize option to illuminating growth areas if it's not small stuff and we can't ignore it. We can illuminate it instead once people know how their behavior impact those around them. They may self-correct maybe one of the team members is taking up a lot of space during retrospectives. We can privately share this with them and ask them to

change their behavior. I noticed that you were the first person to respond to eat conversation point during our last retro when you do that, it makes it harder for your teammates to advocate for themselves. How could you make it easier for the rest of the team to engage in retrospective? By shutting light on a behavior and encouraging the team member to participate in solutioning. We cultivate healthy change in a Safeway. Option 3 redirecting contextually unhealthy behaviors. Sometimes we might have to set it for more boundary. Perhaps something is not merely off-putting or

frustrating but it's costing the king significant time and attention. Here's an example that I encounter with one of my coaching client. This person had a team member who was frequently blocking merges because the design was known as usable as as it should be for the user and they have really good points there were looking out for the user but what they were doing a flocking pull request was it wasn't healthy. It was discouraging the team it was slowing everyone down. They weren't able to bring what I needed to the user as quickly as they could do in a situation like this. We can redirect by

pulling up person inside and talking with them and saying something like I like Kelly care about the customer experience, how can we shift so that you're not giving us feedback late in the process but doing guidance earlier on You can also add a little bit of elimination as well. When we slack on this feedback. That's preventing us from helping our users if we can bring your insights in earlier. We can deliver a better product sooner. Now our team member to develop their skills at a thing, they're passionate about in a place that helps your entire team perform better even more importantly

importantly that's a word they learn the value of applying their skills in the right context. Know some behaviors are unhealthy regardless in those cases is our responsibility to squash it. This is especially important when there's a differential in power dynamics. Someone making snarky remarks about politically correct culture run amok may not seem that bad. But it's a signal to those who live with the effects of discrimination that your team or organization is comfortable with just a little bit of discrimination filter leaking in so long as it's CouchTuner

joke. We have a meeting at work to do if this wasn't public we need to respond in public and set clear expectations for everyone. Hey, we don't make jokes about political correctness here. Now everyone knows that that behavior is unhealthy and not acceptable within artwork context. As we shift our teams behavioral Norms are jobs become more sustainable when we go or teams capabilities instead of hopping in to fix everybody or shielding the team from customer for teeth the team take more ownership of the work which result in higher engagement and higher quality work. And

that's freeze your time up for really high value activities like taking naps. That's a great. As he develop your people individually 1/3 common problem, you might encounter is how these individuals work together. Even when everyone is really well-intentioned and doing their best each individual's natural communication patterns can only extend so far. And so that makes even when everyone is having the best of intent this Communications Gap can occur you might see this happen when you're coordinating between teams, maybe one team make an API change and that API changes

in conflict with another team's goals for that same API or maybe one team is changing the visual style sheet, but it's conflicting with another teams use of the style sheet. You might also see that happen in work that is not happening because it's beyond the scope of a single engineer new one is taking ownership for setting up a style guide, even though the same style arguments break out repeatedly in all of your pull request for automating the process even though there are questions and challenges every single time. This is the work that Tanya Riley called glue work in her

talk being glue. It still work at three sets of Wheels to work at Bridges the gap between individuals and teams when this invisible work doesn't happen the individuals on your team who has been carefully growing they're going to do their best, but they won't be able to make big changes on the team because they won't be working together and going in the same direction. The problem is that glue work is not working. Most people naturally do. It's not rewarded you might recognize individuals who perform this work and thank them publicly for doing it. But glue work as a non non promotable

work. That means if you spend time doing glue work that takes away from time that you could be spent shipping flashing projects that leaves your next promotion. One solution to this is for the manager to do all the glue work themselves. But then you want to spending all your time telling her team how to talk with each other and then they're totally helpless without your intervention, but you're not going to do any of the work that you're supposed to do Beyond juggling all the glue work. Another solution is to find a single individual

who will do all the glue work for you, but then she's not able to do the work she signed up to do and won't be able to move her career forward. Is it say someone put a lot of work that super valuable into making the team works together? They're also cuz I know this is that person gets recognized publicly, but maybe never gets a promotion and don't know what work to avoid. The engineered was doing all that glue work and she's not getting promoted. She's also smart. She will take her talents elsewhere and then where will your team be? Depends on the person who just drove away by

not promoting. Here's what you should do instead. Instead of relying on a single individual weather that's yourself or one of your team members teach all the members of your team how to do glue work show them how to pursue communicating beyond the people they work with daily how to think about the other people in the company who might be affected by her actions. Show them the word that no one is doing but what can benefit everyone if it got done? And then once you start showing them the stuff incentivize them to want to get good at it. The way you incentivize people is

when you promote someone point out all the glue work that they've been performing as part of why they got promoted set that expectation that everyone needs to be skilled at glue work in order to get promoted. If you don't do this, you're going to end up with a senior engineer who can only ship tickets not a senior engineer if we can pull other Engineers around them and ship projects. This is my favorite part. By the way. I read it like 12 times. So you're going to love it. Thanks. I learned that this year imagine. We have team members with different tests

velocities Alice prefers micro test with subject system boundaries different sure. She's not distracted by meeting with failure faces. Bob prefers integration tests to make sure API changes to not rock the boat. Alice may agree with Bob on his preferred testing strategy tester being written no problem, right but through one-on-ones and retrospectives. We see rough edges Alice's checking out. She's adding fewer tests because they slow down to build Bob starts to worry that the system is riskier to change and they can be tempting to ignore it. We literally just told you

that ignoring it is a totally valid option but rough edges like this when uncared-for become sharp edges that leave scars. We have to avoid avoidance when we ignore these rough and sharp edges in our team's environment. They don't disappear, but your team will at first maybe just their engagement and productivity, but eventually the people will leave to no one can bring their best selves to work place that is mired in conflict and microaggressions as Allison Bob's manager. It's up to us to bring the work environment back to a healthy State part of conflict occurs in cuz we

focus on conclusions. Alice wants to add face and mocks and Bob wants to keep our test weed fully integrated. We can reframe from conflict to something. That's safer to engage with as a group conscience. Diffuse tensions, we start with the context pensions differ from conflict because it's not about the existing conclusion. So let's walk Alison Bob to three steps to reframe conflict detentions. Stop one expose sources of tensions. Ask your team to share what they think are underlying this tension much

like an iceberg. The thing we see in conflict is just a tiny part of the whole house is burned a lot of time chasing downfalls tells failures because the front end change in a non-user discernible way. Baba struggle with code that was difficult to change because the face being used were so tightly coupled to the implementation. You couldn't make changes without unwinding a mountain of spaghetti. Once we know some of the sources of the tension We Begin step to sharing needs Alice needs not have to worry that Ashley makes changes. You may have to chase down on related problems. She likes to feel

competent and things breaking without being truly broken makes you feel unqualified. Bob needs to feel like he's making small safe changes when he was encumbered by a tightly coupled unit test. When he feels like he can't make the smallest clearxchange they can possibly work Allison Bob find Common Ground. They both really like to get things done. Which brings us to step free. Exploring the resources that are available resources can be internal or external internal resources are resources. The team already has external resources come from the surrounding environment. Turns out Bob knows how

to set up rails for test only data attributes instead of complaining hooks for styling or JavaScript which forecasting he's willing to pay her on some of that with Alice and they agreed to do an internal workshop on not together experience refactoring spaghetti code to reduce the problems associated with tightly coupled fox and a workshop on that support them in the workshop development. They've decided to buy a book on education go to a few local meet-ups together and talk through which techniques they liked and didn't like from the Meetup instructions and if it is time for in which they

can even hire a coach like Jennifer to help them put the workshops together. You can actually hire Jennifer by the way. It's totally okay with a shared understanding at one another's motivations underlying needs and available resources. We refrained from conflict attentions. Now that is a problem that can be solved together as opposed to a conflict between incompatible predetermined decisions to remember avoid avoidance and refrain from conflict to tensions. Scoop back the spell. Sorry, we're doing a dhh thing in reading the story. pictures of Drake

It's the middle of the night production goes down alone engineer jumps in and saved you all. This can be pretty cool and inspiring but if he looks like this become a regular occurrence, you have a hero culture. Hero culture allows problems to go from small and ignorable to text down production levels. Hero culture is too busy saving the day to do the preventive work to stop prices from developing. She-Ra culture creates real teams because your people are too busy dealing with disasters or recovering from late nights dealing with disaster has to

work towards whatever it is that would build your business. Hero culture is what stops your team from being able to scale successfully. If you want to learn a little bit more about zero culture and its policies look up jumper Davis's talks from 2014 on the topic. She does a really great deep dives into exactly how hero culture stop Steam from being successful. Russell let's let's take a different. Look if hero culture is around solution. What's another approach we can do instead? We can grow leader culture. That means that when someone production goes down someone

performs heroics, we hold a retrospective. We thank the person who bought this time and then we passed our team to figure out how do we prevent ever needing to do this again in the future? Once they figure that out make space for them to be able to carry through that work. When we do this, that means we acknowledged the work of someone who just saved our production system without setting that example that action that something is temporary that other should model. By pushing our team to Boise work culture. We are creating an expectation that our team is going to address

problems before they get out of hand. We're creating an expectation for leadership. If you want to learn more about retrospectives after incidents, I highly recommend Courtney at cards talk from last year's rubyconf. It's called retrospectives for humans. Picture doesn't just happen in code it can happen when you as a manager perform heroic for your team. As a manager people are consciously or unconsciously modeling their behavior off of you. If you modeled being a hero your people will do the same thing. Your people will be more likely to do that as well. If

you're on email or slack over the weekend. Your people will also be an email or slack over the weekend. These are not the habit of a passionate team. You have a habit of a team that is working Beyond its capacity and a team that is not working effectively together. As a manager being a hero isn't limited to your actions around your set your team. Are you jumping into conflict and resolving them to yourself or are you giving those involved the prospective and Direction they need to resolve that are you directing every minutiae around the collaboration and

communication or are you setting expectations and getting out of the way so they can do the glue work themselves? Just like saving the day single-handedly as an engineer can't scale jumping in and saving the day as a manager can't scale. Instead these son of yourself and support your people as they grow into leaders not Heroes step up as a manager. But otherwise set your team up to be able to own problems themselves. That means when your people aren't talking with each other said expectations that

they need to do that. If it's a communication gap outside of the team between the people on your team and other that's when you should jump in and help get those lines of communication unlocked. If your people are disagreeing amongst themselves set some expectations or suggested directions for how they can resolve that themselves. But if the disagreement is coming from outside the team or from above the team, that's a space. You should be helping with And I'm finally keep an eye out for conflict across acrylic Gap and if anyone is punching down if you have a more experienced engineer

and they're pushing around and you were developer set the expectation with the experience engine, but that's not appropriate or under-represented person on your team isn't being heard set the expectation with the other team members to give that person space. This is how you can grow the people on your team into leaders in your organization and create a robust team that can operate without your constant supervision. Then you can go take that nap. Naps. All right recap what we talked about forming

storming norming and Performing are all natural stages of team development hiring don't hire the best and the brightest hire people who will fill the business needs that your organization has tasked you with your people invest in the people instead of doing the work yourself. Will work create an environment for your people are rewarded for doing glue work and an expectation that everyone does it conflict pensions together leader culture and direction for your people to

self-actualize and save fixing things yourself for the stuff that's bigger than the team. That's it. Thank you all for coming to our talk on guarding your team stuff. Okay are our talk titled gardening teams. Come here offers coaching for your leaders in your pretty leaders and training courses for everyone. We will stick around for off my Q&A or you can find us on Twitter. I am at JT you are company is at the Spencer and we will post our slides later. If you're watching this on YouTube and not live

it is totally up now. Yeah, and this is how we communicate doing live introductory workshops because we're not preaching at rows of seats. This is absolutely terrifying for me. I'm done this and we can hear. Calm and also I failed and I bought that domain name cuz I assumed everyone would just like realize that when the website says cohere on the logo if you would like to do that, but no we go here, please don't do that. It makes my heart practice a little bit inside every time someone does it. Yes, we are still here. Thank you very much for coming.

Cackle comments for the website

Buy this talk

Access to the talk “RailsConf 2019 - Congressive Management Techniques: Gardening Your Team by Jennifer Tu & Zee Spencer”
Available
In cart
Free
Free
Free
Free
Free
Free

Access to all the recordings of the event

Get access to all videos “RailsConf 2019”
Available
In cart
Free
Free
Free
Free
Free
Free
Ticket

Interested in topic “IT & Technology”?

You might be interested in videos from this event

September 28, 2018
Moscow
16
166
app store, apps, development, google play, mobile, soft

Similar talks

Eric Tillberg
Software Engineer at TEECOM
Available
In cart
Free
Free
Free
Free
Free
Free
Ryan Alexander
Back-end developer at Money Advice Service
Available
In cart
Free
Free
Free
Free
Free
Free

Buy this video

Video

Access to the talk “RailsConf 2019 - Congressive Management Techniques: Gardening Your Team by Jennifer Tu & Zee Spencer”
Available
In cart
Free
Free
Free
Free
Free
Free

Conference Cast

With ConferenceCast.tv, you get access to our library of the world's best conference talks.

Conference Cast
577 conferences
23287 speakers
8705 hours of content
Jennifer Tu
Zee Spencer