Difficult to believe it’s day 60 already but it’s true. Since my last post we have made significant progress in a number of areas but what I have found to be most pleasing is the way the entire team is working together.
I have experienced working with both high performing teams and with teams that, at least in my humble opinion, simply didn’t function in a productive fashion. Describing the feeling of working with a team of individuals that have managed to organise themselves in such a way where everyone is fully conscious of their role in the success of the enterprise, and crucially is acting towards achieving that success, can take many forms but, for me the feeling sounds like a precisely tuned engine firing on all cylinders and it’s instantly recognisable. So I’m delighted to say that last week I heard that noise loud and clear!
How to achieve cadence
I’m not going to dwell on the importance of cadence, rather I’m going to assume that its importance can be taken for granted. Cadence in the workplace is about achieving harmony in the way we work to maximise our productivity. The factors that have to be considered are things like the type and frequency of different meetings, who we meet, how often we meet and what we discuss. Over the past 60 days we have engaged in a considerable amount of experimentation, and we continue to experiment, but I’d like to share some the insights gleaned so far and the practices that we are institutionalising.
Project Launch Workshop
This is one time workshop which I asked to have organised when first joined YOU Technologies Group. A four hour workshop with presentations from the product, business and engineering teams with the express goal of ensuring everyone is fully informed of the current state. For me, as new joiner, this was an invaluable meeting. While I had gathered considerable information about our product and current state I still didn’t feel comfortable that I had enough information and as it turns out, I wasn’t the only one. This workshop gave the entire team the opportunity to be brought up to the same level of understanding as everyone else. I would stress that it didn’t really matter that the project was already well underway before I joined, the point was that for me, as an executive, I wanted the rest of the team to share their understanding with me in a formal environment where we could all challenge each others interpretations and have the necessary resources, in one place, to answer all of our questions in front of everyone else. Overall this was an incredibly useful exercise and one that I have witnessed in the past to produce a strong foundation for future success.
This was without doubt the most difficult meeting I have had to date but one that had to be endured. Following on from the Project Launch Workshop the purpose of the Engineering Offsite was to capture as many of the stories required to implement the product as possible and to achieve a reasonable amount of elaboration on those stories. The point of holding it offsite was simply to be in a neutral space where we could openly discuss different points of view and to hammer out how we wanted to move a ahead. Luckily my Senior Solution Architect is a member of Dim Sum Labs Hackerspace so we held our offsite there.
I have to be honest, getting bunch of engineers into a room and keeping them there for six hours while we go through each story with the product manager, discuss it and update JIRA accordingly was torture for everyone involved. However, we got through it and the benefits of this activity in the long run far outweighed the short term pain. For instance we decided to adopt the syntax of Agile story writing, something that had not been previously agreed with the product team. Getting all our stories into JIRA meant that we could begin tracking progress on them more effectively and also allowed me to create the sprints, epics and releases for the product. We now have a detailed and shared view of what we need to do to launch our product.
Daily Executive Catch Up
We typically schedule 30 minutes at the beginning of every day for the executives to provide an update their progress on key tasks. This is especially important when anyone in the executive team is out of the office, which is unsurprisingly often the case. The meeting ensures we are all kept informed and can react to fast changing events quickly and with a unified response. Sometimes these meeting can take longer than 30 minutes and so far we have all managed to accommodate this when it happens. I would much rather that meetings overran as long as I felt properly informed and confident of the actions that I need to execute as opposed to slavishly keeping to the schedule, especially at this early stage.
Within engineering our sprint planning meetings occur fortnightly for 90 minutes. So far we have managed to cover all the stories prioritised by product team in the scheduled time in every meeting. We have managed to achieve this largely because the product and business teams elaborate the stories and share them with the appropriate engineers during the course the previous sprint, so that by the time we engage in the sprint planning everyone is already well informed of what they are being asked to deliver and the discussion centres largely around confirming our understanding and estimating the time it will take to complete the stories.
I run the daily stand-up meetings with engineering which run for 15 – 30 minutes. We discuss progress made on stories, any blockers to progress and raise awareness of the backlog (if anyone has a good strategy other than hiring more staff to clear backlogs do let me know). I also use the standup meeting to inform engineering of significant events that may have occurred that day which they need to be aware of. Our stand-up meetings occur at the end of every day.
I started the design meetings at the beginning of this week. The purpose of these meetings is to have the business and product teams meet with engineering to explain the users’ flow through the application for a single use case. The flows are created before the meeting and typically there will have been some prior discussion around the flow before we enter the meeting. The objective of the meeting is for all parties to agree on the design of that flow. The output for the engineering team is to identify the components and API calls that will implement the use case. I originally scheduled these meetings on the daily basis for 90 minutes but we found that after the first three meetings we had already created a enough of work to pursue and further meetings would only result in us having to revisit the deign to refresh our memory once the time came to implement the designs. Ultimately I think one or two design meetings a week will be adequate.
Weekly Team Hangout
An essential element for building cadence is the weekly team hangout. These meetings are a combination of work and play. We start the meeting by having one person from each line of the business providing a retrospective on the week. What went well, key milestones achieved and what can be improved. The retrospective takes no more than 30 minute and then we order the drinks. We try to hold the weekly hangout in a different location every week, this way we all get to know Hong Kong a little better every week and I think it also helps to keep the hangout energised and refreshing.
Meet Leo, the proprietor of Mezcalito which offers the widest range of tequila and mezcal in Hong Kong!
The venue for the hangout has to meet certain criteria, firstly it must be quiet enough to be able to have a discussion, at least for the first 30 minutes. Finding such a venue in Central is no mean feat however it can be achieved if you know where to look. Secondly it has to have character, in this respect Hong Kong is blessed! For instance last week I found Mezcalito, an amazing bar tucked away on the 27/F 18 On Lan St. I’m a big fan of Mezcal so when I found Mezcalito I didn’t waste any time to introduce myself to Leo the proprietor in order to organise the location of our next hangout.
In the next post I will delve into vendor management and the technology supply chain. The most successful projects I have witnessed are those where our vendors took an active role as partners in our delivery. The importance of having productive relationships with your technology suppliers; having them actively support you in identifying solutions and really being an extension of your engineering team cannot be underestimated in my opinion.