Hey friends, I'm Scott Hansman and this week I want to learn how to not ship the Org Chart. What are you learning today, Mark? Learning with you, how not to ship the Org Chart. Mark, I went and I wanted to buy a new electric vehicle and I went and did a bunch of test drives. So I'm test driving every EV on the market. And I went and I sat in an unnamed electric vehicle and the lady was, they didn't name it. Yeah, I don't want to name it because I want to like help them email me and be mad.
I sit in this thing and she's like, okay, well here's the shifter and here's how you do it and whatnot. And I like, I kind of froze up and I said, I don't think I would be able to tolerate this car. And it was a weird thing to say and I felt a little bit like that was awkward and she says, why? And I said, well, I'm looking at the map and then I turn and then I'm looking at the climate thing and then I'm looking at the speedometer.
And I can see the oh, like at like the letter, the number O on the map is part of something and the an O as part of the temperature and an O as part of the this and they're all different fonts and then I realized it was three Android tablets chain together and I could suddenly see the organizational chart of this large international auto company and I realized that some group ship the map thing and some group ship the climate thing and some group ship the
thing and then they stuck a bunch of Android devices behind a screen and they called it the panoramic whatever screen I was like, they didn't even talk to each other and then I get overwhelmed me because the knobs the buttons they're all from different groups they shipped the organizational chart of the company in a car that they want me to spend $40,000 on so I didn't I didn't complete the test drive. Am I a bad person?
Well, isn't that a separate question? Yeah, it's a separate question, but like have you ever had that feeling? Yeah, yeah, I've had that feeling and it's actually shipping the orchard is the phrase that's used at Microsoft. Yeah, a lot. Yeah, because we want to avoid shipping the orchard, but unfortunately sometimes we do.
Yeah, I think all tech companies do that sometimes though is the answer to have some Steve Jobs type Bill Gates at the top of the thing and then they just I alone watch all things because that isn't really a good model.
No, that's one way to do it, but I think a more scalable friendly way to do it is to come up with standards like the UX gestures, you know, and the UX language that is one place that you can just say here are the standards when you write a designer UX for your feature component, here's your font, here's your spacing, here's the way the buttons are going to work. And then everybody can go read it and make sure they're adhered to it and then it looks consistent.
Yeah, some kind of a like this we believe we can all get together and write a constitution, maybe amended 26 times and then everything will be great and I'll give you a great concrete example of what we've done in Azure for that because when we started as a resource manager or as a resource manager is the control plane for Azure and it's decentralized control plane it provides this entry point into Azure services, but the services implement resource providers that plug into arm.
And what we found was that early on that we needed to define standards for the API's that these resource providers surfaced, so that they were consistent with arm and with each other and so when you wanted to go, for example, query a resource for a list of child objects that query operation was the same across all of our resources and not different for one versus another.
And so we came up with API guidelines standards is published on GitHub and we've got an API review board that and we've got tooling to try to ensure consistency. You know, guidelines are good, but tooling is even better that just pushes you to do the right thing, but this is a place where we're not perfect and there's inconsistencies and if you actually look at the older API surfaces of Azure, you'll find even more consistency, but we continue to make it better.
I like the board idea. I was like having like I had suggested maybe we have like a CTO or something a boss like a single person, but then that becomes a bottleneck. Yeah, but it board can be a bottleneck as well, like I was playing around with Copilot in Visual Studio recently and looking at unused and commonly not used features.
And I noticed that well in one instance, it's a icon of a bot and in another instance, it's a pencil with sparkles and another one, it's a magic wand and I was like, wow, the Copilot people haven't yet figured out what the metaphor is and there should be like an icon board boards like this are helpful because they can make things look consistent, but they would also slow down innovation and they're really innovating at a very fast rate.
Well, it depends on how impactful an insincensiscency might be in the case of an icon, it's like, okay, so user might get confused or look at it and go, this is inconsistent and it might hurt their impression of the polish of the product, which is a different level of impact than an API or multiple API that are different that forced developers to go, wait a minute.
I've learned this way to do it over here and now I've got to learn this completely other way to do it over here and that causes them friction and time tedium and potentially even leads them to make mistakes and it's something that can't just be fixed because of backward compatibility it's going to be there forever. And so 10 years down the road somebody coming across the same APIs goes like this and that versus an icon which okay next rabble just make it consistent fix it so.
It depends on how important the inconsistency is. So now you're making me feel like I shouldn't have left my test drive because I thought it was important like I'm going to sit in this you're going to have a software upgrade in a month and then I don't want to fix it.
Seriously, can we all just agree on a font here like I didn't think it was that unreasonable. I just found it very off putting yeah that I was looking at three Android tablets strong together but I understood but this is the thing I have empathy because I can imagine the teams making the decisions to string this stuff together I just it was very frank and build yeah and maybe wonder what the like those are just the visual systems here's another thing that's just the part that they put on the front and put a screen on what internal systems are shipping the org chart that I can't.
It makes you sort of question that because if it had been consistent on the top you'd assume it's consistent throughout and basically they lost a sale because of that you could say that was impactful and they should go prioritize fixing it.
But it's important like that the experience somebody has the visible experience somebody has because they you just infer the rest from that yeah that's right I did infer that like if this is the skin of the onion what else is going on inside this thing is it rotten all the way you know I had it been all consistent.
You're like let's make sure this is consistent but everything else is completely inconsistent you wouldn't have known well that's really interesting so like let's invert that and let's think about another unnamed electric car that is well known for being very consistent from a UI perspective that's very polished it's the iPhone of cars but there's been talk that the internals may not be as shiny so that is the inverted problem whether design is gorgeous but maybe the guts are less awesome.
Yeah the importance of that depends of course on how much the internal inconsistencies are going to cause problems. Yeah for example if you talk about a cloud platform like Azure internal inconsistencies actually cause problems because that leads to mistakes that leads to a time to go troubleshoot something in the case of a life site incident for example I've got to do it this way over here and another
way over here it causes extra engineering costs too because if you want to apply some improvement to something now you've got to make three versions of the improvement because every place you want to apply it is slightly different versus if I can just
give it one place one way and apply it to everything then I've saved a lot of time and energy and I've actually made sure the improvement is reliable in once without having to do it three times where every time I do it I could be making mistakes so consistency inside
of a platform is extremely important but like you said you know moving it quickly for innovation that's the way Azure started we had to move very quickly and then you know you don't have enough time to like what is what you know what is the design paradigm for the
icon equivalent of the icon inside of our API surfaces in the platform we don't have time to slow down and and decide because we don't even know really yet we're innovating and then you start to realize oh wait a minute this way of doing it is better than these other ways let's all standardize.
So you think about the kind of like the layers of abstraction that sit on top of things in order to kind of clean up like you've got arm the Azure resource manager you've got bicep which is kind of like the type script of the JavaScript of arm using that analogy like
it's a little bit of layer that makes it better and then the you know the UI the UX the portal that's calling all of those things and using all of those things is in some cases lying to you in a good way to make this experience seem consistent
while also maintaining backwards compatibility going back many many years which is something I think microsoft doesn't get a lot of credit for that should get credit for yeah I mean that that's been a principle of Azure and you know windows has had this too you
could still your run doom on your windows 11 machine example I gave was that you can still run well you count 64 bit for a very long time on 32 bit you could run visit calc you could run down british is a cow from 1976 yeah I just got a dos box set of uh dos games called exo dos yeah which is like all of the eighties and it works great on windows it runs on arm windows that's incredible it's just amazing and that's the the back of the compatibility promise which is
extremely important in the enterprise not so important in the consumer space but extremely important enterprise because enterprises develop apps every time you break an app that costs the enterprise time money and maybe even prevents them from going to a newer version of this system which is going to give them a lot of benefits for security reliability features so backward compatibility is absolutely essential we have actually part of that
API review board we talked about it approves breaking changes and I'm the actually the arbiter for breaking change approvals and our standards around that as well as deprecation of services because removing a service is also a breaking change that we take very seriously so we've got published policies around SDK deprecations service deprecations announcements channels that are formal around how we tell people it's
coming and process that ensures that we're not doing it capriciously and only for good reason and that there's good path forward and so that's just part of an enterprise promise.
This is a good time to remind folks that have made it this far into the show that this is this is our opinions and while we may work for Microsoft we didn't work for Microsoft a very long time before this and after this we may not work for Microsoft so what I'm about to say is my opinion I'm a fan of windows I enjoy windows I have an iPhone I'm non-denominational I have an iPad so I kind of move calmly and smoothly through
things but oftentimes I admire how consistent and self consistent iPhones and Macs are in their look and feel and I am frustrated where windows things are like why does this look like this why does this behave like this but then I dig into it like how the window compositor works in windows and the different UI frameworks and stuff and I'm like why can't we do this and I realize that a lot of the things that Apple has done to make things
look so quote unquote pretty and some of the things that windows gets dinged for are well windows chooses to have backwards compatibility and in the process possibly ship the org chart well Apple with a smaller market share on the desktop and a very large wall garden on the on the mobile side
choose to unapologize like the break stuff and abandon entire heart like dope this one and the first time that we did that was the windows 11 security stuff where people are still mad that their processors in some instances well they're older Intel processors are being left behind it's
interesting to see how often Apple can do that and people are like celebrate the change but if Microsoft makes your 15 year old laptop no longer work on the latest operating system they're like you suck you know but there's there's a reason for it in the org chart and the values that they have as an
organization where backwards compatibility are kind of like at the forefront of that and I think it's consumer versus enterprise is a big priority yeah that's a good point you have like SLA service level agreements on how things are going to work and there's well shoot dude I was running my
blog on windows server 2002 or 2000 and you know like an early very when a server for like 20 years 2003 2003 yeah when a server 2003 and done it to and I stopped running it only because I couldn't get TLS 1.3 to work on a 20 20 year old operating system and that's why I finally moved but the
cool part was I was able to move to containers and Linux and Azure so you were incredibly insecure you were running on a unsupported version of the operating system that is no longer getting security fixes so you're lucky your website wasn't just owned well nobody nobody visits my website you know
yeah I was impressed though that the compatibility lasted as long as it did like we should get credit for that I think yeah when you're trying to avoid shipping the org chart but you're also at the top of the org chart is it frustrating like are do you just have to like make compromises
and say well this is just the way it's got to be we're going to have to let that abstraction leak as you say that you're the arbiter of some of these decisions at that board level well I mean what we do is try to identify places where we need to prevent leaks and fix them I mean it's frustrating for me to see the leaks to see the inconsistencies but again like you know I only have so much time and energy to go of catching these things and we only have so much energy to go and fix
these we have to prioritize where the most important places we need to be consistent and prioritize those and even in those areas like API reviews like what are the most important aspects of an API surface that must be consistent and then that's where you we invest time and energy and reviewing
and also coming up with tooling that helps ensure that those things are just consistent from the start and not something so we actually have a we've got something called tight spec yeah yeah which is a language we've created for defining APIs and using type spec which in supports inheritance we can define standards at a top level that get inherited by the API developers creating new resource providers so that they're automatically compliant with our type or API guidelines.
That's a great way to not ship the org chart is to give something teeth I used to use the term word documents don't break the build so someone goes and writes a word doc and someone publishes an API that's
break something and nothing about the word document broke the build set off a claxon called anybody no one got paged but with something like type spec when you can go and describe the shape of something and then project it across rest GraphQL GRPC whatever you could put constraints on the shipping to prevent something from leaking out that would show the org chart or break something that we believe as a group so you're giving teeth to the spec by making it formal.
So there's three degrees on this spectrum of consistency or four there's like nothing let everybody do what they want to then there's like here's the doc or web page internal web page it's the guidelines like we talked about earlier it's like here's you will do this you must do that
you can't should do this kind of guidelines better than nothing but a lot of times people read it they forget it or they don't come across it they design something they ship it it's like oops I screwed up next step is auditing which is go check to see if they're doing it the right thing
and flag them if if they're not and have them fix it again that's better than even just the doc but you still can end up having things leak out and then it costs time and energy to go fix them even better is the guard rails the controls that that just like when I go design the API it is by definition compliant because I can't make it in compliant one because the tooling won't let me and so if you take a look at anything when it comes to enforcing consistency whether it's security
reliability consistency of UX consistency of APIs that's you want to be on that end of the spectrum of the controls and but the controls also have to be not get in the way either and so they can't cause too much friction and they can't stop people from doing the things they need to do so obviously much more expensive to implement that side of things but where it's really high impacts high stakes that's where you you want to be that feels very they use that term shift left right the people of the
exactly what shift left is is exactly that that end of that whole spectrum right there yeah yeah yeah the that shift left it's such a like a corporate businessy person thing to do and like meetings with executives and stuff like that but what you're really saying is catch it early because a bug is cheaper before it ships yeah yeah an inconsistency once you have shipped the org chart they've seen what's going on when I used to work in like XML in the soap days simple object access protocol
many many years ago we would talk about like it's just an IDL right it's an interface definition language and it's choosing to expose stuff we would always use the analogy because I'm all about analogies of there's what's going on in the kitchen
and there's what you choose to put on the menu and like if there's rats in the kitchen you don't want to put rats on the menu and if you can get rid of the rats without the menu finding out then that would be like ideal and that that analogy has served me well for almost
almost 30 years this is interesting where would I go and learn more about this this is like its leadership its cloud architecture like I wouldn't even know like shipping the org chart in quotes is a really great term and I like it but I don't know where I would give a call to action for me and listeners to learn more about how not to ship the org chart I don't have any good references either I'm sure that there's books up there on leadership and does product design that cover these things though
from an engineering background and ever I didn't get exposed to those kinds of books and so my learning of this has been on the job. Yeah that's a tough one like it's a very big concept there's articles on it online if I find some I will go and put them in the show notes this is an opportunity for us to ask the audience if you recommend books that bridge leadership in the squishy business sense and like this is high level CTO
hey look we have a CTO here you know chief architect type type conversations and if you are whether you're in a big company or small company just being aware that maybe we don't want to ship the org chart and then what systems can be put in place to shift left so that we catch those things early and again identifying the systems or surface areas where the impact of shipping the org chart is the highest so you can prioritize those things. That's a great point.
Cool well I I felt like I learned something there that's pretty cool. Yeah I did too. All right well hopefully you're enjoying markets got learn too if you'd like to hear particular topics please let us know reach out to us on social media this is just a podcast that's getting started we're trying to figure out what we want it to be
but we know that Mark and I learn for a living we want you to feel great about learning for a living so please review share with your friend let us know what you'd like us to learn so we can help you learn as well this has been an episode of markets got learn too thank you for making it this far.