My Team Is High Performing But Everyone Hates Us

Transcript

Janaway: I'm going to talk to you today about "My Team Is High Performing... But Everyone Hates Us." As slide says, I'm the VP of Engineering at Bloom & Wild. We are a flower and plant gifting company. What we do that's a little bit different is a lot of our range is what we call letterbox flowers. If you look at the picture in the middle, that's how you get your flowers from us, so in a specially designed box, and you can then arrange them however you like. You can make them look like that beautiful bouquet there. The great thing about that box is it fits through a letterbox, which means if you want to send flowers to somebody, they don't need to be in their house, you don't need to phone them up and go, "Surprise. Please be in for something which might be flowers." I run the tech team there. We are 24 people in a company of 100. We are a very technology-focused company, and I love that.

I'm not here to tell you about flowers. I'm not here to tell you about Bloom & Wild per se, either. I'm here to tell you about a short period in my life, because conferences are littered with stories of perfection. Whether that's teams that delivered on time, challenges that were overcome, products that were perfect. I often wonder why that is. Is it because, as humans, we naturally want to tell stories that reflect positively upon ourselves? Is it this idea of kind of culture inflation a little bit, particularly in startups where, yes, you're selling your product, particularly when you're pitching, say, to VCs, but you're also selling your people and you're selling your culture, and you want that to appear positively? I thought I would redress the balance. I'm going to tell you a story about a high-performing team, a short period of my life, because high-performing teams don't last forever. They make mistakes, just like every team does. Sometimes those mistakes can threaten the life of the product or the life of the team.

Let me tell you a little story about a high-performing team, a short period of my life, and a team that we felt like we were going to change the world. This is a story of luxury fashion. It's a story of catwalks, and fashionistas, and influences, and celebrities, but above all, it's a story about what makes a team high performing, and what could derail them. When I was putting this together, I thought, "Should I name the company that it's about? Should I not?" I tried not to. Maybe that's not the done thing. I failed completely when putting this together, so this is about the Net Set, powered by Net-a-Porter.

This is what the Net Set is, or was. It was a social network. The team I ran, we built, from scratch, a social network. It did all the things that social network would do. You had a profile, you could upload content in an Instagram-like feed. You could group people together, you could comment on things, you could love things. We were the first team in the company to write an Apple Watch app when the first Apple Watch came out. This is kind of 2015. More importantly, this was a brand new team. We were a brand new codebase, we were starting from scratch, we could decide what we worked on, how we worked on it. We were even in a different floor of the office, away from everybody else, getting on with launching our social platform.

There was a really cool bit of tech in here, which is, let's say you saw me and you thought, "Steve, that's a wonderful blue polo shirt you're wearing." You could take a picture of it, upload it to the Net Set, we would image match it against Net-a-Porter's catalog. We would show you all the things you could buy from Net-a-Porter that look like my blue polo shirt. You could then buy them from within the app. It was right at the beginning of the kind of age of social commerce before the big players were really doing this. We thought it was pretty fantastic. Frankly, being in that sort of situation is great. We loved being a part of that team.

Think about the best team you've ever worked in. What made that team great? Let me tell you what was great about being part of the Net Set. We were sponsored by the company founder. This made getting things done very easy. If we needed a floor of the office to do our Net Set thing on, it made getting that floor of the office very easy. We had a very clear deadline and a very clear focus. We had to launch this platform with a big party on our founder's 50th birthday, which is like the hardest of hard deadlines I ever worked towards in my life. That doesn't move. It's kind of important, very important to her, very important to us, but great when you're trying to build a high-performing team, because you've got a very clear deadline and focus to build around.

We were starting from scratch. We had no dependencies. We had no debt at all. We could work however we liked. This meant we could build a great, safe team spirit within our team. We could cluster around something we all really believed in. This meant we shared, we supported, and we self-organized. This is one of the easiest teams I've ever managed, because effectively it kind of ran itself with a little bit of kind of tweaking behind the scenes. All of this helped us have a great culture and really perform.

This is the sort of culture we were trying to build within the team. One small, entrepreneurial team against the world. We were sat on our own floor of the office, building our brand new product that the founder loved, no technical debt, no dependencies, working how we wanted. We involved everybody in all the decision making. We were a classic case of autonomy, mastery, and purpose, as Dan Pink would say. It was fun. I mean, it was a heck of a lot of hard work, but it was really fun. We met our deadline. Life was pretty great. It's not often you get to put an update like this on your social network platform of choice. I don't know whether talking about social network on another social network is a bit meta, but I've been up since 5:15 a.m. Who can blame me?

We went big when we launched. We launched with a massive party. There were Premiership footballers, fashion designers. Matthew Williamson stood on the end. For anyone who don't know who Matthew Williamson is, he's a very famous British fashion designer. Somebody made us a cake with the dev team on it. That was a good cake, actually. I should have put things to scale in that picture.

Ultimately, we launched. The press loved us. "Has Net-a-Porter found the holy grail of 21st-century fashion?" "It gives Instagram a run for its money." We thought we were fantastic. We were going places. This was going to be the future of luxury fashion. It was all good, right? Product was great. Team was awesome. We launched on time. I reckon that's probably it, right? I'm joking. I bet you're probably thinking I got you in here with a clickbait-y style title. I've told you about how it was all super successful, and we changed the world. The history of conferences is littered with stories of greatness.

So What Happened?

What actually happened? You might be wondering why we're not all Net Set users now, perhaps. You might be wondering why the flowers don't look quite so happy. There was a merger, and our company founder left as a result. It was at this point we realized that we had all of our eggs in one basket, which was not a good thing. Autonomy is great, but total detachment from a technology, from a business, and also from a geographical perspective is not. We built one small team against the world, and that made everybody else jealous. Effectively, what we've done is built ourselves one big silo. This was not good. It felt like a bit of a cult of the Net Set to other people.

We found maintaining that entrepreneurial spirit that we built once we launched a bit of a challenge. Our attempts at reintegrating back into the company, a company where codebases could be 10 years old, for example, was hard. It was a company with things like change-advisory boards, for example. Whatever you think about change-advisory boards, I'm with Steve Smith on this, they're risk management theater, so just didn't bother going because, "Don't need them. We're the Net Set team".

Six months after we launched, that kind of thrill of selling to market, and the sort of people that really got that thrill out of it were starting to get bored. We started to find they didn't quite maybe fit so well when we needed to kind of scale up our processes, and scale up documenting things, and generally working in a slightly more process-driven way. We stumbled on for a bit. Some people left, including me. the Net Set got rolled, merged in with another team. Then eventually, a couple years down the line, the whole thing got axed. This is what you get now when you google the Net Set. I'm not wondering about the sports shop, though. What is The Dog's Meow? I'm going to Salt Lake City just for The Dog's Meow.

As one might imagine, you'd be thinking, "What could I have done differently?" It's human nature, right? When something doesn't go right, you look, and you analyze, and you think, "How could I have made it so that thing didn't hurt? If only I'd done this, that would have happened." Hindsight bias kicks in massively. The problem with this is you look at the negative stuff. I really firmly believe the first thing you should do when something goes wrong is look at the things you did that went well. Think about how you can amplify those, because it's human nature, in times of failure, just to look at that negative.

There's a lot of things we did in the Net Set team, which I've taken and I've used in other companies, I use in Bloom & Wild, that's helped make the teams that I run successful. Don't forget, in times of hardship, when things go wrong, your teams do some really awesome stuff, and you shouldn't forget that. Remind yourself once in a while.

We Were High Performing - How?

Why were we high-performing as a team? Firstly, there was room for people to grow. This was a team that started small and then grew. We tried to bring people along with us. We involved everyone in decision making, and we set clear shared set expectations of people within the team. We recognized that this team and a high-performing team is greater than the sum of its parts. There are some people in your team who, when measured on output alone, will not look as strong as others, but they're there gluing together the team. They're doing this often without you actually realizing.

It was hard to join this team, we set our hiring bar high. We protected our culture, whether the culture that we built was the right one or not, let's say, but it was hard to join. We ensured the team was diverse, whether that's diversity of gender, of sexual orientation, of ethnicity, of age. Diversity brings diversity of ideas. We had feedback loops, we built feedback loops into our culture. We measured our health regularly, and we course corrected. This was really important. From this comes a little bit of, I guess you could call it my playbook for happy people in happy teams. Set clear expectations in your team. Make your hiring and your joining great. As much as you can, make your own tech choices. Share your learning. Measure your health. Then check in regularly.

How do we do this? Firstly, setting clear shared expectations is all about charters for us. A team charter effectively sets the rules of the game for a team. It's effectively the rules the team live by, written by the team for the team, and shared outside of the team. So this is an example up here of some of the stuff we had in a charter from the Net Set team. We made this together. We held ourselves accountable to this. It's sometimes hard if I say to you, "Give me the characteristics of a high-performing team, and tell me how you're going to hold yourself to them," you'd probably go, "That's a bit hard." If I go to you and I say, "Tell me about the worst team. Tell me some things about the most low-performing team," you'd probably find that a little bit easier because you're all humans.

We've put this together using a technique called reversal. We got the team to tell us all the bad stuff. Like we never turn up on time, for example, or we get nothing done. Then we got them to reverse those statements. Those formed the basis of our charter. We put this charter together, we stuck it on the wall. All the teams knew what our expectations were of them and theirs of us. As a team grew, we revisited this.

Secondly, I mentioned it was hard to join the team. If you want a high-performing team, make hiring and make your joining great. Make sure you spread your net wide. Make sure you're not consciously or unconsciously discriminating, whether that's, for example, through the gender coding of the words you have in your job descriptions. Whether it's your job descriptions are full of bullet points which we know appeal to men and don't appeal quite so much to women, for example. Whether it's, you've got blind reviewing of, say, take-home tests, or whether you've even got take-home tests at all. Some people have commitments, they can't do them. Make sure you raise your brand first. Always be raising your brand, because then when you need to hire, people know who you are. Make sure you take your people in your team through that idea of teach them how to sell you, ultimately.

Then when people do join, make it easy for them to join. What we've started doing at Bloom & Wild is this, which is our onboarding board. This is an idea I got from Melinda Seckington. I saw a great talk she did at LeadDev last year. This is one thing. Everyone who joins gets an onboarding board. This sets their expectations. It also gives them a sense of progress as they move things through the board, as they become more and more experienced. When somebody joins, do that charter exercise, because your team has changed and that new person's ideas are super important.

We were lucky in the Net Set. In the Net Set, we had no technical, no organizational debt. We were totally fresh start, new team, we could choose our technology. As much as possible, I know we were very lucky there, but as much developer agencies you can give, that will pay back. That helps people's engagement. There's a direct link between that agency and engagement itself. This helps your hiring, it helps your retention. It can also go horribly wrong if you allow everybody to pick any technology you like. We started writing the Net Set in Rails, and then decided three months down the line that wasn't the right thing to do, and the back end should have been in Scala. We started again writing it in Scala, and wasted three and a half months when we had a very hard deadline. Hindsight, probably not a good idea.

What Net-a-Porter did really well, it's this idea of a golden path. One technology path, which is supported particularly by the shared teams in the business. You can follow that if you want to, and it's easier to follow it, but if you want to go off on your own, you can go off on your own. So you can choose your own cloud provider for example but if you do that then you are responsible for your own production environment and supporting that. You are responsible for your apps and your technology solutions. This gives enough agency while providing support.

There's downside sometimes to giving too much agency and that is you lock up information in people's heads. We have one guy in the team who was like the expert on our back end platform. That caused us problems when he wasn't there. It caused us problems when he decided to leave. Since then, I've always made sure teams that I run have shared learning built into them. The first step being share what you want to learn. This is another example from Bloom & Wild. We have a shared Trello board of ideas and areas we want to learn so that we can pair together and get people learning together.

We make sure that we allow space to learn. We have something called Tech & Share, which is regular time, no agenda, anyone can present anything, anyone can run any sort of sharing or training that they want. Because I'm very much with Richard Feynman, the very famous physicist, on this. It's like you do not know something unless you try to teach it to somebody else. I think he said teach it to a child. We don't have that opportunity at Bloom & Wild, or Net-a-Porter. I've tried to teach my kids about what I do, but they don't seem to be very interested, so there we go. Allowing those spaces for training and Tech & Share, whether it's through communities of practice you might have, or whether it's through persuading people to come and do stuff like this, or to talk at meetups and share that way. It's super important.

I mentioned feedback loops before. Measuring health as a team is super important. We started this in the Net Set, we do it now. Who's heard of the model that Spotify use for health checks? We use a little bit of a modified. This is the Bloom & Wild version. As you can see, it contains flowers, obviously. This is effectively an activity you can run that really helps focus coaching efforts. It's not a maturity model or some sort of competition between teams or ways of actually measuring one team against another. It allows the team to tell you how they are, tell you how they're failing. Then it gives you the opportunity then to work with them to figure out what they could improve.

We run this every three months. We have a deck of cards. I read out what's on the card. If the team have a deck which consists of a green card, a yellow card, and the red card, if they agree with the positive statement, and they think we're doing that most of the time, they hold the green one up. If they agree with the negative statement, they hold the red card up. If they can't make their mind up, and they want to sit on the fence, they hold the yellow one up.

Because we do this every three months, we can look at the deviation from the previous time we've done this health check. Then we can say, "Let's look at the two that have got better, because there must be a reason why they've got better. Let's look at the two that have got worse, because there must be a reason why they've got worse, and we should do something about it. Then let's look at one in the middle because why is everyone still ambivalent about it." Then we form little groups, which come together around each of those five areas. They come up with some actions on how we can improve. It's empowering to the team.

Here's an example. "We are a totally gelled super-team with awesome collaboration!" This one, right down the middle. We thought, "Better have a look at that one." We did. We got the team together. This particular team loves doing things in Lego, if you've heard of Lego Serious Play. We got them to build their perfect team out of Lego. Then we got them to effectively come up with some actions on next time that particular health check question about teamwork is asked, how it might score more positively.

The final part on the happy teams playbook. This was about measuring team health. Don't forget about measuring individual's health. When I say measuring individual's health, I mean how people are feeling. At Net-a-Porter we had a review timeline a bit like this. Look familiar to people. What did you do? Review every year, review every six months if you're lucky. We should set some objectives at the beginning of that six months, then we have a review at the end, the notion stuff happens in the middle, probably.

That happens in the middle. We get excited about setting goals, and then we forget about them because life gets in the way. Everybody gets asked to give 360 on everybody else at exactly the same time, which when you've got a team of about 16, gets super disruptive. The manager then ends up having to do 16 performance reviews all at the same time, which again, gets super disruptive. We don't do this very often so we get anxious about it. It's natural. It's really demotivating. I have seen this as a factor in people leaving high-performing teams as well.

In the spirit of the Net Set, in the spirit of do it however the hell you like, even though your company works in this way, we decided to make a bit of a change. We did it because of this. Feedback is always better when it's timely, when it's given in the moment, when people have an opportunity to course correct. Slightly selfishly, because I was managing 16 people at the time, I also did it because of this. It's always better when people prepare for their catch-ups with you.

We took a lot of inspiration from Atlassian. We started to run monthly, aligned, themed sessions. Everybody in the team would have the same theme session every month. Their goals will be shorter, so they would only last from one of that sort of session to the next. We got people through a form to tell us how they were before the session, so we could spend the 30 minutes of the session talking about them, not going, "How are you?" "I'm all right." And then afterwards, you suddenly think, "No, actually, I wasn't alright, but he put me on the spot and I hadn't really prepared. I haven't got the most out of this." Effectively, what we're trying to do here is take a performance review process and chunk it up into timely bite-sized pieces of feedback. We operated this within this six-month cycle, but we had to because HR told us we did, and everyone in the team absolutely hated. We asked questions in these.

We have one called removing barriers. We say, "What barriers have you encountered to your work over the past few months?" For example, at one stage in the Net Set, everyone was telling us the bill pipeline was too slow. We know we need to invest, therefore, in the pipeline. We have one called love and loathe. "What have you loved over the past few months? How can we do more of it? What have you loathed? How can we do less of it?" One that looks at career, "Where do you want to head to in your career? Has anything changed since last time?" Sometimes it's just nice to get feedback.

The timeline looks a little like this. We do this in Bloom & Wild as well. I've actually written about this. These happen at different times throughout the year, but everyone gets the same one. Effectively, what we're doing is we're helping engage the team. By doing this often, we're helping to remove the anxiety and the demotivation. We're introducing short, small feedback loops.

Above all, frankly, keep it fun. It's one thing for a team, keep it fun. This is a Christmas retro we did with beards and Santa hats and dodgy Christmas jumpers. Doesn't quite go with the really nice-looking office, does it?

Effectively, this is what made the Net Set high performing. These are the things that I've taken on to other teams. Don't forget about the good things, especially in times of failure. Meanwhile, let's get back to our story.

Recap

A little recap. We were this team sponsored by the company founder. Starting from scratch, no dependencies, no debt, we could do whatever the heck we like. That meant we could build a really great team spirit. We built a one small team against the world culture within a much larger company. Then the founder left, some of our people kind of got a bit bored. Everyone hated us because of all one small team against the rest of the company approach. That meant maintaining that spirit was challenging. Our product ultimately got axed.

We could and we should have recognized that there will be change. We were bringing something to the market quickly, with a team that was working very hard. We were a bit blind to change. We didn't open up to the team about the fact there will be changed. We didn't tell and work with the team to understand what that change would be when this thing launched, because that's a big difference.

I'm sure everyone's seen this before. It's kind of the standard change curve thing. We believe, as humans, we go through change in roughly this way. There's a few subtleties to this that I wish I had explained to particularly people in the Net Set team. You can move backwards on this, as well as forwards, this isn't linear. You don't just start in denial and then suddenly move to commitment after a while. Something may change that may move you backwards. Maybe you might work really hard and then launch a social network, for example. It's all about making this okay, and making this clear to people that it's okay to feel anxious about change.

Because as any product ages, the team changes. We let people sometimes get a little bit frustrated in their roles, for example. I can't remember who told me this quote, but it's a really great one. Your role as a manager is ultimately to get your team member ready for their next role, whether that next role is in your team, in your company, or elsewhere. We didn't do this in the Net Set team. We tried to hold on to everybody, one small team against the world. Why wouldn't you want to be a part of this one small team against the world? Ultimately, we lost people as a result.

I really like this quote as well. This is from Heidi Helfand. She's written a book called "Dynamic Reteaming," which is really good. There's a picture of it in the last slide. I'd really recommend it as book. It's very good. All these things you do as your team changes, because your team will change because your product is changing. One person is new, or one person leaves, you fundamentally changed that team. Anything you do, whether it's team building activities, whether it's charter activities, whether it's resetting how you measure or when you measure health in that team, you should do that when one person joins, or when one person leaves.

This applies to leaders too. As I touched upon earlier, I left the Net Set team, and I found the replacement to me. Some of those activities I've done around charters, around health, around check-ins and measuring individual health, this made it very easy to hand that over then to somebody new. Cake can play a big part in all of that, of course. The cake has a dark side. We had this cake ultimately, and everybody wanted a slice of our cake, but we were one small entrepreneurial team against the world, and we weren't going to let them have a slice of it. Ultimately, we were arrogant, we were hidden away. We cared about ourselves. We were missing a lot of this as a result.

Trust

This is super important. This is the most important thing to ensure that you build, in my opinion, in a high-performing team, both inside and outside. We had a problem with trust, other people didn't trust us. When the company founder left, we realized that none of the senior business leaders really trusted us either. They didn't get what we were about. I thought a lot about trust since the Net Set team.

I have come to this. Watch out for the signs. Your role as a leader of a team is to watch out for these signs, whether it's frustration, "I can't believe the Net Set team are doing this." Or equally, "Wat are the Net Set team doing? I don't care what the Net Set team are doing." That should be a good heuristic to you as a leader to say, "Hang on a minute, something's not right here. There's a trust problem." Or, "No, the Net Set team, why would I want to use something they've used? I didn't invent it." Or the worst one, "Well, of course, you can do it like that, because you're in the team that's special." I wish in those situations I talked to that person, "How can I get you involved? Whether directly or indirectly, how can I engage with you? Not, 'Well, of course, you can do it like that.' Yeah, I can. Thanks very much. Bye".

I wish I'd done more of this. Sharing. Much more sharing. Without visibility in sharing, there is no trust. As an aside, this is a really, really good blog post to read. I would very much recommend it. Trust itself is made up of many different things. I really like this. This is from a book called "The Trusted Advisor." It's called the trust equation. And it goes something like this. Credibility, i.e., how well do you actually know what you're talking about? Plus reliability. Do you do what you say? Plus intimacy. Ultimately, how safe do people feel sharing with you? All divided by your apparent self-interests. How much do you care about yourself?

Let's use an example. Let's say you're getting a builder into your house to quote on something, you want an extension to your house. You might do some research on them. You might get some referrals from somebody else to establish whether they're credible. Do they turn up on time to give you the quote? Maybe they're reliable. As they're quoting, and as you're talking through with them what you want done to your house, do you feel like they really get what you want, and they really understand it, and they really want to build you the best extension to your house that they can? Or do you get interrupted three times, they take other calls for other quotes, and they appear massively self-interested? I found this is a really good way of just sense checking trust in different situations.

This applies in a couple of cases. Let's look at trust within the Net Set team. Credibility, high. We talked a good game, we knew what we were doing, and we knew we knew what we were doing. Reliability to our founder, high. "Please launch it on my 50th birthday." "Click, there you go." Intimacy within the team, very high. We looked after ourselves. We understood each other. Our apparent self-interest was low because, to each other, we cared about our product. We cared about each other. Our trust in that situation, I would say, is pretty darn high.

What about outside the team? Let's say to the top dogs, sorry bad joke :), in the company. Credibility, I'd say, was kind of around about medium. They knew we had some good devs, so we must be doing something good. Our reliability wasn't very good because we weren't delivering anything for them, we weren't really making any money for the company. Yes, we launched, but I'm not sure whether they even got an invite to the party. Intimacy was low. We were arrogant. We were hidden away. Our self-interest was massively high. Where we relied, for example, on APIs written by other parts of the company, we'd spend more of our time complaining that the responses were slow. Not working with the team to try and figure out how they could be made more quick. Ultimately, trust outside of our team, pretty low. Always focus in both directions. Focus out and focus in when you're thinking about trust.

We focused in far too much and that got us to our launch, but after that, we realized we'd made a mistake. By that point, I'd argue it was too late. What could we have done to focus out more? What could you do in these situations to focus out more? Firstly, we had an API. Why not open up that API to the rest of the company? Why not have some sort of shared hack day, for example, where you can work on solutions building on top of that API, talk in a language that everyone wants to talk in and understand? We could have opened up our team more, we could have shared more through blogs, through newsletters, through all-hands meetings, perhaps a little less arrogantly. We could have helped others to discover and engage better. Shared user testing and beta testing groups are great example of this. If you've got something new and you want people to use it, get people within the company excited about it. That will build trust too. It's all about alignment rather than ignoring. I mentioned the change-advisory boards earlier. I should have gotten to the change-advisory boards. That was important. I didn't. It's all about engendering trust, rather than jealousy.

If you do one thing, do these things, build credibility, reliability, and intimacy, reduce apparent self-interest, and ultimately, this will increase trust. Trust is what you want.

And If All Else Fails, Keep Building High Performing Teams Anyway

You may be in a situation right now where you're saying, "Yes, I'd love to do that, but the rest of the company is actually a bit rubbish. I've got this high-performing team and it's really important. What do I do?" Firstly, don't give up. You got a high-performing team, that's an awesome thing. Figure out how you can work around this. Maybe focus your team inwards, and as a manager, do part of your job which is shielding them a bit. Be careful how much you shield. Don't build one small entrepreneurial team against the world where the world is the rest of the company. It will come back and bite you. Ensure that alignment yourself, whether it's through goal setting or whether it's through how you communicate with the people within your team.

If people aren't getting the support within your company, find them an external network, whether it's through reciprocal brown bag sessions, for example, and lunch and learns, whether it's through meetups, whether it's through coming to stuff like this and promising not to talk to each other for two or three days, and meeting new people. All of that is really, really important. If all else fails, leave. Sometimes it's better to go somewhere else and build a high-performing team somewhere else. I was part of a high-performing team. It was a short period of my life, it didn't last forever. We made mistakes, just like other teams do. Those mistakes threaten the life of the team and the life of the product.

What would I do if I could do this all again? Firstly, I'd keep doing the good stuff because the good stuff is really important. I'd recognize and I'd be more open on the need for change. I'd reboot the team regularly. I'd watch out for those signs from other teams, the frustration and ignorance, not invented here. Trust. I'd build that trust by focusing out as much as I focused in, whether it's opening up that technology and opening up that team. I'd build trust, not jealousy. Then finally, if all else fails, I'll just get on with it anyway, frankly. What did I do? I left and I joined the company where I can do all the good stuff that I've talked to you about, and I can do it across an entire organization. Maybe you could join us. If not, maybe you'd like lovely flowers, and you'd like to get them a little bit cheaper.

These are the two books that I mentioned as we went through. The slides, I'm sure, will get shared out. They've got the links to the different blog posts and stuff.

Questions and Answers

Participant 1: I run a team of about eight people [inaudible 00:43:31] locations and people are one of the things. I was quite pleased to know that it gelled quite a lot with what I do. Where does empowerment sit here? Because one of the things that I try to do with my teams is empower everyone. Did you come across any situations where you felt that if the team was empowered, then they wouldn't really need you to do all that shilling and everything? Where does that sit?

Janaway: If the team's empowered, then great, frankly. You need to do effectively less of that. What you need to do if you've got a much empowered team and a disinterested everybody else is much more of that focusing out. I found that empowerment was needed. I needed to do a better job of empowering the engineers in my team to want to focus out. If anything, I did too good a job of shielding them, and I let them be shielded. If I could do it again, I wouldn't do that. I would double down on it, making sure that they, as much as myself, were building that trust outside of the team.

Participant 2: You've talked about how you looked after your team or your teams. I was wondering if there were any similar pieces of advice you've either tried, or not tried, or advised for maybe dealing with your peer group, or managing up? Have you tried some of those techniques? Have any of them worked?

Janaway: I think peer group wise, it's a lot of that focusing out activities. It's about actually getting people interested. I was trying to figure out what that hook is. For some of my peer group in this particular scenario, it was quite easy because they were technology leaders in another part of the business and we were using some of their technology. It was about doing a decent job of showing that we cared about their solution. For example, we were pulling a bunch of products through a product feed through an API. When we launched, I went out to that team and said, "Look, we're going to launch and this is the impact. We've done some load testing. Can we work with you to do that," so about effectively building that trust.

The managing up piece is kind of interesting. I think it depends very much on the organizational structure you're in. In this example, I had a boss who managed a number of different disparate groups of technology solutions, rather than managing one product. He was very, very interested when we were about to launch because it was the founder's pet project, and it was the founder's 50th birthday. If I didn't do my job right, we didn't launch right, then it wouldn't reflect great on him. A lot of the rest of the time, he wasn't quite so kind of interested, which I guess is because we were doing things right. We didn't need help. It was about keeping putting what we were doing on his radar so he wouldn't completely forget about us.

See more presentations with transcripts