Tech: Why It’s Always About the People | StackPod E18

Episode transcript:

Annerieke: Hey there, and welcome to the StackPod. This is the podcast where we talk about all things related to observability because that's what we do and that's what we're passionate about, but also what it's like to work in the ever-changing, dynamic, tech industry. So if you are interested in that, you are definitely in the right place.

Introduction

Annerieke: I am so excited to announce the guest of this show: Jujhar Singh! So a few episodes ago, we talked with fellow podcaster and tech evangelist Dotan Horovits. During that episode, Dotan shared with us that he wrote a blog post together with Jujhar called “How Much Observability Is Enough? ” and we were eager to invite Jujhar to the StackPod as well to dive into this topic a bit more.

Annerieke: So, to give you some background information: Jujhar has worked in tech since he was very young and when he was in his mid twenties, he was already an IT manager. After a while, he decided to take a paycut because he wanted to be in software engineering instead of management, which was, I quote: “the best decision I ever made, man”. Currently, Jujhar is a lead consultant at Thoughtworks, with a specialization in DevOps and infrastructure, where he has the chance to work alongside some of the writers of his favorite software book: “Accelerate: The Science of DevOps .”

Annerieke: In this episode, you will hear Jujhar and Anthony discuss why tech is always about the people and not so much about the technology; how you can enable engineering teams to make their lives easier while preventing cognitive overload and why platform teams can be an answer to that; also why diversity is crucial for successful working environments, and much more. I will not spill all the beans - let’s dive into it, and enjoy the podcast.

Anthony: Hello, everybody. Welcome back to The StackPod. My name is Anthony Evans. I'm your host as always. With me today, I have a very special guest, Jujhar. Jujhar, do you want to introduce yourself and what you do in tech, and where you're located, so that people can get to know you a little bit?

Jujhar: Hi, everybody. My name is Jujhar Singh. I'm currently a lead consultant for Thoughtworks, my specialty being DevOps and infrastructure, and I separate the two out because I'm a DevOps purist. You know, the sort of Gene Kim, Jez Humble definition of DevOps, and then infrastructure. I'm celebrating 24 years in technology. I started out when I was 16 years old, in a computer shop, fixing Windows 95 machines.

Anthony: Control, alt, and delete, getting rid of all the-

Jujhar: That's right, that's right.

Anthony: ... new age internet stuff that people were installing.

Jujhar: Yeah. Yeah, dial-up... Yeah, exactly, and AOL CDs, and dial-up modems, and all that kind of stuff, right? But yeah, so I've been working in technology from a very, very young age. I mean, it predates that, really, but that was kind of when I actually got money for doing what I was doing. And I'd say the first half of my career, the first sort of 10 years or so, was around classical IT. I always did software engineering on the side, and I didn't sort of discern the difference between the two, but sort of by mid-20s, I'm an IT manager, kicking Microsoft Active Directory, and Microsoft Exchange boxes, and that kind of stuff.

Anthony: Yeah.

Jujhar: And then I was sort of towards my late-20s. I got a bit sort of disenfranchised with it, if I'm honest with you. There's only so many sort of copies of Backup Exec that you can install, right? And IT gets a bit boring in that sense. Apart from when things go wrong, it's just mostly the same, so I took a pay cut at the time and became a software engineer full time. The best decision I ever made, man. Yeah, absolutely love it. Software engineering's so much more creative. And then just a timing thing, you know? I've always been interested in optimization and making things more effective and efficient, so early on, I'd say my DevOps journey began pre-cloud, and it was around CI and CD, so I'm giving maybe a bit too much away here, but sort of... It wasn't even Jenkins. It was... What was Jenkins called before it got called Jenkins? Hudson.

Anthony: Yeah, yeah.

Jujhar: I was setting up Hudson servers and-

Anthony: Yeah, Hudson. Oh my god.

Jujhar: And sort of doing unit tests on PHP applications, and getting them deployed out to servers, old-school SSH, and that kind of stuff, right? Predating cloud, this is, or my exposure to cloud rather. And then around 2011, cloud really sort of starts to kick off, and I jump on the AWS bandwagon, and absolutely fell in love with it. And again, further optimizations. Like to me, what is cloud? And I told someone off today about the definition of cloud, talking about private cloud, and it's... If you look at cloud infrastructure in terms of compared to a traditional data center, let's say, I mean, the two'll look very similar from a distance. But the differentiation for me is the APIs, because everything now is controllable via an API. And you've got pricing models and all the sort of efficiencies of scale, but it's now that everything... What was previously a hardware concern, you send up a request and it takes a month, or provision a server, and some person will come and stick a box in, and then he or she will stick a USB stick and configure the box.

Jujhar: Now everything's done via software, so what was previously a hardware problem is now a software problem, and then that then allows me to... Well then, I sort of really fall in love with that, and how do you really take the sort of DevOps approach to infrastructure, and optimize that further now that it's all within the control of software, and everything's configurable from your ID? And that, to me, it still blows my mind away to this day, right? Even after 11 years of AWS, five years of GCP, and 10 months of Azure. It still blows me away, the sort of power that that gives us, spinning up platforms and controlling them, so yeah.

Anthony: I had a very interesting conversation with... You know the data center provider Equinix?

Jujhar: Yes, I do. I do.

Anthony: So, do you know, right, that AWS centers use Equinix as their data centers? So all that's happened to Equinix is that the paycheck has gone from individuals renting out rack space to now just AWS renting out the rack space and being paid to do it. It's just so interesting that, although it's not a hardware problem anymore, the hardware is still there, and to make it available in a Software as a Service setting like AWS, you need to at least have 10X the current demand, to be able to cater for the unexpected demand, right? The amount of management that goes into that, that is now all simplified, it's amazing, really, how they've done it.

Jujhar: But you can only do that through software, right? Fundamentally, and there's no way you could do that in the old school sort of configuration and spreadsheets kind of way. It has to be software. That's the only way it can manage these things at scale, and that's what the likes of AWS, and GCP, and Google, and Microsoft have sort of mastered, and I think everyone else is catching up. But yeah. The last, my previous job to this, I was global head of DevOps for The Economist, the newspaper. That was a wonderful job, really, really enjoyed that. Shout-out to my ex-colleagues in Birmingham, London, and New York. And prior to that, I was sort of-

Anthony: I'm actually a subscriber to The Economist as well, so-

Jujhar: Oh, fantastic.

Anthony: I refuse to get my news over the internet, and The Economist is perfect, because I just get a once-weekly book, with everything that happened that week, plus an economist's opinion on it. That's all I want. That's it.

Jujhar: I'm old school as well, right? So yeah, but I prefer reading, definitely reading the newspaper. And then prior to that, which was a fantastic role. They're a fantastic organization in the UK. I was the cloud evangelist at John Lewis.

Anthony: Okay.

Jujhar: You know, and that was taking that organization through, it was zero cloud basically, and into Google Cloud, and that was a real privilege, and fascinating. You know, by the time I sort of left... Before, it would take months to do a deployment of the website. Now it is sort of daily deployments to GK and Kubernetes by the time I left, and that was a privilege to be part of that process. And John Lewis is a fantastic company. And then prior to that, it was startups and SMEs and stuff, so that's kind of my background. Now I'm at Thoughtworks, which is a company I've always admired from a distance. It's a wonderful, wonderful company, my first time as a consultant, and it's a really clever...

Jujhar: I mean, some of my colleagues, Gene Kim and a few of the others, these are the people that write the books that I talk about, right? So to be able to work shoulder-to-shoulder with them, with the likes of these, again, is a privilege and an honor, and I love the Thoughtworks hive mind, and we can always consult the hive mind and find answers to most things. So that's kind of what I'm doing at the moment.

Anthony: Yeah, I've done the consultancy thing in my career as well. The only thing that I struggled with, working as a consultancy, rather than working at a vendor, right? I'm in tech, right? So I work at the technology thing. I worked at ServiceNow. I work here at StackState, you know? I work on the technology side, and having... When you work on the tech side, you kind of own it still, which is nice. Like, I like that ability that I'm putting my stake in the ground on something, and I'm building something, right? Where I didn't get that feeling as much when I was a consultant.

Why tech is about the people and not about the technology

Anthony: I got a different feeling, right? I felt like I was really helping people, and that I didn't have to keep telling them about my stake in the ground, because that wasn't important anymore, you know? I'm here to solve problems and do things, and I still keep that mindset with me when I'm talking to clients today, because I honestly think that there's not enough of compassion and empathy from technology companies with their customers, so I always make an effort to treat my customers with honesty, respect, all that kind of stuff. Because that's the difference. It's not just the tech, it's the people too.

Jujhar: Oh, it's always the people. Technology's easy, right? Computers do what we tell them to do, right? It's software's really about people, fundamentally, and just getting that right. And that sort of segues into what I wanted to talk about today, which is that sort of intersection of technology and people, and how do you make technologists' lives better. How do you make them more efficient, more effective? How do you make them happier? How do you optimize sort of the splitting of the domain, the tooling choice, the architectural choices, even the ways of working? How do you optimize all that, so that you can get... Engineers can just be at their best? And I would say, given sort of my experience, is what I've been focused on for, I'm going to say the last three years, four years, probably five, six years has kind of been that intersection of technology and people.

Anthony: Yeah.

How Jujhar coaches his clients to get better at practices like observability

Jujhar: And currently, I'm working with some clients, and we're sort of looking at... Again, sort of I'm going to pinch a lot of ideas from the book, “Accelerate.” I love that book, about capability modeling, so not just going into an organization and saying, "Hey, you need to get better at availability. You need to get better at durability."

Anthony: "You suck. You need to do better."

Jujhar: "Your observability sucks." Yeah, it's actually, can we a bit more prescribed, and a bit more precise about that? So that then, again, from the book “Accelerate ,” about capability modeling as opposed to maturity modeling. And that led me sort of to create this tool . I'll share the link. Hopefully, you can share it with the listeners in the show notes.

Anthony: Oh, yeah, we'll put it in the show notes. Yeah.

Jujhar: But essentially, it's just a radar, if I can describe it in words. It's a radar, and feel free to fork it. It's MIT licensed. Underneath is a JSON blob, so you can customize it, and you can map your own team's capabilities to it. But what we do is we then... I pinched another idea from Matthew Skelton, the author of “Team Topologies ,” and he has software engineering assessment cards, so we're doing this with a few clients, is we're creating engineering assessment decks of questions, and we'll ask them, "Well, what's your CI/CD like?" And then they rank themselves between a one and a four, or five, sorry, five being, "Yeah, we're amazing. We deploy 100 times a day, automatic rollbacks, blue-green canary deployments, yada yada."

Anthony: Yeah

Jujhar: Feature flags, all that kind of good stuff, all the way to, "Yeah, the Jenkins box dies, and sometimes we manually look at the screenshots, and click, click, click, and that's how we deploy." So we run this kind of two-hour workshop with all the teams, and they score themselves, and then we plot that score, and we capture the comments as well, but we plot that score on this capability diagram. And then we...

Anthony: And it's actually really clever. Sorry, I didn't mean to interrupt, but it's really clever if you think about it, right? Because the fact that you're getting them to tell you what they think their problems are means that you don't need to go in and say, "You guys suck," because you're basically having them tell you, "Okay, this is where we think we need to focus on." Now, that doesn't mean you go down that path, right? You just need to get an understanding of what they think their problem is, and what their real problem is, right? So asking the questions and getting them to rank their own solutions allows you to see where they think they're strong and where they think they're weak, right? That's groundbreaking information for you, because then it allows you to deliver your recommendations in the most optimal setting, right? Because you can appease their insecurities, or you could then go head-to-head, and say, "No, what you think you're strong is actually killing you," you know? Like that type of conversation that you can have, but you need the data.

Jujhar: So yeah, the process gives us the data, but back to your point about compassion and listening, is it gives us... They actually feel like they're being heard. And when we get into a... You know, we sort of guarantee privacy in these sessions, and when engineers will all of a sudden get to talk about... They actually get to put their tools down, because you know, the pressure's, "Deliver, deliver, deliver." They actually talk about, "Oh, what's our observability like, what are our security practices like," and you talk about them in the open, about their Git branching strategy or something. They're often very like, "Oh, we don't get to talk about these things," even with each other, right? Even with people in the same team, sort of working together all the time. Because they're too busy just, "Deliver, deliver, deliver," so we're just taking a step back to be able to sharpen their axes a little bit, and just look at where they are, and have that introspection. Just facilitating that, and just watching that is wonderful.

Jujhar: And then to your other point, that we then get the data to then make the recommendations to the client, "Look, it's clear that your durability's bad, so maybe we need to work on some runbooks, maybe having it spin up an enabling team," back to sort of Team Topologies, to help teams move the needle on... get some backups working, get them tested, maybe a little bit of chaos engineering or just regular testing, or a platform team that can... And again, so this is one of the tools I'm working on. I'll open source it on the same website that I share, is where do you make the decision between a platform team and a you build it, you run it.

Anthony: Yeah.

When platform teams can be an answer to cognitive overload

Jujhar: So back to cognitive overload of a team, and you're an observability person, right? So we'll talk about observability. Should a team manage and run all its own tooling, and do observability, and still manage 15 microservices and deliver at high velocity, or should it be, "Hey, let's take some of the pressure off them"? Should we have a team take away that cognitive load from them, hand them some templates, some ready-made stuff. Or should it just be an enabling team, so a team comes in temporarily, and up-skills you on this stuff, and gives you all the templates, and walks away? Or should it be a 24/7 team, that looks after this? And the answer is always it depends, right?

Jujhar: There are two metrics that I look at when recommending a platform team, is A is the sort of capability, the maturity of the team. Are they sort of mostly fours and fives or are they mostly twos and ones? For whatever reason, right? There's no judgment. And the complexity of the domain. So if it's a very complex domain, with like 15 microservices and seven different data stores, probably help them out, and they're a mid-maturity team, you should probably do a platform team, and support that, and give them some enabling team to move them along. If they're a very cutting edge, high-trust, high-velocity team, and it's a medium complexity problem that they're working on, just a handful of one or two monoliths, or whatever it is that they're looking after, give them full build it, you run it, give them full control. They don't need a golden cage. They just need a golden path, so just recommend the tools that you've got, right? Whereas sort of the less capable teams, you want to kind of put more of a golden cage, or a framework around them, say, "Only use these tools, and only use this gavel in this way."

Jujhar: So I've gone both extremes in my career, and what I've come to learn is the answer is always it... It always depends on the team, which is why, then, I like to do this deep dive with the team, work out where the team are, and then give them the appropriate support, tooling, processes, people, to give them success.

Training people to deal with constant change

Anthony: Well, now that I think about it actually, you probably have like an amazingly unique perspective on things, given the work that you did at The Economist , right? Because The Economist is an 1800s news outlet store, which delivers print.

Jujhar: 1843, yeah.

Anthony: Yeah, yeah, yeah. It's 1843, it's as old as time, and you are in charge, or you were in charge, of taking this 18-whatever, 1800s, 1814, whatever thing, and delivering technology, right? So The Economist, I've noticed over the last couple of years, the app has come out. Obviously, that's now a technology component. The podcast as well, and then the managing of people that you've got in London, and in New York, and all the different reporters that they've got there, that need to join those podcasts, that then you're recording, and you're monitoring and editing, you know? So when you talk about that, and the fact that you probably had to introduce nothing but change at The Economist, by deploying tech, right? So to get to those outcomes, there was a lot of hurdles, I'm assuming. Do you have any good examples around challenges or issues that you faced trying to implement what it is that you're now consulting for, if that makes sense?

Jujhar: For our listeners there, I'm stroking my beard now and sort of thinking. If I was to summarize the thing that was... You know, a few failures as well, right? But the best thing that I did at The Economist was focus on shipping process and people and not technology. And again, I'm going to sort of link this back to “Team Topologies” and “Accelerate .”

Jujhar: But when I joined The Economist, my remit was a lot of stuff was outsourced, and they wanted to in-source, again, to bring software to the heart of the organization, and make it a digital-first organization, as opposed to sort of just software is on the outside, in the periphery. It's a service you buy in, you know, that old IT mindset, to, "Okay, we're a digital organization now." So I got to be at sort of the vanguard of... Well, I'd say the phase two of that transformation, and that is, "Now, well okay, great, we're going to do this. Now let's build the teams, and let's take back control." Not that you shouldn't use vendors, but just who controls the mindset there.

Jujhar: And my number one focus was around infrastructure and DevOps practices, was building the teams and building the people, and making sure that they can be successful. Which then led me onto the “Accelerate” thing. That's when I first started, and my boss sort of challenged me around that, and the answers were in “Accelerate.”

Jujhar: How do you get people to be agile, and flexible, and change, and deal with any new technology that comes along, respond to business need and business ask? Because that's always going to change. The landscape's always going to change, even with an organization that's been up since 1843. The only constant, I can say, is change, and the pace of change is accelerating. So my focus was always shipping process and people, not technology, and the difference is...

Jujhar: I'll give you an example. One of my friends, he works in an insurance company. He's just finished with them as a contractor, and he helped build their data lake out, right? To do all the actuarial... You know where they sort of stick their finger in the air and make up insurance premium numbers, right? So this was to build a platform to do that. He's a super clever guy, and again, most of the stuff was external to them, from vendors, and they built this thing, and it works, and it's great, AWS, and just the scale of this thing, one of their dev environments, just to load data into it, into this data lake, costs like 10 grand, right? It's mental, the size of it.

Jujhar: And his contract was coming to an end, and he couldn't stay on because of tax reasons, and he refuses to go to permie, because he's an evil contractor. And he was like, "Well, the organization still doesn't know how to use this thing. Like, we've spun this up. The architects have come in, given the spec, and we've created this thing, and it works, and it's pretty impressive. But when I leave, they're going to be stuck." And I said, "Yeah, because their leadership is focused on shipping technology, and not people," right? Whereas the focus should have been on, "Hey, can we create and empower people that can give us a solution?" Instead, what they did is went out to market with a solution, and then asked the market to deliver that solution. The solution was delivered, a box ticked, the boss gets a pat on the back two months before he updates his or her LinkedIn and buggers off to the next company, and now this rather large insurance company have got a platform that nobody knows how to use.

Jujhar: And then the next cycle will come around, and then the next boss will come in, and say, "Yeah, that's been built wrong. Let's buy Snowflake off the shelf, and let's use that instead," and then they're going to spend another couple of million trying to transform that. And the focus, it should always be on your people, and again, how to bring that sort of back to the same conclusion. You've got your people. How do you enable them to be effective? How do you enable them to... You know, okay, "My staff is a level two." How do you get them to level five? What processes should they have in place? How much cognitive load should you give them? You don't want to give them too little, right? Because then they'll be under-stimulated, and they won't be growing and learning. You don't want to give them too much, because then they'll get overloaded and become ineffective.

Anthony: Yeah, you're kind of hitting a nail on the head, which I think a lot of people confuse this as like a millennial thing, that we need to kind of do what we love as opposed to do what we do kind of thing, but I do think it's a change in the way that we view work, because we've now come to the realization that it consumes a lot of our time, and the best thing you can do is doing something that makes you happy, not making money. Making money usually doesn't make you happy at all. I can tell you right now, give me 1,000 bucks, I can tell you a million reasons why it's not going to make me happy. It's pointless, right? To a certain extent. You need to pay bills and stuff, but if your motivation is just to earn money, you're probably going to be incredibly unhappy in whatever job you do. I mean, I just-

Jujhar: You've probably got the wrong-

Anthony: ... guarantee it.

Jujhar: ... type of engineers if they're motivated by purely money.

Anthony: Yeah.

Jujhar: You know, if you look at sort of autonomy, mastery, and purpose, you want to have those engineers that are motivated by mastery and purpose, and give them the autonomy to achieve that. If it's just money, money, money, you're not going to attract the type of talent that feeds off innovation, and if you don't have innovation, if you're a digital organization, well then you're not going to innovate, and companies that don't innovate in the modern age, well they die. So you know, it's as leaders, it's super important that you kind of attract that talent.

Jujhar: I mean, to the other point, that people say, "Oh, these millennials, they don't like doing work, and they only want to do what's..." About the cognitive load thing, well, the challenge is that the cognitive load that you have to have to deliver systems now is... I don't got a number, but I'm just going to make one up, 10X of what it used to be like 20 years ago, when I started. When I started, it was just they had a Linux box, or ASP when I first started, and you upload, and you knew a bit of Microsoft Access, and MySQL, and FTP server, and that was it. That was kind of all you needed, a bit of jQuery, and that's all you needed, and you could be a full stack developer.

Anthony: Yeah.

Jujhar: I know of just... I mean, I've hired engineers all over the world, right? I know of just two who I would actually say, in a modern sense, are full stack, you know, they can go all the way from the CSS all the way down to the operating system level. You know, I jokingly call myself a 2/3 stack developer. I'll take you from the hard disk up to the JSON, but that's as far as I can go. I have no idea about the frontend, mobile, and all the complexity that's there. So I'll take you right to the edge to the CD end, and then that's kind of where I'll leave it.

Jujhar: I just think in modern software development, the cognitive load is absolutely massive, so it's incumbent on us to organize our organization to structure it in a way that gives people success, so they've got just the right amount of cognitive load. And once you find that sweet spot, that balance, your engineering teams are going to start flying, right?

Anthony: Well, I got to tell you... Sorry, I didn't mean to cut you off. Were you going to-

Jujhar: No, no, no. Just use the tools. They're all open source. I want to give back to the sort of community that's got me where I am, and yeah.

Anthony: Yeah, well I mean, to that point, a lot of what we've just spoken about and what we've done is related to several things that you've mentioned. You mentioned the book, “Accelerate,” as a potential recommendation of something as a next step, “Team Topologies” as well. These are all key things we'll include in the show notes, as well as the links to your site, but I think anybody would benefit from incorporating some of the stuff in their day-to-day lives or their jobs today, based on some of the thoughts that we've kind of come up with here, and based off of some of the other areas that we're at.

Anthony: But we have run out of time, unfortunately. Is there anything else you want to give as like a parting word of advice, any other recommendations for things that people can do if they want to get involved in the community?

The importance of diversity in tech

Jujhar: Well, I mean, the big thing is, that I'm a big supporter of, is getting more women into tech. And quite recently, since George Floyd is getting more people of color, now black people specifically, right? Into technology, and I think it's incumbent on all of us to create the opportunities. And you know, anyone who's saying, "Oh, it's really hard," well, you know what? Good things are hard, and at The Economist, we spun up our first all-women's infrastructure team, manager to engineers, and it was a privilege to work with them, and these engineers that I've got to work with, female engineers, just absolutely knock it out of the park. So from a community perspective, everyone please do what you can, and let's get tech more representative of everybody, right? Because until the least of us is represented, none of us are represented fully, so...

Anthony: Yeah. I totally agree with you. I think there should be a lot more diversity. I live in New York, and I live in New York because I love diversity, and I love eating different foods, and seeing different people, and hearing different languages, and stuff like that. That makes me feel alive, and if I can represent that in my workplace in any way, shape, or form, I'm all for that, and making... And it usually does make a great working environment as well.

Jujhar: Absolutely.

Anthony: Yeah.

Jujhar: Absolutely, yeah.

Anthony: Cool. Well, thank you again for your time. We'll duck out today, but I really want to talk to you a little bit more at some point. Maybe we'll do a panel or something, and we'll bring together some interesting perspectives on things, and we'll do that potentially in a later episode. But I do want to thank you for just taking the time so far, and for being so open, and just lending us time to hear about what you do, and how you're impacting technology.

Jujhar: Thanks, Anthony. I appreciate it, and thanks to my employer, Thoughtworks, sort of kindly giving me this time as well, and letting me bring myself to work and be who I be. Really appreciate that. Thank you.

Anthony: Awesome. Thank you so much.

Outro

Annerieke: Thank you so much for listening. We hope you enjoyed it. If you'd like more information about StackState, you can visit stackstate.com and you can also find a written transcript of this episode on our website. So if you prefer to read through what they've said, definitely head over there and also make sure to subscribe if you'd like to receive a notification whenever we launch a new episode. So, until next time.

Subscribe to the StackPod on Spotify or Apple Podcasts .