Introduction
One of the great benefits of working in a software consultancy is the diversity of problems we are exposed to. The creativity applied by our team to solve these problems, and collective experience gained while doing so becomes a valuable body of knowledge that we can utilise. Sharing those learnings and experiences across the team allows us to truly become greater than the sum of our individual parts. At least, that’s the promise. The reality is that it doesn’t happen by accident, and requires ongoing focus and support. Today I’ll walk through the approach we are using to foster not only the sharing of ideas and experiences, but to collectively define the technology direction that we are taking.
The following diagram provides a high level overview of the activities we employ.
Solution delivery
Delivering successful outcomes with limited resources forces us to be pragmatic and make choices based on what works, not what we’d like to work on. Real problems are an amazing filter of ideas and technologies, and a great source of inspiration if your existing approaches are found lacking. This tech vitality process helps us to come together as a team to share ideas and opinions, but it is important to keep in mind that it’s all just talk until we have successfully employed them. As such, we recognise that solution delivery is a key part of our tech vitality process, not something that succeeds because of it. We are not prescriptive about technologies used on client engagements, we expect our team to adapt to the problems they face. We empower our teams to make their own decisions, and expect them to be accountable for the outcomes.
This tech vitality process helps provide our team with the learning opportunities and tools necessary to do their job. Beyond that, we keep out of their way.
Solution tech retro
We do need something extra from our team. We want them to package up their learnings and experiences and make it easy for others to consume. We do this through technology retrospectives. This has similarities to an agile retro, but we focus on technologies, patterns, and learnings for others to consume rather than how to make the team work more effectively.
These findings are published on our internal wiki. We strive for a concise summary that answers:
Who was on the project?
What key technologies, patterns/techniques were used?
What worked well and why?
What didn’t work well and why?
Why is also key in the points above. It is only by understanding why things worked or didn’t work that we can apply those learnings elsewhere.
We are not creating an instruction manual that teams can apply without thought on other projects. Any “best practice” we attempt to define is only relevant at a specific point in time, for a specific problem, and subject to a specific set of constraints. What we are creating is a consumable set of experiences and learnings that can be used by other teams to improve delivery speed, avoid mistakes of the past, and improve confidence in their choices.
We run these retros prior to tech radar sessions so that the team has consolidated their thinking and ideas are fresh in their minds. Running them at the same time makes them easier to schedule and therefore more likely to go ahead.
Discipline tech radar and voting
Tech radars are a popular mechanism to capture opinions on the suitability and maturity of technologies and techniques. Sessions to define tech radars are fun to participate in, and promote a healthy environment for sharing ideas and opinions. We don’t attempt to re-invent the model, but where we differentiate is how we integrate our tech radar process into our overall approach to tech vitality. Here I’ll share some of the specifics of how we run the process.
Tech areas and inclusion
We run sessions for each of our major technology areas including UI, API, Platforms, Data, and AI/ML
Discussion and categorisation
We spend the first quarter of the session brainstorming ideas and putting sticky notes on the wall.
We spend half the session discussing the technologies and placing them into categories of Hold, Assess, Trial, Adopt. This is the most animated part of the session, and we learn a lot from the discussions. I am always surprised how aligned most of the team are on the majority of items and we avoid so we don’t spend much time discussing these. There are always a few items that require some debate. When facilitating these sessions it is important to ensure that the team doesn’t get hung up on which category the technology falls in, but to define why it has been put there and when it is not applicable.
Voting
The final quarter of the session is simple to implement, but the most important. We ask the team to vote for their favourite items. We typically give each team member 5 votes and ask them to vote for the items that they think we should invest in over the following year. We encourage them to apply an investment lens to this process. We want to place bets on promising technologies in the assess category that have a chance of providing a high return in the future, and also to ensure we’re improving skills and offerings for technologies in the adopt category.
At the end of the session we have a big list of technologies and techniques, and good alignment across the team on when and where to apply them. Most importantly, we have buy in from the team on which technologies we should focus on in the subsequent six months. We do have principal engineers in each area who are responsible for identifying investment in each of their respective areas, but their success in this role is measured by how effectively the team builds technology recommendations rather than just themselves.
Technology strategy
The technology strategy is where we determine how to invest in the identified technologies. This is not only a Mantel Group activity, it also feeds into the broader Mantel Group technology strategy. The outcome here is a business plan that includes technology investment activities.
We have several ways in which we invest:
- For technologies in the Assess category we perform technology assessments.
- For technologies in the Trial category or Adopt category that we want to expand our skills, we develop and offer training.
- For technologies in the Adopt category, we develop solution accelerators.
These investment approaches are explained in more detail below.
Tech assessment
We need a way of moving technologies out of the Assess category into Trial without placing undue risk on our clients. We do this by running technology assessment workshops. Some key attributes of these sessions are:
- Team is picked based on suitability, not availability. This often means taking them off client engagements, and we budget for this.
- We solve a real problem, or at least a realistically contrived one. The aim is to test the technology in a realistic environment, and not just to play with quick start guides.
- Related to the above, we typically test a vertical slice of technologies in a single assessment so that we can build something end to end.
- The session must produce a working demonstration that can be used to showcase learnings.
- The session must document findings and recommendations that can be used to present to the broader team and clients.
- The theoretical model we use to plan and budget is 5 people working for 5 days, although in practice we adjust as required.
These aren’t your typical hack days. Hack days provide a rewarding and creative outlet for creativity and positively contribute to the team culture, but they lack the focused outcomes we need here.
Training
Training is typically used for technologies in Trial or Adopt categories where we have small pockets of strong knowledge, but need to broaden this knowledge across the team. We pride ourselves on being a learning organisation and we often leverage the knowledge of experienced team members to develop and deliver our own training material. So far, we’ve developed and/or delivered training for Kubernetes, Istio, and Golang.
We offer this training to our entire team, and invite interested clients to participate as well. We have a dedicated area used for hosting large groups for meetups or that is leveraged for everything from community meetups, to delivering training. We typically deliver our training in a 2-day facilitator led format, although we usually augment these training sessions with self-managed activities either side of the event to make best use of the time together, and to help participants continue to explore and develop their knowledge outside the session.
We have a great space to deliver training, it’s the same space we use for hosting community events. Having a dedicated venue is really important to us, organising an event is as simple as booking a room and sending out an invite. Anybody in the team can propose and run a group event and this makes it much more likely that these types of sessions will occur.
Solution accelerator
For mature technologies we often find ourselves solving similar problems on different engagements, so we look for ways to share reusable components across clients and engagements. We promote a platform thinking approach to improving leverage and reuse across teams, and have been fortunate to work with clients who are willing to share components in areas that don’t directly relate to their core business. The easiest areas to promote sharing are in common tools and infrastructure to support development and operational activities. Over the past 12 months, most of our efforts in this space have been to used to support the adoption of the Kubernetes ecosystem. We hope over time to improve re-use in APIs and UI technologies.
So what about products? This is really a question of labelling. All solution accelerators should be treated as a product, they need to be branded, marketed, have clear product ownership, and have a market justifying its creation. But, the value they add doesn’t have to be an explicit revenue stream, it is sufficient for an accelerator to speed up solution delivery and promote good practices. In other words, we may choose to offer products commercially but we want to keep the bar to achieving re-use as low as possible.
Acquisition and growth
Mantel Group employs a house of brands strategy and is looking to introduce new brands over time as new opportunities arise. If a technology is identified as having sufficient potential, one option is to launch a new brand focused on delivering it to market. As an example, we have recently launched the Kasna brand (https://kasna.com.au/) to help clients introduce Google technologies to their business.
Community collaboration
Community collaboration is critical to our ongoing success. It provides perhaps the best avenue for sourcing new ideas and experience, identifying future team members, and increasing our exposure to current and potential clients. I won’t elaborate in detail here, but this takes many forms. It includes the obvious venues such as attending and presenting at meetups and technology conferences. We’ve delivered brown bags to our clients to help increase awareness of newer technologies and how we can contribute. And we’ve organised forums for non-competing clients to discuss and share approaches to solving common challenges.
We don’t attempt to manage our participation centrally, it is too organic in nature for that. However, we do have several ways of encouraging participation. These include:
- We provide team members time and space away from client engagements to consolidate their learnings and build materials to be shared. Specifically we provide time to write blogs, develop meetup and conference presentations, and study for certifications.
- We have developed our own presentation space which is used by Meetup groups, used by clients for offsites, and used by our team for brown bags and training sessions.
- Our internal team of teams structure has allowed interested team members to self-organise around supporting our Meetup involvement and help with the lesser celebrated tasks such as catering and cleaning.
Summary
We’re still a young organisation, and that is an advantage. We’ve had the opportunity to pool our ideas and learnings from the past, and come up with ways that will help ensure we continue to evolve along with our clients and their needs. We like what we’ve come up with so far, but it will never be perfect so we’ll keep trying new ideas. Many of the approaches we use are not new, but we think our application of those ideas is what makes us different.
We’ve attracted a great team, with great clients, and interesting challenges. The only way we’ll continue to do that is to keep learning and sharing.
