Guided Ownership

In our Tech department here at Coolblue, we strive to give our development teams the ownership they need to build the solutions our domains, and thus our customers, need.

We enable ownership through (at least) 6 Pillars:

• With clear Tech Principles
• With guidance on when to use what through a radar, architecture blocks and solution blocks
• Self-service cloud infrastructure (AWS/GCP)
• Observability
• Grow the skills you need through our Coolblue University, our Master classes or other resources you may need
• Our Domain roadmaps

Lets dive a bit deeper in each of these.

Tech Principles

Everything we design, build, deploy and run adheres to our Tech principles. I wrote about these principles in a series earlier: Our Tech Principles.

Most of these principles have been learned, the hard way. And this is our way of passing that experience along to the teams of the future.

We have made these principles part of our evaluation criteria for those that work in Tech. Making it very clear how important we think it is to work with these at every stage and at every level of development.

Radar, Architecture blocks and Solution blocks

We want teams to develop solutions freely as much as possible.

We believe that means: give the teams a lot of ownership and freedom to build these solutions.

It also means, we need to enable the teams to do so as much as possible. And by having guidance and reusability we can eliminate some tedious work, making the time and effort a Team spends focus more on the actual value delivering solution.

Reuse
We all know that reusing proven code, for a give pattern or a piece of plumbing, helps you focus on the actual solution and increase your speed of delivery.
That is why we have quite a few reusable items:

• Architecture blocks; in our industry we have quite a few Design patterns and we have selected those that work well in how we develop our solutions. You can see this for instance in our Tech Principle Encapsulate for volatility and the design pattern Ports and Adapters and the Transactional Outbox pattern.

• Solution blocks; actual implementations developers can find and use in their solutions. Some of which are packages/components to reuse, or templates to jumpstart a new app or service. And a Design System for building Customer facing applications, one for building Activity Focussed Employee applications and one for our Email communications. Through these building blocks we also make sure common practices, like performance and security, get addressed with solid implementations to be used and to serve as inspiration.

fyi: Architecture blocks and Solution blocks originate from TOGAF 9 - Building Blocks

Deploy and maintain
That does not mean we think having every team build with different tools and languages is the best way to do so. Every language and every development environment means learning something new, means support from our CI/CD platform and from our cloud platform(s).

It also means when people want to move teams, or solutions move to a different team, we have to deal with the knowledge needed to support, develop and run these solutions over time.
So we adopted a few core languages with an intended use case. Maybe not entirely a Radar, but it does give guidance and focus.

Self-service cloud infrastructure

Is every team SecDevOps to the full extent? No. Not yet at least, but I want our Development teams to be able to create new secure solutions and run their existing ones by themselves as much as possible.
Not only can you see that through our Principles Recovery over Perfection, Automation and Testing, but we also want the Teams to deploy, scale and fix when it suits them.
Our Hosting & Deployment teams develop and maintain the tools and core infrastructure that enabled our teams to do so. Through automated (Github) repo creation for instance. Want to build something new? Add the desired repo to Github via automation yourself. The same way to make sure our observability platform is hooked up to a newly created stack and CI/CD pipeline. We use this also to implement proven practices when looking at availability and security for our. cloud infrastructure.

If you were to ask any our 50+ development teams, if they want more self-service? they will say YES. Of course they will, it's in our corporate culture to "just do it". So we keep growing their toolset to do so.

One key area for 2023 is to invest in this area. We want our Solutions to be onboarded with more standard Cloud Infrastructure and to make sure key data can be shared with other apps (outside of the bounded context), our data warehouse and our analysts. We aim to leverage Events and Event Drive Architecture more and more, and making sure key Infrastructure is ready to use will help the teams tremendously. Think standard Queue's, topics in Kafka, Tables in BigQuery and more.

Observability

Technical Observability

Any Development Team owning a solution wants to know how it is performing and if it is performing correctly. And using Observability is a great way of doing that. Our Development Teams rely on metrics, dashboards and alerts to be in the know of their solutions. We believe this is critical for a Team to fully Own It. Acting on these insights and making sure our Employees and Customers can do what they should.

Business Observability

Another way we enable teams is to also give insights beyond the technical metrics.

• Operating Costs; having insights in the total costs your App/Stack makes, triggers conscious decisions on Right-Sizing the Stacks.

• Business Insights; All our Applications have a purpose: it can be process Orders, finding the right amount of Stock to keep or Sending out the right Product to a Customer. By having access to these dashboards also, the Team with their Product Owner can track if what is being done is actually Moving the Needle.

Coolblue University

Maybe an obvious Pillar, but having the right skills (ie. technical, leadership or social) will make you better at what you do. It will allow you to work better with your Team and your Stakeholders.

For that reason we have a Coolblue University with over a hundred different trainings available for you to take and use. Other online resources, IRL events, books and Class room trainings are optionally available also of course.

To understand our Business and what it is they do, we also have created Master classes. These are currently presentation-based and help any that attend to fully learn our way of working on key topics in the company.

We also share what we have learned via our internal, monthly, Tech Demo's. These offer a podium for our developers and engineers to share their learnings and insights with the rest of us in tech. By tech for tech.

Domain roadmaps

We cannot forget the reason we build Solutions/develop Software. We build it because there is a benefit for our Customers (NPS) or the Company (EBITDA). And sometimes there are more strategic reasons to build something.

Each team works with a Roadmap. We evaluate these at least 4 times a year. Always be ready to change and adjust to what we have learned. The Market, your context will always be changing. And as such we need to adjust when needed and not fall for the invested-too-much-reasoning. Agility is crucial for us as a Company and for our development efforts then also. Evident by the inclusion of Flexible in our Corporate Values.

Conclusion

This post turned out to be longer than I expected and full of corporate speak I usually try to avoid. But here we are. There are more ways we support or teams off course, but I liked the idea of focussing this on these six Pillars.

This post is mostly to share and explain how we work and think at Coolblue and how we try to create the environment for Ownership for our development teams.