We show people what good looks like (because we have experienced it, many times). We put metrics on the landscape to help understand where we need to focus and demonstrate the change. We enable your people to deliver the change, through coaching and pair programming. Success for us is stepping back out of a modern cloud native engineering/technology/digital function.

Many of our clients do not have the insights to help them really see what is going on within technology. A technology practice within an organisation is a function of its people, teams, organisational structures, leadership, technical direction and strategic direction. No 2 organisations are the same, and their ability to perform is dependant on so many intangible factors. We’ve created a series of exercises based on industry best practices to help you better articulate the true state of your team. By using a combination of quantitative, data-driven metrics, as well as qualitative insights, we provide your teams with a sense of their strengths and areas for improvement.

The AK way is a collection of approaches for “delivery with engineering agility” that we have used for many years as a baseline when we are engaging with clients. It’s not meant to be a fixed approach model, nor is it the only way we work - as we all know, operating in the world of software is about adaptation and pragmatism - but these approaches have served us well across a range of industries, projects and engagements, and are constantly evolving. If the client/team/dept we are working with doesn’t have a practice in place for any of these practices, then we have something to fall back on.

Most of our engagements with clients are about helping them change how they deliver technology, whether helping with the adoption of scalable microservices, or building self serve infrastructure platforms. However, in the most part we are helping our clients adopt the mindset, practices and approaches that will enable this approach beyond our time onsite - modern, cloud native engineering practices. Alongside this, we enable the change of the technology function as a whole (structurally) and how the technology function interacts with the rest of the business - whether that’s with business functions, governance, audit/security and others. Below is a “typical” engagement model, but our approaches and modular/productised and so we often just do one part of this. Step 1 - Understand the landscape/topography In order to work with a client, we need to understand what is going on in their organisation, with an external focus/viewpoint. Step 2 - Start to plan the roadmap Once we have a view on where the organisation is at, we start to work with leadership on where they are trying to get to, aligning to the organisation strategy and/or the engineering/technology strategy, and build out a roadmap. Step 3 - Educate In an ideal world, the entirety of the (technology) organisation understands what we are trying to achieve. Typically we find that there is a lot of “unconscious incompetence” - ie people don’t know what the don’t know - so we run sessions/workshops to demonstrate hands on what good looks like. This aligns the whole organisation to the approaches and mindset that we are trying to distil into the teams - and “should” create a sense of desire around that end goal. Step 4 - Start to drive change This can take many forms, but all are based around coaching individuals or teams through the change. Example: An Engineering Accelerator: we embed a pair of experienced practitioners into a team to coach and pair (rotating round your team) for 3 months, shaping that team into a modern cloud native engineering mindset and ensuring that the practices are embedded and desired by the team, not a chore. Step 5 - Observe, Orientate, Decide, Act Constant observation, sensing of what is working, what is not, learning and adapting as we go.

At a technology/implementation level, Armakuni uses the Dora research and metrics, based on over 12 years of surveys, research and data collation, to benchmark and guide technology performance metrics to business outcomes. We combine this with our Engineering Insights which helps us look at broader environmental metrics - capabilities, approaches, psychological safety, cognitive load - all significant factors in a function's ability to respond to business/organisational needs. At a more holistic/contextual level, we identify the symptoms/issues that the broader business is experiencing and tie these back to the metrics we gather so we can demonstrate change over time.