Jeremy Burns
- How do you measure delivery speed (lead time to change and deployment frequency) and platform stability (change failure rate and mean time to restore service)? Are you happy with both sets of stats?
- Where is the sand in the machine? What causes friction? For example, delivering quickly enough, too many last minute changes, inefficient deployment processes, red tape or other things?
- What's the overall confidence that changes will work and not break things?
- How would you describe the availability and reliability of your system? And - if you had to choose - which is more important?
- What monitoring and alerting do you use? New Relic?
- Do you have many high impact incidents? How do you compensate engineers for being on stand by and for responding to incidents? How would you describe the mop ups and resulting action plans?
- What sort of business and technology measurements do you use for transparency and constant improvement?
- How do you ensure that the right people are rewarded and promoted? How do you assess progress against career milestones? How do you identify and manage non-performers?
- How are people moved into the right roles? Do you have progression streams for individual contributors, technical leads and people managers?
- Does this role have a budget? What are your budgeting processes?
- How do you view your staff retention and attrition? If people leave, what are the common reasons?
- If you viewed engineering/technology as the supply side and the business as demand, where does the delivery function sit? How would you describe the relationship between demand and supply? Does technology supply fast enough and do delivery requirements compromise stability?
- How would you describe the culture? What non-work related activities are common? How often does the entire team or pockets of people get together to celebrate achievements or have fun? Who drives those? How can people safely air problems or concerns?