Topics that made the cut:

• Transitioning to manager, mentoring others is part of that
• Can’t screw it up, if you have a willing partner who needs advice. Just requires transparency and honesty, and commitment to time
• You know you’ve done well if they stop talking to you.
• mentoring vs coaching?
• Explaining the why is important when you coach
• coaching as managing learning, mentoring as transferring expertise, habits
• On transparency, what do I have to offer? What would you like to get stronger in?
• Also amazing what you learn

Hybrid Planning

(Planning across organization, multi-company)

• Complicated, looked for books and resources
• When you have a scrum team, you want low overhead, collaborating quickly
• have to have a plan to get there, the parts come together
• Within an effort, a project.
• changing from throwing documents over the fence
• plan the path you can see to, all the boulders on the way, put them out there to think about them
• Have to convey what you don’t know, focusing change
• timbox thing, deliver as much as you can get done
• you can’t know everything
• keep the communication flowing
• understanding problems is hard
• people move into agile because they are sick of project plans, more about changing the mindset
• key person is product owner, reframing how you deliver value
• (why is the team huge and spread?)

• ok with “here is how I see things” vs “you should change”
• Ask them to try it for one task, one story, one sprint (then lets talk about it)
• Retrospectives are an opportunity to change (e.g. quality is a problem, lets try pair programming to up the quality)
• Try in small pieces
• [change is hard, needs an advocate]

• Want to get things done
• Select and area of the code and turning refactoring into a project (infrastructure projects)
• We didn’t refactor as we go, e.g. this area of functionality as you go (“just get it done fast”)
• Refactoring as skunkworks
• Refactor as you go (vs as a project)
• features are shiny
• communicating value in effectiveness
• Shared aesthetic of what good code is
• Unacceptable to leave them in a bad state
• Takes just one person making a mess (broken window theory)

• How to set yourself targets
• appropriate sized targets, actionable
• targets, estimates, commitments
• stretch goals
• Don’t know what an effective way to get better
• Talk to an expert, mentoring, club
• concrete goals, e.g. X games of Go, attending club regularly etc.

who only think in scope, schedule, budget

• executives have different needs, haven’t found an effective way to communicate to them
• How communicate to each need and style?
• can talk in terms of value provided
• How do we keep value in front to get buy-in and communicate effectively

• Sinking into to something away from people (books, movies, games, puzzles)
• Sports
• Scheduled relaxing – have to hit the minimum relaxing time or ‘cracks appear’
• Something creative that has nothing to do with work
• Need to “fill the well”

• managing your energy
• going to bed ritual
• Spend time on passion
• Doing too many things at once
• (light quality, winding down)
• (allergies)
• (diet, stress)
• (rythms + interuption, lights)
• (learning)

how to explain business value to executives

• optimization, neutralization, and differentiation (to executives)
• once you build it its debt, support
• How do you make projects
• Talk about costs
• Talk about options
• slack, momentum, efficiency
• TDD, build cleanly to minimize the need for later
• focused on minimum product instead of minimum viable product
• end at monolithic huge debt platform that ties you down
• need to not talk at the level of features and implementation to execs and customers
• (issues and risk)
• (wall of requirements – decision makers should have to hang each printed requirement (or story) on their wall)

• DB group, Ops group, Product group, Dev group, App development, etc each with managers.
• Can’t work in agile teams with separate managers
• Specific skillsets are problematic

• How do discuss true value
• Seems like product owners don’t really talk to owners to decide priority
• often wonder “how did they prioritize the work?”
• Can we get past “I own the backlog, trust me”?
• Could be trust problems, why do you need to know?
• How do we talk about brush-strokes across an entire area vs going deep
• The reverse problem can be moving on without polish and finishing everything
• Product owners aren’t well connected to clients (in this case, product owners are developers)
• (Does this work end to end with the customer?)

Special thanks to Colin for taking notes.