Tag: projects

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

  • Bi-Monthly Rituals: The State of All the Things

    Bi-Monthly Rituals: The State of All the Things

    order_chaos
    Credit: Pixabay / geralt
    At the end of last year, I somehow found myself as the lead of a team that was 4x as big as my previous one. Many things were different, but one of the big ones was changing from having one person on each platform who really knew everything that was going on… to having some unknown set of projects with unknown combinations of people involved. My first task, then, was to figure out what our multi-month multi-engineer projects were, what had happened on them so far, and what we were aiming for – in terms of scope and time. And that is how I accidentally implemented deadlines. Which I think is an example of what can go wrong when you arrive in a culture where something that is core to you is not thought about. I asked “when do you think this will be done?” because it’s impossible to me to be involved in anything and not have thought about this. But, that wasn’t the culture of the team – some people hadn’t. I think a sense of time is important, but if I knew it wasn’t there, I wouldn’t accidentally implement deadlines – I would very deliberately encourage setting goals. Which is where we ended up… eventually. Aside from that small SNAFU, this became a useful enough process that we repeat it every other month as an internal post we call “The State of All the Things”. The timeframes in the first one were very wrong. The second one – also very wrong. But over time, they’ve gotten less wrong. They allow us to see how we’re doing relative to where we thought we would be. As we no longer do lone wolf projects (we theme work so that everyone can be part of a “team”), it captures closer to the work of the entire team. They also provide a helpful high-level insight into what the team is doing that it’s easier for people outside the team to process. One of the things I find in a company that focuses very much on written communication is that it’s easy to communicate an overwhelming volume of low-value information. Selectively communicating a smaller amount of high-value information goes a long way. If someone really wanted to find out the state of one of our projects, they could using other means – but this is where the high level summary is. It moves the bar on finding that information from “dedicated investigator” to “passive interest”. For each project we include:
    • If it’s shipped, that goes in the title (along with the launch post link).
    • Who is the DRI? For the overall project, and for design.
    • What are we doing and why are we doing it?
    • What have we accomplished?
    • What does “done” look like and where are we tracking what’s required to get there?
    • When do we expect to be done?
    • How are we doing relative to our expectations last time?
    As a note on trust and accountability – it’s scary to admit that things aren’t going to plan, but when you’re up front about the ways in which that’s the case, people have much more faith in you to fix them, than when they find out by other means.
  • Why Do Standup

    Why Do Standup

    1. Share work before it happens – prevent overlap, raise gotchas.
    2. Foster communication and collaboration – offer help rather than waiting for someone to ask.
    3. Start the day with intention.

    Turns out, status updates are not the most useful aspect of standup.

  • Start a Project. Kill a Project.

    Start a Project. Kill a Project.

    The Last Postcards (sent from Paris, Jan 3 2015)
    The Last Postcards (sent from Paris, Jan 3 2015)

    I have been enjoying everyone’s year in review posts, and reading what they hope to achieve over the next year. I love the enthusiasm and the new projects starting, but one thing I love even more is when I see people defining what they will do less of in 2016.

    For myself, I set my self a limit of 6 talks in 2016. This is a big constraint (in 2015 I gave 6 – different – talks in September alone). I’m also working to shed various things, most notably admin work (I will write more about how my word for 2016 is “scale”).

    Because the thing is, what you don’t do, is maybe more important than what you do do. When we say no to things, we create space. Then it’s up to us what we do with it.

    Like many people, I started the year with a new project. Well, instead I called it a challenge – it’s to send a digital postcard from every place I leave in 2016. I called it, since people ask me this a lot, Where the Hell is Cate?

    This came from the fact that I have realised that I only really stay in touch with people I communicate with on Twitter or IM. I don’t really use Facebook, and I am exceptionally bad at email. Sometimes I exchange emails with friends who are like “tell me everything” and I don’t even know how to respond… I mean I tweeted about it all, right? I don’t want to rehash it again. Every so often I send an email and include some longer form rambling about travel, or life. Things that aren’t particularly personal, but that I wouldn’t put on the public web.

    So: I decided that I could accept email as an outward bound form of communication, registered a domain, and started working on the first one (which I sent out yesterday from CDG airport). Basically I have taken everything I know about sustainable projects and applied it here. It may still fail, but at least should it fail it will fail in a new way that I cannot predict.

    1. Low bar. I firmly believe that most things fail because we set the bar for success too high. Whilst yesterday I sent out a lengthy essay talking about loneliness, languages, and commenting on the history of luggage, the bar is a picture and a favourite thing. I can put that together in 15 minutes at the airport as I wait for a flight. It feels very possible.

    2. Specific Trigger. I believe in a schedule. I operate my blog on a schedule. We run Technically Speaking on a schedule. If something is “optional”, it needs to have a specific trigger to happen because otherwise the constraint is “ready” and then it becomes very easy to overthink and delay. I usually use time as the trigger, but for this project the trigger is leaving. It’s the airport.

    3. Something Must End. At this point anything coming into my life means that something must leave it. When I contemplate a project I ask myself “what will I give up to do this project?” and if the answer is “nothing” then that is a sign that project should not happen. I shed a bunch of things to start my job, so projects that remain are ones that I really, deeply love. It is very hard for me to make space for a new project. For WTHIC, I am giving up two things: 1) the rambly emails periodically sent to friends, 2) sending postcards.

    One of the interesting and challenging things for me is the idea of creating something transient and ephemeral. I am very into the Documentation of Achievements, and rather than have the same conversation multiple times, I write things up in blog posts and then I can just share them. (Sometimes, when I write sentences like this, I am amazed I have any friends, let alone many). But one thing about transient and ephemeral is that is affords a greater level of privacy and a lower expectation of judgement than the forever web. A postcard is just a point in time. A blogpost is much closer to forever, or forever in digital terms, at least.

    Why Kill Postcards?

    I started sending postcards when I left Australia. It started as a controlled way to stay “in touch”, if you can call it that, with my favourite ex boyfriend. Leaving Australia also meant leaving him, and that broke my heart. Even though it was the right thing to do. Even though he and I were never going to figure it out. I started sending him postcards, from my adventures, as a way to let him know that I still thought about him, and still missed him, but not in a way that we actually had to… have a conversation.

    Over time, I started adding in other people to send postcards to, particularly friends who I knew were having a rough time. And sometimes I would tweet, and send a postcard to anyone who wanted one. This has been a surprisingly time-consuming activity. Sending 5 postcards from Paris yesterday took ~45 minutes (and where to find stamps had been on my mind for days). Sending 24 postcards (and 2 packages) from Easter Island took – I am not kidding – at least 3 hours. I spent 1-2 hours mailing postcards and failing to mail those packages from Santiago. I spent at least 2 hours writing and mailing things in Croatia.

    I was really happy to share a bit of my adventures with people, and really happy so many people wanted postcards! But this project was a prime one for killing for a few reasons:

    • I’m heading to Colombia, a place where there is basically no postal service (I bought postcards when I was there in April, and ended up mailing them from Santiago).
    • I get very little feedback from people who receive them. What was a feature of sending things to the ex – a communication medium outside, no need to respond – is a bug when it comes to sending them to other people. I asked a friend recently if he got the postcard I sent and he said, “yes I took a picture of it!” (He did not Social Media the picture, so does it really exist at all?)
    • It’s superficial. I write at most 1-2 personalised sentences per postcard, but usually just “hi from <LOCATION>. I pick cards that I think may speak to people, but usually it’s quite generic. I think people liked postcards because it connected them to my bizarre nomadic life, but did it really? It’s just a physical object transported from one place to another. It does not convey anything more than “I was here”.

    Onwards

    Start a project. Kill a project. Postcards are dead. For 2016, if you want to know about my nomadic life, let me send you letters from airports: Where the Hell is Cate.

    And if you are here for the musings about sustainability of projects and don’t care where I am, I leave you with the thought: things only exist if there is space for them. What space do the projects in your life need, and how do you plan to create it?

  • A Small Focus Hack

    A Small Focus Hack

    Happy New Year Danbo
    Credit: Flickr / Leland Francisco

    I decided that my word for 2015 was “ship”. Part of this is that it’s easy to flounder in an unstructured environment (which I did a bit at the end of 2014). The way I decided to solve this was to give myself structure, and goals.

    How do you measure bigger milestones though? It makes sense to have a separate place, away from how we manage our todo lists.

    My strategy: a simple text document. At the top a list of projects or significant milestones I’m working towards.

    Below, each month is a heading. Under it goes things that “shipped” that month. New client contracts, talks, alphas, betas, releases, open sourced libraries.

    When I want to see what I’ve achieved this year, this is where I look. It keeps me focused on moving the needle, reminds me not to fill my days with transient busywork, but rather the 2-5 (typically 3) things that will still matter months from now.

  • The Procrastination Project

    The Procrastination Project

    Reverse Whack-A-Mole
    Credit: Flickr / Chris Clayson

    There is something I’m working on that I’m really excited about, that if we have hung out in person I may well have talked about, but it has been going nowhere.

    So “I’m working on X” has really only been true if “work” is defined as “not getting around to and feeling really guilty about”.

    This was a project that I didn’t have the nerve to apply for, I thought about it, decided my ideas weren’t good enough, but someone reached out to me, and I was like YES! Here are my ideas. And they were positive and so it was all agreed and then I just… made no progress.

    (And that, by the way, is an example of why it’s worth asking women to do things and rather than complaining that they didn’t put themselves forward).

    I procrastinate productively. So whilst I was not doing this one project, I submitted talks for two conferences. And my blog was scheduled two months out and all I had created for this, my most important side project was… an outline.

    To make this seem even more stupid, not only is this something I really want to do (directly related to my secret “What I would do if I wasn’t afraid” plan), I’ve already done at least 50% of it, and this is in many ways just a restructure and repackage of that work, with some extra bits and pieces.

    After weeks of this, I finally made some progress. Not on the full day that I set aside for it, which I spent filling up my buffer of blogposts (rationale: “maybe when I have blog content done for all of this month I’ll feel like I can focus”, and then when that was done, “maybe if I just get these finished they’ll be out of my head and I can focus”). But when I set myself a goal of working for an hour on it, with a limit of 90 minutes I could work on it, because I needed to leave (checkout, eat, go to airport). And I went back to the outline, which I had forced myself to write a month earlier, and just started following it.

    Turns out it was a pretty good outline. It should be, I guess. I thought about it for a month before I wrote it down.

    And voila. Two out of 5 sections were done.

    I don’t know that I have anything to add here than hasn’t been covered again and again elsewhere. But whilst my excuses were good and genuinely, I had been moving/without internet/sick/travelling/insanely busy at work it was only on a Sunday morning – having shut myself away since Friday night citing need to make progress on this – that I finally took a hard look at myself and admitted that I was afraid to fail at this. Better to keep it as a possibility rather than try and fail.

    Which is obviously stupid, so I sat down and got working.

    Some observations:

    • An outline really helps. Creating an outline is such a low bar, if I’ve been thinking about something (which if wracked with guilt over not doing it, I have) it shouldn’t take too long to write one.
    • Once I have a good outline, it’s easy to just follow it and fill in the blanks.
    • I procrastinate more on coding (for personal projects, not at work), it’s like I’m more afraid to be bad at it (who cares if I suck as a writer? I’m an engineer, there’s a pretty low bar for me there) or just feel like I have less to add.
    • Shutting myself away and just working through my excuses until I run out works. It does take a while though.
    • At least I procrastinate productively. I achieved a lot whilst not achieving this.
  • Awesome Foundation KW Meets Kwartzlab

    Awesome Foundation KW Meets Kwartzlab

    Jeff-o's awesome pumpkins
    Credit: flickr / flying squirrel

    This week we had yet another amazing pitch night for Awesome Foundation KW. It was a tough decision, but we decided to fund Kwartzlab’s “Hacky Halloween” project.

    I’m really excited about this project, and I think this paragraph from their blog post shows why:

    We live in a world of electronics. Learning a simple skill like soldering and seeing a bunch of parts turn into a working device is the first step to realizing that all those gadgets that everyone uses every day are made. They’re made by ordinary people. You can make them too. It gives you the courage to take things apart and see if you can put them back together again, or re-purpose them after they stop being useful. It opens up a door to understand the world around you a little bit better.

    As an engineer, it worries me when humans see technology as a black box they mustn’t look inside. I don’t think people should be afraid – and I don’t think they should be content with terrible products. Knowing enough to demand better – even better, to make it better is important! I think this is becoming a necessary life skill.

    We all have our different ideas of what awesome is, and we deliberately keep it vague because we don’t want to rule anything out. Awesome is often a surprise. It’s more than the sum of it’s parts.

    I think bringing people joy and brightening their day is awesome. The Secret Gardener and the Food Love project both did this. I’m confident this project will too. I also think it will inspire people to take something apart that they were afraid to, to build something they weren’t sure they could – and that, sounds pretty freakin’ awesome to me.

    Thanks to everyone who came out, and especially everyone who turned out to pitch! So many great projects and as ever, I left energized and inspired.

  • Decisions

    Decisions

    "Goody Glam"
    Credit: flickr / yarnpunk

    Last week, in California, I met the amazing Meggin who leaves such astute and beautiful comments here. It was great – or terrible timing – depending on how you look at it. Terrible timing, because, one of the first things I said to her was:

    In a while I’ll spin this into a really positive sounding blog-post, but right now? I can’t do that because I’ve spent half this morning in tears.

    Great timing because she gave me some good advice. So – rough week. I’m pretty chilled out travelling, but packing and timezone changes are still stressful, and I get claustrophobic in MTV. I spent the week jetlagged, came back, and I’m still jetlagged. I enjoyed the weather, wondering around San Francisco, and a day at MOMA. It was great to meet Meggin, and hang out with Maggie and John, and connect to other female engineers based in MTV who I had only seen on video chat.

    Anyway, circumstances have meant that I’ve been figuring out what to do next. Stay on my current team with more travel, or move to a new team. I’ve been trying to work that out in the context of wanting to move back to Europe sooner rather than later, of enjoying what I work on currently, but being tempted by this other challenges, and not really wanting to spend so much time in California – it would be different, if I was going somewhere (a city!) where I’d actually enjoy spending time.

    It’s been difficult – hence the tears, and the lack of blogging – I couldn’t write about this, but I was sufficiently absorbed by it to be unable to write about anything else.

    Coming to a decision has really forced me to think about – what is most important to me? What compromises will I make? For the right project I could be willing to travel more, but the right project depends on a number of things, not just the project itself, but the people involved, and the potential for personal growth.

    So I’ve been asking myself questions. What do I want to work on? What level of pressure can I live with? Who do I want to work with? How much will I compromise? How do I want to organize my schedule? What matters to me most? In the end, certain events made the decision was very clear, although still not easy.

    I’m switching teams – I know, again. I’m going back to my original manager, and I’ll be working on docs. I’m excited about the project, the people on the team (50% women! Yay!) and I’m really happy – and lucky – to have this guy as my manager, because he’s awesome. They all are. The project is a really good fit for me, I hope. Social was too, and I am fortunate to have been part of that incredible experience, but – for a number of reasons – it’s time for me to move on from that, and this is, I’m completely sure, the right place for me to move to.

  • Reminding Myself As To Why We Continue, Despite Everything

    Reminding Myself As To Why We Continue, Despite Everything

    If you can turn yourself into smoke whenever you want, why do you bother walking?
    Credit: flickr / Jackman Chiu

    It’s been a mixed week. Some successes – Awesome Foundation! Girl Geek Dinner! Getting my visa sorted! And then a number of things that made me wonder why I was bothering. Mostly stupid things, and you could say that I shouldn’t worry about them – but that is easy to say, and hard to do.

    Telling a friend about one of them, she gets it, telling me I shouldn’t be bothered by it but understanding that I am, likening it to the first negative comment she received on her blog (which, of course, she still remembers). And I think about how insane it is that I can’t remember the first positive comment from a stranger on my blog, but I can remember chunks of the nasty ones. How I’d forgotten I was on the radio until the recording came on my iPod and creeped me out (“who’s that talking? Oh wait, it’s me?”) but I definitely haven’t forgotten the couple of mixed press articles about things I’ve done, or the article where they misspelt my name.

    In interpersonal relationships, a ratio of five positive to one negative interactions is needed, from Wikipedia:

    After studying married couples for many years, psychologist John Gottman has proposed the theory of the “magic ratio” for successful marriages. The theory says that for a marriage to be successful, couples must average a ratio of five positive interactions to one negative interaction. As the ratio moves to 1:1, divorce becomes more likely. Interpersonal interactions associated with negative relationships include criticism, contempt, defensiveness, and stonewalling.

    When doing things, I don’t know what the ratio is, but I do know that it’s very easy to dismiss the nice comments as people “just being nice” and take the nasty ones to heart. By nasty I don’t mean constructive criticism – the kind people who say, “have you thought about X” and then offer you something – time, a contact, a piece of information – that will help you do that. I mean, just straight up, “you suck” with no acknowledgement of the time, effort, and energy you put into doing whatever it was sucked. It’s stupid to get worked up about, I know. If they have nothing nice to say, they were likely not your target audience.

    Personally, I do things for two reasons. Either I find them interesting, or I think they should be done. “Have people tell me how awesome I am” is not on that list, and please, should it ever be that way, shoot me. So – why does “Having people tell me how much I suck” make the list of reasons not to? It shouldn’t. I know, objectively, that the more successful you are and the more you do the more people will try and belittle what you do, and at times somehow manage simultaniously to try to take the credit for it. I know that. And yet, each time it happens (as it did twice this week) I’m hit, afresh, with feelings of guilt, inadequacy, and frustration. And, too often, I wonder if they have a point.

    Deep breaths. Focus on the reasons why. When I dislike someone’s means, remind myself that the ends – and their intentions – are good. And, as a reminder that set-backs are not necessarily the end, this week a battle that I had been fighting for several months, was won. I hadn’t thought it would be, and I’d had to go and focus on other things. But then, someone else didn’t give up, and the result is that we all win. And the following day, something happened to remind me why I thought that battle was important in the first place.

    But, again, all of this – easy to say, hard to do. So tell me, how do you avoid taking things you shouldn’t to heart?