# Autonomy vs Structure - Can work when there is a clear vision - Leadership sets and communicates these effectively - Teams can influence up as well as leadership setting goals - Product responsible for problem definition? Engineers have autonomy for solution? - Product manager can enforce a structured approach which limits autonomy e.g. "Work on xyz ticket" - How do you allocate accountability to autonomous teams? - It might be possible to use micro-goals to guide team autonomy - Does it need to be autonomous, or just "feel autonomous"? - Motivation comes from a sense of autonomy - Having influence on decisions i.e. being heard may be more important than autonomy - Understanding the goals but still having freedom to pick an item that may not be the first thing product want engineers to work on - Engineers might want to have autonomy to grow their careers rather than company aligned reasons. If not motivate by product and vision, motivated engineers may go off and build something that is of value to them but not the company. - If you are too dependent on other teams for your OKRs success, then you need to push back and redefine what is being measured - Engineers don't want just a hypothesis but data to give them confidence that it is the right direction - If you are using a PM then a lot of the context only comes from them, which has its own challenges - If they "shield" engineers too much then that limits engineers in terms of autonomy - If everything is commercially driven, then that makes things harder to work on things that are hard to measure against this e.g. speed of delivery vs sustainability/total cost, reducing technical debt and toil - If PM and TL are too aligned then there is not enough push back, we still need to work on things that are not fully aligned to PM - The best technical decisions are made when you understand business context - "Demo driven development" or "CV driven development" don't fix an autonomomy problem - The more limited the scope, the less opportunities there are for autonomy - Need to make sure we are no too commercial or too technical, need a balance of these - You need to repeat to the team on many occasions the business context and value - Engineering can try to predict what product will do if they don't give enough clear direction - Things that require a lot of discovery, research, or longer lead times - Building capabilities in advance - Product need to propose difficult to build features to make sure they have a competitive advantage. If they are too easy the competitors probably have, or will build these too. - A clear boundary between Engineering and Product is too simplistic, really we are one team adapting to the market together. Trying to implement clear division of responsibilities can be a limiting factor. # Methodolgies and Tools - Kanban - Company X - "Scrumban" - All teams have freedom to adapt process as they wish - Doing a bit more planning upfront - Practices - XP - Kickoff - More about business context - Housekeeping - Product fortnightly demos - 5m per team - Mandatory retrospectives - Look at metrics - Throughput - Cycle time - Use it to talk about outliers - Some times to retrospective on specific issues that may include audience broader than the team e.g. post-mortem on a specific issue - 6 week planning - 1hr rolling - Kanban - Can still have planning - Conversations around what work has priority - When should it start - Building trust with your stakeholders using metrics, that end up being relatively accurate - When working with external stake holders then having some slack gives you adapatability e.g. - 6 week goal, weekly/fortnightly goal - Work backwards on the board based on what we are trying to achieve - What are we shipping today - What do we need to look at next? - Team goal, and then update against that goal - Assess against the goal as you go through the week? - Makes the team more accountable - Sometimes the team will change the goal in the week - Under or over committed? - Makes the plan a negotiation tool - There is more to your team than just coding - Preparation - Reviews - QA etc. - Pairing on in progress tickets rather than picking up something in TODO - Team README, Ways of working process map, workshop, definitions of ready and done - What is OKR is blocked by another team? - Loan developers? - Use OKR as a negotiating tool, does it trump the other teams OKR? - Escalate through leadership if neccessary - Post-morterm after to see what lesson can we learn - How do you factor in discovery? - Discovery goal as well as delivery goal - Have it on the same board - Might me product or research lead - Could have engineers involved, might requires spikes # Remote Camaraderie - Context - Company previously was 1 day remote - Was hybrid, but going fully remote - New joiner left as he came in but usually there were not other engineers coming in - Techniques - Have 2 week engineer lunches - Have "official coffee" - But is this a bit forced, and it's yet another Zoom call - Hangout rooms - Pairing - Games - Buddies for onboarding - Even fully remote companies have special days where everyone gets together - Creating small clusters of people that are a mix of teams, seniorities etc. - Can use (already communicated) company news as a talking point - Could be around a certain project, or not related at all - Non-work related chats e.g. Movies - Personal introduction slides - Could be a mini-presentation - Could be HR facilitated and published more widely that team/tribe - End of probation period - Grows and glows e.g. highlights - Make sure new joiners are aware that they can and should ask lots of questions, even if they are already asking questions they can probably ask more - Co-working space - Can help with isolation even if it's not with your team members - Able to work with some of your team, or some of the company, or just not on your own all day - Gives home/work separation - Company treats - Something that can be sent out in the post - One company sent out a menu you could opt for a shared experience e.g. tasting: gin, beer, cheese etc. - Phone calls not zoom to avoid zoom fatigue? - How can we make the office more productive? - Open plan offices can be distracting - There may not be enough meeting rooms if most teams come in on the same days - Signalling - e.g. I am going to lunch, finishing work, going for a break etc. - Use a cohort of new joiners to onboard them separately before joining their teams - Depending on the seniority of the new joiner, could have intros with leaders who can explain their problems and motivations # Developing People - Technical - Specific courses, certifications, pairing - Soft skills - More difficult to improve - Aligning the work to give the opportunity - Showcase what people have improved to team members - Bringing people down to earth when they think they are already doing something well when they aren't - How do you do this in a way doesn't demotivate there - Reviews - Set goals and objectives - Company aligned - Personal goals - Check in to find out - Why not if they aren't progressing? - Different learning styles - Reading - Making/Doing - Make sure they have the right work to improve their skills - Encouragement vs requirement? - Everyone has to own their professional development - Company will provide means - It could be made mandatory part of the job, you must get better at your work - Could make this optional, but get buy in from other team members to set an example - It is part of your preformance - Create a ticket that tracks the work - 2-4h work per week - Allows you to break down a bigger chunk of professional development work - Brings accountability and visibility - Lack of passion/motivation - Could be a symptom of burn out - Lead by example - Show the rest of the team and your reports you are spending your time improving yourself too, and they will feel more empowered to spend the time yourself - "Encouraged turnover" - Incentives for people to move team - Improves knowledge sharing, business context - Puts people out of their comfort zone, work with new people, work with new technologies - Low performers might be encouraged, as a new team may give them new motivation if it aligns more to their interests and career objectives - Make sure you put juniors in with motivated pepole, this should rub off (and vice-versa if you pair them with someone unmotivated) - Peoples personal experiences about their own personal development - Manager who was very supportive - There was a clear structure to a certification - There was a mandate that you had to do certain things - Anything you needed was no trouble - Mentoring - Have company aligned values - If your manager is rewarded based on delivery then this may conflict with personal development - Giving people opportunities to own small projects - Competencies and skills defined - Some core - Some optional - Encouragement rather than fear