Artwork

Sisällön tarjoaa Treasa Anderson. Treasa Anderson tai sen podcast-alustan kumppani lataa ja toimittaa kaiken podcast-sisällön, mukaan lukien jaksot, grafiikat ja podcast-kuvaukset. Jos uskot jonkun käyttävän tekijänoikeudella suojattua teostasi ilman lupaasi, voit seurata tässä https://fi.player.fm/legal kuvattua prosessia.
Player FM - Podcast-sovellus
Siirry offline-tilaan Player FM avulla!

Serverless Craic Ep37 What is Engineering Excellence?

20:54
 
Jaa
 

Arkistoidut sarjat ("Toimeton syöte" status)

When? This feed was archived on January 21, 2024 18:06 (2M ago). Last successful fetch was on December 01, 2023 13:11 (4M ago)

Why? Toimeton syöte status. Palvelimemme eivät voineet hakea voimassa olevaa podcast-syötettä tietyltä ajanjaksolta.

What now? You might be able to find a more up-to-date version using the search function. This series will no longer be checked for updates. If you believe this to be in error, please check if the publisher's feed link below is valid and contact support to request the feed be restored or if you have any other concerns about this.

Manage episode 346831027 series 3310832
Sisällön tarjoaa Treasa Anderson. Treasa Anderson tai sen podcast-alustan kumppani lataa ja toimittaa kaiken podcast-sisällön, mukaan lukien jaksot, grafiikat ja podcast-kuvaukset. Jos uskot jonkun käyttävän tekijänoikeudella suojattua teostasi ilman lupaasi, voit seurata tässä https://fi.player.fm/legal kuvattua prosessia.

What is Engineering Excellence?

We are chatting about two things that I think are quite interesting: engineering excellence and well architected. They are two phrases we kick about a lot. And they're heavily featured in the book, The Value Flywheel Effect coming out soon.

Few companies will say they don't want good engineering. And we are happy with bad engineering. But they don't define what good looks like. And then the second thing is that 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! There's a body of evidence, supporting material, videos, tutorials, workshops and labs to support well architected. People can google well architected, whether they're talking about AWS, Azure or Google. And they're going to get a fairly consistent response. They self serve and self learn.

I remember years ago, when you talked to architects, they said that good architecture is a non functional requirement. It's performability, scalability, extendibility and every stupid word ending in 'ility'. Now the fact is that it is well documented, understood and you can rhyme them off as SCORPS makes it easier. 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. I

f 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. You're investing in performance, security, resilience, high availability, every day and every week. And those things compound on each other. It's like compound interest!

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 book
Follow us on Twitter @ServerlessEdge

  continue reading

51 jaksoa

Artwork
iconJaa
 

Arkistoidut sarjat ("Toimeton syöte" status)

When? This feed was archived on January 21, 2024 18:06 (2M ago). Last successful fetch was on December 01, 2023 13:11 (4M ago)

Why? Toimeton syöte status. Palvelimemme eivät voineet hakea voimassa olevaa podcast-syötettä tietyltä ajanjaksolta.

What now? You might be able to find a more up-to-date version using the search function. This series will no longer be checked for updates. If you believe this to be in error, please check if the publisher's feed link below is valid and contact support to request the feed be restored or if you have any other concerns about this.

Manage episode 346831027 series 3310832
Sisällön tarjoaa Treasa Anderson. Treasa Anderson tai sen podcast-alustan kumppani lataa ja toimittaa kaiken podcast-sisällön, mukaan lukien jaksot, grafiikat ja podcast-kuvaukset. Jos uskot jonkun käyttävän tekijänoikeudella suojattua teostasi ilman lupaasi, voit seurata tässä https://fi.player.fm/legal kuvattua prosessia.

What is Engineering Excellence?

We are chatting about two things that I think are quite interesting: engineering excellence and well architected. They are two phrases we kick about a lot. And they're heavily featured in the book, The Value Flywheel Effect coming out soon.

Few companies will say they don't want good engineering. And we are happy with bad engineering. But they don't define what good looks like. And then the second thing is that 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! There's a body of evidence, supporting material, videos, tutorials, workshops and labs to support well architected. People can google well architected, whether they're talking about AWS, Azure or Google. And they're going to get a fairly consistent response. They self serve and self learn.

I remember years ago, when you talked to architects, they said that good architecture is a non functional requirement. It's performability, scalability, extendibility and every stupid word ending in 'ility'. Now the fact is that it is well documented, understood and you can rhyme them off as SCORPS makes it easier. 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. I

f 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. You're investing in performance, security, resilience, high availability, every day and every week. And those things compound on each other. It's like compound interest!

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 book
Follow us on Twitter @ServerlessEdge

  continue reading

51 jaksoa

Kaikki jaksot

×
 
Loading …

Tervetuloa Player FM:n!

Player FM skannaa verkkoa löytääkseen korkealaatuisia podcasteja, joista voit nauttia juuri nyt. Se on paras podcast-sovellus ja toimii Androidilla, iPhonela, ja verkossa. Rekisteröidy sykronoidaksesi tilaukset laitteiden välillä.

 

Pikakäyttöopas