Tag: process

  • Scaling Teams: People, Projects, and Process

    Scaling Teams: People, Projects, and Process

    Credit: Spencer Watson / Unsplash

    Scaling teams is one of my favourite things to do – probably because it’s where people meet systems, with ever-changing questions about what makes teams effective and how to balance now versus next.

    Sometimes this gets presented in a pure numbers way, but I like to come at it from a systems perspective: Engineering teams have three primary components: people, projects, and process.

    Strong teams of people who are individually doing well, deliver business value, predictably and efficiently.

    I don’t include process in that statement deliberately – good teams are not defined by their processes, good teams use and evolve process effectively in order to meet the organizational need. My hot take: engineers often love process, but when they love it, they call it culture.

    This post builds on a previous one about what makes a good team. This is about how to scale one. Scaling teams requires attention to all three of these components, identifying and addressing bottlenecks as (or ideally before) they emerge.

    People

    Having enough people (hiring) – As you scale, your hiring process needs to be effective – can it be improved? Should it be improved?

    The process needs to be efficient without sacrificing quality. It’s not enough to just hire people – you also need to make them effective. Good onboarding is predictable.

    Note that whether the hiring process is working well isn’t impacted only by the stage and needs of the team, but also by the market. The market has been a wild ride the past few years, and AI has presented additional special challenges. It’s worth thinking regularly about whether your hiring process is a good predictor of success, and if you have concerns about that, what you can do about them.

    Ensuring people are properly supported (managers/leadership) – in an ideal world, everyone gets a good manager. Sometimes “good enough” has to do.

    As teams scale, you need to grow your management layer thoughtfully. What blend of hiring and growing internally makes most sense for you? Both of these take time and have their own associated risks.

    Feedback loops/culture – feedback loops need to be solid. Under-performers are addressed (up or out), high performers get developed. As teams grow, individuals can be lost sight of, and when there’s pressure often high performers get taken for granted rather than developed further.

    If you want to build teams where high performers can thrive, you need to make sure that good work gets rewarded and poor work gets addressed. Feedback loops are foundational for this (more on that in this post on 1:1 structure).

    Team alignment and values – larger teams need more deliberate alignment. What are the shared values and principles that guide how the team operates?

    A team is formed based on what they share. Is that some shared ownership (like a codebase), or a mission (like a flow or feature). What metrics is the team responsible for? As teams scale, the scope of what they can cover adjusts, so you need to come back to the shared purpose and figure out how that needs to evolve, too.

    Projects

    What is being worked on and why – clarity of purpose becomes even more critical as teams grow. Everyone should understand the portfolio of work and how it connects to business value.

    With more people, what used to be obvious starts to be less obvious over time. You need to get more explicit about metrics, mission, and goals, and more structured about prioritization and decision-making.

    Work allocation becomes critical. For small teams, there’s often a ‘goto person’ who gets pinged for everything, but the more people you have, the more important it is to create transparency, equity, and accountability in work allocation.

    Effective project management – it’s not enough to pick the right work, you also need to deliver that work, and to continue to deliver consistently over time.

    This means thinking about the project life cycle:

    • Set projects up for success – clear goals, well defined scope, and the right people involved from the start.
    • Keep projects on track – larger teams need better visibility into project health. Set up warning signs and mechanisms for course correction before problems compound. As teams scale, decide what you’ll actively monitor versus what gets surfaced to you through people or process.
    • End projects well – close projects cleanly, capturing learnings, and celebrating success often gets lost in the push to start the next thing.

    Process

    Process should be driven in support of the above. Good process is like an oil that keeps a team moving, bad process is like glue that favours performance over progress.

    How do we communicate – meeting structures, standups, documentation practices all need to evolve. What worked for 5 people won’t work for 50.

    How do we work together – collaboration practices like PR review, design review, and pairing need to scale without becoming bottlenecks.

    How do we escalate effectively – as teams grow, escalation paths get longer and more complex. Clear escalation mechanisms prevent small problems from becoming crises.

    How do we build a mindset of continuous improvement – all process has a purpose. Easy things are easy. Hard things are possible. Processes evolve as problems change.

    Identifying Bottlenecks

    The key to scaling is identifying where the bottlenecks are and addressing them before they constrain growth. Is it hiring? Is it unclear prioritization? Is it communication overhead? Is it feedback loops breaking down?

    Good scaling isn’t about implementing every process or even doing every process perfectly. It’s about thoughtfully addressing the specific constraints your team is facing, evolving your approach as the team and organization changes, and always keeping the focus on people delivering value effectively.

  • Low Process Culture, High Process Culture

    Low Process Culture, High Process Culture

    When I changed jobs in 2020, I went from a low-process culture to a high-process culture (or: what I perceive as high-process, all things are relative). It was a bit of a culture shock.

    The process stressed me out. For instance, my previous job did not have performance review. You were supposed to submit feedback every ~6 months – which I had always understood to be inconsistently enforced (I typically managed to do feedback for my directs every 6-9 months). So, coming into my first performance review, somehow my first ever as a manager despite years of experience, was something of an Ordeal.

    To be clear, what stressed me out was the process. I really struggled with the template I had been given. And then I finally submitted what I’d put together, only to get the feedback that I had written everything as a list of bullet points.

    Well, yes. The template had been a list of bullet points. Hence: my struggle.

    My boss gave me a helpful piece of advice. He told me that if I knew what to do, I should just do it, and then fit the process to it. It helped a lot.

    Time passed, and we came to the next performance review cycle. This time I was less caught up on my own struggle, and had more insight into how other people were approaching things in the role of “feedback reviewer”. From this vantage point, it was clear that having a performance review doesn’t guarantee great, or even good feedback – because that depends so much on all the other feedback that happens in between.

    But, it’s better than nothing at all.

    In Thanks for the Feedback, one of the frameworks is the difference between “evaluative” and “developmental” feedback. Evaluative feedback tells someone where they stand (and whether or not someone gets promoted is inherently evaluative). Developmental feedback tells someone how they can improve. If someone only gets developmental feedback with the evaluation, the evaluative feedback will override everything else. Being great at performance reviews (if there is such a thing), requires consistent developmental feedback the rest of the time – a product of accepting that people are unlikely to fully process the developmental feedback in the review.

    The second review cycle was still stressful, but for entirely different reasons. Largely it was stress about whether or not people would get promoted, and anxiety about telling people if they didn’t get what they wanted. In short – it was healthy, unescapable stress. Not stress about process, or the stress of a manager who last gave feedback last review cycle.

    Perhaps a less emotionally charged example, consider the release process. Any release process has a checklist. And I believe such a checklist is essential. But the checklist is about the release process and not what is being released. A great release is defined by what is in it – exciting features. A bad release is also defined what is in it, a bug, that causes a problem (and another process: that of running an incident).

    The checklists maintain adequacy. They are necessary, but insufficient.

    We have checklists for onboarding. We’ve worked hard on improving them. But I knew our onboarding process was better when the checklists failed, and people stepped in anyway to ensure the outcome – the success of the new person. The mindset of the team was one of collective responsibility, the checklist was just adequacy.

    I believe the judicious application of process is a super power. But I also believe that process is necessary, but insufficient. Process as a super power makes the unclear, clear, and supports a mindset shift that leads to something more.

    But like all super powers, used the wrong way, process becomes a bind and a distraction. People focus on the mechanics, rather than what they’re supposed to accomplish and why. They start thinking their job is to perform the process, rather than the desired outcomes they’re looking to achieve.

    Stepping back to consider the contrast makes more clear to me why the low-process culture didn’t really bother me, or (for the most part) impede me from the things I wanted to do. I was willing to create what was necessary in order to achieve the outcomes I wanted. At the same time, it gives me more empathy for the people who I saw really struggle without it. There is no clear starting point or agreements about how things work in a low-process culture, and that can be very overwhelming.

    All of this is not to complain about a higher-process culture. It is a relief to have a starting point for most things, even if I don’t agree with all of it. But process is inherently a mechanism of standardization and enforcement. There is no way to enforce greatness – we just enforce adequacy, and should be cognizant of the limits of that.

    A company with a performance review process won’t necessarily mean you have a better manager or a better growth path than an organization without one. It just makes it harder for managers to fall short of the absurdly low minimum of some amount of somewhat reasonable feedback on some specific cadence.

    No release process will guarantee a great release, just like no onboarding checklist will ensure someone is successful. But – they can help you avoid known pitfalls such that your release doesn’t explode and your new hire isn’t still completely lost after their first month.

    But it’s always worth considering what process makes sufficient, and what you’re really aspiring for. Sometimes adequacy is the goal, but when it’s not, the process is usually the least of it. What are you optimizing for?

  • Co-Active: Process

    Co-Active: Process

    Continuing my Co-Active coaching training with course 3/4, Process. Earlier this year I took Balance (2/4), and Fulfillment (1/4), after taking Fundamentals last year.

    Once again, I took the 5 days. This time it coincided with moving, which was a bit of a nightmare organizationally – especially as our apartment wasn’t ready on schedule and we were living in a hotel. So I was taking the course from 10-1430, then frantically running around Rotterdam trying to get things organized. I can’t imagine trying to do a course like Fulfillment under such circumstances, but luckily, Process is all about being with the emotions.

    Whilst Fulfillment is about living your best life, and Balance is about getting unstuck, Process is about being in the moment, especially the hard ones. We learned about emotional range, and work on expanding our own, because you can’t take others where you can’t go.

    What I got out of it

    • One of the core concepts in Co-Active coaching is “The Client is Naturally Capable, Resourceful and Whole” – this feels more present than ever to me after this segment. Truly seeing someone that way is so core to being with them in the space of difficult emotion.
    • Before this course, I thought I spent a lot of time on people’s feelings, but now I see how often I let them label and move on. But whilst we use the same labels (“insecure”, “anxious”, “lonely”), underneath them our experience and meaning is often wildly divergent. I will continue to explore the distinction between when to take the shortcut (label) versus when it’s worth taking the long way round.
    • As ever, I confronted some of my own emotions. Once again, I got front of the room coached and it was both brutal and clarifying.
    • Perhaps not something I got out of it, but it feels remiss not to mention it: this was the first course where I had a bad experience in one of the breakouts. I’m not talking about coaching that didn’t land, because it’s a learning experience and giving yourself and your classmates space to try and fail is part of it, but a sequence of events that felt genuinely quite horrible (especially given how this course is really about getting very vulnerable) and left me upset and anxious in subsequent breakouts (although the others were extremely lovely). This was the first time I really felt the downsides of the online format, which I felt both made that situation more possible and exacerbated it.

    What’s Next?

    • My next course (Synergy) is now pushed back to February so I have a break for a bit.
    • I’m continuing to practice and maintain contact with my classmates, which is nice. I much prefer taking this online, but I do miss the opportunities to meaningfully connect with other people also on this journey.
    • I continue to love my work coaching engineers, and am looking forward to taking on 1-2 more clients over the next few months.
  • Talk: The Culture of Process

    Talk: The Culture of Process

    I recorded this talk for the previous round of LeadDev Together. You can access it here (requires signup).

    All the penguin imagery in this talk are photos my mom took in Antarctica.

  • The culture of process

    The culture of process

    My latest in LeadDev…

    One of the challenges we face as engineering managers is how people react to process differently. Sometimes it’s like we’re talking about entirely different things – we propose something we expect to be lightweight, and people react like we’re instituting TPS reports or time-tracking in six minute intervals (normal for lawyers, everyone else: hell no).

    Continue reading…

  • Three signs of a poor hiring process—and four ways to fix it

    Three signs of a poor hiring process—and four ways to fix it

    My latest in Quartz…

    When given the opportunity to establish a process, we’re all biased to advocate for one in which we would be successful ourselves. In hiring, this plays out in two main ways: “A” players build monocultures, hiring people just like them, and “B” players hire “C” players, hiring people who won’t threaten them.

    In other words, top performers too narrowly define what top performance is, and okay performers hire mediocre people; in both cases, they’re making selections that bolster their own position.

    Continue reading…

  • Phase 1 of Hiring, Getting from 0-30

    Phase 1 of Hiring, Getting from 0-30

    Towards the end of 2017, we reopened hiring on the mobile team at Automattic which had been shut since the start of the year as we got things in order. I think of this as phase 1 of hiring on the team – nailing the basics of the process, and making some progress with diversity numbers.

    An up front note about diversity: Diversity is more than gender, and gender is not binary. However whilst acknowledging the limitations and flaws, we can use gender as metric as to how our hiring process is doing with respect to inclusion. We can use it as an indicator for diversity at every phase in the process, and use that to identify where we can improve the process for everyone.

    For reference, I was the first woman on the team, which was ~24 people when I joined at the end of 2016. When we opened hiring, there were two women, although both in leadership positions – this helps a lot.

    The TL;DR of how our funnel looked at the end of phase 1 is this. You can see that using our raw (and flawed) metric, the diversity improves at every step in the process. This makes sense given that data shows women hold themselves to higher standards when applying for jobs.

    Q4 20173 people
    Q1 20185 people
    Q2 20182 people
    Q3 20185 people
    Q4 20181 person

    Revamping the Process

    Whilst we didn’t change any of the steps in the process, we did revisit each one and improve it.

    • We revisited our job postings to appeal to a broader spectrum of people, emphasising impact and collaboration. The job postings now score 95 and 96 in Textio.
    • We diligently posted a hiring stats update each month (the way we review all our projects on the team regularly!), breaking down progress at each step of the process. Monthly was a good cadence for this – it allowed us enough data to make good decisions, but short enough timeframes to meaningfully iterate.
    • We standardized code tests with checklists of what we were looking for, what was necessary, what was nice to have. This also helps us give better feedback.
    • At Automattic, everyone who is hired does a (paid) trial project where we work together to determine mutual fit. We treated our trial projects as a pre-onboarding. Every new hire has completed a shippable feature and has meaningful interactions with at least three people on the team.
    • Previously, onboarding had been inconsistent and hit-or-miss. We got serious about onboarding, identifying good first projects and teams, and working to make sure every new hire felt welcome and set up to succeed.

    Successes

    • 31% of our new hires are women.
    • We added teammates in six new countries: Chile, Turkey, Germany, Serbia, Hong Kong, and Ireland.
    • 63% of new hires speak English as a second language.
    • We added three languages to the ten already spoken on the team (helpful for internationalization!): Hebrew, Serbian, and Polish.
    • Outreach:
      • WordCamps – we presented at WordCamps in Montevideo, Montreal, and Taipei, as well as WCEU and WCUS.
      • People from the team also presented at various local meet-ups and ThatConference.
      • We hosted a Women’s Brunch at 360AnDev.
      • I did my usual slate of presentations and started writing for Quartz.
      • Eli (the new mobile lead) and I did a webinar with Women Who Code in both English and Spanish!
      • I did an interview with GitPrime about our hiring and onboarding process, and Amanda followed up by sharing her own experience.

    Areas for Improvement

    Whilst we’re pleased with the progress we made in phase 1, it’s clear we have more work to do. 2019 marks the start of phase 2, where we will be focusing on:

    • Racial diversity.
    • Under-represented geographies based on our user base: APAC and Brazil in particular.
    • LGBT.
    • Gender diversity.

    We’re also keen to take advantage of the openness that working in Open Source allows – so we’re supporting our teammates in sharing more about their work online and IRL at events.

    If you liked this post, you might also like being part of our team: we’re hiring.


  • Understanding how process impacts outcome can help avoid useless meetings

    Understanding how process impacts outcome can help avoid useless meetings

    Capture d’écran 2018-09-23 à 19.38.38.png

    My first article in Quartz!

    Earlier this year, when I was learning how to facilitate a specific type of workshop, a colleague revealed the secret to making it great: understanding the outcome and keeping it in mind throughout the entire process.

    If the team isn’t focused on the outcome, than they’re just performing a process.

    Now, I see this phenomenon not just in workshops that I attend or facilitate, but everywhere.

    Management is full of mechanics that could easily become process performances. One-on-one meetings. Feedback cycles. Team meetings. Retrospectives. These are not inherently useful activities (and I’m sure we’ve all been in some of these that felt extremely pointless). They are useful only in service of some kind of outcome.

    The key is to consider the outcome as you design the process, and to pay close attention to the behaviors that emerge as you introduce the process. Behaviors are the link between processes and outcomes—processes encourage behaviors that create outcomes.

    Continue reading…

    Thanks to Belinda, @folletto, and @mnowster who helped clarify my thinking.

  • 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.