Accidentally in Code

Tag: management

  • How do Developers Define Success?

    How do Developers Define Success?

    This is part 2 of a series of blog posts based on a talk I prepared called Successfully Derailed Product. It’s about the ways in which we define and talk about “success” influence what – and how – we build. See part 1.

     With the caveat that how we define success comes from various places, and any collective definition is most likely nonsense. I set off to understand the ways in which developers, and particularly individual contributors think about success.

    I started with the Stack Overflow survey. Caveat: I hate it and I think it’s riddled with bias. For example, women make up ~fifty percent of the population, around ~twenty percent of technical roles… and 7.2% of the respondents to this survey.

    So let’s start by looking at how developers feel about jobs and careers. Developers tend to be pretty satisfied with their career, a bit more so than their current job.

    This slideshow requires JavaScript.

    When looking for their next job, the top priorities are professional development, compensation, office environment and technologies.

    Capture d’écran 2018-03-23 à 09.14.15

    The most valued parts of compensation are vacation time, remote options, health benefits and expected work hours.

    Capture d’écran 2018-03-23 à 09.15.18

    Most developers check in code multiple times a day. And the more often they check in, the happier they tend to be.

    This slideshow requires JavaScript.

    Success metrics developers would choose are: customer satisfaction, time and budget, peers rating and product performance. It’s interesting that manager ratings and self ratings are considered about as useful. Not a ringing endorsement for managers there.

    Capture d’écran 2018-03-23 à 09.20.01

    So to rounding out the quantitative data riddled with bias, I got some biased qualitative data in the form of posting a question on twitter.

    I got some interesting responses. But I’d also love to know what you think. (Leave your answer in the comments or tweet at me).

    Many of the themes from the Stack Overflow survey showed up here – shipping code, learning and developing, autonomy.

    Capture d’écran 2018-04-01 à 16.40.39

    There was also a theme of recognition – including financial. Which makes sense, because as as society money is the usual mechanism by which we communicate value.

    Capture d’écran 2018-04-01 à 16.40.42

    People also talked about the way the sense of accomplishment changes (or has to change) as your job evolves and you take on more responsibility.

    Capture d’écran 2018-04-01 à 16.40.48

    Another theme, though, was the theme of impact. People using what was built, benefitting others in some way.

    Capture d’écran 2018-04-01 à 16.40.44

    The graphs show trends, but people’s personal definitions show that success is personal. We see the baggage people bring with them from previous (external) definitions, the way that definition changes over time, or that what we believe is important conflicts with what makes us happier in the moment.

    It was noticeable to me that women who responded seemed much more likely to talk about the supporting others in some way – whether their teammates, or people using what they worked on. There are a number of different observations we could make here – one is that the patriarchy trains women to consider others in a way that is not as true for men. But also it hints at what might be different about those survey results if they were more representative of the demographics of the industry – and what could be different if the industry were more reflective of society as a whole.

    What’s next? A look at the way we talk about team success.

  • Try This One Weird Tip To Increase Leadership in Your Organization

    Try This One Weird Tip To Increase Leadership in Your Organization

    For-Two-Together-Cup-Danbo-Figures-Coffee-Cup-1865513.jpg
    Credit: MaxPixel

    As leaders, most of us have been in a place where we’re maxed out. It can be tempting to just do it ourselves and hope things improve. Another thing that often happens is that it gets shoved on someone else, and they’re left to deal with it.

    As a rule, I try not to hand things off without offering some support to those I’m handing it off to. So for example, a conversation about if someone wants to try being a team lead will include:

    • The question of what they’re open to / interested in.
    • Some insight into why I think they might be good at it.
    • The kind of support they will get.
    • The question of: what kind of support would they want to feel comfortable with things.
    • Time to think about it.

    Some people thrive on being thrown into the water and left to sink or swim. But that’s not appealing to everyone – and it can be particularly unappealing for those for whom failure is much higher cost (like… people who aren’t white men). Making the prospect safer makes it seem more possible for a more diverse set of people. Bringing the conversation of support up front makes it less like it’s addressing a problem, and more like a normal part of taking more on.

    I’ve come to observe that sometimes those who feel they need the most do the best over the medium to long term. They are more likely to embrace the help available to them, work harder to overcome natural preferences, and pay that support forward to others on and off their team. It can be a leading indicator of those who will level up and those who will burn out.

    As a rule, I expect to spend a third to half the time that it would take me to do something badly on helping someone else work up to doing it well. E.g. if I had an eight person engineering team, and I wanted them to have a manager who wasn’t me. For me to do a poor job of it would probably look like about ~4 hours per person per month (32 total), broken down:

    • 16 hours of 1:1s a month.
    • Another 16 hours of misc. activity (4 hours of team meetings / misc follow ups).

    But, if instead of an eight person team, I have one manager, I would have:

    • 4 hours of 1:1s a month.
    • Another 8-12 hours a month of ad hoc support, reviewing etc (incl. 8 hours of skip 1:1s per quarter).

    So now I’m spending 12-16 hours a month, instead of 32. But instead of a minimum acceptable level of management, the team is getting a better manager – and that manager is getting a good level of support from me (and likely taking on some other things beyond people management as well). Perhaps I haven’t saved that much time, but I have scaled in a way that should help the team execute better, and mean there are fewer emergencies.

    Tried this? Benefitted from this (I know I have)? Leave your story in the comments!

  • Process Design

    Process Design

    (or: be careful what you incentivise)

    danbo-danboard-japangirl-toy-84368.jpeg

    When we design processes, we are heavily biased to design processes that we would be successful in. We see this with hiring processes, and we see this with promotion processes. You might think having multiple people would help with this but this seems just as likely to create the very narrow process that set of people would all be successful at.

    Feedback on processes will also come from this bias. This doesn’t mean that it should be ignored, but does mean that it needs to be analysed critically and different questions asked.

    Processes need to be compatible. If you have a hiring process and a promotion process and you will hire people into roles you wouldn’t promote them into, and promote people into roles you wouldn’t hire them into… something is wrong with one or the other, but most likely both.

    Your process encodes your values in the things that it incentivises. Any process that involves stack ranking incentivises diminishing others. When you incentivise technical complexity you tend to get a lot of it… not all of it necessary. If you have a process that makes it hard-to-impossible to hire people managers… you will end up with poor management.

    How do we minimises the process? In hiring I ask: what are the minimum things that we need to see someone being capable of. And then ask: how is this person great? People need to be able to function on the team, but we also want people who will add to the team in new ways – ways that can (and should) vary per person.

    In asking people to take on more responsibility I ask, who makes the whole team better? Technical capability doesn’t go very far unless people engage and pass it on. But interpersonal skills are not always sufficient to get things moving.

    It’s easier as we grow to create ever more process – sometimes with the ideal of fairness – but actually what that gives us is a longer list of things to selectively apply, and more and more reasons to say no.

  • Book: How F*cked Up is Your Management?

    Book: How F*cked Up is Your Management?

    how_fucked_up.jpgHow F*cked Up is Your Management? is a collection of essays, many of which I’d already read on Medium. I did like it though – there’s a value to reading a curated collection the builds upon each other. Also, I want to support people writing things that I appreciate.

    Some of it’s really good and actionable – like the stuff about hard conversations, but some things (like hiring product people and what good product people do) lacked some depth. It sold me on the idea… But I didn’t know where to start with the execution.

    One thing: whilst the book talks well about diversity and inclusion, but I think only cited men as management resources (and one of them is pretty problematic), so that was a bit disappointing.

    Overall: short read and worth the time.

  • Simple Leadership Podcast

    Simple Leadership Podcast

    Capture d’écran 2017-11-07 à 22.13.51I recorded an episode on managing managers. We talked about getting feedback, coaching, and why peer support is so important.

    It was really fun to record, and I hope you like it!

  • Monthly Rituals: Snaps

    Monthly Rituals: Snaps

    Screen Shot 2017-09-07 at 17.22.30.png

    A few months ago, I started putting up posts like this each month. Some other teams started doing it too.

    I like the idea of encouraging people to take a moment for what they’re happy about, and the things others have helped them with.

  • On Skip 1:1s

    On Skip 1:1s

    danbo-2008791_1280.jpg
    Credit: Pixabay / Alexas_Fotos

    One of the first things I did as a new manager of managers was schedule skip 1:1s with everyone on the team. I blocked off an hour per person, and crammed ~20 hours of them into my first two weeks – along with a lightning trip from Buenos Aires to Philly for WordCamp US.

    It was exhausting, but it was also illuminating. Change can be hard, and change in leadership can be especially scary – making that time for people, getting to know them and taking any questions they had of me – taught me a lot about what was going on in the team, and helped me be more successful.

    Some of those first 1:1s were pretty dramatic. Lately they’ve not been as exciting, but that’s good. The goal isn’t just the meeting itself, the goal is to have a connection to people on the team, a more nuanced sense of what’s going on.

    My standard set of questions are:

    • How are you? Good to include life-specifics if there are any, e.g. “How was your vacation?”
    • How are things on $team?
    • How’s it going with $project? Mention recent achievements here if applicable, “I’m excited that X shipped!”
    • Do you have any questions for me? If someone doesn’t have anything, I typically respond that it’s fine if they don’t have questions for our 1:1, if that means they ask me questions as they have them.
    • Do you have any feedback for me? If there’s nothing, one thing I’ve been trying lately: “Do you have any advice for me?”

    It turns out, you can totally fill an hour with these questions if they turn into a conversation (which hopefully they do) and they cover what I care about:

    • How are they personally?
    • How do they feel about their team?
    • How do they feel about their work?
    • Is there anything they’re wondering about?
    • If there anything they want to change?

    For managers it can feel weird that someone else is having a 1:1 with your directs. A tip I learned from my friend Julia Grace is to always sync with the manager ahead of time. Now we’ve done it a few times, it’s not a big deal for most people and I just give a general heads up, unless there’s something the manager and I are worried about, in which case we’ll sync up ahead of time and make sure we’re on the same page.

    For scheduling, group teams together which is quite exhausting, but also makes it easier to see trends. Afterwards I’ll follow up with leads with any feedback or broader questions (e.g. if there seems to be a pattern). At first I found them a really important mechanism for getting managers feedback. Over time, we’ve developed different methods (e.g. feedback surveys, org surveys) and as the teams are running better that’s become less important. I generally think it’s a bad sign if I come away from a skip 1:1 with direct TODOs for that person, but sometimes people raise things that we discuss in the weekly leads call, or that I try and clarify for the entire team in an internal blog post.

    I try to offer people a choice of format, unless say I just had tonsillitis and look like a reanimated corpse and then I might rule video out. At Automattic, we do a lot of 1:1s via text, which I actually really like. It might seem strange, but when people are used to it, you can have really good 1:1s via text, and I find it much less stressful than blocked off hours of back to back video or voice calls. I use Google calendar appointment slots to schedule, and if I know I’m going to be coworking or similar I mark them text only.

    Skip 1:1s can feel really time consuming. I do them every other month, and I know on the months I have them it’s pretty stressful to block off all that time on my calendar. It’s easy to feel like you don’t have time to do them, but I’ve concluded that I don’t have time not to have a connection to everyone on my team, I don’t have time to only find things out when it’s a crisis, and I don’t have time not to hear people’s questions as close as possible to when they have them.

    If you liked this, you might like my post On 1:1s.

  • The Magic of #FEELINGStime

    The Magic of #FEELINGStime

    Danbo-Funny-Figure-Phone-Booth-Phone-2050791.jpg
    Credit: PxHere

    A truth that should be universally acknowledged – but isn’t – is that a group of hardworking people do not necessarily make a high performing team. On a basic level, a group of hard working people checking code into the same codebase isn’t necessarily a team. At a more complex level, hard work doesn’t necessarily correspond with progress made, and progress perceived. It doesn’t necessarily correspond to user benefit, or to things shipped. Hard work doesn’t mean smart work, it doesn’t mean valued work, and it isn’t necessarily rewarded.

    The difference between a team that is killing it, and a team that is… not, is not necessarily measured in commits. It’s not measured in meetings, or design documents, or other arbitrary things. A team that is killing it has an energy, and an excitement. A team that is killing it is shipping. Not just checkboxes and release notes, but shipping as in, delivering meaningful improvement to users. A team that is killing it is not competing with anything other than themselves, who they were yesterday, who they think they can be tomorrow.

    Every other month I put together something we call “The State of All the Things” for our team (a ~26 person x-platform mobile team). It’s where we take stock of our multi-month, multi-engineer projects, where they are at, what we expect next, and how that compares against where we thought we would be last time. When I put together the last one, it was clear that a bunch of great stuff had happened since, and that as a team we had more momentum. This also showed in the ways I personally was able to spend my time – less time on fires, on the emotionally draining work that goes into making a team more effective. More time on longer term things, on problems that had seemed impossible to contemplate and all of a sudden started to slot into place.

    A lot of the work to get here was outlined in the series I did on effective mobile teams. But there was one thing that I haven’t really written about.

    I have five managers who report to me, and we invested the time and effort into making them a team. I really think this is core to all the improvements we’ve made as a team this year.

    The first thing was that we were explicit that they were a team. We had a team meetup (really more like a plagueup, as we were all sick – we had team outings to CVS for drugs). We started a weekly team meeting. I was explicit in the langauge I used that they were a team, and individually they served the teams they lead, and in time their language changed too. As we onboarded new managers, we onboarded them into that team.

    The second thing was that we worked on being open with each other. Management is often extremely lonely – especially when things are hard. We start each team meeting with what we call “#FEELINGStime”. Everyone says how they feel. This gets us straight to the most important things happening on the team as a whole, but also gives us context on how the others are doing. It gives us space to confess to the things we are struggling with, or proud of, without it seeming like we were being “checked up on” or bragging.

    The third thing was that we actively support each other. After #FEELINGStime whoever is happiest takes the team chore for the week. We’ll role play tough conversations with each other, help each other out, review each other’s drafts, and provide encouraging feedback – sometimes something felt really tough, but someone looking from the outside will be really impressed by it. Sometimes multiple people are just struggling with the same things, and it’s reassuring to feel like you’re not alone in that.

    When it comes to management, I really believe in peer support – I work very hard to be a good manager, and support the managers on my team, but I know it’s better for everyone if they get that support from elsewhere, too – and where better than each other?

    If you’re looking for peer support, you might like the Eng Managers slack.

  • Org Survey Part 2: Analysis

    Org Survey Part 2: Analysis

    This is the second part of running an org survey. You can find the questions in part 1.

    What Does The Data Look Like?

    First step is color-coding the spreadsheet to show trends in the numbers. I made a sample spreadsheet and generated random data – so it looks a little chaotic – but you can see how patterns would (hopefully) emerge if it was data from you know… actual humans.

    I used conditional formatting and the colors matched the scale used – so green is good! And red is… not good.

    This is all set up in the template spreadsheet. This is in the Google Docs folder with all the templates – including the survey templates from part 1.

    My random number generators are not particularly happy with Management

    How Does the Data Break Down By Team?

    Now we can break out the answers by team! For each question you need a new sheet. The spreadsheet has a template one.

    This might look like a lot of work, but it’s all automated. All you need to change is the B column and the chart title. If you pull in a different column, everything will regenerate and you’ll get a nice new graph.

    There’s programming in this spreadsheet 😂

    How Do Managers Compare?

    In the graph above we can see that bunnies are either very happier or very sad, raccoons look to be least happy, and owls are somewhere in the middle. This allows you to see whether some teams seem happier than others, and it’s a good conversation to have with the manager of that team about why they think that is.

    You can also use this spreadsheet to generate graphs for just individual managers by deleting some of the data. Make a copy, delete the data for other teams, and everything will regenerate. I make a master sheet for the overall team, and then I make a copy for each manager and delete the data for other teams so that they can focus on their own results.

    You can also compare your overall graphs with the ones generated by the manager survey. Because the first set of questions are the same, this can be a really helpful way to see what managers aren’t feeling great about – and if they’re not feeling great about something, it’s pretty likely that filters down to their team.

    Now What?

    This is all just data. What’s next?

    • Think about the relationship between your manager results and your skip level results – does this give you any ideas of things you can focus on?
    • Think about your team breakdown – what’s the variation like between teams?
      • Are there ways that some teams are more set up to be successful than others?
      • Are there things the managers of less happy teams can work on?
      • Are there things that happier teams are doing particularly well that could be socialized better?