Tell me about a time: leadership Flashcards
Tell me about a time you balanced technical improvements vs product work
Sit: Our team faced a high priority and urgent piece of work: passing service assessment. We needed to ensure our service met the government standard. but a lot of smaller improvement tasks to complete. I could see engineers sometimes get lost in improvement work and lose focus on product work.
Task: Develop an easy way to focus energy on high priority work but also make space for improvement
Act: I led an idea-generating session and proposed a workflow diagram the team could use as a reference, an improvement board, and 10% time pattern. We timeboxed improvement work to 1hr. If it took longer than an hour, add a card to the improvement board. I helped maintain the improvement board and any assessment related work could get pulled into planning. Team would often use their 10% time to chip away at an improvement card which they really cared about.
Result: The diagram was a useful conversation tool to help individuals focus. We were able to achieve our product work and built in improvement work into our planning process.
Reflection: I wish I’d taken metrics on how much improvement work we’d done previously and how much we got done after. I also wished I’d mixed extrinsic and intrinsic motivation a bit, something I’d done with a previous improvements vs product work scenario
Tell me about a time you led a technology strategy
Sit: Our team needed to pass a government service assessment, a set of rigorous standards applied to all government digital services who wanted to move from Beta to Live (a requirement for further team funding).
Task: Create a tech strategy which would pass technical service assessment AND aligned with our stakeholder needs.
Act: I reviewed the assessment criteria and identified areas where we easily met the criteria and where we’d need to improve. I cross checked the “must” list with feedback from our threat modelling session, stakeholder roadmap, and annual IT Health check. This provided an overall picture of priorities, in particular overlapping tasks which could accomplish multiple goals giving weight to certain work. I led a series of sessions to complete a similar process as a team because I wanted the different insights/perspectives. These sessions created a roadmap which was maintained by myself, the PM, and the DM. We created function streams in the team (PM/DM, UX/Design/Content, engineering) and met regularly until assessment date. I led the engineering stream, working with our architect, senior developers, SREs, and cybersecurity expert to plan, implement, and deliver the work, keeping our roadmap updated and communicating with senior management throughout.
Result: We passed assessment, received £2 in funding, and secured the continuation of the team. We used the roadmap to help plan out 2022 work.
Tell us about a time you developed local/global engineering standards
Sit: Our commit practices across the engineering department were a bit messy. Messages weren’t always clear and it was hard to tell a story about what work was done and why.
Task: Find a tool or standard to help us write commits that could tell clear stories about our work.
Act: I researched and found “conventional commits” a commit style guide that helps devs write clearer commits. I started using them on the team when I paired and it spread to my pair partner and then the whole team. I realised we could get a sense of how we were spending our coding time by using the GitHub API to measure the proportion of commits with a set wording. I wrote a Python script to do just that.
Result: Our team used the information in retros which helped us talk about how we felt we were spending our time. I talked about my work in our 20% time meetings and other teams got interested and implemented the practice. I then expanded the convention to google calendar meetings. I wrote Python script that used the Google Calendar API to track how were were spending our gathering time.
Had too much work to do and had to prioritise/deprioritise/make recommendations around work (particularly when considering trade offs like being a dependency for other work in the company, security, effectiveness, etc)
security, effectiveness, etc)
Sit: Our team needed to pass a government service assessment, a set of rigorous standards applied to all government digital services who wanted to move from Beta to Live (a requirement for further team funding).
Task: Focus completely on service assessment in order to pass, deprioritise other work.
Act: Prioritising is made easier when we have a strong sense of business goals and the cost of NOT doing a piece of work (helpful if we can talk in $$). Also helps to have a clear effort for value understanding of tasks. I reviewed the assessment criteria and identified areas where we easily met the criteria and where we’d need to improve. I cross checked the “must” list with feedback from our threat modelling session, stakeholder roadmap, and annual IT Health check. This provided an overall picture of priorities, in particular overlapping tasks which could accomplish multiple goals giving weight to certain work. I also worked with the team to help figure out the cost of NOT doing some of our competing priorities. I made sure we had a board we could keep deprioritised work and an avenue for people to work on deprioritised work as part of their learning (10% time).
Result: We knew what we had to accomplish, why we had to accomplish, the cost of not completing work, and a path to complete that work in the future as well as the present.
Tell us about a time you managed a difference of opinion about a technical approach
Sit: The details are a bit fuzzy. I was a java developer on an app development team. The team was introducing a new tech to our stack. As a group we’d developed a weighted acceptance criteria and a duo had researched options. They created a matrix of tools and how the tech options performed against our acceptance criteria. During the session two colleagues disagreed on two very similar tools (negligible difference on the matrix). We got stuck in a place of disagreement over what seemed granular details.
Task: Intervene in the disagreement to help move the team to a decision.
Act: I asked for a break in the session so people could refresh, get a cup of tea/water. I summarised the conversation so far, I returned the team back to one of our core values: experimentation and our new commitment to “disagree and commit” which we developed in a previous team building session. I watched my teammates nonverbal cues to gauge how this returning to core values landed. People seemed less tense after the break and also a couple smiles. Since the tool was one we’d all be using I suggested we experiment using one option for a period of time and review our experience at X date. The choice of which tool to use could be put to a vote since all of us were going to be users.
Result: We voted, experimented, and reviewed the experiment. I think we stuck with the fist tool. It saved us from having follow up discussions.
Reflect: I wish I’d been doing regular 1-1s with the team to see how the session had gone from different perspectives.
