| |
|
|
May 8 · Issue #143 · View online
Level Up delivers a curated newsletter for leaders in tech. A project by https://patkua.com. Ideal for busy people such as Tech Leads, Engineering Managers, VPs of Engineering, CTOs and more.
|
|
|
The Perplexing Platform Team I’ve been thinking a lot about platform teams this week. When I work with a CTO at new companies, at some point, the topic of a “platform team” comes up. Unfortunately, I have found there are so many different ways this work is used I have to ask questions to understand “what sort” of platform team they are talking about. I want to share some of the common types I discover, even if I don’t agree they should be called a “platform team”
-
The “CD automation” platform team - This variant focuses on automating CI tasks and building the CD pipelines for different teams to bring software into production.
-
The “Cloud infrastructure” platform team - This variant provisions cloud infrastructure through the use of tools like infrastructure as code for various environments. Because they set up environments, they are also masters of environment configuration.
-
The “Operations” platform team - This variant connects product development teams with the tooling found in production such as logging, monitoring, alerting, dashboards and reporting.
-
The “SRE” platform team - This platform team goes beyond the normal duties and is also responsible for driving resiliency improvements from incidents and outages.
-
The “DevOps” platform team - Sometimes a team that “sits in between” development and operations team that focuses on automation.
-
The “Product Core Components” platform team - A team that provides common elements for other product team such as notifications, bootstrapping web services/applications and other code related elements.
Note: Some additional variations blend different aspects above. I’ve also noticed that each type of platform team work in a number of ways:
-
They do the work - In this mode, other teams raise work requests or tickets, and the platform team does the work requested of them.
-
They enable - In this configuration, the platform team are often a functional team where each member is distributed into product teams and they do the work for teams but try to teach them so that the product teams have the knowledge to continue using the platform when they leave.
-
They provide self-service - In many organisations there are significantly more product teams than platform team (i.e. 10+) which means the platform team becomes overwhelmed with work. Instead of doing the work, or showing teams how to do the work, the platform team focuses on automating the common requests which ultimately leads to a self-service platform
What other platform team variants have you seen? Drop me an email and let me know. |
|
What sort of platform team are you talking about?
|
|
|
Is your team struggling with Git? Meet Tower! Our powerful client helps your whole team - from beginners to experts - reach a higher level of knowledge and confidence with Git.
|
|
|
|
People are way more interesting than computers: making the leap to an Engineering Team Manager (and battling imposter syndrome along the way)
Reading time: 6mins Engineering Manager at Skyscanner, Mhairi McClair, shares their personal experience transitioning to the Engineering Manager role by covering some of the things they felt and three pieces of advice if you’re also considering this leap.
|
Resources for Engineering Directors
Reading time: 5mins
Will Larson (@lethain) offers a quick response to a question about pointing people to specific resources for Engineering Directors. He covers a couple of books that touch upon elements of this but also tries to fill in several missing pieces.
|
Career Choices and Business Models
Reading time: 7mins I realise I’m lucky, having studied business at university and worked in consulting, so I have seen a wide variety of businesses and how they run. I’m including this article from Subbu Allamaraju (@sallamar) this week because I think more technical leaders could do with reflecting on the business side a lot more. |
Level up your technical leadership skills with this online 1/2 day workshop
|
|
|
Best practices to keep your projects secure on GitHub
Reading time: 5mins Director of Product Management for supply chain security, Justin Hutchings (@jhutchings0) covers two simple steps to improving the security if you use GitHub. |
Apple, Google, and Microsoft want to kill the password with “Passkey” standard
Reading time: 4mins This is a fascinating development involving the collaboration of tech giants trying to build an alternative to the password with their Passkey standard. Only time will tell if this news reported by Ron Amadeo (@RonAmadeo) will take off or not. |
Celebrating Firefox: How we got to 100
Reading time: 7mins If you care about privacy and the open web, then I encourage you to download Firefox. It’s my default web browser and I remember when it launched as a way to create a more open standard web when Internet Explorer 6 (IE6) was the dominant web browser. This is a short look at its features and a quick look back 🥳! |
Learn how systems thinking apply to software teams with this self-paced course
|
|
|
Agreeably Disagreeing aka How to Handle Conflicts
Reading time: 5mins A collection of conflict resolution tips from personal experience in customer service.
|
How Canonical Systematically Improves Developer Documentation
|
Airbnb announces it won’t dock employees’ pay if they go remote
Reading time: 4mins
Mitchell Clark (@strawberrywell) reports that as part of Airbnb’s announcement to support remote work, they’re not going to change compensation levels depending on location. This will be interesting to see how the rest of the industry responds.
|
|
|
So true and releveant to my intro article!
|
|
|
We tried to build a platform team. I can say that it is easier said than done. The paved road by necessity declares a lot of current practices off road. I agree with this thread, it has to be bottom up but it also needs to have people at the top being willing to make tough calls. https://t.co/owZ3MsOIAg
|
|
|
|
A lot of software engineering means learning. Learning requires mistakes, which means rabbit holes.
|
|
|
|
In software engineering, rabbit holes are inevitable.
You'll research libraries, and not use them. You'll write code, just to delete it.
This isn't a waste — sometimes you need to go down a few wrong paths, to get to the right one.
|
|
|
|
|
|
If you enjoyed this newsletter, send me feedback and share it with others! |
|
Did you enjoy this issue?
|
|
|
|
In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
|
|
|
|
Patrick Kua, Postfach 58 04 40, 10314, Berlin, Germany
|
