Accidentally in Code

Tag: management

  • 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?
  • Org Survey Part 1: Questions

    Org Survey Part 1: Questions

    Danbo_vs_Domo_vs_Minato_Mirai_(8839397350).jpg
    Credit: Wikimedia

    I remember when I managed a 6 person team, and I always felt like I had a handle on what was going on (perhaps I’m being overly nostalgic here). Now I manage a ~26 person organisation, and on a good day I feel like I have a general idea of what’s happening, and certain specific things that I’m focusing on in more depth.

    For all the effort I make to be accessible and to build a relationship with individuals on the team, the reality is that a bi-monthly 1:1 and the odd slack conversation can only go so far. This is managing at a level of indirection.

    A couple of months ago, with some input from existing practises, HR, and my colleague John, I put together an organizational health check. This took the form of two two-part surveys (using Google forms), that I’ve since refined and helped my peers use for their orgs.

    Survey 1: The Org Survey

    This survey goes out to all ICs on the team. The first set of questions focus on their overall impression of the org and org leadership.

    1. My org lead communicates division strategy and direction to me in a way that’s clear and enables me to act on it.
    2. My org lead regularly shares relevant info from the company, org, and other relevant parties.
    3. My org lead has articulated to me a clear vision for the future of the org.
    4. I agree with the vision that my lead has articulated for the future of the org.
    5. The org is aligned with the the mission of the company.
    6. The mission of the company is the right one for the future.
    7. The org is high performing.
    8. The wider organisation recognises the performance of the org.
    9. My org lead provides a space for me to use my voice, and really listens when I do.
    10. My org lead has helped me develop as an individual or leader on the team.
    11. My org lead has actively supported me with technical or people issues.
    12. Any other comments about the org?

    The second set of questions focuses on their direct manager.

    1. Which team are you on?
    2. My direct manager gives me actionable feedback that helps me improve my performance.
    3. My direct manager does not “micromanage” (i.e. get involved in details that should be handled at other levels).
    4. My direct manager shows consideration for me as a person.
    5. My direct manager provides a space for me to use my voice, and really listens when I do.
    6. My direct manager keeps the team focused on our priority results.
    7. My direct manager has had a meaningful discussion with me about my contributions to this project in the past six months.
    8. My direct manager communicates clear goals for our team.
    9. My direct manager has the relevant expertise to effectively lead me.
    10. I would recommend my direct manager to others.
    11. Any comments?

    Survey 2: The Manager Survey

    This survey goes out to all managers. The first set of questions are the same as for the first survey. The second set are slightly different but substantially similar to the first survey – except that because it’s just people who report directly to me, I can use my name rather than “direct manager”.

    1. Cate gives me actionable feedback that helps me improve my performance.
    2. Cate supports me in developing my own leadership skills.
    3. Cate shares interesting and helpful resources with me to make me a better manager.
    4. Cate has the relevant expertise to effectively lead me.
    5. Cate does not “micromanage” (i.e. get involved in details that should be handled at other levels).
    6. Cate keeps the team focused on our priority results.
    7. Cate communicates clear goals for our team.
    8. Cate shows consideration for me as a person.
    9. Cate has had a meaningful discussion with me about my contributions to this division in the past six months.
    10. Cate has had a meaningful discussion with me about my career development in the past six months.
    11. I would recommend this org to others.

    These fall under the general categories of  Development (1-4)  / Priorities (5-7) / Appreciation (8-10) / Recommend (11).

    My hope is that these topics come up in our 1:1s, but there’s something to be said for stepping back and looking at the overall picture as a series of graphs. It’s hard to get feedback as a manager, and it’s hard to trust the feedback you do get – so this can be a helpful checkpoint.

    Now What?

    Well… wait.

    Next week, I’ll share how I analyse the data and make it actionable.

    For now, if you want to use these, I’ve made a shared folder available. Feel free to make a copy and customise them!

    See part 2: Analysis.

  • Running an Effective Mobile Team, Part 4: Building Connections

    Running an Effective Mobile Team, Part 4: Building Connections

    Ghosts-Cute-Funny-Fun-Ghost-Toys-Plastic-Fig-1124534.jpg
    Credit: Max Pixel

    Connected: People work together and take an interest in each other (this doesn’t mean everyone has to be friends – but they are friendly).

    Problem: We lack a clear model for mobile infrastructure. This leads to discussions like whether to have a mobile team or pods.

    Regardless of what your “mobile teams” look like – product pods? A small team that focuses on mobile? Some new configuration that hasn’t been Think Pieced on Medium yet? You have a challenge of connection.

    In a dedicated mobile team, how do mobile engineers connect with the engineers working on front end features? Or the engineers developing the API? Was the API written with mobile in mind? Or does it… work on someone else’s machine?

    Often the answer to this is to have product pods. Which is great – people have been known to build an API that actually works well for mobile this way. But a good app is not just a collection of features. It’s an architected thing that has components that are shared throughout – some notion of user identity, a networking layer, a database. Ideally it follows some standard patterns that are – gasp – possible to write unit and integration tests for. It’s also going to need to be mindful of memory management – mobile is a constrained experience not just by screen size.

    There’s a joke about micro services. It goes:

    “I’ve split the application up into seven micro services”
    “So you have seven teams that hate each other?”
    “How did you know?!”

    Now this isn’t a good way to run any team. But there is no micro services architecture for mobile. Regardless of your configuration, people are going to have to – revolutionary idea – talk to each other. When you organise teams to better facilitate some kind of communication, you make the other kind harder.

    Since there is no micro services architecture for mobile, there is no way for one team’s architectural decisions not to affect the rest of the people working on mobile. Bonus! We are still evolving our patterns and standards for architecting mobile applications. There’s not currently the concept of a “mobile infrastructure engineer”, and great mobile engineers are usually more product focused. How’s that move to VIPER going? What percentage of your iOS app is now in Swift? How’s that networking layer written 4 years ago or so holding up?

    Let me guess: behind schedule / around half / err… not so well.

    OK, but we can’t make people like each other, so now what?

    Align Incentives

    The best way to get two teams to fight is to give them conflicting incentives. Incentivise one team to Ship Maximum Features As Fast As You Can and another team to Maintain Zero Crashes, sit back with the popcorn and watch the show.

    If you incentivise one team to move metrics around user engagement and happiness, and another team to maintain sustainable execution… well it will probably be less like robot wars and more like a functional work environment.

    Invest in Infrastructure

    If your app is badly architected, everyone will pay for that every day. If your networking code is a mess, it will bleed through your entire application. Invest in the things that make everyone more productive and guess what? Everyone will be more productive! These things are often harder to explain to product and business, but every team should have some maintenance time – be strategic about how you use it.

    Build a Team

    The easiest way to build relationships quickly is to unite against a common enemy. This is a short term strategy and not conducive to long – or medium term – good work environments. Your team is not just the one denoted by the org chart. A team is a group of people who work together to achieve a shared goal. Ignore the org chart for a moment, and think about something you’re trying to achieve. Who is on your team? Who do you need on your team to be successful? Reach out to them.

    Read the next part, on automation.