# Paul Blay's Manager Readme **Lead Software Engineering Manager at Displaylink** # Hi! First things first - thanks for taking an interest in this readme. The fact that you're reading it implies that you are working with me now or might be in the future. Great! You're just the person I was hoping to reach. # # Motivation for this document I think it's important to be open and honest about myself to those I work with as I'm aware that the personality and ways of working differ greatly between individuals, and that this can heavily influence peoples experience in their role.  In the past, I've tried to achieve this via an introduction meeting with those that I will be working with (if I'm new to a team, or as part of an interview process). This readme is my way of getting this introduction down in writing, to ensure I'm giving a consistent summary and to force myself to think of how to really describe what working with me is like. # My role At DisplayLink, my role is fairly broad, but the main focus is improving the effectiveness of the software function, the development of people, processes and tooling to that end. My aim, as a Lead Software Engineering Manager, is to provide a vision for our software development group and collaborate with peers and stakeholder on making and measuring progress towards that vision. I try to achieve this by fostering Communities of Practice, coaching & mentoring individuals, identifying efficiencies across the business and promoting modern software development practices. I also directly manage teams, acting as Product, Project and Line manager in most cases. # What do I value most? I value outcomes - whatever we do, if the outcome we're trying to reach is understood and measurable then I'm happy. I'm much less happy if we do something because "we've always done it that way" or "the \ said so". I value psychological safety - I try to imagine the most constructive reason why someone might say or do something that appears unhelpful or negative. I understand that most people are intending to do what they think is right & are more often misinterpreted than actually nasty or vindictive. I'm going to implore that you make the same assumption for others (including me). I value autonomy - I'm going to assume you know how to do your job better than I do and that you'll be at your most effective if I provide three things. 1) A clear set of aims and the context surrounding them 2) unconditional support from myself and the team and 3) the deep-work focus time that you need. I generally take an on-demand support role due to item 3; but realise that, after 20+ years in the industry, my assumption might well be wrong in some ways and, if I identify a need, I will switch to active support. I value accountability - autonomy and psychological safety without accountability can lead to an unproductive comfort zone. Accountability is the critical ingredient that allows us to remain competitive as a business in a psychologically safe and autonomous environment. I value knowledge sharing - knowledge silos are bottlenecks for a team and quickly build risk. This is not code for me wanting to know everything, in fact, I'm very conscious that bottlenecks also occur when one person in the team feels like they need to know everything. This is about focusing on collaboration, and better quality emerging from a broader understanding. Finally, I abhor "panic time" for a team. A team that gets stretched and panicked on a regular basis has its creative potential sucked out of it. With this in mind, I'm going to push for regular releases, automated testing and all that lovely stuff! We're in a knowledge-work industry and creativity is key. Sometime I fear I can stray too far in favour of these, so help me by keeping me grounded - help me identify if autonomy strays toward anarchy, to accept that some panic time a matter of course and point out if you think I'm being too lenient on certain questionable behaviour within my group. I relish a healthy conflict. # My Expectations Let's start with meetings. I've sat through my fair share of unproductive meetings, so I have some opinions on this subject. When setting up or running a meeting: Identify an outcome - We want something from a meeting, what is it? Make sure it's written down in the invite. It doesn't have to be anything awe inspiring, we just want to be clear on what it is. The worst meetings are those where the attendees walk away wondering what the point of it was. This includes regular meetings, perhaps once there was an outcome but there isn't anymore, let's scrap it. Respect peoples time - Start on time, end on or before time. Let's not keep everyone waiting for someone who's late, it's disrespectful to those who were considerate enough to show up on time. Don't drag the meeting on past its finish time unless you have the willing consent of others involved. Moving on from meetings... It's usually best to reach me on whichever instant messaging service we use. I'll usually have the IM app on my personal phone, unlike email. If you're reporting to me, I'm going to expect you to be active in your own personal/professional development. I am more then happy to support with tools, opportunities, coaching and training, I feel accountable for your development, but we're not going to get very far without your active participation. # 1:1s I see 1:1's as time to focus on your situation and aspirations. If you want to talk about project work, that's fine, but I will try my best not to bring it up myself. We spend enough time during the day talking about project work for my questions or concerns to be spilling over into your 1:1 time as well. This time is **not** a status reporting time, it's a time for me to help you on any number of aspects, e.g. personality conflicts, feedback, etc, but also for us to formulate a personal development framework for you. My aim is to have you drive your 1:1, but experience tells me that this is a lofty hope indeed.  # Personality quirks I'm probably a little too cheeky for my own good sometimes. I'll apologise in advance if this should ever not land well - but I like to make work a fun place to be and will keep it pretty light until I know someone well. People tell me I'm often happy - I can't think of a reason I should change that so I fully plan to keep it up. I used to worry that these aspects of my personality are bad because they aren't very "managerial" or "business like". I've since accepted that if these attributes conflict with being upbeat and happy then these are not attributes I strive for. I'm a sceptic at heart and regularly feel conflicted between questioning the validity of peoples claims and not wanting to come across as disagreeable. It is important to me, though, that we believe as many true things and as few false things as possible. I'm aware that I should question my own deeply held believes the hardest. I have a tendency to mull over something someone says if it generates negative emotions in me - I admire people who can call things out on the spot. It's something I am working on improving - but it's to give myself the time to consider whether I had interpreted what was said fairly. Be aware that I might dig up a conversation from a few days ago after this mulling period, to resolve a concern. # Where to focus on your first 90 days? The first 90 days is the time to get up to speed with how the team works. Please question everything and anything that doesn't make sense or you think could be improved - the chances are you might be right and we end up improving something. If nothing else, then we'll have made some strides towards understanding the context behind the situation. Help us dig out the hidden tacit knowledge that should be explicit during your first weeks and improve our new starter guides. Get stuck in and start contributing to the code base - if we've been doing our job properly, we'll have been making sure that this is as low risk as possible. That's all - thanks a lot for taking the time to read this & I look forward possibly working with you in future.