This post is an attempt to capture and expand on those ideas, drawing on two books I’d recommend to any engineer: Accelerate by Forsgren, Humble, and Kim — and Leaders Eat Last by Simon Sinek. Both of them shaped how I think about what high-performing teams actually look like.
There’s a quote I opened my talk with:
“High-performing engineering organisations aren’t defined by their tools — they’re defined by how well their teams collaborate.”
I think most engineers would nod at that, but we often don’t act like we believe it. We invest heavily in tooling, automation, and architecture — which are all important — but collaboration tends to get treated as a soft skill, something you either have or you don’t.
Accelerate makes a compelling case that collaboration between development, operations, security, and platform teams is one of the strongest predictors of delivery performance and organisational health. Not tools. Not talent density. How well teams work together.
Here’s the thing — collaboration isn’t meetings. I’ve been in plenty of organisations that have tons of meetings and very little actual collaboration. What it really comes down to is three things: shared purpose, shared context, and shared accountability.
Shared purpose means everyone understands the customer impact of their work. Platform teams see themselves as enablers, not gatekeepers. Engineers understand why golden paths, standards, and guardrails exist — not just that they exist.
Without shared purpose, collaboration collapses into transactional handoffs. You end up with teams optimising for their local metrics, not the mission.
Shared context means the whole team understands the landscape well enough to make good decisions without waiting for a meeting. It’s not about more communication — it’s about better information.
A lot of cognitive load in platform engineering comes from siloed knowledge. When understanding of how systems work lives in only a few senior engineers’ heads, everyone else slows down and decisions get bottlenecked. Good collaboration closes that gap.
Shared accountability means teams own outcomes together. When incidents happen, people swarm to fix them instead of assigning blame. Platform teams treat developers as customers. Developers treat the platform as a contract they help shape and improve. Security, QA, and Ops are engaged early — not at the end when it’s too late to make meaningful changes.
In short: collaboration is not a calendar entry. It’s a culture. It’s the operating system of high-performing engineering organisations.
I want to be honest about what makes collaboration hard in engineering teams, because it’s not just people being difficult. There are structural things that get in the way:
Accelerate puts it well: high cognitive load and fragmented ownership kill flow and delivery performance. That’s not just a management problem. It’s an engineering design problem.
High-performing teams create clear “contracts” between the platform and its consumers — APIs, SLAs, support models, and paved paths. This reduces ambiguity and accelerates delivery. When developers know what they can rely on and where the guardrails are, they can move faster with confidence.
Platform engineering teams that treat developers as customers — understanding their needs, iterating on the developer experience, and measuring adoption — see significantly higher uptake and better business results. The principle is simple: make the right thing the easy thing.
Simon Sinek’s “Circle of Safety” is essentially this: people perform their best when they feel protected, not judged. Teams with trust, transparency, and blameless communication deliver better outcomes and innovate faster. Blameless post-incident reviews are a concrete way to build this — they shift the question from “who caused this?” to “what can we learn from this?”
A few principles from Accelerate that I think are worth calling out explicitly:
This isn’t just about individual engineers doing better. Leadership behaviours matter enormously here.
When leaders create a Circle of Safety — protecting their teams rather than exposing them to unnecessary risk or blame — teams thrive. When psychological safety is present, people surface risks early instead of hiding them until they become incidents. When engineers are given real autonomy and their experimentation is supported, you get innovation.
Celebrating learning — not just success — reinforces the right behaviours. An engineer who tried something, failed safely, and learned something valuable is worth more than an engineer who never risks anything. Recognition should reflect that.
When collaboration is genuinely working, you tend to see:
If I had to leave you with one practical takeaway: pick one new collaboration practice and measure its impact.
That could be introducing blameless post-incident reviews. It could be setting up a clearer SLA between your platform team and your developers. It could be cutting a paved path for a workflow that currently requires tribal knowledge. It could be as simple as changing how your team runs a retrospective.
Collaboration transforms capability into impact. It’s how we deliver secure, reliable, user-centred services at scale — not just individually, but as a team.
]]>This is outlined in the official Azure Front Door TLS policy documentation, which explains how Azure Front Door (AFD) manages TLS and cipher suites.
The documentation clearly states that the predefined TLS policy is TLSv1.2_2023 under the Predefined TLS policy section.
As of March 1, 2025, Azure Front Door disallows TLS 1.0 and TLS 1.1 as minimum versions. To comply, our organization updated the minimum TLS version to TLS 1.2.
According to the documentation:
For a minimum TLS version of 1.2, the negotiation will attempt to establish TLS 1.3 first, then fall back to TLS 1.2. The client must support at least one of the supported ciphers to establish an HTTPS connection with Azure Front Door. Azure Front Door chooses a cipher in the listed order from the client-supported ciphers.
In other words, AFD will always try TLS 1.3 first. If the client supports any advertised cipher, the connection succeeds; otherwise, it falls back to the minimum version (TLS 1.2 in our case).
Following recent ITHC assessments, our SecOps team raised concerns about weak ciphers being advertised on endpoints—particularly those handling PCI DSS data. They requested that Platform Engineering address this issue.
Reviewing our Azure Front Door configuration revealed that we could switch from TLSv1.2_2022 to TLSv1.2_2023 (which uses stronger ciphers). However, making this change manually in the Azure Portal was ineffective because our resources were deployed via Terraform. Any manual updates were reverted during subsequent pipeline runs.
As of Nov/Dec 2025, the Terraform provider azurerm_cdn_frontdoor_custom_domain (v4.56.0) does not support configuring the TLS policy cipher suite. Azure defaults to TLSv1.2_2022, which was surprising given the documentation suggested otherwise (see Why TLS 1.2 and not TLS 1.3?).
To meet security requirements and stop advertising weaker ciphers, i implemented a workaround using the AzAPI provider alongside Terraform.
Here’s a simplified extract of the changes to the custom domain resource:
resource "azurerm_cdn_frontdoor_custom_domain" "this" {
...
tls {
certificate_type = "CustomerCertificate"
minimum_tls_version = "TLS12"
cdn_frontdoor_secret_id = azurerm_cdn_frontdoor_secret.certificate[each.key].id : null
}
lifecycle {
# Prevent Terraform from overwriting TLS policy changes applied via AzAPI
ignore_changes = [ tls ]
}
}
The ignore_changes directive ensures Terraform does not revert TLS policy changes applied by AzAPI. Without this, pipeline runs would reset the configuration, similar to what happens when changes are made manually in the portal.
The documentation states:
The AzAPI provider is a thin layer on top of Azure ARM REST APIs. It complements the AzureRM provider by enabling management of Azure resources not yet supported in AzureRM—such as preview features or advanced configurations.
In addition to the changes mage to the azurerm_cdn_frontdoor_custom_domain above, the below azapi code was added.
resource "azapi_update_resource" "this" {
...
type = "Microsoft.Cdn/profiles/customDomains@2025-04-15"
resource_id = azurerm_cdn_frontdoor_custom_domain.this.id
body = jsonencode({
properties = {
tlsSettings = {
minimumTlsVersion = var.minimum_tls_version
cipherSuiteSetType = var.cipher_suite_policy
# certificateType = "ManagedCertificate" (if needed as well)
}
}
})
depends_on = [
azurerm_cdn_frontdoor_custom_domain.this
]
}
By specifying the "Microsoft.Cdn/profiles/customDomains@2025-04-15" API version, we gain access to the full tlsSettings properties, including cipherSuiteSetType. This allows us to configure cipher suites while keeping Terraform pipelines stable i.e. terraform not trying to destroy and recreate existing resources. This allow us to keep existing code as is but gave the capability to now change the cipher suite used.
To make this configurable and reduce errors, i now added validation to the cipher_suite_policy variable:
variable "minimum_tls_version" {
type = string
description = "The default TLS policy to apply to Front Door custom domain."
default = "TLS12" # Could be TLS13 depending on your use case
}
variable "cipher_suite_policy" {
description = <<-EOT
TLS policy preset for Azure Front Door custom domains.
Options:
- null: Use Azure's default policy
- "TLS12_2022": More compatible (includes DHE cipher suites)
- "TLS12_2023": Higher security (may exclude older cipher suites)
EOT
type = string
default = null # Let Azure decide the default
validation {
condition = var.cipher_suite_policy == null ? true : contains(["TLS12_2022", "TLS12_2023"], var.cipher_suite_policy)
error_message = "Must be null, 'TLS12_2022', or 'TLS12_2023'"
}
}
This ensures only valid cipher suite policies are used, reducing misconfigurations.
A great tool for validation is SSL Labs Server Test. Enter your domain name, run a scan, and review the results. It provides detailed TLS information, including advertised cipher suites.
Key Takeaways:
TLS1.3 maybe all you need and above code changes not needed.TLS1.3 may have implications for some clients, if so then above suggestion may work for you.This guide breaks each option down in a clear way to help you decide which one fits your use case.
A JumpBox (also called a jump host or bastion host) is a VM deployed in your virtual network that you first log into before accessing other internal systems. Instead of exposing multiple VMs to the internet, you lock down just this one box and use it as your gateway.
JumpBoxes are perfect for small environments, but long-term you start feeling the pain.
A JumpServer is the enterprise upgrade of a JumpBox. Instead of a single VM, it’s a full access management platform with centralised controls, identity integrations, and security auditing.
Think of it as a Privileged Access Management (PAM) platform built for remote access.
Open source:
Commercial:
If you need strong auditing, compliance, and centralised security, JumpServers are the way to go.
Azure Bastion is a fully managed, cloud-native alternative to running your own jump host. Instead of maintaining a JumpBox or JumpServer, Azure handles the infrastructure for you.
You connect to VMs directly through the Azure portal—even when the VMs have no public IP addresses.
For most Azure-centric environments, Bastion offers a clean and secure experience without the overhead of managing infrastructure.
| Feature | JumpBox | JumpServer | Azure Bastion |
|---|---|---|---|
| Type | Single VM gateway | Access management platform | Fully managed service |
| Best For | Small environments | Large enterprise teams | Cloud-native secure access |
| Setup Complexity | Low | Medium–High | Very low |
| Maintenance | High | Medium–High | None |
| Session Recording | No | Yes | No (see Premium SKU) |
| Public IP Needed | Usually yes | Optional | Optional |
| Cost | Low (initial) | Medium–High | Medium |
If you want to go deeper:
Learn more from Microsoft’s docs: Bastion Overview
I also have a step-by-step walkthrough on deploying Azure Bastion using Terraform here:
Azure Bastion Capabilities.
JumpBoxes, JumpServers, and Azure Bastion all help you securely connect to private systems, but they solve the problem differently:
For most modern Azure deployments, Azure Bastion provides the best balance of simplicity, security, and scalability, especially if you want strong protection without managing additional infrastructure.
]]>WAF Protection:
DDoS Protection:
SSL/TLS:
Front Door operates at Layer 7 only
Missing:
What you CAN’T see/do with Front Door alone:
Potential attack vectors that bypass Front Door:
Regulatory requirements often need:
Simple Web Applications:
Development Environments:
Complementary to Other Security:
┌─────────────────────────────────────────────────────────────┐
│ INTERNET TRAFFIC │
└─────────────────────────────┬───────────────────────────────┘
│
┌─────────────────────────────▼───────────────────────────────┐
Azure Front Door Premium
✅ WAF | ✅ DDoS | ✅ SSL | ✅ Bot Protection
└─────────────────────────────┬───────────────────────────────┘
│
┌─────────────────────────────▼───────────────────────────────┐
Azure Firewall / Other NVA's
✅ Network Inspection | ✅ IDS/IPS | ✅ Threat Intel
└─────────────────────────────┬───────────────────────────────┘
│
┌─────────────────────────────▼───────────────────────────────┐
Private Endpoints / Internal LoadBalancers
✅ Network Isolation | ✅ No Public IPs
└─────────────────────────────┬───────────────────────────────┘
│
┌─────────────────────────────▼───────────────────────────────┐
Backend Application
✅ App Security | ✅ Authentication | ✅ Authorization
└─────────────────────────────────────────────────────────────┘
Financial Services:
Healthcare (HIPAA):
Government (FedRAMP):
E-commerce:
Basic Security (Lower Cost) Azure Front Door Standard: ~$15-50/month
Enhanced Security (Medium Investment) Azure Front Door Premium: ~$200-500/month Azure Firewall Basic: ~$200-400/month
Enterprise Security (Higher Investment) Azure Front Door Premium: ~$200-500/month Azure Firewall Premium: ~$1,000-2,000/month Third-party WAF/NVA: ~$500-1,500/month
Figures will vary, use the Azure pricing calculator to get current values.
For most production applications, I recommend combining Front Door with Azure Firewall
Minimum Production Setup:
Enterprise Security Setup:
Bottom Line:
Front Door provides excellent application-layer security, but defense in depth requires additional network-level controls, especially for sensitive data, compliance requirements, or high-value applications. Taking a multi-layered approach is advisable especially at the enterprise level.
]]>Git is a fast and modern implementation of version control. It provides a history of content changes and facilitates collaborative changes to files.
👉🏽 Git is a version control system that let’s you manage and keep track of your source code history.
👉🏽 GitHub is a cloud-based hosting service that let’s you manage Git repositories. It has additional capabilities around tooling, pipelines, security and a bunch of others useful features.
If you have open-source projects that use Git, then GitHub is designed to help you better manage them.
git init
The name main will be used by default.
git init -b master
If using another branch name, you can replace master with a name of your preference, but main (modern) or master (legacy) will suffice.
For your day-to-day projects or if working in collaboration with others, you will want to store content in a more central location such as GitHub or BitBucket best to create a new repository (repo) and the clone to your local machine.
To do so, from your GitHub account for example, create a new repo, then clone that i.e. make a copy of it on your local machine using the commands below in your terminal of choice.
git clone <REMOTE_URL>
You will notice a new folder in the location you executed the command from.
If you already have a local git repo by initialing git locally, you can point it (connect it) to an existing remote repo.
A remote repo is a repo that exists in another location that uses Git e.g. GitHub or BitBucket.
The below command can help you achieve this.
git remote add origin <REMOTE_URL>
git checkout <REMOTE_URL>
Your local repo will now point to your remove repo, meaning when you push changes the remote repo will get those changes.
Note: Watch out for discrepancies aka merge conflicts if files already exists in either repositories. You may have to take further actions to resolve them
A branch represents an independent line of development, like a silo. When working in collaboration with others, you create a branch, a copy of the project, where you can experiment with your ideas make change and not affect the main body of work.
You may also invite collaborators to review your work on your branch where contributions will be added to it and reviews received.
git branch <branch-name>
Note: You don’t really have a branch until you add or commit a file to the new branch
git checkout -b <new-branch>
git checkout -b <new-branch> <existing-branch>
git fetch –all
Optional, but sometimes useful, especially in large projects. This updates your local repo with any new branches that may have been created by others
git checkout <branch-name>
While on the branch you can change it’s name like so,
git branch -m <new-branch-name>
There are various ways to delete a branch, both a local copy and a remote copy.
git branch -d <branch-name>
git branch -D <branch-name>
git push origin --delete <branch-name>
git push origin :<branch-name>
Note: Deleting it locally does not “delete” the branch, it still exists on the remote server until you push your changes out, thread with caution.
Commits can be thought of as snapshots or milestones along the timeline of a Git project.
Used when you want to capture the state of changes to the project or mark milestones as the work evolves.
Before there is anything to commit, you need to add the any changes or files to git. Essentially what this does is that it notifies git to “keep track” of changes to the file.
git add <file-name>
Add’s a single file by name
git add .
This adds every file change in current directory.
Key word here is current directory. If you have made a repo that has many parent and child folders and you make changes in multiple places then you either have to jump to each folder and run the above command or jump to the parent directory and add all.
When you have changes or have reached a point you want to “mark”, then its a good time to commit your changes after you have added them.
git status
Will show you all changes ready to be committed
git commit –m “your descriptive but brief commit message”
git commit –am “your descriptive but brief commit message”
If file has already been staged, you can skip the add commands and just use the -am flag, this is a short cut to both add the file and add a commit message as above.
There sometime is the need to amend a most recent commit e.g. You had committed your changes but added a new change that you want to reflect as part of the previous commit set. To do so you can:
git commit --amend
To add the new change to the last commit
git commit --amend -m "an updated commit message”
To both add the new change and also update the commit message. For example you notice a typo, happens to the best of us. 🙃
git add <the-file>
git commit --amend --no-edit
🔥 Don’t amend public commits, avoid amending a commit that other developers have based their work on, do so only on your local branch/commits.
When happy with your changes, you can make it public or visible to other collaborators by placing it in the central location with the below commands.
git push
There are time when you need to lump things together, combining changes from more than one branch.
Git merge is used to combine changes from two or more branches into a single branch.
Git rebase is used to incorporate changes from one branch into another by rewriting the commit history.
These feature can be very helpful in keeping things organised or help you separate/chunk your work in more that one branch then bring them all together in one branch.
git checkout <branch name>
git merge main
git merge <branch name> main
Options include --squash, --abort, --quit, -s [our] etc.
git checkout <branchname>
git rebase main
The golden rule of git rebase is to never use it on public branches
You can look at a merge as combining two repos together, sorting out the difference between them and a rebase as adding one repo right on top of the other.
Git has a nice documentation called Git Branching - Rebasing that breaks it down in detail. Check it out if you need more clarity.
This is another feature that allows you group multiple commits into one. If you have multiple small changes committed and want to push them out together then squash them.
git log --oneline
git rebase -i HEAD~N
git merge --squash <branch name> (then commit)
ℹ️ Very useful for tidying up local commits before a milestone push.
🔥 Note: Try to avoid squashing too many changes into one push that it become one large commit when its review time. Everything in moderation.
git revert --<hard|soft|mixed> <commit-id>
Git pull is used to fetch and download content from a remote repository, updating the local repository to match that content.
Git aliases can shorten common commands and make it easy for you to remember, just try not to go overboard.
git pull <remote>
git pull --rebase <remote>
Used to ensure a linear history by preventing unnecessary merge commits.
You can look into your git repo or history to search for information about past commits, branches etc.
git grep <text>
This will look through files
git log <options>
This will show your commits
git config --global alias.<name> ‘<git subcommand options>’
git config –e
To open your default editor
git config --list
To show your git configuration and all the crazy aliases you have set, and the one you had forgotten about 🙃.
Git is really powerful and has lots of features, it can sometimes feel overwhelming but practicing one feature at a time is the way to go, you can try out most commands locally.
Any of the below commands in your terminal will provide you with lots of git related information. Comes in handy when you quickly want to verify a command or look up a concept.
git –help
git help -a
git help -g
These will show you lots of other options you can have a play with.
Some great places to look to for deeper learning
FYI don’t get budged down with too much git detail, majority of the time the common commands will be more than enough for your daily work, having good knowledge of git, or what it can do, comes in handy when those edge cases crop up, usually when working with large teams or on a very active repo with many developers pushing changes near simultaneously.
These days however, most of our IDE’s come baked with lots of git capabilities via plugins and extensions. You just need to install one if not already and you’re good-to-go.
]]>PRs can also serve as a learning tool or a means of documentation. As not everyone in working on the same Initiative or deliverables at the same time, the opportunity to review another team members code give you the opportunity to be in the know of whats happening on the project.
Below are some ideas to explore in your professional journey when working with a group of engineers or collaborating with some one on a body of work. These ideas are based on my experiences on various projects, past and present, and i hope you would find some of these ideas helpful on your projects.
Short pull requests (or PRs) are much simpler to review than long PRs. Try to break up large features or changes into multiple smaller PRs, more bugs and issues slip through on longer PRs due to reviewer fatigue. Also bigger PR longer time to be reviewed. Best to get small changes out than one giant change.
Following specific guidelines will allow your reviewers to focus on the substance of your change rather than superficial issues - haggling over whitespaces, funky indentations, style or format of function names is not a great use of anyone’s time.
Think about your variables, function or resource names, signatures, modules, etc. Make sure they accurately describe their contents and purpose. Using good naming convention can make your code substantially easier for your reviewers to understand. Whether it’s IaC in Terraform or a feature in Java or NodeJS. Principles remain the same.
In those cases when it’s not possible to write self-documenting code, it is sometimes complicated or hard to follow just by reading it, a few short comments describing how the code works and why it is the way it is can help, even if its eventually removed after reviews and before your merge.
Caution though not to over load your code with comments, this is where README files in your project can come in handy, especially if you introduced significant change to the project or functionality.
Be specific, describe both the reason for the change and the way this change achieves a goal. Be clear, but not overly verbose. A clear description helps your reviewers gain context on what you’re looking to achieve.
Provide pointers as comments for sections of the code that could use particular attention from the reviewer. Dropping comments on your own PRs can allow you to provide justification for changes in-line. This is helpful when you have thoughts that you need to share but that wouldn’t be useful as a persisting code comment, describing the reasoning behind an approach can sometimes make more sense as a comment than as a comment in the source code. Super useful as well if you’d like other opinions on a particular implementation.
Sometimes, asking for reviews from people with the right context, experience or knowledge of the project can be helpful.
General rule of thumbs is that any member of the team should be able to review, but honestly i’ve been in situations where i had to pull in specific team members on an issue due to experience in that topic or feature. Value every review though.
You can save your reviewers’ time and yourself from frustration by marking your PRs as a Draft while you are still working on it and only tagging people or requesting a review when your code is ready for a look.
This saves a team member having to “down tools” to review your work and also “comments” about things you know you are going to implement anyways but not gotten to it yet.
Always nice to start out in Draft mode then when ready for first review switch to Ready for Review.
It can be helpful to write your reviewers a little note as a comment on the PR pointing out areas of uncertainty you have, requesting specific types of suggestions, or waving them off of something if you have broken a standard pattern for a valid reason.
Leverage comment on your PR at to draw attention to point for feedback.
Once you request a change i.e. Block a PR from merge, “You own it”, reach out if no updates after a while or help the engineer with pointers especially if they are struggling. The time taken to update the PR, especially if not a very complex issue/resolution is requested, can be an indication that the engineer is struggling in implementing the requested change.
I have experienced a situation where a team member requested a change, essentially blocking my PR but then went on leave without getting back to review changes before heading out.
Don’t merge until reviewers’ comments are clarified, where possible. If a colleague has made the effort to review and has asked some clarifying questions, just because you have the “required” number of approvals does not mean you totally ignore their question(s).
Do your best, and as a matter of courtesy, to either respond to the comment or reach out via Slack or whatever internal messaging channel is in use to chat about it.
Engineers are sometimes in a hurry or maybe feel the change is a very small change and they can’t be bothered. This is not a good practice. At least add the link to the Jira ticket, if no ticket, there usually is one, then mention the incident or change request number or any other available tracking detail. If none of the above exist then state clearly the reason for the PR, there has to be one.
There are no “useless” descriptions either, your future self and other engineers, current and future will appreciate the effort.
Making it possible to find or reference changes when looking through your git history can be very helpful. Some ideas when creating your branch include:
<jira number>-<branch name><issue number>-<branch name><incident number>-<branch name><change request number>-<branch name>A colleague of mine uses fix: to indicate a fix or feat: to indicate a feature to help him differentiate what type of change when in.
If your organisation is not fussy about this or there isn’t a standard your team follows then i propose one of the above ideas.
It’s always best to avoid “floating” PR that make no sense 3 months later.
If you are in a position where you can or are allowed to close Jira tickets, it’s good to be proactive, add a small comment when closing a ticket item.
Your Agile lead or Project manager will thank you for it. Useful details/information in your Jira ticket or GitHub project Issues before closing them can go a long in providing context to the wider team, external or interested parties who usually are nontechie’s folks.
Because some other team member has approved a PR does not mean you should not complete your review especially if it’s a familiar code base or project.
I have noticed on projects i’ve worked on where some other engineer abandons his/her review just because more “senior” or “experienced” engineers have give it a thumbs up.
From experience they sometimes are wrong and sometimes miss details, usually because they usually are always “multitasking”, so many other “issues” needing their attention because of their experience.
If not for anything, try understand why that “senior” or “more experienced” engineer thought the PR is good-to-go. You can gain experience for next time on similar PRs, also you may just notice they have missed a point and your attention to detail prevented a bug making it’s way to production, especially if working on a full CI/CD project.
Sometimes waiting for a PR review can be nerve racking. If on a busy project or availability is limited due to holidays or absence, you’ll need to be patience and considerate when “pinging” others to to get some “eye’s on it”.
Some ideas i have used in the past, while i wait, is to “where” a different “hat” and look at my PR again as a “reviewer” or i ask myself “what can i improve on?”. I sometime find more things to do to improve what i thought was “ready for review”.
After all, you asked for it (joke), keep an open mind. Some colleagues don’t have filters and come at you quite bluntly, no “sugar coating”. Keep the end goal in mind, at least consider their point, sometimes they are actually right and sometimes not, always best to consider other ideas or thoughts, your end result will be much better and by thinking through it with other ideas in mind you may just learn something new as well.
]]>