# Tuesday 27th Morning ## Managing at the Threshold: Examining our Principles in a Moment of Change by David Yee We are in a shift in our industry caused by macroeconomic factors. We had this is 2009, and now something similar is happening now but it is not done, it is a liminal space we are part of, and as leaders will navigate and influence. What are you guiding principles? > Do the right thing - Notice - Think - Persuade - Proceed ## Compassionate on-call by Lisa Karlin Curtis - It should be easy to request and get cover - How to do this? - Set an example - Make it easy to ask for cover e.g. slack channel - Have enough people on rota to make this work - Compensation based on time spent on call - They had some success including non-engineers in the rota - Page load is what matters (alerts x time to resolve / people) - Review your recent alert - Beware of false alarms - Sleep is important - If called, perhaps have cover for the following on call shift the next day - Shared the load - Get qualitive data, that’s what really matters e.g. if people *feel* like they are getting paged a lot or not ## Red 2.0: Transforming a Game Company - Patrick Linconi (\*recommended) - Five Dysfunctions of a team - The advantages* - The ideal player* ## What do you mean there’s no onboarding plan for engineering managers? by Daniel Korn - When a company has a great onboarding experience many indicators including attrition are improved - Key factors for a good onboarding plan - Belonging - Accomplishment - What about onboarding engineering manager? - Responsibility of Engineering Director(s) or above - 4-week plan - Self-managed - Build like a checklist - Manager and buddy support - Part of a cohort - Clear definition of done - Weekly breakpoints - 60/90 day extensions - Made up of either - Sessions - Transfer of knowledge - Experience - Practice - Areas - Peopleware - Deliver management - Technical leadership - Not all are required, split into - Required - Recommended - Optional - Separate content for new hires and internal transitions (but still shared, the required/recommended/optional mix changes) - “Don’t worry about it” list of things for cohort of people coming in next - Getting the direct manager buy-in ## Code is Poetry by Niranjan Uma Shankar ![[Pasted image 20230627122411.jpg]] - Code conventions - Reduces congitive load of getting up-to-speed with a new codebase - Normalise Nitpicking (and be kind) - Naming - Abreviation - Code comments (That add value) and are formatted correctly - Use senior engineers to champion process - Recognise individuals who have spent time to write good code ![[Pasted image 20230627122753.jpg]] ## Why Onboarding to a Company's Legacy Codebase Sucks, and How to Make it Work for Your Team by Shanea Leven - Pair if you can - “We read code one line at a time and then imagine how our system works” 😆 - The mental models domains experts have built, will leave eventually with those experts - 3 types of advice - For the team - Start small in scope - Expand strategically - That don’t require lots of extra learning in one go - Choose tasks that build confidence (e.g. some early wins) - Bug fixes (.. in and area that is well tested) - Small tasks the team knows already - Isolated features - Tech debt - For the onboardee - Areas - Domains objects - User examples - Key flows - Architecture - Frameworks - Coding patterns - Development process - Tribal knowledge - Ask! - Explore the marketing site - Read the docs - Write stuff down - Draw it out is ideal - Update the docs as you go - Continuous onboarding - ![[Pasted image 20230627124203.jpg]] ## Making the Move to Manager: Common Pitfalls for New Engineering Leaders by Jacqueline Pan and Marlena Lui - Building Relationships - Need to know it all —> it is ok to say “I don’t know” - Building trust is an important part of this relationship building - Delegating - Continue doing what I did as an AC —> Change mindset. Know where your time is best spent. - Takes opportunity from own team if you take IC roles - Put everything on place - Divided them up to things team could be given - You don’t alway need to prove you can do it before asking other to do so - Delegate the responsibility of learning and knowledge sharing to the whole team - Managing Up - Manage up your vision for the team - Gain your managers trust in decision making - Get to know your manager - You can overcommunicate with your own manager, and they can feedback if you are doing too much. You can tell them what plans you are about to take, even if you are not seeking their approval. - Professor Tina Stealing - Balance between leading and following - Giving feedback - Worried being direct would break trust —> Show your intention - Give your feedback often to show you can help your team —> You don’t need to give feedback right away when you are new. Build the relationship and understand the context so you can give good feedback. - Prepare - Practice with mentors # Tuesday 27th Afternoon ## "I'm happy where I am" - Supporting team members that aren't seeking progression by Ryan MacGillivray - Recognise cycles of ambition - Create a sense of development - We can create a framework that accounts for people that don’t always a promotion - Can people go sidewise as well as up? - How can we celebrate peoples own development? Not in a way where we gather around to celebrate a promotion. - When is ok to push someone? - When they don’t want to? - Try and understand why. Can you work with them to get past it? - When they don’t think they will be good at it? - Honest constructive communication to understand them - See Radical Candor, Giraffe Language - What a manager wants is not important, what the person they manager wants - What not to do? - De-prioritise these Engineers - What we can do? - Support people s changing ambitions at different points in their career - Provide opportunities for individuals to grow their skills - Encourage them to seek promotion if you think that not do is acting against themself ## How to drive pace in your team 🏃🏽‍♀️by Alicia Collymore - “Pace is value delivered at speed” - Metrics can be useful, but not strictly needed for the below advice… - How to improve pace with teams - Set some defaults with team - Put pace at the hear of your team - Discuss with team - Give lots of room for autonomy - Transparent by default - Create some hype - Optimise your projects - Keep projects short, very short, inappropriately short. - Think weeks not months. Even with month long projects, split them up and get valued out as soon as you can. - Keep things simple - Do the hard bits first - Work done > work started - Regroup when something changes - How to improve pace with individuals - Encourage their super power - Not the same in everyone, and different people contribute to pace in different parts - Be laser focused on value - Beat deadlines - If you finish early, don’t fill the time, find the next bit of value - Don’t stay stuck e.g. 30-60m is ok as a learning process - Pain is expected, and ok - What could go wrong? - Too much pressure - Poor code quality - Unhealthy competiveness - Focus on speed rather than value - False sense of speed ## How we support making architectural decisions by Olena Sovyn - Created an architecture review group - Rotation of the group every 6 months (but not everyone at same time) - No gatekeeping. No veto powers. Providing advice. - Decisions are made in public and tech specs are submitted in public so people are aware - Tech spec —> architecture review group —> resolution - Sponsored - Needs Updates - Not Recommended - Review Not Needed - Escalated - https://stackoverflow.blog/2020/04/06/a-practical-guide-to-writing-technical-specs/ - They have a facilitator (one of the group) - There is a tech spec template - Reading - Thinking in bets - The staff engineers path - Black box Thinking ## Where we’re going wrong with developer productivity by Cat Hicks - Brittle Productivity - Your org will look productive as long as **nothing goes wrong** - But when something goes wrong, it **breaks**. - Resilient Productivity - Your productivity builds for the **long-term** - When something goes wrong, it **delivers** - Measuring Thriving - Agency - Learning culture - Motivation & self-efficacy - Support & belonging - There is a strong correlation between developer thriving and productivity - If you never stop, the thing that engineers drop is reflective processes ![[Pasted image 20230627153655.jpg]] ![[Pasted image 20230627154434.jpg]] - Reading Pi - https://www.pluralsight.com/resource-center/guides/how-visibility-leads-to-high-performing-teams - https://www.pluralsight.com/resource-center/guides/developer-thriving-white-paper ## Engineering a more equitable hiring process by Jason Wodicka - There is no such thing as a “diverse candidate” - Diversity is a function of a group - These are the tools for creating equitable process - The job opening - Overstated requirements are most likely to be ignored by certain groups, and more likely those with more confidence - State the real requirement - Eliminated biased language - Sourcing - Actively seek the candidates you want - How and where you search matters - Things like employee referral are likely to recruit from similar pool of people to that you already have - Screening - Avoid pedigree bias - Don’t over-screen candidates - AI screening has no evidence base it's not bias - Interviewing - Familiarise candidates with the interview - Let candidates retry thei interview - With diff questions and interview - Candidates who complete 3+ practice interviews are 6 more likely to land a job and twice as likely to feel confidence in succeeding in an interview - Use structured evaluation - .. and structured assistance - Decouple assessments - e.g. communication as a whole vs verbal/written etc. independently - Eliminate hidden assessments - But people who seen before have an advantage - Reading your mind is not a competency - Under represented candidates are less likely to ask questions to clarify - Make consistently fair offers - Salaries are less secret than ever and if you treat people differently with the same skills they will not feel as valued once they find out the discrepanacy or think there is one - Don’t treat onboarding as the final exam - Create a personal onboarding plan - It is extremely difficult to improve something you are not measuring ![[Pasted image 20230627165939.jpg]] NB. Examples happen to be race or gender as those are the ones with the most research, and acknowledge there are many other areas of diversity. ## How to effectively “Spike” a complex technical project by Aditya Bansal - Effective Spiking - Problem it is trying to solve - Technical - Known unknowns - Unknown unknowns - What NOT to do - Write production ready code - Solve for everything - Take all the time in the world ## The 9.1 Magnitude Meltdown at Fukushima by Nickolas Means # Wednesday 28th Morning ## Building bridges: The art of crafting seamless partnerships between engineering, product, and design with James Stanier, Winter Wei, and Janet Balneaves There is a “Trifecta” of product, UX, and engineering that make most decisions together. Every project has 3 phases: 1. Proposal 2. Prototype 3. Build Decisions are documented with reviews and comments in one place. But doesn’t sound like waterfall? Not really, there are iterations within and you find out new information and make new decisions. Getting alignment: - Common problem with UX is design can have technical challenges implementing - Best way to mitigate is to explain in layman’s terms why - Sometimes focussing on pixel perfect may distract from mission - You can use company values or principles Vent time: - Providing inappropriately lengthy estimates for work people don’t want to do - Over use of metrics for productivity, that drives strange behaviour in teams including gaming the systems - Don’t tell me you want to refactor code - tell me why - Being able to explain something complex in simplest way possible means you understand it. ## Riding the rollercoaster of emotions by Gabriel Michels ![[Pasted image 20230628100026.jpg]] - Identify, acknowledge, and reflect on your emotions (Mindfullness) - Recognise your negative thoughts in a non-judgmental way - Thoughts lead to emotions, so if you can control your thoughts you can control your emotions - Find the positive aspects of the challenge - Use “if-then” thinking - It’s easier to practice this way - When triggered, don’t react immediately. Calm down. - Communicate that you need to take a step back - There are no good outcomes when you react emotionally ![[Pasted image 20230628100816.jpg]] ## Platform engineering is all about product by Gal Bashan ![[Pasted image 20230628101218.jpg]] - Goals - Enablement “Golden paths and paved roads” - Developer Experience - Cycle Time - MTTD - PR/Release Frequency - **Attrition** - Problems - Infra - Boiler plate - Security - Obserrvability - Code discovery - Code ownership - Cognitive load - Quality - **Our developers know what problems they have** - Solutions - Focus on value - Value to developers > impressive tech - Building - They decided to create a framework that fit their domain, but still could be tailored to different needs - But they ended up with people struggling to adopt, and some people not adopting at all - Why? Agile is still valid. Deliver quickly, learn, iterate. > If you make adopting a new platform mandatory then you rob yourself from the most useful metrics: adoption and use. ![[Pasted image 20230628102617.jpg]] - If you can’t afford a PM - Choose an engineer that is not best technical engineer, but the most connect to user needs, business understanding, and product skills. - Consider split the team up and put them in product teams so they can deliver value ## Cultural post mortems: an approach to learning and recovering when your people systems fail by Winna Bridgewater - Complex Adaptive Systems - You can’t really understand the whole system by looking at single part of it ![[Pasted image 20230628103347.jpg]] ![[Pasted image 20230628104032.jpg]] ## Strategies for succeeding as a underrepresented engineering leader by Rafia Qutab Kilian - Leadership is a learned skillset - Even “born to be leaders” need to continually hone their skills - Formal and informal learning opportunities - Things that can help succeed - During selection of company - Assess a company like you assess a neighbourhood - Learn and practice boundaries - Establish up-front - Don’t participate in gossip with subordinates - Expand your network - With other teams - With upper management - Use opportunity to advocate for yourself and demonstrate the value are providing - Find sponsors - Be strategic - Seek opportunities with organisation that align with passion - Cultivate a reputation for effectiveness - Operate in a manner that is conducive for your career and your growth ## Feature flags unleashed by Roger Gros - To be successful - Needs to be fast and convenient, no boiler plate - Built-in dimensions or segmentation - Managing tool - Feature flag superpowers - Merge often - Complex do migrations - Canary release and beta testing - Test on production - Fracture rollback - Customisation & plans - What are the risks? - Breaking current behaviour - Operational complexity - Tech debt - Initial investment - Some best practices - Show lifecycle and small scope - Feature flags management app - Testing both scenarios (With and without FF) - Rock solid and trustable CI ## Build a data-driven on-call workflow for your team with atomic habits by Bianca Costache - What defines an effective on-call workflow? - An iterative data driven process with time for relfection - How to build an effective on-call workflow? - Applying “Start with why” - Why is on call bad in your team? - How can you improve it? - What are the results of your action? - Metrics that are the most important to the case study - Mean no. Of interrupted nighters per week - Mean time to fall asleep again - A series of bad on-call team habits - Siloed knowledge - Poor documentation (and not enough motivation to do this) - Boring technology adversity - e.g. all plans leading to big changes to fix problems rather than small tweaks - Alerting disconnected from service level targets - Introduced on-call retrospective - Review the latest on-call data tends - Discuss the last retro incident root cause and actions - Prioritise what is important - Used data to change it from an emotional discussion to a pragmatic one - Let the data reward you, you should see the results - but note that results are not immediate, but (negative) feelings are ![[Pasted image 20230628122636.jpg]] > People don’t just leave managers: they leave shitty on call rotations as well. > You can only build positive habits when your team has bandwidth. Those who make progress typically figure out how to pressure people to slow down to speed up > - John Cutler Reading: - Start with why ## Keeping your team health after a layoff by Leandro César Silva - The Preparation - Plan what work that will be dropped - Prepare the communication well ahead - Draw several scenarios and team structures - Take diversity into account - Talk to direct leaders (before, and on the day) - If you are the direct leader - Be aligned with company-wide communication - Reorganise ongoing tasks - Take sometime to accept - Through he Layoff - Impacted people (Immediately) to show support - Company communication (ASAP) - Send a message there is a future for this company - Tribe/Team communication (Following company communication) - 1:1 (but not a normal one, one that is focussed on the layoffs) - Tips - Make sure you have your narrative - Be as honest and transparent as possible - Give time to say goodbye - More humane - Don’t - Report another big change immediately - Don’t change your personal principles - Moving Forward - Fear - Reinforce the company next steps - Work-life balance - Guild - Reinforce the whys - Encourage the support for impacted people - Grudge - Difficult to revert - Retention Action - Recognise good work - Reinforce education benefits - Rebalance the stock options - Implement shared projects to bring a sense of belonging again - Prioritise opportunities internally - Give some time off - Be closer to some people # Thursday 28th Afternoon ## Parents who code: How to welcome your developers back after parental leave by Sinéad Cummings - Step 1: Documentation - Individuals over processes - Step 2: Keep In Touch - There is KIT days during parental leaves - 10 days, paid on top of parental pay - Help connect outside of being a parent - Step 3: Buddies - Act as an advocate while person is on leave - Chosen by person taking leave rather than manager allocated - Someone they trust and can be honest with - Lasts for period of leaves + a few months after return https://www.maternitypledge.com/learn-more ## Creating inclusive career ladders by Sally Lait - Rather than “gives talks” —> find ways to share knowledge and level up others - Share clear opinions in team meetings —> Help the team understand the impact of different choices - Your people, your situation is unique. Progression framework from somewhere else might not fit. ![[Pasted image 20230628145927.jpg]] ## Building for the Underserved, Solving for All by Serah Njambi Kiburu ![[Pasted image 20230629145851.png]] https://developer.spotify.com/documentation/accessibility ## Driving positive change through performance improvement plans by Cristina Yenyxe Gonzalez Garcia - We end up with processes that happen too rarely and too late - What are we really trying to achieve? - Improving the relationship between the person and the company - Let’s set up our employees to succeed - Accept that is not always going to work (her personal success rate is about 50%) 1. Before 1. Trying to avoid the PIP 2. Don’t wait for multiple occurenaces 3. Sometimes a hint is enough 2. Initiation 1. Ensure the employee understands the full meaning 1. The objective is to make the relationship work 2. Outcomes (good and bad) 3. Measurable evaluation criteria 4. Expected positive trend before “point of no return”. 2. Affliction information to get off on the right food 1. get the persons feedback on the plan and answer questions 2. Identify potential barriers and support they might need 3. Duration 1. Frequent follow ups 2. Based feedback on evaluation criteria and metrics 3. Improves —> encourage and celebrate 4. Concerns —> raise them early 5. Keep a written record 4. Wrap up (and next steps) 1. It didn’t work out 1. Final review of unsatisfied critiera 2. Who delivers the message about contract termination? 3. Clarify next steps: end of contract date, holidays, garden leave, company hardware 2. It all went well 1. Celebrate success 2. Follow up actions? 3. Keep it in the back of your mind (or 1:1 agenda) Don’t try and be too nice ## Exit plans and how to talk about them by David Kiger ## Orchestrating thousands of bots from the cloud by James Donkin ## The awful agony of the app store: When software delivery goes wrong by Clare Sudbery https://docs.google.com/document/d/1wtSutVJW8S29PXMlWG77rvVcRY5h3UQCceZGdvmAuiY/edit https://www.geepawhill.org/2021/12/21/mmmss-the-shortest-distance-floptimization/