Artwork

Conteúdo fornecido por Serverless Craic from the Serverless Edge. Todo o conteúdo do podcast, incluindo episódios, gráficos e descrições de podcast, é carregado e fornecido diretamente por Serverless Craic from the Serverless Edge ou por seu parceiro de plataforma de podcast. Se você acredita que alguém está usando seu trabalho protegido por direitos autorais sem sua permissão, siga o processo descrito aqui https://pt.player.fm/legal.
Player FM - Aplicativo de podcast
Fique off-line com o app Player FM !

Serverless Craic Ep37 What is Engineering Excellence?

21:00
 
Compartilhar
 

Manage episode 346826829 series 3304957
Conteúdo fornecido por Serverless Craic from the Serverless Edge. Todo o conteúdo do podcast, incluindo episódios, gráficos e descrições de podcast, é carregado e fornecido diretamente por Serverless Craic from the Serverless Edge ou por seu parceiro de plataforma de podcast. Se você acredita que alguém está usando seu trabalho protegido por direitos autorais sem sua permissão, siga o processo descrito aqui https://pt.player.fm/legal.

What is Engineering Excellence?
Few companies say they don't want good engineering. But they don't define what good looks like. And secondly,engineers are expected to write lots of code. For me, engineering excellence is not writing loads of code. It's about getting into code reliability, feedback loops and how well engineering is functioning. And how your team is performing and meeting bigger goals.
I love to say 'slow is smooth and smooth is fast'. So how do we set ourselves up for that? At the beginning, I like to go slowly to look at our process.
To define engineering excellence, we use Dan Pink's motivation factors of autonomy, mastery, and purpose. We translate those motivation factors to technical excellence, autonomy, and customer focus.
Well architected is better defined than engineering excellence. But I find that a lot of people haven't heard the term well architected and they think you've just made it up!
If you want to move fast, you've got to be empowered and know what good architecture looks like. When you have guidance or patterns that are implemented in a well architected fashion, that sets you up for rapid delivery, moving with speed, and in an engineering excellence way. It's fast flow aimed to facilitate you moving fast, getting things out quicker and being more competitive.
Teams are rapidly delivering product value multiple times a day. And they have a trail of evidence that they're going the right way because of these practices. They have dashboards, logs, alarms, alerts and the run books and the playbooks. And the key business indicators (KPIs) at their fingertips. So any stakeholder can challenge them on what they are doing, how they are operating or what they are deploying.
If you arrive in an area that isn't well architected, you've got to spend three months trying to understand what went on before or trying to understand the decision making. Or you've got 12 months of technical debt that should have been taken on board before you moved there. That very difficult from a personal perspective.
There's a whole bunch of advantages. One is a problem prevention culture. But I don't think it exists in a lot of organisations. It hasn't really cut through. They're still on the feature, factory, server mindset. Deliver, deliver deliver. Feature, feature feature. And then they have a tipping point where everything grinds to a halt for months or maybe years. And it may never recover.
But if you have a continuous improvement mindset and you are investing in fraud prevention, well architected, engineering excellence and continuous learning. And you are enabling and applying this to your teams, you get ahead of problems before they become problems.
From a problem prevention perspective, do you want to spend all your time babysitting a non well architected workload and dealing with all of that? You want your teams moving, adding value and moving on to the next thing. That's not possible if your build lacks quality, is always down or if you're having to constantly upgrade.
With well architected and engineering excellence, we can build things that run and increase in value. And there's less work over the long term, while your teams move on to what the business needs. I don't think a lot of orgs think in that way. By the time they do get thinking that way, they're already experiencing a lot of problems

Serverless Craic from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube

  continue reading

55 episódios

Artwork
iconCompartilhar
 
Manage episode 346826829 series 3304957
Conteúdo fornecido por Serverless Craic from the Serverless Edge. Todo o conteúdo do podcast, incluindo episódios, gráficos e descrições de podcast, é carregado e fornecido diretamente por Serverless Craic from the Serverless Edge ou por seu parceiro de plataforma de podcast. Se você acredita que alguém está usando seu trabalho protegido por direitos autorais sem sua permissão, siga o processo descrito aqui https://pt.player.fm/legal.

What is Engineering Excellence?
Few companies say they don't want good engineering. But they don't define what good looks like. And secondly,engineers are expected to write lots of code. For me, engineering excellence is not writing loads of code. It's about getting into code reliability, feedback loops and how well engineering is functioning. And how your team is performing and meeting bigger goals.
I love to say 'slow is smooth and smooth is fast'. So how do we set ourselves up for that? At the beginning, I like to go slowly to look at our process.
To define engineering excellence, we use Dan Pink's motivation factors of autonomy, mastery, and purpose. We translate those motivation factors to technical excellence, autonomy, and customer focus.
Well architected is better defined than engineering excellence. But I find that a lot of people haven't heard the term well architected and they think you've just made it up!
If you want to move fast, you've got to be empowered and know what good architecture looks like. When you have guidance or patterns that are implemented in a well architected fashion, that sets you up for rapid delivery, moving with speed, and in an engineering excellence way. It's fast flow aimed to facilitate you moving fast, getting things out quicker and being more competitive.
Teams are rapidly delivering product value multiple times a day. And they have a trail of evidence that they're going the right way because of these practices. They have dashboards, logs, alarms, alerts and the run books and the playbooks. And the key business indicators (KPIs) at their fingertips. So any stakeholder can challenge them on what they are doing, how they are operating or what they are deploying.
If you arrive in an area that isn't well architected, you've got to spend three months trying to understand what went on before or trying to understand the decision making. Or you've got 12 months of technical debt that should have been taken on board before you moved there. That very difficult from a personal perspective.
There's a whole bunch of advantages. One is a problem prevention culture. But I don't think it exists in a lot of organisations. It hasn't really cut through. They're still on the feature, factory, server mindset. Deliver, deliver deliver. Feature, feature feature. And then they have a tipping point where everything grinds to a halt for months or maybe years. And it may never recover.
But if you have a continuous improvement mindset and you are investing in fraud prevention, well architected, engineering excellence and continuous learning. And you are enabling and applying this to your teams, you get ahead of problems before they become problems.
From a problem prevention perspective, do you want to spend all your time babysitting a non well architected workload and dealing with all of that? You want your teams moving, adding value and moving on to the next thing. That's not possible if your build lacks quality, is always down or if you're having to constantly upgrade.
With well architected and engineering excellence, we can build things that run and increase in value. And there's less work over the long term, while your teams move on to what the business needs. I don't think a lot of orgs think in that way. By the time they do get thinking that way, they're already experiencing a lot of problems

Serverless Craic from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube

  continue reading

55 episódios

Todos os episódios

×
 
Loading …

Bem vindo ao Player FM!

O Player FM procura na web por podcasts de alta qualidade para você curtir agora mesmo. É o melhor app de podcast e funciona no Android, iPhone e web. Inscreva-se para sincronizar as assinaturas entre os dispositivos.

 

Guia rápido de referências