At the end of October we held our first Engineering Leadership roundtable, bringing together leading engineers in the tech space, to discuss relevant topics within the industry.
The event was a great success, with insights and collaboration from all the speakers and attendees.
Stranger Things – Scaling Teams and the Adoption of Microservices
For the first talk of the event, we were joined by Director of Engineering, Data, Infrastructure and Growth at Blinks Labs GmbH, Gopi Krishnamurthy, who spoke about scaling teams and the adoption of microservices. Blinkist hosts an app that breaks down non-fiction books into short ‘book-in-blinks’, offering you key summaries and insights.
Gopi indicates that when originally beginning a start-up or SME journey, the application architecture and RACI is usually quite simple. Relating to his own experience, however, after a 2 year hyper-growth phase at Blinkist, the engineering team grew to around 40 engineers. With everyone building new features in order attract and retain customers, deploying features suddenly became a high risk / high impact move. To counteract this, Gopi found that moving to a microservice architecture automatically built an organic guard rail around the engineering services, creating a clear segregation of duties. The scope, risk and impact became clear to the teams and as a result increased their efficiency.
There were three distinct patterns that Gopi noticed during this transition. Firstly, the small landscape and application architecture of a start-up or SME does not need to be defined. It is very simple to organise, with more focus given to growth and fast delivery to go to market with a high quality product.
The second pattern Gopi discusses revolves around the complexity of the data landscape as businesses grow and scale. At Blinkist, a lot of these teams were generating their own product and processing this data which made it very difficult to manage this landscape between teams as they struggled with end to end accountability, further data reliability problems, and the overall move into domain architecture that lacked capability. To overcome this, Gopi suggests moving into data domain architectures as they create an isolation of the data, whilst still preserving an exchange-to-exchange (E2E), accountability model for the members of the team.
The final pattern Gopi discusses, is applicable for evolving organisation structure as you scale your engineering team. The adoption of microservices allows you to give engineers autonomy, creating a more flexible and dynamic working environment.
These patterns were natural transitions that created an environment where it made sense to adopt microservices, an environment of now 55 engineers and 220 microservices. This organic growth is something that Gopi made sure to really point out as the technical environment pushed them into a corner where they had no choice other than to adopt microservices. This is an important point that Gopi emphasises that encapsulates the entirety of the talk; the need for teams to focus on their outcomes rather than technology trends and let that guide them.
Opening the discussion to the floor, questions were raised around synchronising these changes, and whether microservices should be avoided all together. It was decided that microservice adoption is relative to the organisation you are working in, and this adoption should happen organically if there is a need to move.
Productivity Metric in Measuring Team Performance
Hizam Sahibudeen, Senior VP of Engineering at Newstore, discussed the productivity metrics behind measuring team performance. Newstore provide omnichannel as a service, offering customer and clientele features like order management and mobile point of sale.
Hizam mentions how he came into Newstore with the ambition to shake things up, change the team mindset, and improve performance. By implementing microservices the focus became data driven, from order management all the way to fulfilment, allowing the management to subcategorise and break down teams into different business contexts to measure. Hizam also reiterates the idea that by adopting a microservices approach, more autonomy was given to the engineers. Microservices allow you to provide support to an individual team rather than applying practices to everyone.
Once Newstore increased in scale and autonomy levels, Hizam mentions how he bought in productivity metrics to ensure that everything was one track. An important aspect of establishing high performing metric teams is organisational culture.
It is important to point out that there are clear deficiencies in metrics, with the key problem being that you focus more on output rather than the outcome. Hizam emphasises that metrics are only valuable when paired with a business goal; something to aim and work towards, using metrics along the way as nuggets of knowledge to position teams in the most effective way. In addition, you can’t necessarily use one of these metrics in isolation completely successfully, instead you have to introduce all of them to find the best value.
Hizam provided an overview of 6 metrics that he had implemented in his team to measure productivity: Lead Time, Cycle Time, Deployment Frequency, Team Velocity, Throughput, MTTR (Mean Time To Restore). Together these metrics measure how quickly the company can provide value to the customer.
Lead time is measured from an idea concept, to the delivered software. This allows you to be more responsive to your customers, simplifying decision making and reducing wait time. Cycle time is the time for an issue to cycle from an open state to a finished state.
Hizam mentions when talking about team velocity that he looks at velocity not as speed related but as a capacity. He uses it as a planning tool to see how much a team can do in the next sprint. Alternatively, when you just look at speed as a goal, the team just focuses on that number. Whilst in his definition, Hizam wants a team to use that number and plan deliverables.
Throughput considers alignments in activity – measuring the number of support tickets that go into a team. Throughput is very useful from an investment perspective and when focusing on individual teams.
The last metric is Mean Time To Restore (MTTR). This measures how long it takes for a team to react and recover from an incident. By tracking this from failure, they ensure team collaboration, as the process is transparent, and the technical debt is all in balance. A lot of issues can be fixed this way, and the longer it takes for something to be brought up, the longer it takes to realise you are in a bad place in your code and need to fix something.
It’s important to point out that you can’t necessarily use one of these metrics in isolation completely successfully, instead you have to introduce all of them to find the best value.
How to Bring Back the Red Projects on Track
For the final talk of the event, Shivendra Tiwari, Engineering Manager at dunnhumby, spoke about how to bring back projects in red on track.
Talking about his own experience, Shivendra mentions how one of the products in his company was delayed by a year, when the team size was sufficient to achieve the goal. The team found it difficult to deliver the product due to the shaky code quality. The product failed the User Acceptance Testing (UAT) five times, and the leadership team were beginning to have little confidence in the team. Since Shivendra joined the team just six months ago the product has gone from version 0. to v2.4.0 with a successful UAT, with users starting to adopt the product.
Discussing how he bought the product back on track, Shivendra highlights three aspects to the product: people, process and product.
Shivendra emphasises that it is important to be a coach to your engineers so that they feel enthusiastic about the product and confident within their role. To achieve this you must identify what motivates the individual members of your team. Build a culture of learning through schemes such as mentoring, workshops and tech talks. Reiterate the goal you are aiming for at every occasion and cultivate a challenger mindset in the team.
A key aspect to bringing back your failing products is to be adaptable with your processes. Document the roles of individual users, remove time wasting activities – Shivendra highlights meetings – and take risks.
The third and final aspect to bringing your projects back on track is the product itself. Shivendra emphasises that it is crucial to stick to the release schedule, things improves motivation, increases focus and releases pressure from the team. Understand your product really well – know what features are a must-have, instead of an add-on and recognise the pain points.
Thank You
I’d like to thank all three speakers for thier insightful and engaging talks, and the attendees for contributing to a great event.
If you are interested in speaking at our next event, or attending one don’t hesitate to contact Third Republic or even the host Gus Firth directly.
