Has your entire career ever hinged on a single moment? For Darren Dillon, free beer in college set him on the path to a computer science degree and eventually a wildly successful career at Microsoft.
Today, as the CTO of Azure and AI at Microsoft Industry Solutions, Darren leads an impressive team of over 130 engineers and is at the forefront of cloud computing and AI technology.
Listen to Darren as he discusses his management philosophy, why he believes status reports are overrated, how to best think about building products for your end user and the implications of the GDPR on the future of AI.
Episode Highlights Include:
- What GDPR means for the future of AI
- Why managers shouldn't believe status reports
- How "real people" use computers
- Advice for setting boundaries when working with close friends
- The future of cloud computing and Azure
Join the Dev Interrupted Community
With over 2500 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No sales people allowed. Join the community >>
Transcription:
---
Dan Lines: Host
Darren Dillon: CTO of Azure and AI at Microsoft Industry Solutions
---
[Music throughout intro]
Darren: I was a manager of a team at the time where three or four of the people on the team were people I’d gone to university with, like they were friends, we had we partied together…
Dan: Yeah, like true friends.
Darren: Yeah like true, and we ended up going to each other's weddings and stuff. I had to, at one point, put these people on ninety days notice for their jobs…
[Music gets louder]
Sponsor: This episode is sponsored by Linear B. Accelerate your development pipeline with data driven engineering metrics, continuous improvement automation, and project visibility while cutting your software development cycle time in half. Sign up for your free demo at LinearB.io and mention the Dev Interrupted Podcast discount for one month free when you sign up for an annual pro membership.
[Music begins to fade out]
Dan: Hey, everyone, welcome to Dev Interrupted. I'm your host, Dan Lines, and today I'm joined by Darren Dillon, Microsoft's global CTO for the Azure Cloud and AI business in Microsoft's consulting organization. Darren, thank you so much for joining us today.
Darren: Hey Dan, glad to be here.
Dan: Yeah. I heard that you got into computer science for free beer, can you tell us about that?
Darren: It's true. So I went to college in the mid-90s. Back then biochemistry was super hot and everybody was trying to get into that profession and that's the field of study that I was planning on doing. I went to see three or four of the universities that I wanted to go to and when I got there, there was just no vibe, no atmosphere, they wanted to show you their labs and talk about the curriculum. I had a fifth slot on my application sheet for another course and I copied one from my buddy, who wanted to do computer science and I went off to that university for their open day. They were handing out free beer, they had a rock band playing, they didn't talk about curriculum, they didn’t have a lab. I had an epiphany, and I thought this looks like more fun. I knew I’d never look back because of my friends back then got into biochemistry and science like that. They all they ended up with good jobs, but just not the diversity of opportunity that we have in the tech industry today so looking back was a lucky event for me.
Dan: Good decision. I think from my experience, free beer goes a long way in not only computer science, but software engineering in general. If you can give someone free beer, you can usually get stuff done. So it sounds like you really decided with the culture, go with the culture there, instead of the lab. I want to give our audience an opportunity to get to know you a little bit better. I saw that you actually worked your way up through Microsoft, I think maybe about seventeen years now something like that you started as a solutions architect and worked your way up to CTO. So how did you make the journey from thinking like an individual developer to being an organizational leader?
Darren: Yeah, it wasn't intentional, it was just I was fortunate to get opportunities that just cropped up as they went along, and a lot of it was either being in the right place at the right time with maybe rewards or a different sort of inflection point in the industry. Two big ones for me were we had this thing in Ireland at the time called the Celtic Tiger. It was like the late 2000s, where the economy was pretty much doubling every year, customers were spending money like crazy, they were doing a lot of tech deployments, it was the sort of precursor to what we call digital transformation. But then also that economy actually bust we had the global dot com bubble a few years later, and then you learn a whole different set of skills, whenever you're shrinking, that that's just as important to learn as how to grow. But I guess in terms of that journey, I started after college, I was a developer for about eighteen months, and then I moved to a systems integrator, focusing on infrastructure, so doing a lot of infrastructure engineering work build outs of data centers, and the solutions on top. What was happening is that that systems integrator was very focused on what we would call mid-range systems today, so a lot of Unix, a lot of Oracle, a lot of IBM mid-range. I was hired as one of their first employees in what they call their Wintel team, which at the time, we were starting to roll like pieces of MT as it was called the precursor to Windows Server. And then exchange took off as like the killer with messaging so that team expanded. So I was hired as employee number one into that group, and within a year fifteen people in the team, because I was there before anybody else I converted to leading them. And then that taught me the basic stuff like, how do you delegate? How do you set goals? How do you prioritize? Things like that. And then after about six or seven years doing that, I moved to Microsoft back as an individual contributor. And again, because of that economy growth, the team that I was in was pretty much doubling every three or four months, and I moved into a management role. But in Microsoft, the focus was very much more about teaching you leadership skills in parallel. So not just managing activities, but thinking about how do you strengthen the team for the future and thinking strategically about your organization, intentionally bringing together different skill sets, how do you grow people? How do you coach people? How do you retain people? And doing this on the job but also very fortunate in Microsoft who have got a lot of internal training, which you can use. We've got various HR programs and we focus a lot as well on mentoring people, and especially early career. I took a lot of advantage from learning from people who had been doing that for fifteen, twenty years. So it was mixture of the right place the right time, on the job training, and then supported from other people. And I think, also on reflection, we've all had very good managers, and we probably all have a sometimes not so good manager. I think from the less positive management experiences I've had, I probably learned more in terms of I don't want to do that thing, I don't want to be that guy. I think one of the things that's common in a lot of tech companies, certainly Microsoft and we reorganize a lot to try to keep up with what we're doing in the industry, it's quite common to get a new manager every eighteen months or so. So having that sort of rolling set of different leaders that you're working under, lets you see the good and the bad from different people, and you can then build your own composition from that, in terms of your own style.
Dan: First and foremost, if you are in an organization that's scaling or has promise, that's when opportunities arise. So, you got to put yourself in, pick a good project or pick a good company. The last company that I was at, I was actually the second engineer hired, individual contributor, I was actually doing front end work, I became a full stack developer, I then became a team leader, started managing multiple teams, director, and then eventually became our VP of engineering. We were acquired by Cisco Systems that was a company called Cloud Lock. It was like a nine-year journey for me, and I was I think, to myself, Okay, what was a hardest leap? Was it from developer to managing a team or managing one team to multiple teams or that VP strategic role? For me, it was going from individual contributor to management, Team Leader, people management responsibility, I actually think that was the hardest jump for me, what was the hardest jump for you in your career?
Darren: I think that jump you just mentioned, Dan, from IC to manager is hard, quite often people's first management job, they're in a team, they get promoted to leading that team, for some reason or another, prior manager moved on, or the team just grew too big. And that's a hard one, because you move from being a team member to managing your peers and quite often, they're your friends as well. You could be in a situation where on the Friday, when you're the IC, you're going out for beer with these guys or having coffee, and on the Monday, maybe you're having to go and give one of them feedback about their performance, that's super hard. I was actually in a scenario, Like I mentioned, we worked through this economic downturn during dot com days, and was the manager of a team at the time, were three or four of the people in the team where people I'd gone to university with like they were friends, we'd party together…
Dan: Yeah, like true friends.
Darren: Yeah like true, and we ended up going to each other's weddings and stuff. I had to, at one point, put these people on ninety days notice for their jobs, because we were downsizing a little bit and we needed everybody to go through a process and that was horrible.
Dan: Yeah.
Darren: But the hardest jump actually, for me, was moving from managing a team where everybody's working out of the same building or working on the same stuff, to managing a globally distributed team where they don't actually talk to each other that much. And that's super hard just to try to get a team culture going to try to get people collaborating, you really have to lean in so much there compared to my initial management roles, where we all worked out of the same building and if we want to go for lunch, or have a meeting together super easy. Whereas I've had some team meetings where it's literally required people to fly halfway around the world and it's probably cost us $50,000, to just host a meeting, so you can't do that every week, right?
Dan: You've brought up a few interesting topics here. I've also been in the situation because you're that individual contributor, usually if you're doing a good job as an individual contributor, you do become friends with your colleagues, the people that you're working with, you're collaborating a lot, then all of a sudden, there's a promotion opportunity, and they're reporting to you. The advice that I can give that worked for me in that situation is always just be straightforward, you are going to be friends. So if you're clear cut, you're straightforward, here's what's going on, whether it's something bad happening in the company, and you have to let people go or there's a performance conversation or they're legitimately doing a great job. I think it's just honesty goes a long way there.
Darren: Thinking back to that particular situation, with the people that I was closest to, we actually had an agreement that there would be work mode and there would be friend mode and work mode, everybody got treated the same and they should treat me the same as any manager they had and then when you're in friend mode, we don't talk about work anymore, and we're back to normal and actually intentionally setting that boundary help me a lot that also helped them because nobody wants their peers to think that they're getting favorable behavior just because they know the boss that's not a good place for anybody to be.
Dan: Yeah, absolutely. The other thing, I'll just bring it up and then we'll move on, the thing that I struggled with the most is I was really used to, I guess, taking the reins as an individual contributor, working the code getting shit done coming in being Superman, I can fix anything, or I can solve anything. And when I became a dev team leader, like that doesn't fly well, at least in my organization. I had to learn from some pushback from the individual contributors, like, hey, this is my area, I don't need you to come in and solve this, you need more coaching and guidance. So that was the thing. Once that clicked for me, then I was off and running, oh, I get this role now. It's much different just sharing with the audience, you got to go from being Superman to Okay, let me coach and really set my people up for success, but they're the ones that have to achieve. And if they're achieving well, that means you're doing a great job as a leader. Now, Darren I saw on LinkedIn, one of your past managers described you as having “deep technical knowledge combined with the ability to relate it to and apply it to solving real business problems.” And some developers, it's difficult to make that leap from having this great technical knowledge to understanding the business in solving real business problems. What advice would you have for people looking to improve their ability to imply their fantastic technical skills to solving problems that the business is facing?
Darren: I think the first part is really just that self-awareness, right? If you're in the tech industry, you obviously like tech, and some people just want to go and play with tech all the time. But tech by itself doesn't solve a business problem. And once you come to that realization, which took me some time, actually, to realize that especially whenever I did a lot of work in the infrastructure space. You know infrastructure is just plumbing, there to go and host applications and solve problems that the application solves. But I worked in teams where infrastructure was the Holy Grail and they would talk about things like how big these servers were, or how many users you could host and stuff like that, you need to go through that maturity of realizing that's not the center of the world. And until you've realized that, there's no point trying to solve business problems, because your heads in a different space. I think the second part then is make sure that you're connected with the people in the business who are trying to solve the problem. Too often, the technical people are maybe abstracted from where the business problem is, there might be a business analyst between them and the end user, or they could be given specs or requirements over the wire, and they're just churning out code based on that. You got to get the connection with the end business and see what are they doing? What problem are they trying to solve? I was pretty lucky in that, in my college days, I did an internship where I basically had to hit the road and go and install applications for social workers and caregivers and things like that, I worked for a hospital. And I actually got to see how real people use computers, and they didn't use it the way I did, they weren't a savvy. And once you realize what they’re trying to do, you put yourself in their shoes and it will give you a whole different perspective. And I think from that, then it's also important to talk their language, not tech language. I know that sounds obvious, but too often, we lapse into tech speak and we need to think what does it really mean for that user or that customer. And I think finally, this is an area where the part of Microsoft where I work is really investing heavily is a lot of business problems are solved more quickly by showing rather than telling or talking or, you know, explaining features or doing presentations or whatever, actually building a demo, or an MVP or a mockup and letting somebody touch it. And then leveraging storytelling skills and things like that actually helps you get a good dialogue about the business problem, I think, more richly, and also a lot more quickly, and so on, I think this is a great trend in the industry, to use storytelling combined with being able to touch and feel stuff as opposed to sending documents or boring people with presentations and so on.
Dan: Yeah, actually, it reminds me of something that we're doing at Linear B that I see our engineering team doing. They have an unwritten rule now that the most important thing is how quickly can you get to a demo, or even if it's just a alpha demo, a beta demo, something that if a developer, you're presenting it back to the business, that's how I'm one hundred percent on it. That's how everyone can feel it a little bit and really understand like, is this solving a problem? Is it not solving a problem? That's when the best conversations come out and I agree with you, when you're just talking verbally, I think a lot of it can get missed. When it gets a little bit more concrete, that's when you can say something like, hey, okay, I see what you're putting down here. It's almost solving the problem. Here's the real pain point. And if we just did these other things for the customer, okay, now I get it. I'm a developer. I can understand the customer pain we've made that a rule at Linear B and that goes a really long way. So I just wanted to double down on that point, Now, Darren, you've been a CTO of a couple different organizations in Microsoft now and the dev team lead at several levels, what leadership challenges have you had to overcome and what have you learned from them?
Darren: So probably some very recent ones, actually, that the first is about twelve months ago, we underwent a fairly big reorganization and that was during COVID, obviously, so in sort of the old days or pre-COVID days, you would have had a lot of team meetings, got people together, spent a lot of time bonding, learning styles, and so on. And we needed to do it all over teams. And what we learned pretty quickly was that it's really important to spend time and allocate time to actually get to know each other talk about stuff that's not work, try to learn about each other's personal life, and so on. And you have to do it artificially, which feels a little bit uncomfortable at first presenting to people you've never met before, about your family, and your hobbies, and everybody else is on mute, that's a bit of a disconcerting thing. But once you've done it a few times, and try to make things fun, it does build up trust and collaboration. So one of the things that we did, actually, about two months into my new team was we found a company that hosted cocktail parties online, so they shipped out the drinks, all the ingredients. And then there was a zoom call where a cocktail bartender took us through how to build some drinks. What was really fun about it was because it was an international team, and this company was based in the UK, then we did it at about 4pm. UK time, so it's some people in Asia and some people on the West Coast of the US who hadn't had breakfast yet, and they're making margaritas, they had to take the rest of that day off. I think another big challenge, and it's one actually we're going through at the minute because we've just made some other organizational change, if you're in an environment as a leader, and there's a lot of change a lot of ambiguity, don't assume that people read the emails, that explains here's the org setup, here's what we're going to do. Even if they read it, they don't understand it generally and you need to be very accessible. Spend time with people, both one on one, skip levels, one to many, give people time to ask questions. Listen more than you talk, use that as your telemetry try to use open ended questions a lot so people have the space to think and ask. And then the last one, which a I learned the hard way pretty early in my career was whenever you get conflict inside a team, or between teams, and someone comes in and says Person X isn't pulling their weight, or they're causing problems or whatever, don't jump to conclusions, there's always two sides to every story, always, and go seek multiple ways of looking into that problem before you try to address it head on. Because if you jump to a conclusion, you're just going to make things worse, you're going to look like you're making some people favorable over others, you're going to burn bridges, and so on so always take time when someone comes to you with a conflict problem and try to get as many data points as possible before you do anything about it.
Dan: I think what we've learned so far in this pod is that free beer and alcohol really solves a lot a lot of the problem. I'm in a CTO group, and it's all remote obviously now, and they started doing thing, I think it's similar to what you're saying where everyone gets a drink sent to their door around the similar time right before the CTO group is starting. And it just seems like it actually brings everybody together because everyone's doing a common thing and actually lightens the mood a little bit and just humanizes it in a remote setup. Darren, on the flip side, is there a mistake that you've made that sticks out to you, you know, either as a team leader in the past or as an architect, or in the role that you are now that provided some interesting lesson that you think our audience should know about?
Darren: Yeah, there was one again, this just plays on the model that we're all in today with working remotely and quite often very highly dispersed teams. There was a scenario where I had hired a manager for a team thousands of miles away from where I was based and I didn't know that person very well, but they came with a lot of good recommendations. And I didn't spend any time with that person’s direct reports, once we got the manager on board, because I thought that this person is going to take care of the team. As long as, you know, they're hitting their results, then this is all good. On the surface It looked good, their results were fine. Feedback from their stakeholders was positive. But I've never talked to anybody in the team for a while. And it actually took about nine months before I did get around to talking to one of these guys and by his body language, I could tell there was a challenge. It turned out there was some sort of things going on in the team that we wouldn't really want to happen in terms of just culture and how people were being treated and so on. And as we double clicked on it we realized many people have that feedback. And what I learned from that was, well, I should have invested the time and having skip level sessions with our team, like never hire somebody into a team and assume that they're going to take care of things, always check in on their direct reports, just to see how things are. Don't believe status reports, don't believe feedback that shows we're hitting our metrics actually look at how the people are feeling as well. Because we've all worked in teams where you've had people may be struggling from performance point of view but if you've got a manager who's struggling from a performance point of view, then that's impacting the people they manage as well and it's a much bigger challenge in the business than just one person who's maybe not meeting their objectives. So always do your homework with the skip level, spend time with people across the organization as much as possible, and use that as your telemetry into how things are really going.
Dan: Yeah, the new manager that you bring in, or the team leader you want, of course, you want to trust them, and you want to give them space, but there's no shortcuts, you can't replace spending time with people within your organization. No matter how big of a boss you are, doesn't matter if you're the CEO, I still think you should spend some time with contributors from our all levels, at a minimum, you'll learn something, even if there's not like a catastrophe happening, you'll learn something that will help the business and maybe at the maximum when you find out oh, there's like some issues here and I really need to address them, thanks so much for sharing that. A lot of our audience on this pod are engineering leaders at startups and scale ups, Microsoft is on an entirely different level of scale. So just to learn a little bit about your organization today, how big is your team? How is it organized?
Darren: My team today is about one hundred and thirty people, which it's probably one of the biggest things that I've managed, but it's small in the scheme of things. So with the organization that we sit in, my direct boss has got about four and a half thousand people. So we're a small team in his world, which has a lot of advantages, because we fly under the radar for a lot of things, which is good. It's effectively two teams at the macro level. So we have a team that is called our industry team, the team does a lot of consulting pre sales and consulting delivery into some discrete industries, so Financial Services is one, healthcare is another education is another. And they do some very specific things with customers in that sector. And they pretty much run as their own practice, as it were, they've got their own metrics, they hire and fire and take care of things and sales. It's a great bunch of leaders in there. And then the second side of the team is what we call the solutions architecture office, which sounds like a grand term. It’s really the people that look after things like the technical strategy for our part of the business, they represent our part of the business back in the key stakeholder groups in the product groups engineering, customer success, and so on. They're both for how are we building capabilities in the organization for the future, whether that's technical skills, soft skills, intellectual property, or whatever. And that is then broken into a series of teams, at the minute they're organized by technology. So we have an infrastructure team, series of infrastructure architects in there. There's an ops team, which is mostly people that come from the dev background. And then we've got a data and AI team where we've got data experts, as well as some very smart artificial intelligence practitioners as well.
Dan: So do you have two direct reports? Like one for each side? Or do you have a few people reporting?
Darren: The industry team has got one overall leader and then he's got direct reports by industry, and it's like a traditional structure in that way. And then the rest of my direct reports are basically leads for each of those technical areas. So the admin lead and ops lead and then you have an AI lead and then we've got a business manager who basically acts as the air traffic controller and make sure that we're any cross cutting initiatives we're doing are on track, and so on. So it acts like a PMO across the rest of the organization.
Dan: Gotcha. And is the team like, where's everybody located? Are you global? Are you all together?
Darren: It's global. I'm actually not sure. I couldn't tell you all of the places where people are, but we have people all over the US. We don't have anybody in Latin America as far as I’m aware. We've got some people in Canada, across Europe with Central Europe, Eastern Europe represented, Middle East, UK, Western Europe, and then over in Asia, all over China, Japan, Australia. Yeah, that's very international thing.
Dan: Is everyone remote now with the COVID situation, everyone from home?
Darren: Yeah, like in some countries… So Microsoft's got a classification for each country, which generally follows, you know, the rules that the country has and then it will dictate whether the offices are open or not. So in some of our locations, like I was talking to someone in Dubai the other day, and the office is open, but you can't have meetings, you can go in for yourself, but you can't meet customers or anything. I don't think we've got anywhere like that and then a lot of locations like where I am still can't go to the office. It's gonna at least be next calendar year, I would say, before we can start to have internal face to face meetings, and that's been optimistic, I would guess.
Dan: So if we paint the picture, you have Microsoft that has a global reach, you have people on your team in all different time zones, different countries, maybe a hybrid remote situation depending on where they live and what's the situation in that city or that country itself, and there’s a question that I ask most of our guests, in that remote, in different time zone setup, what are you doing to avoid problems? Are there lessons that you've learned that you can share being in that distributed team situation?
Darren: It's something, I switched to a role pretty much ten years ago, to this month, which was my first global role, and I spent a lot of time intentionally learning about working in that environment, I had a mentor that helped me a lot. There's actually a really good book it's called Kiss, Bow or Shake Hands, and it's basically an encyclopedia for every country in the world and it explains, here's their business culture, here's things not to do, not to say, don't cross your chopsticks in certain parts of Asia and so on. We actually bought that book for everybody that came into the team, because many of these people, it was their first time on a global team as well. I think as you build up that cultural awareness, you got to work at it, you can’t just assume that it will happen. So for example, don't do large emails, like org-wide emails, or all hands on Fridays, because even though that sounds great in the US, it's the end of the week, Fridays are actually the weekend in the Middle East, so that's not very inclusive. We think when you're collaborating a lot globally, and you've got people from multiple time zones, be respectful of their time, but also be pragmatic. They need to realize when they move into those sorts of teams, it's not nine to five, I've done a couple of calls this week at 6am, which is my sort of early end of the boundary, I do calls late at night with the US. But then I also block out time during the day and go take my dogs for a walk or play tennis or just relax. So enabling people to build their diary around this and not assume that you need to work nine to five plus both ends of the morning and the evening. And if you've got things like recurring meetings, make sure that you're swapping those around, so one of the things that my boss does, which I really appreciate, he's based in Australia, his leadership team meeting every other week, one instance of it is in the morning, my time one instances the evening, my time that way, across all of his direct reports, everybody sort of shares the love in terms of working during their day. And sometimes maybe once every six weeks, you got to get up early or stay up late so that's very key. And then the last part, two more parts that one is always seek feedback, we talked about skip levels, and making sure you're getting that to a telemetry, make sure you're asking people how that's working out in terms of the distributed piece. And then finally, you know, pre-COVID, that face-to-face time is golden, in a distributed team, that we would have internal events. We might have external conferences and tech-ed, for example, most of the team could be going there, use that as an opportunity to actually get as many of the team together as possible and talk about work. But maybe then also go watch a game, get some food, because you can actually see the productivity of a remote team spike for a number of months after you invest in that that's well worth investing. I don't know when we're going to be able to do that again, but certainly before COVID, we would always be planning in my team when's the next time we can get most of the team together and at least have a slot on the calendar that people can look forward to and talk about business, but also make it fun as well?
Dan: Yeah, for the size of your organization is actually like coding, building apps, things like that. Do you know, is there anything that they're doing with either like asynchronous communication or getting notifications, hey, this code is ready for you to review? Or is there anything that you're doing to keep the team in sync while they're remote and distributed?
Darren: Yeah so the nature of the work that many of them do is that they don't really work within the team so much. So they may be working with a customer team representing my team, or that could be working on another internal initiative, again, representing my team. So it differs based on the team, some of them don't really invest in doing that, and the good ones actually do and try to, you know, keep that thing going. There's a lot of value there, because one of the benefits of having that distributed team is you can pretty much get work done around the clock. People in the US can be doing stuff and they finish, you know, their evening and they get up the next day and the people in Europe have maybe moved that piece of work further along so you actually get the feeling that you're working or you're developing your product if it is a product or you're developing your progress twenty four-seven even though you might only be working seven or eight hours that day.
Dan: Yeah, you have continuous development always happening. For those, more so those development teams, are there any metrics that you use to try to understand, is there bottlenecks happening or teams that are struggling or teams that seem to be flowing efficiently, what do you look at metric wise?
Darren: We're fairly informal in my team, because a lot of the work that we do is in like an overlay or support function. We're working with either customer facing project teams or sales teams, who they're accountable for either a sales target or customer outcome, and we're there to support it. The actual key thing that I look at is stakeholder feedback. And a lot of that is qualitative, through discussions I would have with various stakeholders, how are we doing? Basically, if you ever hear someone saying, I don't know what that team does, then in my business, that's a bad thing, right? If you're in this sort of support function, and people don't know what to do, so we spent a lot of time on stakeholder management, some of the other metrics so that our overall org drives, which we also track our progress towards, one is just cloud consumption. It's a massive metric for pretty much everybody in Microsoft, what influence are you having on the adoption of our hyperscale clouds? We would have various initiatives underway in our team, this huge one at the minute around just modernizing some of our project delivery techniques, and it has a series of OKRs, we use that framework a lot. What's the completion progress of those OKRs on time? And again, what's the feedback from the end users of those solutions? I guess another one, which I hadn't seen done in previous companies is, we also measure employee feedback on their manager through anonymous pulse surveys, and the managers are held accountable for what's called their work group health index. So it's a series of questions around does the manager set clarity? Do they give you new opportunities? Do they connect your work to the business objectives? Do they give you feedback and so on? And we actually measure the managers pretty hard on that health of the team, which I think it's a good thing. But like I'd said earlier, sometimes you need to double click beneath the metrics, because you may find this manager could look great on the metrics, but when you talk to that team maybe there's some room for improvement there, maybe in terms of their style and so on.
Dan: The last question that I wanted to ask you, in this topic area, you mentioned, I think you said, Hey, I was the first person within this group and I grew it, I think you've worked on a few different startups, maybe within Microsoft, what have you learned about scaling or rapidly scaling engineering organizations and how do you do that?
Darren: I've heard people describe this a lot within Microsoft that in some functions, it's like working in startup, but you've got all the benefits of a big company behind you and I've been lucky to experience that, myself. I think as you're in that startup mode, you need to be thinking mentally, through your head of who are the other leaders that you want to bring into that team. I've been here a long time, like 17 years. I know a lot of people in the company, and I know quite a lot of people outside the company as well. When you're in startup mode, you're constantly thinking, who do I need on this team, based on what can they bring, and even if it may not be the right time, or they may not be interested at that time, you need to keep that internal network alive. I talked to people that I don't have a direct need to work with for maybe the last five years, but we still might catch up once a quarter and just have a chat. So keeping that alive, I think you need to be looking then within your team, as you build it up, like who's looking to step up and own things, there are always people that want to take on more and find these people that are looking to take on more and invest in empowering them, whether it's giving them extra scope, or you're giving them extra skills, or some more resources. Someone gave the analogy once that those sorts of teams do really well by lighting small fires, and if you just give one person a little bit extra thing to do, and maybe change somebody else's scope, eventually this whole thing starts to gel and get a lot of momentum. I think it's important as you're building like your team to really understand, what's your non-negotiables? What are your basic principles, right? Like, what does success look like, obviously, is key, but what sort of culture do you want to drive? What do you want to be known for? Because that will help you when you're recruiting people to filter through, are they the right fit? One thing I've learned a lot in the last five years is the importance of communications in large organizations, and the thing that I learned is that when you communicate something, like it might be an organizational change, or here's a new policy, or a new thing we want people to do, if it's more than about 500 people that get that message, you need to communicate it seven times in three different modalities to get it across. So a couple of emails from leadership, you might do an all hands, but then you need to empower maybe the first line managers to understand this and explain that to their teams, and then maybe you need to get some of the individual contributors to maybe live that change and then explain it to their people and so on, so really over investing and communications as you grow. Then I think the last part is don't lose sight of why you exist. I've seen teams that started small and then they're successful and we get more scope and more scope. They don't actually refine themselves over time, they just keep getting bigger. I think it's important to periodically look and think, what are the things that we don't have to do anymore, just because we used to do it doesn't mean we should still do it and use that to stop being bloated, or doing things that aren't really connected to your core purpose. So always be thinking critically about exactly what you're doing and just don't keep building on the status quo.
Dan: I can totally relate to most of what you're saying. I definitely think if you move into that leadership position, and you're responsible for scaling an organization, I always think back to previous relationships I've had in my engineering career and thinking, I'm so happy I met this person, because if I can bring them now into my team, you pretty much know what you're getting, number one. It's not, like, an unknown when you hire someone you've never met before, the interview processes are so tough and difficult to figure out, hey, what does this person really going to contribute? Or, you know, if you can get a few stable pillars, hey, I know these two or three people, they can own this area, and yeah, I'm gonna recruit from the outside, that's worked really well for me. And the other thing that I can relate to, the last CEO that I worked for, his name's Gil Zimmerman, great CEO from CloudLock, he used to always joke and say, “I feel like I'm not the CEO. I'm really the CRO, I'm the Chief Repeating Officer. I need to repeat our goals and our message in different mediums over and over again.” like you're saying, you can't just send an email, you can't just say it once at an all hands, you need to repeat what are we all about over and over. Because for one that's hard for people to just pick up the first time and people learn in different mediums. I'm going to move us to our last topic around Azure and AI. Microsoft is one of the most interesting companies in the world. Again, you're the CTO for the Azure cloud and AI business, you're at the forefront of, pretty much, really freaking cool technology. What can you tell us about what's happening at Microsoft in Azure in AI?
Darren: Of the stuff that's top of mind for me and my team and where we're having some really interesting customer dialogues, I think one of them is this technology called Azure Purview. If you've got the microsoft.com, you can find it, you can play with it. So that's a service for data governance across multiple clouds, so helping customers discover data, classify data. It's really an enabler for a lot of regulatory compliance, but then also, as they start to do a lot more with artificial intelligence, then you really need to get on top of your data governance. So that's going to be pretty hot for us going forward. Another area totally separate area is networking 5G. We had some press releases a couple of weeks ago, where AT&T is moving its 5G network to run on Azure. The idea is, that's a better service model for them, but also then they can use our AI technologies to automate things like customer service and differentiate from their competitors. You're going to see a lot of mobile operators take that approach going forward. And then the third one, that's pretty hot for us at the minute is Azure Ark. That's our technology for managing multi cloud and on-prem environments, all from Azure. It really started as an infrastructure, management technology, but it's moving up the stack, and now you can start to manage data platforms with it, and so on. And then the last one for the developers out there, there's a technology called Bicep, which again, you can find all of this if you Google for it. Bicep is really the next generation for how to create infrastructure as code, and that should be an easier way for how you write that type of declarative template. A lot of the focus overall, within Azure is about democratizing the technology, making it easier for people to actually use. So that yes, we still have a need for the extremely smart developers and consultants and so on for the tip of the spear stuff., but really moving towards that sort of low code environment across the board to really help everybody get value from that platform as much as possible.
Dan: That sounds awesome! You spoke about AI a little bit what is next for AI in your world? Is there any interesting things you can share for uses of it, or something about the technology, what's coming next?
Darren: In terms of coming next, there's one thing that I would encourage people to go look up, it's a thing called Project Bonsai, [Spells Bonsai] it's a Microsoft technology. It's really the low code platform for AI, so the idea is that you can build self-learning models without necessarily being a very deep specialist in artificial intelligence or being a data scientist. And then actually the AI technology and Azure itself would then apply reinforcement learnings into those models, so it's sort of equivalent of using a digital printer to print a digital printer or not digital, is that the right term? 3D printer to print a 3D printer, sorry I had a brain-fart there.
[laughing]
Dan: Yeah, yeah.
Darren: So that's pretty cool. I think, though, and parallel, we're seeing the usage of AI becoming more widespread. And it's not just niche anymore, or just for customer service bots or things like that, but people are actually using it for mission critical decisions, and as a result, there's also a growing trend to regulate the use of AI. The European Union's about to bring in some legislation, for example, so we've all been through the GDPR process in the last few years now the European Union's looking at similar things, just around how is AI used ethically so that when we're making decisions, especially related to humans, that we're actually applying fair principles. Microsoft has a set of principles, you can read them on our website, this is what our product teams have been using as the sort of the North Star when they're building product, but we're also now starting to work with customers and helping them adopt and adapt these principles as well. So I think the technology is growing, and the adoption is picking up a lot, but we're going to see this big focus, especially with large customers on how do you actually make sure that you're using it responsibly, and we don't end up doing bad things with it?
Dan: Yeah, that totally makes sense. The last question here that I wanted to ask you, I think you have dev teams, and when I'm thinking about dev teams that want to build an app, or maybe build an app at a rapid high quality pace, and they have options, they can choose Azure, you could go AWS, there's some other kind of platforms as a service, what types of teams should use Azure? Like, where are the strengths if someone's trying to decide, okay, where should we go?
Darren: I think the strengths of Azure is equivalent to the strengths that we had back in Windows Office back ten, fifteen years ago, it's not that a given Azure feature is necessarily better or worse than something equivalent in Amazon, or Google, that maybe you're getting into sort of feature level comparison, I think the value of going with Azure is just the overall Microsoft stack, right? So you've got, you know, the Azure cloud, but where Microsoft's going to is around what we call industry clouds, and this is where we're starting to stitch vertical solutions using multiple cloud technologies. So for example, we have a healthcare cloud that that we announced, and you can see some of the demos of it online, that actually uses Azure and teams, and dynamics, and GitHub, and Azure AD, but it's pulled them all together. So that the integration of these things may not, each one may not be necessarily best in class at a feature level, but when you pull them together, you just get the value of solving that whole lifecycle and then being able to build on top of it. Because what these industry clouds do provide vertical solutions, the idea is then that the partners and customers can go and build on it on top, necessarily getting into the vertical business very hugely deeply. But we're trying to build vertical platforms that people can then go and improve and augment that. And we're seeing this elsewhere in the industry as well then, where Salesforce acquiring Slack, for example in the last couple of weeks, I think that this is where the next big set of battles in the tech industry are around cloud integration, specifically around industry solutions.
Dan: Awesome. Darren thank you so much. This has been a really stellar conversation, talking to us through your journey in engineering and give us an inside look into what you're doing with Azure. Awesome to have you on the pod today.
Darren: Thanks for having me. It’s been fun.
Dan: What's the best way for our guests to get in touch with you or follow you if they're interested in speaking with you more on what you're up to?
Darren: Simplest way is just LinkedIn, you can find me there. I don't spend a lot of time blogging. I don’t tweet. Anything I do share is generally on the LinkedIn platform and you can connect with me there, hit me up with a message I'd love to continue the conversation.
[Music plays]
Dan: Awesome. Definitely hit up Darren on LinkedIn. And a quick reminder for our listeners, if you haven't already reviewed the show on Apple podcasts, podcast reviews are super crucial for our show to get discovered. Also, be sure to join the Dev Interrupted Discord community. That's where we keep this type of conversation going all week long. And Darren, thank you again, awesome to have you.