Crossing the Feedback Chasm - a Conversation with Ken Finnigan

Transcript

Michael Stiefel: Welcome to the Architects Podcast where we discuss what it means to be an architect and how architects actually do their job. Today's guest is Ken Finnigan. He's been a consultant and software engineer for over 25 years with enterprises throughout the world. He's presented on distributed tracing, microservices and other related topics,at conferences like CodeOne, JavaOne, Red Hat Summit, and DevOps UK among many others. He's a founder and member of the Common House Foundation, which helps open source to be sustainable.

And in addition to all that, Ken has found the time to be an author of several books including Reactive Systems in Java, Kubernetes Native Microservices with Quarkus and MicroProfile and Enterprise Java Microservices. I've written several books, I've written two, and those are hard enough, so I can imagine what it was like to do all of those.

How Did You Become an Architect? [01:42]

It's great to have you here in the podcast, and I'd like to start out by asking you, were you trained as an architect? How did you become an architect? Because it's not like you woke up one morning and said, today I want to be an architect, and were one.

Ken Finnigan: Well, first off, thank you very much for having me on, Michael. It's great to chat. Well, it's funny you say that in terms of you weren't trained to be one. I almost did for a while, but the different kind of architect. When I was in high school I did work experience at an architecture firm. It was only for a week, but the whole time I was there, I basically spent it copying architectural drawings onto tracings and stuff, and it was like, "This is boring. I don't want to do this".

Michael Stiefel: Well, it was like when I was an undergraduate, I took a computer operating system course and I decided, this is boring. I never want to have anything to do with computers ever again.

Ken Finnigan: Yes. But to get back to your question, I guess I never really thought of being an architect, and I certainly started as just an engineer at the time working on mainframes for IBM many, many moons ago, and I think it was somewhat of a natural progression over the years of working on projects, then moving into leading those projects and leading teams, and then that kind of naturally led to the next step up of being an architect.

Different Types of Architects [03:11]

But it's also interesting because I've been different kinds of architects as well. I've been architects over a single or a couple of products that were very implementation heavy, and then I've also been enterprise architects for banks in the UK and it was very much a centralized architecture group where you reviewed plans of all the teams, made sure that they were aligning, and you didn't write any code. You just kind of helped people fit the jigsaw pieces together.

Michael Stiefel: And I hope you were, shall we say not resented too much for that role?

Ken Finnigan: No, they'd had a very large enterprise architecture group at Lloyd's and it was probably at least 50, 60 enterprise architects. So it was not resented and it was understood. Sometimes there was certainly some pushback of like, "Oh, why do we have to do it this way?" Particularly as we had a lot of governance and data standards that need to be adhered to some that were kind of financial regulation based, but others that were a lot of this is the way the bank does things, this is the way they always do them. You need to follow those rules.

Enterprise Architecture in Highly Regulated Companies [04:19]

Michael Stiefel: Yes. I've done some work for financial services firms and they can be quite frustrating sometimes.

Ken Finnigan: Yes, definitely.

Michael Stiefel: Especially when the people who work at the bank, even in the software, are used to doing certain things and the world changes on them and it's not always the most fun thing in the world to do.

Ken Finnigan: No, not really. And I've worked at banks for many years, 20 odd years ago, and it was very much a case of, for the most part, it's even still true today that they are usually five to 10 years behind anything else in the industry. So it doesn't make for a very always fun and enjoyable thing because working on fairly outdated tech most of the time, but it's certainly a good place to learn the ropes, get some experience, have an understanding of more of the fundamentals and less about what's cool in tech.

Michael Stiefel: Yes. Although I do remember one time when the company I was working for, shall remain nameless, had to go to 24 hour a day trading because their trading platform was a batch system that counted on the fact that you could shut down at night to run all the trades.

Ken Finnigan: Oh wow.

Michael Stiefel: So sometimes even in the financial services industry, they get kicked in the pants and have to move on.

Ken Finnigan: Yes. No, I've definitely been involved in some of those projects too over the years, but usually it's in a very almost kicking and screaming kind of way that they're brought into the modern world. Sometimes you're lucky and you have some leadership folks that are more forward-thinking and into bringing that more modern tech into a banking environment, but it's also done very carefully to ensure that any risk is extremely minimal, which is understandable. They can't afford to go down for extended periods. So yes, it's one of the reasons in many respects, I'm kind of like, "I'm not sure I want to be in the medical field in software" because to me that kind of feels like you got people's lives in your hand kind of situation.

Michael Stiefel: I will tell you a story along those lines. Many, many years ago I did a project where I was writing tests for some medical equipment, and several years later I was in my doctor's office and had a procedure done and he brought out the equipment that I had been working on and I said to myself, "This is what mission-critical software is, iIt's when my health is on the line.

Ken Finnigan: No, exactly. I think that's something that's always give credit to those who do that kind of work because I can't imagine that it's unstressful on a regular basis knowing that if you get this testing wrong, someone could have serious consequences.

Michael Stiefel: And also they have the same problem with rigidity because I remember another project I worked for in the medical field, I had to get some fax software to work because the regulatory process was certified with faxes-

Ken Finnigan: Oh Jesus. Wow.

Michael Stiefel: ... even though society had gone way beyond faxes.

Ken Finnigan: Wow, that's funny.

Michael Stiefel: And it was interesting because I think I had to get a SOAP protocol working over a fax.

Ken Finnigan: That doesn't sound like fun.

What is the Feedback Chasm? [07:41]

Michael Stiefel: No, it wasn't. Anyway, you have written about something that I find interesting and something that we don't talk about enough in software. It is a little different from what we usually talk about here because it's not directly related to actually building systems, but on the other hand, I don't think you can truly build a system without acknowledging the fact that we have something that you can call the feedback chasm.

Ken Finnigan: Yes.

Michael Stiefel: And I think if we don't at least try to bridge that chasm, it's going to interfere with the effectiveness of being a developer, and the effectiveness of being an architect, and the effectiveness of actually just building the system. So why don't you try to explain exactly what the feedback chasm is and why it can be so devastating?

Ken Finnigan: Sure. So currently kind of in the process of a job search myself right now, it's something I've certainly experienced, so it definitely came to mind, but I'm pretty sure I've had the similar problem in the past as well. It's not a new thing. So the feedback chasm is essentially highlighting a gap between the feedback you receive from your current role or organization, whether it's from your manager, skip level managers, your peers, mentors, whoever it might be, they are very much going to be providing feedback that is focused to the role you have now, the org you have now, and to help you improve and take steps up on that ladder, whatever that might be in that organization.

So it's very good to help you grow in that organization and the roles that they have in that organization. The gap and the chasm comes into play when you start then looking for future opportunities at different employers and needing to understand what they're looking for in the characteristics and traits. I'm not really focused on the skills side of thing, it's more characteristics and traits, but skills can play a part, that they're looking for when they're going through the hiring process, whether it be chatting with the hiring manager, the technical interviews. I know a lot of organizations have what they call behavioral style interviews where they really get into your history and how you explain things and whether you do it well and really analyzing you as a person and how you communicate.

Now in those interviewing situations, most of the time I found that you don't really get any feedback from that process. You may get small comments here or there, but usually it's more to do with technical interviews of you didn't know these algorithms or you weren't quite fast enough in getting to that conclusion or you didn't explain yourself what you were thinking because that's always the challenge with technical interviews is, having to think aloud and explain what you're thinking. So that kind of feedback can often happen, but it's very small and not very forthcoming in terms of you being able to grow and expand your skills and traits and characteristics into something that could in the future land that role.

So that's the chasm between the feedback you get in your current role versus what you need when you're interviewing at places to say, okay, what am I missing as a person that meant I didn't get that role. And I feel like we're doing engineers in the industry a disservice by not providing that feedback simply because it really narrows down our growth opportunities as an engineer or architect or whatever it might be to the company you're in and hopefully finding a company that is looking for similar things. Because if you come across a company that's looking for something different, you are more likely to hit that chasm of you don't have that knowledge or experience or characteristics they're looking for that they'll be interested in you.

Michael Stiefel: I want to ask this sort of a clarifying question.

Ken Finnigan: Sure.

Different Types of Feedback Chasms [11:54]

Michael Stiefel: You mentioned that in terms of looking for a new position at a different company, but couldn’t that also happen if you're trying to make a lateral transfer in the same company or explore a different opportunity in the same company?

Ken Finnigan: I think it could because if all the feedback you've been receiving in your current role is focused on a particular path at that organization, so for example, if you're going from an IC kind of position to a manager position or a technical position to more of a product manager kind of role, then yes, I think the same thing would apply in terms of the feedback you've gotten for that IC role isn't necessarily applicable to either a manager or a product manager role. So you need to start from scratch again in terms of what am I missing to be able to make this a success?

Michael Stiefel: I sometimes think even within trying to allow transfer, the company sometimes often doesn't want to give you that feedback because it also wants to keep you in a certain role.

Ken Finnigan: Yes, there is that challenge certainly found over the years, and I've read many stories online about this as well, is that there are some really great managers out there who whether you stay with them or you go somewhere else they just want to see you grow and succeed and they are the ones that will help you with this kind of problem irrespective of if it means you leaving them at some point in the future. But then to add to your point, there are also lots of managers out there who are really focused on their own org and certainly want to help you grow, but maybe not so much that you end up leaving.

Michael Stiefel: Yes, I mean sometimes it may be the manager above the manager that has put such pressure on that manager, so maybe they would like you to grow but it's not in their narrow self-interest to get you to grow.

Ken Finnigan: That is very true as well. In particularly a lateral move kind of situation your direct manager doesn't usually have a lot of say over whether that can happen. It's usually several layers up that something like that would have to be agreed.

A Thought Experiment on Delivering Effective Feedback [14:07]

Michael Stiefel: So let's run a little thought experiment. You sort of hinted on what is effective feedback. So pretend you're interviewing me for a job and you want to give me effective feedback or you're interviewing for a job and I have to give you effective feedback. What would you expect to hear? I mean we can answer that question on several dimensions. One is purely content. The other is in terms of how the information is delivered. Because very often how it gets delivered can be just as important as, for example, if somebody says to you, you lack A, B, C, D skills, but we can help you remedy that as opposed to you don't have A, B, C, D skills and goodbye. How would you in your ideal scenario,I know it's a little vague so you can play with it as you think would be more helpful, how would you deliver that effective feedback?

Ken Finnigan: You make a good point there in terms of it's not just the feedback you're providing, but it's how you're providing it will have an impact. In terms of what feedback to provide. It could be any number of things. It could be as simple as you need to work on this technical skill because we found you didn't understand or maybe putting it this way is, you weren't able to effectively communicate your understanding of this particular facet of an algorithm or whatever it might be in some kind of fundamental piece. So that could lead to either actually you don't have that skill and need to improve or it's just you didn't do a very good job of explaining you do know and getting that across to the interviewers.

Michael Stiefel: And that's certainly under the pressure of an interview I'm sure

Ken Finnigan: The time crunch on interviews is usually insane. And trying to answer the questions and do it in a thoughtful way and trying to understand what might be coming next so you can prepare yourself it's definitely a very stressful situation. And then in terms of how you give that feedback, I think definitely doing it in a way that says these are things we think you need to work on and for internal it would be a will I be able to help you work on these to fill that gap so that you can get to that role at some point in the future. For an external company I would see it as a if you work on these things, we'd love to hear from you again and have another shot at seeing whether you're a fit in the future and see how you've grown in that time

Michael Stiefel: Listening to you there are two thoughts that come to mind and they're somewhat divergent. One of them is that sometimes I'm surprised, I haven't interviewed in a long time, but sometimes I’m surprised how ill-prepared the interviewer is. It's never very often clearly communicated to you what they're looking for.

Ken Finnigan: No, that is very true as well. And that can certainly put the candidate on the back foot in terms of what they're expecting. I actually had that kind of situation a couple of weeks back where I was going through a process with a company and was going to meet with the hiring manager so I naturally assumed that was going to be more a general discussion of what the role is, what my experience is, what they're looking for, all that kind of stuff. And it turned into a very technical interview dealing with networking protocols and all sorts of stuff like that, and I was completely unprepared for that level of a technical discussion. So that is true. Companies need to be very clear about the kind of interview it is, and what the candidate can expect. If there's a mismatch there, then that can increase people's anxiety and stress levels before they've even answered anything.

Michael Stiefel: And you're not going to get useful feedback from that because you weren't prepared. So to tell you, for example, you didn't know network protocol A, B, C, well, you might've known it if you had prepped for it.

Ken Finnigan: Right.

The Art of Asking the Right Questions [18:31]

Michael Stiefel: Yes, that's the other thing. Sometimes I think companies do ask the wrong questions, which leads me to the other part of the feedback chasm is I often wonder if people who either present themselves in an interview or what companies are looking for is they confuse general ability, malleability, the ability to grow, the ability to learn on your own with someone who knows X, Y, Z fact. And you may get someone who knows X, Y, Z fact, and that may help in the first six months of the job, but then that person is going to be not very helpful to you as you grow. And how do you communicate that to a company? If you do get feedback, and sometimes you do get the interview because you can look at the interviewer. In other words, how do you from your end narrow the chasm by helping the person who's interviewing see that you're a stronger candidate than you actually might be.

Ken Finnigan: Well I think that gets to your point in terms of you need to get across to the interviewer that you are malleable, you are willing to learn and grow, you're not of a fixed mindset in terms of what you know. And you can do that by providing examples to them of times where you started on a project and you didn't know a particular technology or tool or whatever it might be, and within whatever the time frame might be, three, six months, you became knowledgeable enough in that tool or language or whatever it might be to be extremely effective on the project and timelines weren't missed and things like that even though at the beginning you didn't know the tool, but you are able to transfer the knowledge you have from previous tools, languages, whatever it might be, and apply that to something new.

Feedback is a Two Way Street [20:33]

Michael Stiefel: Because I think perhaps sometimes you don't get the feedback because you don't communicate that you're open to feedback. In other words, if you have this chasm, there are two ways to bridge the chasm and maybe both so you could meet in the middle. I don't know if that's viable or not.

Ken Finnigan: That's an interesting question that I know from my experience, I'm often asking for feedback of the HR person after the fact saying, "Yes, I'd love to have any feedback", blah, blah, blah. But maybe it's something you actually need to be asking at the end of an interview process with the person being saying, "I don't know what your policies are on this, but I would love to hear any feedback about how I can improve for the future".

Michael Stiefel: Sometimes I think, and this goes if bridging the gap, the person who's being interviewed doesn't realize that they can be interviewing the company at the same time the company's interviewing you and that also perhaps is another way of bridging the chasm because you're being a little proactive and asking them questions.

Ken Finnigan: Yes, I know they usually allow five to 10 minutes at the end for you to ask questions of them, but often that ends up being a kind of pro forma how do you like working here kind of thing.

Michael Stiefel: Right, but for example, I'm just thinking off the top, suppose someone asks you to design something on the fly, you can ask them questions converted into a sort of design session where it's not just you presenting, but you ask them questions, you see how they respond, maybe to give you feedback on your ideas. You can make it into a two-way street.

Ken Finnigan: Yes, and you can certainly utilize that kind of opportunity to, as you say, in a system design kind of interview if they're asking you to design some kind of system that maybe they've actually already built themselves. You can frame your answer in a way where you're saying, knowing these X assumptions, this is what I think I’d do, but I'd be curious to hear whether those assumptions fit what you've experienced or how they differ and go from there.

Michael Stiefel: Yes. I remember one time a client asked me to interview for an architect position and basically what I did is I created a problem, it was an open-ended problem, and I expected interaction between myself and the potential architect. And what was interesting, of course, was the manager was also in the room observing the interview.

Ken Finnigan: Oh boy.

Michael Stiefel: And he found it interesting because he didn't participate, but ultimately he would've been the manager for the architect that got chosen. So he had the ability to observe, but there was an interaction there where it was not just a one way street and we could get a feel and we could give feedback.

Ken Finnigan: No, I think that's definitely important is that interviews aren't a one way street. And I know for candidates it can be difficult to make that happen because you're in an environment and situation where it's like you are wanting to progress and wanting to say the right things, so you kind of don't want to ruffle feathers or anything like that. So it can be challenging to try and make it a two-way street, but I think you're right that if you can, even in some small way, that is probably more meaningful than just answering things back to them the whole time.

Michael Stiefel: And you may find out that if they don't want to give you feedback, maybe you really don't want to work for this company or this person.

Ken Finnigan: That is true, yes. And I think that's definitely a key piece with interviews for people is trying to get an understanding of whether the company they're interviewing at and somewhere they actually want to work. Granted, it's very difficult to do that in an interview scenario because-

Michael Stiefel: Especially at the lower levels.

Ken Finnigan: Yes.

Michael Stiefel: At the higher levels it's a little easier.

Asking Interesting Questions [24:32]

Ken Finnigan: But yes, certainly at the low levels you're dealing with someone that it's terrible to say but on their best behavior as they're interviewing you so it's like I've taken to asking interesting questions or trying to ask interesting questions, and one of the ones I use is what didn't you know before joining this company that you would've liked to have known?

Michael Stiefel: Yes.

Ken Finnigan: And I always say it doesn't have to be bad, it can be good as well it's like, but I'm just curious, what did you find out after the fact?

Michael Stiefel: Yes, I think that's an excellent question. I remember using that one back in the day, but I think that's a really, really good arrow to have in your quiver in order to at least get some sort of feedback out of somebody.

Ken Finnigan: Right. And I think it's a good one because it's not one people typically expect to get from a candidate so they're less likely to have some kind of canned answer already prepared, so you get a better sense of how they feel about things.

Seeking Feedback [25:30]

Michael Stiefel: Yes. So I'd like to switch gears a little bit because we've been focusing on the difficulty of getting feedback in a particular situation, but maybe you can look for feedback elsewhere. In other words, we've talked about situational feedback chasms, but suppose you truly are facing a feedback chasm either in your current job or in your job search. I mean feedback is almost a gift and maybe you can get this gift from a mentor someplace else or some other place where you seek out maybe someone else in a similar situation that can help you bridge this chasm.

Ken Finnigan: Yes, I think it's definitely important to have mentors outside the organization you're currently working in, whether that's people that were former colleagues at previous companies or whether they're people you've met through user groups or conferences or met online or whatever it might be. Or to your point, people who are also going through a solo interview process either with the same company or different companies to be able to share experiences, how they've handled particular situations. I think that's very important. You can often get yourself into an echo chamber of feedback from one particular group, and if you don't go outside that you never get someone saying, "Oh, hey, I think you need to work on this because that's what a lot of companies are looking for these days".

Michael Stiefel: I think your statement about not getting trapped in one group is a good one because there is an old saying of Mark Twain, a cat that learns not to sit on a hot stove also learns not to sit on a cold stove. Because someone can be burned, someone have bad experiences and they see the world just through those experiences. For example, if someone said to you, "Well, I've tried to bridge the feedback chasm and I've felt, and you'll never do it". You don't want to get trapped by that kind of situation.

Ken Finnigan: Yes, everyone's experience is different and just because one person had issues and was unable to bridge that chasm, or even were unable to get feedback from an organization doesn't mean you won't.

Michael Stiefel: Well, it also sounds like what you're also suggesting, which is just general good advice, go to groups, talk to people, network not only for jobs, but also experiences.

Ken Finnigan: Yes, it's definitely a case of, and this is something I was terrible at early on in my career was, I missed the importance of networking, and to your point, not just to find jobs, but to meet people who are doing similar things to you, doing different things to you. Just learning what's out there because sometimes the deluge of new tech through media and whatever else we consume it with can be challenging in terms of, well, what should I learn next? So sometimes it can be very helpful to go to conferences and meet people and hear what they're doing and be like, "Okay, that sounds interesting. I might want to look into that".

Michael Stiefel: Yes.

Ken Finnigan: And then you've also got to contact potentially to say, "O, I'm having a problem with this. Can you help me understand it?"

Michael Stiefel: I'll give you an example. Then of course I was an independent consultant for a long period of time, and I remember one time chatting with somebody on the bus that we were taking from the airport to the hotel and we were talking, and we exchanged information, and two years later, ironically I was in the meeting with another client, he calls up and says, "You can help me". So why don't we talk about it? So you never know what's going to pay off.

Ken Finnigan: No.

Offering Help or Feedback Without Expecting a Quid Pro Quo [29:33]

Michael Stiefel: And I think when you network not with the immediate idea of getting a job, it's likely to increase your odds of getting a job because people don't feel used.

Ken Finnigan: Yes. And in the job search I'm going through right now, it's always been a challenge is I don't want to be really hitting people on LinkedIn that I'm connected with, be like, "Hey, do you have a job?" Blah, blah, blah. It's just like I'm not that kind of person that's like... And you want people to not feel like you're just using them for a job and you're actually interested in what they're doing and what they're experiencing and all that kind of stuff.

Michael Stiefel: I mean, especially if I think you also help someone else and therefore you've shown them in the past that you've not been looking for an immediate payoff, they're more likely to help.

Ken Finnigan: Definitely. I think, and I'm maybe a little corny to say, but it kind of ties back into getting back to being more of a giving culture rather than taking one and whatever comes your way, comes your way, and if you're always trying to take you're never going to get anywhere.

Michael Stiefel: Well, just because it sounds a little corny doesn't mean it's not true. And sometimes it sounds corny because it's obvious and we take it for granted, but I think being out there being helpful is definitely something that will pay dividends.

Ken Finnigan: And I think to a large extent that's why I love open source so much is that it's very much, I wouldn't say completely, but for the most part, those in open source are definitely there for the giving and sharing and they're not there to take anything. Maybe the company's taking advantage of the open source stuff without paying, but that's what companies do.

Michael Stiefel: But that's another dimension. I mean, the discussion about open source is an entirely different one, but to the point that you're making, it's an environment where people want to help people and people want to donate. Again, you could argue about the efficacy of that and the profitability of that and all that, but that's not the discussion we're having. In the discussion we're having it's a very giving place.

Ken Finnigan: And I think also just thinking of it now that's potentially one way to bridge the chasm. If an organization you're interested in has open source projects that they run and manage is to get involved with those projects, contribute to those projects, then that's a way of getting known by those who work on the projects at the company. And that's how I ended up with one of my first jobs at Red Hat was through working in open source before I even worked for Red Hat. And that was how they got to know me through that.

Michael Stiefel: And they could see the quality of your work.

Ken Finnigan: Yes, exactly.

Feedback Must Be Timely [32:23]

Michael Stiefel: So actually that raises a very, very interesting question because they talk about the quality of the work. I think there's another feedback chasm and that exists with the work that you're doing now. And I saw this very much so as an independent consultant because I used to tell people, if there's a problem with what I'm doing, tell me now, don't wait two months when it's too late or too expensive to fix the problem. I think there are two parts of the chasm. Because when we think of this feedback chasm we think in spatial terms, there's this two sides of a mountain and there's this gap in between, but there's also a temporal feedback chasm where you do get the feedback, but you don't get it at the right time.

Ken Finnigan: That's very true. It can often be the case with performance reviews. If they're only performed annually at the current company it's like A, first of all, you're often trying to remember things that happened 10 to 12 months ago. And then B, you get feedback on those and then you're like, "Okay, I'm not really sure how to apply that now because I can't go back and change anything that's already happened". It's like maybe I can use that going forward, but the timeliness of that feedback is another key aspect. Feedback today is 10 times more valuable than feedback in the future?

Michael Stiefel: Yes, there's a time value to feedback. Well, feedback in some sense is money. And maybe if companies started it that way they would maybe have a little different attitude towards it.

Ken Finnigan: Maybe. It's funny you say it's like money because I just said the thought of it's like investing.

Michael Stiefel: Yes.

Ken Finnigan: You get better returns by putting things in earlier.

Michael Stiefel: Yes. I mean, I get it that there's sometimes for legal reasons people have been burnt and they don't want to receive feedback, but certainly inside a company, the feedback chasm exists both in space and time. And I think if people would think of it in terms of ROI, maybe they would have a little different attitude towards it.

Ken Finnigan: Yes, and certainly for the feedback chasm that's internal to it all there's really no need to have it.

Michael Stiefel: Yes.

Ken Finnigan: It's like it shouldn't be there at all. You should be able to get feedback from your managers or peers whenever you need it or whenever they see something that requires feedback.

Michael Stiefel: Yes. I mean, theoretically Agile is trying to solve that problem, but I don't think it's been completely successful in solving that well.

Ken Finnigan: No, I think it tries to solve one set of problems and maybe creates a whole other set.

Michael Stiefel: Yes, well that's the engineering life where is the old joke about pick two out of three.

Ken Finnigan: Yes. Yes.

Michael Stiefel: Is there anything else that comes to mind about the feedback chasm that we haven't touched on?

Managers Must Understand that Good Feedback Improves ROI [35:20]

Ken Finnigan: I think we've touched on pretty much most of it, but I just want to hammer again that this feedback chasm, whether internal or external does really impact people's opportunity for growth and learning.

Michael Stiefel: And which means it impacts company's ability to be better.

Ken Finnigan: Yes.

Michael Stiefel: I want to come back to this ROI thing because very often managers, this is touchy-feely, this feedback thing. This is human, this doesn't make any sense, but when you point out to them that it actually makes dollars and cents different somehow that changes their attitude.

Ken Finnigan: Yes. It also highlights the growing importance of soft skills in the engineering world today. It's not just about what you can do technically, and it's like if you are unable or unwilling or uninterested to also provide feedback to others and receive feedback and certainly don't have to act on it if you feel like it doesn't apply for some reason-

Michael Stiefel: Well, that's a good point too.

Ken Finnigan: ... that's your choice.

Accepting Feedback is Optional [36:22]

Michael Stiefel: Yes. I mean that is a good point. That just because you get feedback, there's no obligation to act on it because you could think the feedback is wrong.

Ken Finnigan: And maybe it is, and maybe they have a biased opinion, you just don't know, but you certainly want to be open to it. What you do with it is then entirely up to you.

Michael Stiefel: Yes. All right. So I found this interesting, and I hope the listeners find it interesting too and think of ways that they can explain the importance of this to their team and the people who do the interviews because I think you'll wind up with a better class of people if you're capable of doing this.

Ken Finnigan: Definitely.

The Architect’s Questionnaire [37:02]

Michael Stiefel: And people will be capable of growing. So now I get to the part of the podcast, it's always fun for me. I have my architect's questionnaire, which I like to ask because to me it also sort of personalizes it and gets different people's perspectives on architecture. And what's your favorite part of being an architect?

Ken Finnigan: I think it's really being involved at the early stages of something and being able to set the direction of a product or a change in technical strategy and really having a say in the direction of things. A lot of times as an individual contributor you're just handed down, we're doing this, and it's like, "Oh, okay". But when you're an architect most of the time, not always, most of the time you're actually involved in those discussions around planning what's next, what the strategy is, the direction of things. So it's kind of nice to be able to have some level of autonomy over where you're going with things as opposed to just being told this is what's happening.

Michael Stiefel: Conversely, what's your least favorite part of being an architect?

Ken Finnigan: I guess it's kind of a twin to my favorite bit in that it's the actual effort to get some new initiative going is often so time-consuming to be able to get everyone on board with A, what it is that is going to be done, how it's going to be done, and then to get the necessary buy-in from leadership. That can take a very long time. There can be a lot of inertia to overcome to make something happen and particularly if it's very different from the current status quo in an organization.

Michael Stiefel: Especially if you've said you've had a lot of experience with financial institutions.

Ken Finnigan: Yes. That is always a very slow process. 20 years ago I was involved in planning the migration from when Lloyds TSB bought HBOS in the UK. We planned that migration for like 18 months to two years before it actually happened. It was a huge lead up to ensure everything went smoothly on the day. I think we had six or seven dry runs of the data on different weekends mimicking what we were going to do on the day and measuring what didn't work, what did work, and what needs to be fixed. It can be a lot of fun, but it can also be very time-consuming.

Michael Stiefel: Yes. Yes. Especially if you did it 40 times and then on the 41st time something goes haywire.

Ken Finnigan: Then you have people just say, "Oh, if we'd only done it two more times we would've found out that problem".

Michael Stiefel: Yes. Or if we hadn't done it.

Ken Finnigan: Yes, if we'd only done it 20, we would've never hit that problem.

Michael Stiefel: Is there anything creatively, spiritually or emotionally, about architecture or being an architect?

Ken Finnigan: I think there is to a certain extent because you can almost equate it to bringing life to something, whether it's a new system or a new way of doing something. Even if it's just a process change it's essentially bringing new life into the world from nothing, and you're trying to use your brain, everyone else's brain to come up with what's the best piece of life we can create at this point in time.

Michael Stiefel: I know that that can be quite rough when you do that. What turns you off about architecture or being an architect?

Ken Finnigan: Oh, I think probably the biggest thing is the number of meetings that you're usually expected to be in. I know that's kind of the double-edged sword of being an architect is that you need to be working cross-functionally so that often means more meetings with different groups, as well as the groups that you are kind of overseeing things for as well. But I try and make sure that those meetings are only as long as they need to be, have clear agendas and when that agenda is complete or the main goal of the meeting is complete, it's done. We don't dilly-dally around for another 20 minutes for no reason, taking up people's time.

Michael Stiefel: Do you have any favorite technologies?

Ken Finnigan: I have a few. Having worked with it for 25, 26 years now, I really love Java. It wasn't my first modern programming language, but it was certainly one of them and it's one I've used the most over the years, so I certainly favor that. But I've also been having fun recently with React, doing some mobile development, so that's been interesting to get more into that world. Kind of dabbled in the front end side over the years to actually build something that people can use is a lot of fun.

Michael Stiefel: What about architecture do you love?

Ken Finnigan: Solving the challenges of optimizing an architecture for business use cases and doing it in a way that hopefully makes the customers happy as well, because always that difference between what the business wants and what actually makes the customers happy. So you hopefully achieve both, but not always.

Michael Stiefel: Yes, and especially if you've been a technologist and you have to say this tech launch would be fine if it wasn't for these nasty customers.

Ken Finnigan: Yes, indeed.

Michael Stiefel: What about architecture do you hate?

Ken Finnigan: I think the one thing I hate is when it takes you away from being able to code. I've been that architect before and it's not a fun place because you feel like you're out of touch with the teams working on the products or projects that are being built. And I feel like to really understand where the architecture is for something and where it needs to go, you can't be looking at diagrams of boxes, you need to be hands in the code, otherwise you may easily miss huge opportunities for simplification because you've seen how the code works and what it's doing and you don't always see that from boxes connecting to each other.

Michael Stiefel: And also I think you lose your intuition.

Ken Finnigan: Yes.

Michael Stiefel: That's important even when you're looking at boxes to have an idea: could this work?

Ken Finnigan: Right. And even when you're looking at boxes to ask the questions of is this the best way to do this? Is there other ways to make this simpler? Instead of five boxes, can we have two? Or whatever it might be.

Michael Stiefel: Right. What other profession, other than being an architect would you like to attempt?

Ken Finnigan: Since I was a kid I've always loved the idea of writing fiction, but-

Michael Stiefel: Well, you write software sometimes that's fiction too.

Ken Finnigan: And I've certainly written nonfiction with the technical books, not exactly huge bestsellers. So I have written stuff in that. I guess the other thing would be being a genealogist. I do family genealogy as a hobby so it would be cool to do that as a job.

Michael Stiefel: Do you ever see yourself as not being an architect anymore?

Ken Finnigan: Yes. I think there'll come a point where I'd want to start slowing things down and not have as much responsibility and you can't really be an architect and get those things. You need to be on top of your game all the time as an architect as to where things are now, what's coming down the pipe. And certainly with the ever changing landscape of tech over the last five years in particular and 10 to 20 even more so, there will come a point where I'm like, "Okay, yes, I'm happy with what I know. I don't need to keep learning new things. I think I'm done being an architect".

Michael Stiefel: I think that's something that people don't appreciate because people talk about slowing down being semi-retired. I found with technology you're either in the game or you're not in the game.

Ken Finnigan: Yes, it's very hard to dabble and be up-to-date with everything.

Michael Stiefel: Yes.

Ken Finnigan: You can still keep doing stuff with things you've used for 5, 10, 15 years, that's not a problem at all, but yes, you can't step out and then expect to step back in three years later, for example, and be up-to-date with everything.

Michael Stiefel: Yes. And finally, when a project is done, what do you like to hear from the clients or your team?

Ken Finnigan: From the clients I like to hear that it met all their goals of what they were looking to see in terms of what they asked for and maybe to a certain extent what they weren't directly asking for, but were really asking for and you had to get out of them, but that met their goals and they're happy with the end system. From the team I think it's more around did they learn? Did they have fun? And was it something, given the choice, they would do again?

Michael Stiefel: That's very interesting. Well, thank you very much. I enjoyed this interview or this discussion very much. I think it's something that we don't think about enough, but it is just as important, at least for the long-term success of the software organization to understand how to bridge this feedback chasm.

Ken Finnigan: Definitely. Well, thank you very much for having me on, Michael. I really enjoyed it as well, and hopefully the listeners enjoy it.

Michael Stiefel: Okay, well thank you very much.

Ken Finnigan: Thank you.

Mentioned:

• How to Mitigate the Pain of Getting and Giving Feedback
• The Feedback Chasm