The Dark Arts Wizard of Quality (With Paul Grossman)

Read The Transcript:

We’re trying out transcribing our podcasts using a software program. Please forgive any typos as the bot isn’t correct 100% of the time.

Intro In digital reality, evolution over revolution prevails. The QA approaches, and techniques that worked yesterday will fail you tomorrow, so free your mind. The automation cyborg has been sent back in time. TED speaker Jonathon Wright's mission is to help you save the future from bad software.

Jonathon Wright Hello, and welcome to the show. Today, I've got Phil Burgess, who's a famous podcaster, so I've got a lot to learn from him. 200 episodes, and he's got a great blog on his LinkedIn profile that talks all about what he's learned from his Energizer IT Career podcast. So, Phil, I'd love to welcome you onto the show, and for the listeners, would you just be able to give us a brief to A, your podcast, and also to what you've been doing in the QA world?

Phil Burgess Sure. So first of all, thank you for inviting me to your show. So talking about the IT Career Energizer podcast, so that's been running about, it's just coming on to its third year anniversary, I think it'll be 250 episodes pretty much around the same time. So the idea behind that particular podcast was to provide individuals who are thinking about coming into the industry, or maybe with a bit of experience, an understanding of what other people have been going through, their sort of career stories, and a bit of sort of highlights trip across what they've done and gleaned from them career tips, and we probably go into a little bit of depth in each one. And then I ask them a little bit about how they became interested in getting into IT themselves and what they would do differently now if that was the case, and so forth. And there's usually quite a bit of conversation around, particularly, what opportunities exist in the industry going forward. So yeah, as I say, 240 I think it is now, and more to come, definitely. It's something I'll probably continue for as long as I feel I can.

Jonathon Wright Yeah, there was some great advice. I binged listened, and it was completely addictive. It literally was half of my afternoon, and there was some really good advice, especially if you don't love your job, you've really got to think about what's best for you and be happy. I think there was some great advice there and actually some top tips as well where people have had bad experiences, good experiences, and a lot of lessons to be learned. I think there's a lot of people who are out there who maybe are in the same role, and they feel a bit restricted, or they feel like they're not really meeting their full potential. So I definitely advise them to listen in. So what's the best way to download the show or at least subscribe?

Phil Burgess Yeah, sure. I'm sure it's very similar to your own. The best way probably is through Apple Podcasts. If you've got an iPhone, you'll find the little sort of pinky-purple app on there, and if you search for IT Career Energizer or just Career Energizer, it should pop up, and you'll be able to download episodes and subscribe. If you're not an Apple person, there are other apps, such as Stitcher. I think Google have now released their new version, which I think is Google Podcasts, but there are all sorts of other ways. There are plenty of podcast streaming apps out there that you can find the podcast on.

Jonathon Wright Excellent. I joke around, the Quality Energy Bunny, and literally you were kind of a non-stop going machine. I was really quite impressed. I've literally learned more than I ever did about podcasting in those six hours. So definitely download the show. What I'm really looking forward to is finding out what you've been up to, because you've been in the industry for over 20 years.

Phil Burgess Yes. Yeah, that's very true. It makes me very old when we say that as well.

Jonathon Wright I must admit I started in the '90s as well, and what I really find now is either I'm referring to it as I started in the last millennium, and this is getting quite concerning really.

Phil Burgess Yeah. I think it's even worse when you start working with people who hadn't been born when your career started. That makes you feel terrible.

Jonathon Wright Gen Z. We talked about them yesterday with Theo. He's a fellow TED speaker, he writes for Forbes magazine, and partly he was kind of interviewing for his podcast series. A twelve-year-old, a futurist, who literally was talking about and started a movement around what the future should look like with technology, and it's unbelievable what the generations are doing now and how they use the technology. When you started, obviously you've got quite a lot of experience from when you did your degree, did you ever think you got involved with doing quality?

Phil Burgess No, to be honest. Just rolling back to when I did my degree, I had absolutely nothing to do with IT whatsoever. So you're talking end of the '80s, and my interest at that time was very much around the property, and I wasn't exactly sure what I wanted to do when I left school, so I took a year out to decide and eventually ended up going to university and doing a degree in building surveying. So completely different to where I ended up, but I think the reason it did happen was going back to that degree was at the time, it was probably very early stages of the desktop computer being around, and the packages that were being used at the time were things like, I'm trying to think back, but things like WordStar and SuperCalc and all these things.

And that began to pique my interest in what was possible with a computer. And obviously doing a degree in something like that, it was very architecturally driven. Things like AutoCad were also coming along more on the mainframes than anything else. And again, I was far more interested in doing those sorts of things than I probably was in the rest of the degree. Eventually, I suppose I was already on my way to a career in the IT industry.

Jonathon Wright In actual fact, I would guess that there's more to do with quality within surveying than there is probably in a standard computing course.

Phil Burgess Well, yes. Yeah, probably going back to that question about quality, so yeah, the importance around quality and things like safety checks and standards and all that sort of stuff is very much embedded within the building and property industry. So there's a lot around, I remember, to throw my mind back now, but yeah, there was a lot of regulation that you had to understand, so quality was a very important aspect of it. So I think yes, presumably that would've given me a nice grounding in understanding the importance and the meaning of quality.

Jonathon Wright Absolutely, and I literally worked for the UK's biggest building construction firm, and they have a platform called COINS, and it's a construction platform, and I guess things have moved on from the WordPerfect days and Lotus 123. But they had for each house, for each property, each plot, they'd have a Bill of Quants, which was ... They'd have 20,000 components that would build a house, they'd have all the plans, they'd have all the blueprints, they'd have all the logistics, they'd have all the suppliers, the brickies, and the timescales. I guess that's probably where did your love for program management kind of come in, or how did you develop this career into program test management?

Phil Burgess Yeah. So I suppose part of the degree was a management aspect to it as well, so that definitely helped, but it wasn't intentional, and I think many of these things tend not to be. So I ended up, after finishing university, deciding that working in the building industry was exactly what I didn't want to do. So it was a case of then trying to decide what it was that did interest me, so I ended up working for a pharmaceutical company not too far from where I was living at the time, and they were doing a system's implementation. It was something very simple in terms of the way they were approaching it. It was to do a parallel run between their old system and the new system, and I got very much involved in doing that in a very manual comparison process. But on the back of that, I got asked by the software company who were implementing the new system to go to them for an interview. And it was from that point that my career began, and that's how I landed my first testing and QA role.

Jonathon Wright And what year was that?

Phil Burgess '94, I think, just thinking back. '93 or '94.

Jonathon Wright So even that methodology you're talking about is what they're using still today. A lot of shadows, what they call shadow, and also digital twitting is where they literally will run a similar system maybe that's running on AI in parallel, and part of that is they'd understand whether or not it's making the same decisions as to the system it's replacing. So it's interesting that the tools and technologies and the approaches that maybe you were kind of familiar with as part of your surveying and your approaches to managing large projects and the complexity around them are transitioned nicely into kind of the QA landscape. So what's that journey been like since starting in that role for the software company?

Phil Burgess I was the first one to undertake that role. At the time, the way the company was set up, they had the consultancy department, who were responsible as well as doing the implementation and customer sides. They were also responsible for making sure that any upgrades to the core system, or more specific modifications, were actually correctly tested, and of course, what ended up being the case was that I spent doing more time with the end client and the implementation and not finding enough time to test the changes that were coming through.

And of course, that was in some ways self-defeating, because all that happened was, of course, as any system is when it's not tested sufficiently, you find issues in production. So they got themselves into that state, and they decided to bring somebody in to work pretty much solely on testing of these modifications and changes and enhancements, and that was me. And I think it was over about a two-year period, it started with me, and we ended up with a team of four. So they understood and saw the consequences, if you like, of a lack of test process in what they were doing.

Jonathon Wright I think that's a great move to this leadership aspect and also the strategy point. I know, like myself, you've had a lot of experience with things like test maturity models. So what's your journey been for how you put processes in place, how you've managed teams?

Phil Burgess So even back then it was a case of really moving into that team leadership role by default because I was the first there, I suppose. My set-up, the ways that I expected things to happen, and we put some very basic processes in place that supported that, and therefore, we had some elements of repeatability and traceability as well, even though I probably didn't really know that's what I was doing at the time. But I think that really progressed, so I stayed there for a couple of years before I decided ... Obviously, I was working for a very small software company. There was a limited opportunity if you want to progress your career beyond what I was doing, and I didn't really want to be a consultant. I did try it for a while, but it did mean driving around the country rather a lot, and I was leaving at silly hours in the morning, getting back late, and I just thought, "This isn't what I want to do."

So this is where it all was strangely changed. I was getting a bit depressed at what I was doing, and I decided what I would need to do is start looking elsewhere to find out what else was out there. I didn't really have a lot of exposure. There wasn't a lot of information out there either about moving around between jobs. It's not like now where you can go onto the Internet pretty much and do a search and see what's available. I think at the time, there was a publication, was it Freelance Informer? Does that ring a bell?

Jonathon Wright It does indeed.

Phil Burgess So I think a friend of mine who was also in the industry lent me a copy, and I just did a bit of a troll through to identify which agencies were out there. And there was one that was located not too far away from me, so I actually decided one day just to go and visit them and walk in the door, which I think they were a bit surprised by. But the consequence of that was they actually had a lead test analyst role available for one of the banks up in Canary Wharf, and they're one of the very first buildings in the Canary Wharf at the time. I moved into that role, and that was just a little completely different way of looking at things. I was probably more embedded in more sort of a larger program than I was within sort of a small software house. It was a bit of a change in that respect. And unfortunately, that was very short-lived.

What happened there was that the software house was effectively part of a larger organization. I won't just go into exactly who it was, but the decision was made to actually set off the software arm of the company to, I think it was, EDS at the time, and the decision of course at that point was they needed to actually trim the resources within the company, particularly middle management layer. So I'd only been there a matter of a few months, and I found out that my boss was being made redundant. He came back from holiday, it was all very unfortunate, he came back from holiday and got called into his manager's office and was told there and then that he was longer required, so a bit of a shock to him. But I decided at that point I could see that there were limitations on what would happen.

It was at that point, I decided that I might like to look at going independent and becoming a contractor, and really, I think it was at that point that my career began to change. I moved to [London 00:15:35] Electricity, and they were doing the 1998 deregulation. So you know now that you can go to pretty much anywhere to choose a supplier to purchase your electricity from. There was a massive program at the end of the '90s across the country to deregulate the industry and enable competition, and it was that point really that my career began to take off. And I moved through different aspects of the program, so then through team leadership into test management, and that was probably over about a six-year period. So that really was where I think I developed my career into a true test management role, and since then, it's been real continual progress. There's never a linear progression to your career, I'm sure you've seen that yourself, but I've managed to sort of navigate my way, I suppose, through different test management roles in different industry sectors as well. I've never been one to stay in one sector.

But eventually, I got the opportunity through a contact to head up a testing department, so it was an insurance underwriting company, who was doing a major implementation. I was contacted thanks to a recommendation by somebody that used to work for me to join or be interviewed and then join this company and then head up their QA and Testing Department. That sort of all leads into the whole TMMi and Assessment process. So a bit of a whistle-stop tour, and that's maybe over 10 years ago I got to that point, but from then, I've had a series of different roles that related between sort of head of testing, test program management, some sort of process improvement activities as well.

Jonathon Wright So I'm guessing wearing multiple hats, I know you have to change how you deliver news when you're either part of the organization or you're external. What kind of tools and techniques did you find were successful? Obviously, you've got things like PRINCE2 on one side of things for you, your program side of things, and then you've got your TMMi and TMM kind of methodologies for testing and also kind of quality. So what kind of patterns did you find were useful to navigate your way through those leadership roles?

Phil Burgess You're right. I think the importance of communication cannot be underestimated, and in particular, understanding the level of communication and the type of communication that you have, for example, with the stakeholder as opposed to somebody who's working alongside you or maybe within your team. They all do vary. So it is understanding what that message or what that stakeholder is most interested in and, therefore, what that message needs to be. I think that was something to learn, and somebody I think you do learn over time.

But for myself, I'm quite a structured person. I do like process a lot and, therefore, the ability to produce meaningful reports from information and statistics, for me, is very helpful, but that's not to say you mustn't be able to present, as well as the raw stats, be able to present a message to a stakeholder in a particular way as opposed to maybe a project manager or somebody working within the test team. So structure, yes, but understanding how to actually provide that information in a way that's meaningful to the end recipient.

Jonathon Wright And I've always found that's maybe one of the most difficult things, because there's a lot of politics, especially if you're in financial services. Part of it is a lot of what is the objective of what you're trying to help them achieve by giving them this information, and you have to really understand what matters to the organization. And I think it's a shame, because a lot of things like PRINCE2, I realize you still can do PRINCE2 foundation, but to be a practitioner, some of those courses are disappearing. You've got some of the new ITIL stuff coming through but really doesn't cover project management in the same kind of way.

For those who are new to TMMi, so TMMi was a great framework of reusable blueprints and design patterns, and the TMMi aspect was kind of more of an independent version of that. I remember the experiment disguise. My good friend, Stefan [Sovakovic 00:20:44], who's also been on the show, loves process as well, and I love the process. I think it gives structure, and I think also what's really important is things like the ISO and those other standards that maybe aren't always pulled in, not anymore, but some organizations have to adhere to them. Did you find that while you're going through to different industry verticals that there's a different viewpoint on quality and what that means for each one of those sectors?

Phil Burgess That is true. So you mentioned Stefan there, Stefan's very much a process guy and very keen to put new ideas and stuff together, so very much a fan of what he's able to do, and having worked with him as well, which does help. In terms of quality, yes, it does vary, and obviously, you've got to throw in considerations about the different industries that it applies to. But obviously, personally I find a quality, or the definition of quality, is one thing that how it applies to the way different companies operate and what's important to them is something different. And we always have to remember it's all about, really, it's about business, it's about how they operate and what their objectives are, and therefore, the quality is aligned to that, so it will be different for each company that you work with.

Jonathon Wright And I guess operating within a framework, like TMMi, and I guess part of that maturity is a really interesting one because as you go into organizations you establish that there are certain levels. So I think the UK, on average, is 2.2 or something, and they may have an objective that they want to get from maybe two to three, and that might be because they're wanting to improve efficiency, they want to reduce waste. There's a goal that's a business kind of orientated goal.

Phil Burgess Yep. I think models are useful. There is this danger, I think, when you apply a model to an organization that it is a bit too black-and-white at times, so it's a bit like a box [inaudible 00:23:03]. If you're able to do X, Y, and Z, therefore you are at this level. But of course, you know what it's like with these assessments. You almost have to tick every box to be graded at a particular level, and I'm not sure that's always appropriate for every organization. So although yes, I'm a fan of the principles, and I think it's really helpful to be able to do that assessment, I'm not sure it's always meaningful when you actually sort of give a company a rating. But that's my opinion. It goes back really, I suppose, to the fact that, as I said, every company has its own objectives and what they want to achieve, and therefore, a level that's appropriate to one company may not be necessary for another.

Jonathon Wright Absolutely, and that's exactly what I've always seen. I always find it really fascinating, because if you look at things like CMMi, NASA back in the '90s was the first company to be hitting that level 5, right, which is an unachievable kind of the goal of the level of process and maturity. Now, they operate at level 3. So with people like SpaceX and their ability to deliver at the same level of quality but faster, the challenge really is how many processes do we need the process saved. And I think that can even potentially go down a level lower in the sense of does that particular team or that particular program of work need that same level of due diligence kind of thing. And I think it can be very flexible.

They do have massive value, but I think there's a lot of people who are probably entering and who are probably listening to this podcast now who were born in the Agile manifesto days with the working software over documentation, maybe misinterpreted the idea that when they set the manifesto, they said, "What the stuff on the left we value more, we still value the stuff on the right as well." There is a hard balance. You must find that now when you're in your kind of field, your current role, that actually how do you manage these global testing functions that say, "How much is enough?"

Phil Burgess Yeah, that's always a tricky one, isn't it? It's always along the lines of the same question isn't it that how do you know when testing is finished or complete? It is very dependent, and of course, we tend to set, as an industry, we tend to set what's the definition of done or what are the exit criteria for particular testing activity. We tend to sort of measure ourselves by setting these criteria upfront. Whether that works, I'm never so sure, because inevitably what will happen we'll end up at the end, and it didn't quite come out as we anticipated, and then we'll make a list of exceptions, and then decide whether we continue or need to revisit and work on it some more before we deliver it.

Jonathon Wright I think that's the expectation, isn't it, around ... Testing used to be kind of an end of the V-model lifecycle, and the time would be always reduced. You'd have more and more pressure on doing more with less. And I think where we kind of pivot this a little bit, and we look at quality gains, and I know you've done quite a lot with quality gains. It's the idea of enforcing a certain quality gain for entry or even exit of a particular phase. Those get blurred when you look at things like DevOps and Agile, and really what is enough? What is the role of a modern program test manager/head of testing? What does your job look like now than what it used to look like?

Phil Burgess Right. Well, it's interesting. I'm actually working on a program right now, which I would say is a bit of throwback in terms of the approach. It is ... Because of the nature of the business, I won't go into, again, who the client is or what it's about, but the nature of the business is it's very, very structured and would have a lot of consequences if it did go wrong, so it's following far more of what you would describe as a PRINCE2 approach. Not exactly a PRINCE2 approach, but it's got far more documentation and far more governance than you would expect, for example, with more of an Agile or DevOps type of Star Delivery.

Right now, I would say from what I'm doing it is very much held by gates and criteria and exception reporting and RAID logs and all those sorts of things. However, working with other companies more recently, I'm sorry, in the recent past, should I say, that definitely changes, and it's more about understanding what the quality of the software is at a given point in time and whether you feel you are ready, for example, to deploy or go live. And I think that is a little bit of a different mindset required, and it's more about, not necessarily taking to drawing a line in the sand, as it were, and whether we can cross it or not, it's more about can we cross it at different parts or different points, and then maybe retrospectively go back and revisit other areas before we then continue?

Jonathon Wright And it's a non-stop activity, isn't it?

Phil Burgess It is.

Jonathon Wright We talk about quality being everyone's responsibility and quality being baked-in from day one from the requirements. I'm going to ask a really controversial question now, but I think you've probably got some really valuable insight into this area. So managing test providers, whether they be onshore, offshore, that's quite, I always found that a real challenge to understand. You get these RAID statuses or you get your RAG status, and it's green, green, green, then it's red. And you've seen things like this happen before, or that there are a hundred tests being run. Well, what do a hundred tests mean? This kind of risk-based approach. They've been automated, but what does that actually mean as far as quality's concerned? How do you find managing third-parties, the best way and any kind of top tips you might have on that?

Phil Burgess Right. Okay. So it is a good point, and I think any test manager who's done this will have either been burnt or experienced pain by trying to manage an offshore provider. I think one of the things that often gets missed within organizations is the understanding that it's not as simple as if we, therefore, offshore a particular function, such as testing, actually we can replace a whole group of people, if you like, with the cheaper resources offshore. Okay, fine, but they still have to be able to deliver the same thing, but also now they're in a different location. There's an additional overhead in managing that relationship.

Then communication becomes a very important factor in that, and for me, and I know this is not necessarily what happens in most organizations, but to me, that all starts right at the beginning with the negotiations and actually drawing up the contract. So I've worked in too many organizations where there will be a contract with an external provider that will define the engagement, including testing, without any real definition of what that means and what deliverables and responsibilities should be. And I think unless you get that agreed and clear upfront, it becomes very difficult to manage that relationship.

I know when we communicated before, we agreed to do the podcast, but we talked about a little bit by email about the importance of key performance indicators as well, and I think that those are almost essential to be part of that contractual engagement. So you've got absolute clarity in what to expect, what sort of reporting you will get, and therefore you've got more understanding of how testing will be progressing, and therefore identify potentially where things aren't going as well as you would expect. So for me, getting that agreement up front as early as possible is so important, but also when you're actually doing it is making sure that you have those channels of communication open all the time, and you have a continual flow of information between the onshore and the offshore teams, for example, to ensure that you don't end up in the position where you do, as you said, go from green one day to red the following day without any chance or warning that it might be the case.

Jonathon Wright Or even any level of protection. There are so many tools out there, and I think tools is obviously a bit of a bugbear. We won't go through too much detail, but I completely agree with the idea around cascading KPIs. I think that's always to me, personally, has been the hardest thing I've ever done, because most of these tools, I'm not going to name and shame any of the vendors, are more project-specific. What's the quality of a particular project? If you look at it a level up and you look at the program, you look at the dependencies of upstream and downstream systems, so a number of projects that have deliverables that impact other projects, you start getting into things like scaled Agile, you're safe. You're doubting it less.

You start getting to the portfolio level, and you start getting the levels of product increments and things like that. And I think that is a really important thing to actually say. When you're looking at the contract, how do you report those KPIs, what's the frequency of that, what's the value of those, what the outcome's got to look like? How do you best track those cascading KPIs, and do you have any tips on things to look at?

Phil Burgess In terms of tracking, obviously reporting is a key part of that, but obviously you can build in potentially two different tools, getting that visibility pretty much on an on-demand basis. So that's obviously one way of doing it. So I missed the other part of the question, so could you repeat that?

Jonathon Wright Yeah. It's that question around ... So cascading KPIs, when you're asking somebody for some information, so you could be saying the results of a test run or a weekly report or maybe even a quarterly report, there's information in there which is incredibly valuable. Things like the RAID log, things like a [inaudible 00:34:36] for who's responsible and accountable for what, and how that goes through the different formalized quality gates. What is the minimum documentation or the evidence that you need to see? What's does that look like in sort of these organizations that you work for?

Phil Burgess And yeah, normally, from what I've put in place myself, it tends to be driven by an old-fashioned test panel, some sort of test engagement model that would exist, and therefore, that's predefined, so we'd expect reporting to be produced, as you say, even maybe daily. If it's an execution, for example, daily or weekly, defect tracking being a very important aspect of that. But also you want to maybe track the engagement across multiple programs and projects as well, which would potentially be done on a monthly basis. And as you say, things like RAID logs are so important to that and being able to actually manage that, not just the fact that it's a report that's being received, but you have some sort of engagement to ensure that that report is understood, as much as anything else. So the importance of producing a report is all very well, as long as it's actually consumed and understood and, therefore, becomes meaningful to the recipients.

Jonathon Wright Absolutely. There are so many times that I've seen people pass the information on without adding anything to it. I call these people proxies, but this could be a project manager, it could be a PMO resource where they'll take some raw data without doing any real analysis on it, and then they'll just pass it on, so they're just a proxy, they're just taking data and then passing through without adding anything to it. And I think we joke about things like, "Well, companies are run on spreadsheets," but it's amazing the amount of information that you can get from a Power Pivot these days or a VLOOKUP. I'm sure there are organizations that are just run on these.

And then, as you said, defect prediction or even understanding what that's looking like, and also those estimates around time. Being topical with the new IR35 coming through, a lot of the contracts are changing to become more outcome-based, and I actually think this is quite a good thing. Instead of saying, "We're going to have a resource for six months," we don't really know what we're going to be doing for the next six months, depending on the project [inaudible 00:37:07], right? But we know that they've got to provide a particular service to a certain of the quality, and they can deliver that within whatever period of time as long as the outcome is achieved. Do you see this being more outcome-driven going forwards?

Phil Burgess I think so. I've always been a fan of making sure that deliverables are specified, particularly when it comes to third-party delivery. But I think the quality of the outcome, I think that is an important factor. I hadn't heard of that from an IR35 perspective, but that's interesting. And I think that that is a potential measure that could be introduced there, but certainly, one that you should be monitoring if you're doing and managing a third-party delivery.

Jonathon Wright Sure. And I'm going to backtrack a little bit because ... What kind of tips do you have for people who are trying to start off on the leadership side of things? What kind of good resources do you find are incredibly valuable to you?

Phil Burgess Sure. So I think this is one of these things that companies don't necessarily always focus a lot of energy or input into, so they tend to promote people from within, if possible, which is a good thing. But there's often not that much support in enabling people to understand what the needs are of maybe moving into a leadership role because it is different. It's definitely a different view or mindset, if you like, in terms of what you're trying to do. So obviously, if you're an individual, and you're focused on what you need to do, you're worried about maybe working with your team, but it's really about what you're delivering and how you're delivering up to your team leader or manager. When you move into more of a management or team leadership role, you've then got to consider the wider implications of what you're doing, how you're leading the team and the individuals within the team.

I think one of the things that people don't necessarily understand is that you need to think about the entire picture if you like. I'm just trying to think of the right way of describing it. How do you make sure, for example, that your whole team is working effectively together, and how do you make sure that they understand from you what your expectations are, but how do you also ensure that you provide the ability for them to deliver what they need to for you? So it's not just about direction, that's part of it, but it's also about enabling and listening and dealing with issues and unblocking problems and all these sorts of other things that have to be considered. But I think one of the skills that's part of that is being able to listen and spending time with people within your team to understand the way they work, so you can get the best out of your team as a whole.

Jonathon Wright So this could even be down the Myers-Briggs kind of landscape of trying to understand those stakeholders and how they take and interpret data, how they want data to be provided to them as far as reports, what formats work with them.

Phil Burgess Yeah. So it is bi-directional. It is up and down, and obviously, when you move up, that sort of communication will change as well. So you have to understand how to communicate and provide the information that people at different levels require.

Jonathon Wright It's so fascinating. We could definitely talk about this all day, but what's the best way for people to reach out to you if they've got questions or they want to subscribe to your podcast and blog? What's the best way to get you?

Phil Burgess So probably the easiest way to find me would be on LinkedIn. I'm pretty easy to find. I think you'll find me if you look up Phil Burgess. There I'll pop up I'm sure. In terms of the podcast, there's a website, which is itcareerenergizer.com. You can contact me there. You can find out about the episodes that are online. I'm also on Twitter, @philtechcareer. Yeah, they're probably the easiest ways, and if you want to subscribe to the podcast, either through your Apple Podcast, Stitcher, whoever it might be, just go on, find the podcast, and click Subscribe.

Jonathon Wright Fantastic. Well, thanks so much for being part of the show, and there are some really useful tips. And what we'll do is I'll add those links to the actual show information, and we'll make sure that people can contact you and reach out.

Phil Burgess Yeah, great. Excellent. Thank you so much for having me on the show.

Jonathon Wright Thanks, Phil, and thanks to your amazing podcast on the IT Career Energizer.