Accidentally in Code

Tag: management

  • 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

    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

    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

    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.

  • Running a Manager Feedback Cycle

     

    danbo_fall.jpg
    Credit: Flickr / Thorben

     

    I just ran a thorough feedback cycle for the managers (leads) in my team. This is what it looked like.

    Motivation: It’s hard to get feedback as a manager, the hope was that people would be more candid if they 1) submitted feedback anonymously 2) to someone else. Because we tend to amplify negative feedback, there was a benefit to having someone else go through it, find trends, and repackage it for the recipient.

    Process

    • Put together a document of questions and discussed with people who to send the feedback requests to (everyone on their team, other leads in mobile, people on projects owned by that lead).
    • Sent those questions to those people using our anonymous feedback system.
    • Gave people a week to respond (and then extended it so they had two).
    • Asked people getting feedback to send me a 3-2-1-Oh! Put it in a doc for each person.
    • Collated responses in a spreadsheet (and in the doc for each person). Made sure these were private.
    • Color-coded the spreadsheet (green = positive, orange = actionable). I would have used red if there was anything that was particularly worrying, but thankfully I had no need to 🙂
    • Went through and summarised under two headings: What Your Team Appreciates About You and What Your Team Would Like to See From You.
    • Put together a section called Takeaways which contained 4-5 actionable things from the headings above (including things to keep doing).
    • Copied relevant content into a new google doc (excluding responses), and shared it with the person. These were called “Name – Private” (my working doc) and “Name” (the one I shared).
    • Had a call and discuss the content.
    • Sent to HR.

    Questions

    1. On a scale of 1-10, how would you rate XXX’s overall performance as a lead? (one being “they suck” and 10 being “they don’t come any better”? Explain your rating. 
    2. What’s the best part of working with XXX?
    3. What’s the hardest part of working with XXX?
    4. What are three of  XXX’s strengths?
    5. What do you wish XXX would do more of? What do you wish XXX would do less of?
    6. If you had one suggestion for how XXX could go from good to great, or from awesome to awesomer, what would it be?
    7. If you were having lunch with a friend and talking about your job, how would you describe XXX as a lead?
    8. Complete the following, “My ideal lead is someone who…”
    9. Describe yourself when you are at your best. Is there anything XXX does to enable that?
    10. Anything else?

    My coach Dani put these together for me 💜

    Document Headings

    Bold: Included in the document I shared.

    • Feedback
    • > What Your Team Appreciate About You
    • > What Your Team Would Like to See From You
    • > Takeaways
    • HR Questions
    • 3-2-1-O
    • Questions
    • Response 1
    • Response 2
    • …

    What I’d Change

    • Keep track of who I sent requests to – mainly to have an idea of how many responses I was expecting, and be able to remind people via email (would have to be all of them) instead of posting general requests in Slack.
    • Adjust the questions for people who aren’t on the team (e.g. have peer questions, and perhaps also project IC questions).

    Time Commitment

    • Researching and thinking about the questions: several hours. I asked a colleague and three of my CTO friends for advice, and ended up having my coach help me with the more detailed questions.
    • Sending out feedback requests: 15mins / person.
    • Collecting feedback into the doc / spreadsheet: 30 mins – 1 hour per person (I also read it through which got me thinking about the feedback before I started processing it).
    • Going through the spreadsheet in detail, colour coding, and writing up detailed feedback (including the HR feedback questions I was sent): 2-3 hours per person.

    Note: this is just the time commitment for me to run it. Writing the 3-2-1-Oh!s and filling in feedback for others also took up time on the team.

    What People Said

    I loved this feedback review mostly because of how structured and transparent it was. Not only did I know everyone who was getting reviewed, but I knew everyone was getting the same questions. That relieved a lot of the stress in wondering “why did I get this review request?”. The question format of listing things (name one thing, what are the three things, etc) also made it super quick.

    ~@kwonye

    There weren’t any big surprises in my feedback, but I appreciated getting the reinforcement that I’m on the right track — knowing what you’re doing well is always motivating. I liked that the top-level points were broken down into “what your team appreciates” and “what your team would like to see” — where criticism is presented as concrete things that can be improved or changed.

    ~@mattmiklic

    I’ve always been apprehensive about getting feedback about myself just because of a fear of failure. Internally I can feel like I am succeeding but still get nervous when I go through a feedback process. This process eliminated a ton of that upfront fear because I knew what questions were being asked and trusted the process to be fair and unbiased unlike in previous jobs. I love getting actionable things to do or try out!

    ~@astralbodies

  • The Weekly Notes Post

    I read a lot of stuff on the internet, and a lot of that is about being a better manager. It’s rare to find something that is:

    1. Extremely concrete and actionable.
    2. At the exact time you need it.

    But in November, I did. I found this post from @SonOfGarr about sharing information with his team.

    Week-in-Review: a document containing relevant meeting notes from the week prior.

    Over the past few months I’ve evolved my own process. We use internal blogs heavily, so I publish it there and include a link to the previous one at the end of each one. Either I wrap up my week with it on Friday, or it’s how I start the week on Monday morning. I put it together as I look over what I did the previous week and figure out what my plan is for the one coming. Because much of what I do ends up in written form, and the notes from meetings I was in are often in other places, it’s an opportunity to tie all that together in a more coherent narrative. It’s also an opportunity to talk more about the why – which is something that I haven’t always taken advantage of that I can work on.

    I also find this a useful place to post initial or partial thoughts that I haven’t fully fleshed out yet. For example, I was thinking that we should probably improve our tooling, so I mentioned that one week to see what came of it. It’s also a place to explore themes that I’ve noticed in communication. Whenever similar things come up in 1:1s or skip 1:1s, then I’ll highlight the things I’ve heard from multiple people and explore them a bit.

    With a team of 25, I don’t manage to interact with everyone, every week. However in my last round of skip 1:1s I asked people if they had any feedback for me and was pleased that this weekly post came up from a number of people as something they appreciate. It has become part of how I make my work visible to the team, and combined with skip 1:1s how I try to demonstrate approachability, accountability and transparency. Improving accountability on the team has been something that we’ve been thinking about lately, and I think it’s important to demonstrate that accountability in return.

    I miss writing code, and the concrete deliverables of a feature, a test suite, the high of conquering a bug. It’s easy to want to go back there, when the nebulous and meta-ness of what you actually should be doing feels overwhelming. For me part of embracing longer term impact is to make it concrete where I can – to theme my weeks, and see if I can push one major thing forward – and to celebrate my wins where I get them. The regular act of sharing with my team what the details of that looked like helps with that, even as I judge myself by the impact over the longer term.
     

    There is also a small, personal benefit to the WIR. I found that whenever I finish a WIR, I have this tremendous feeling of accomplishment. I used to look back on my meeting packed calendar and think that I didn’t get very much accomplished. The act of writing my WIR helps me extract the value from each meeting. It allows me to reflect and keep things moving forward. It makes me realize how much I “did” each week. Authoring a Week-in-Review has been simple, yet powerful management tool. If you’re trying to figure out how to share information your team needs, that only you have gathered, and you want to cut out a team meeting, give it a try.

  • Things to Figure Out as a New Manager: Part 5, Trust

    wall e and Danbo
    Credit : Flickr / Glenn Lascuña

    This is the fifth and final part of the new manager series. Yes, there’s plenty more to figure out, but the idea is that with some sense of these things you will have the basics under control, and then you can figure out what your team needs from you and go from there.

    The fifth part is trust, because it builds on the other four. Trust is a characteristic of human relationships more related to respect than to like. It’s something you need to earn, rather than expect. It’s something you need to create any kind of change, and to get people to follow you into the unknown.

    If you’ve figured out your schedule, you’ll be able to be where you said you would be. If you’ve figured out social support you won’t ask too much from those who report to you. If you’ve figured out communication, people will feel like they can talk to you and make sense of what you say. If you’ve figured out feedback, people will know that you will tell them what they do well, what they can do better, and that you’re always thinking about what you need to do better, too.

    This is your foundation. When it comes to getting people to trust me, I have a simple rule: never ask for it. Just earn it. Lack of trust is the biggest, most implicit piece of feedback. If someone seems not to trust you, return to these pillars – have you been flakey on 1:1s? Sort your schedule out. Are they tuned into your anxiety? Figure out what support you need, and get it. Do you not communicate together well? Make more of an effort to adjust to their communication style. Do they not feel recognized or supported? Pay more attention to their work and highlight the things they do well. Or – give them clear information about what they need to do to be successful.

    Motivations matter here. We’ve all encountered people who we didn’t trust because we felt they were selfishly motivated or just somehow inauthentic. We earn trust, not by seeking trust out directly, but by building the foundation of a strong and respectful relationship. Trust follows. Or doesn’t. Regardless – we do the right thing, for the right reasons.

    It’s also important to acknowledge and appreciate acts of trust. The question someone asks, not knowing how you’ll react to it, or how supportive you will be. The failure someone owns up to, before they know how you’ll handle it. The risk that someone takes when they join the team.

    Giving Trust

    Whilst we can expect to earn trust ourselves, we can give it freely. Distrustful people are exhausting, and paranoid people cannot build a strong team.

    But understanding people means understanding what the boundaries of that trust should be. You might trust someone to architect a system, that doesn’t mean you don’t ask any questions about the decisions they make. You can trust someone to do something, that doesn’t mean you never follow up to see how it went. You can trust someone and promote them to manage under you, but that doesn’t mean that you never check in with their reports to see how that’s going. Trust means that you bet on someone’s capacity to grow into something – it doesn’t mean you never help them along the way there.

    Trust and accountability go together. Accountability works both ways – it’s hard to hold people accountable without making yourself accountable. When managers are flakey, this can bleed down onto the team. Accountability – like trust – rests on respect, rather than like. If people don’t take you seriously, even if they like you, you can find yourself being held accountable for a team you can’t hold accountable. This is unlikely to end well for anyone, least of all you.

    Special Types of Trust

    There are two people I seek out – people who can be relied on (trusted?) in a particular way.

    The Person Who Keeps It Real

    This is the person who tells you the truth, even when they think it’s not what you want to hear – in fact, especially when they think it’s not what you want to hear. This is a great person to have around.

    The Super Reliable

    The person who if you ask them for something, it’s done. Use judiciously. Appreciate tremendously. When there’s some kind of crisis and you feel overwhelmed, this is the person you turn to.

    Now What?

    I want to tie this series up in a neat little bow, but I’ll refrain. People are messy. The process of learning to people is messy. You’ll screw up. Some people you’ll try hard with, and you still won’t succeed. But if you act with kindness and empathy, avoid the trap of being self-serving, and work really hard… it’ll probably be okay.

    This is part 5 of a series aimed at new engineering managers. Part 1 was about figuring out your schedule. Part 2 was about social support. Part 3 was about communication. Part 4 was about feedback. For help and support, you can also ask for an invitation to the New-ish Eng Manager Slack.

     

  • Things to Figure Out as a New Manager: Part 4, Feedback

    danbo hiding in a shoe
    Credit: Flickr / Daniel Lee

    There are two things we should talk about before talking about feedback.

    First is the idea that feedback is just when you tell someone they screwed up in some way or need to do better. This makes us dread giving feedback (well, for those of us who aren’t sociopaths who enjoy tearing people down), and it means people dread receiving feedback too. It’s noticeable that we more often qualify “positive feedback”, because the default is negative (aka “constructive”).

    Obviously constructive feedback is necessary, and something we need to get comfortable both giving and receiving. But we also need to get comfortable with the idea that feedback is just observations of another person’s behavior reflected back to them – ideally it’s normal, and not some big event.

    Secondly is that feedback is often a very gendered experience. My friend Camille once observed to me that women get too much feedback, and men get too little. Women have often had the experience of receiving a lot of low quality feedback, which they then have to filter through to the pieces that are useful. Men are often not used to receiving feedback at all. Whilst this is not universally true, it’s worth thinking about how your own experience can affect your expectations.

    Regardless of the baggage we bring to giving feedback, we can learn to be good at it. Step one is understanding where we are coming from.

    Receiving Feedback

    Implicit Feedback

    Implicit feedback is feedback you observe rather than receive. It’s something I particularly look out for in communication. For example, when I communicate a complex topic to people, I always pay attention to see what they say about it later, because this tells me a lot about what they took from whatever I said. If what they are saying doesn’t fit with what I intended, then it’s a sign we need to talk about it more – and that I need to be more clear.

    Other places to look for implicit feedback include: velocity, morale, and collaboration. For instance if you start doing standups, and it seems to improve team (or individual) effectiveness – that would be an example of implicit feedback.

    Explicit Feedback

    An important behavior to model as a lead is the act of listening and acting on information – including things that make you uncomfortable (e.g. “constructive” feedback). Bear in mind that it’s really hard for people to give their boss feedback, and that feedback more than ever is likely be based on partial information.

    E.g. Someone gives you feedback that you’re not managing poor performance well, but what they don’t know is the context of that poor performance (e.g. events in someone’s personal life).

    Or, someone gives you feedback that you’re not sharing information, but what they don’t know is that your boss isn’t telling you things, and you found out in the same meeting they did.

    Or, they complain that you’re not involved enough in the day to day of the team. But what they don’t realize is that you’re spending most of your time being a shit umbrella.

    Feedback that lacks context helps you understand what the person is experiencing, even if it doesn’t (shouldn’t!) inform what you are doing. Say thank you, highlight what you are doing, and be honest about what you’re not going to do – for example something you’re going to consider more before acting on.

    Owning Up

    Because people are less likely to give their boss feedback, it becomes all the more important for you to give yourself that feedback to them. To own when you screwed up, and apologise. To acknowledge what you learned and what you would do differently. To recognize implicit feedback, and make it explicit between you.

    Giving Feedback

    Positive Feedback

    People often talk about building a relationship where you can give people constructive feedback and they’ll listen, and mention positive feedback in that context. Yes, it’s important to build a relationship where you can give constructive feedback. Yes, positive feedback helps with that. No, that’s not the only reason to do it.

    In general, people like to be appreciated and recognized. Noticing what someone has done really well, or worked really hard on, is not a very arduous thing to do. It’s part of your job as a manager to recognize what people do well, and not just at performance review time, but continually. It’s good to recognize what specifically was good, in order for your feedback to feel personal, and not bland (and meaningless). Aside from this being a worthwhile endeavour in and of itself, it’s a safe assumption that people want to be successful, and telling them what’s appreciated is a way to get them to do more of that.

    Pre-emptive Encouragement

    This is encouraging people to do things they’re unsure about or a bit uncomfortable with, especially things that will result in positive feedback if they do them (or “constructive” feedback if they don’t). For example, at work, we have an internal blog, and I want to see people posting on it more. One thing I do to encourage that is to ask people questions about things they’re working on – their support rotation, or a project. Then, I listen to them. If they seem engaged by the topic, or I learn things from the conversation, I suggest to them that would make a really good blog post – and offer to help with that, e.g. proof reading it.

    Constructive Feedback

    There’s a lot written about giving constructive feedback, and I don’t feel much need to add to it. A couple of points.

    Firstly, this is something that we often put off in some misguided idea of kindness, but mainly because it makes us uncomfortable. It’s not kind not to tell someone that they will eventually discover. For example, finding out that they didn’t get promoted because of something you didn’t tell them six months earlier. These conversations are hard, but not having them is harder.

    Secondly, it’s important to ask yourself why you want to give them this feedback. Are you trying to make your life easier, or them better? People will often realize your motivations. Often the people I’ve learned the most from are also the people who have stressed me out the most. My life might be easier if they pushed me less – but neither of us would be better off.

    This is part 4 of a series aimed at new engineering managers. Part 1 was about figuring out your schedule. Part 2 was about social support. Part 3 was about communication. For help and support, you can also ask for an invitation to the New-ish Eng Manager Slack.

  • Things to Figure Out as a New Manager: Part 3, Communication

    Credit: Flickr / Ravi Shah

    Now you’re a manager, communication (always important) has become even more import, and your words carry more weight.

    How do you communicate… one on one?

    … to the team?

    … about the team?

    One on One

    In a relationship with a power dynamic, the burden of a good relationship is on the person with the most power. I first made this observation with respect to interviewing but it applies here too. If conversations with someone are painful, it’s on you to make them less painful. Showing up regularly helps, as does taking an interest in them as people. Ultimately, different people will have different ways in which they want to communicate with you, and you can learn their styles and preferences and make an effort to accommodate that. Different people also have different baggage that they bring to work. If someone isn’t used to their manager seeing them as a human being, that will take a while for them to get used to. If someone has had bad experiences in the workplace they might take a while to open up.

    Be consistent, and be kind. Work on doing good 1:1s. Take time getting to know people, and use what you learn. But don’t delude yourself that it’s kind to delay telling someone something they will find out eventually – for example, don’t delay talking to someone about their performance if there are problems. These conversations don’t get easier.

    To the Team

    How often do you talk to the team as a whole? What kind of things to you talk about? How do you communicate a the direction of the team and keep things on track despite all those tempting diversions?

    Get comfortable repeating yourself. Decide what you will do, and make hard choices about you won’t do. Talk about why you are choosing to do what you are doing. This is team direction communication.

    The other aspect of this is communicating the kind of things you spend your time on. Figure out what you’re comfortable with. I do a version of this, each week I post some notes about what I’ve been working on to the team blog. Bigger things get their own post, but consistently I show up and share how I’m spending my time. With a smaller team I used to share my priorities in the daily standup.

    How you communicate to the team depends on the size and how people are receptive to information – some teams like to write, and others like to talk. But it’s easy to not share what you’re doing, in part because people don’t ask and it can feel like there’s not much interesting to say about the activities of management. But people having some kind of insight into the kind of things you worry about and spend your time on is really helpful.

    About the Team

    How do you talk about the team to your peers? To your boss? How do you highlight what is going well, and how do you get the alignment and help you need from other leaders in the organisation?

    If you manage a team that has been underperforming (and particularly if your joining the team was supposed to address that) how do you communicate that things are getting better – given that they won’t change overnight?

    This depends very much on the organization, but again I think consistency is key – and patience. People are focused on their own priorities, and can take a while to notice improvement elsewhere.

    This is part 3 of a series aimed at new engineering managers. Part 1 was about figuring out your schedule. Part 2 was about social support. For help and support, you can also ask for an invitation to the New-ish Eng Manager Slack.