Tales From The Database | Warning Signs

  |  Compiler Team  
Desarrollo profesional

Compiler • • Warning Signs | Compiler: Tales From The Database

Warning Signs | Compiler: Tales From The Database

About the episode

They say wisdom comes from experience. Starting out in the tech industry likely means you’re short on experience and looking for advice. One area where people could use a leg up? Learning the warning signs of a problematic project.

We hear stories from people who’ve figured out the hard way how to spot potential red flags, and what can happen when they’re missed.

Compiler team Red Hat original show

Suscribir

Subscribe here:

Listen on Apple Podcasts Listen on Spotify Subscribe via RSS Feed

Transcripción

If a project comes in, we really do need to analyze it and find out should the rest of my team be working on that? Should I be working on that? What are the why's? Jennifer Scalf has learned the hard way, why it's important to ask those questions. When you're just starting out in tech or in any job really, it can be really intimidating to ask questions about the work you're assigned, but questions will probably help more than they'll hurt. I don't want to sit there and tell you to doubt all of your managers and your directors and all the people who might be... I'm not saying that. I mean, there's a time and place to just go, "Okay, yeah, I've worked with this person for many years. They seem like they do the proper analysis and decide if something should move forward, and now it's just time to move forward, right?" So I am not saying that, but I do think there is a time and place, especially when you're a little bit further in your career, to question a little bit more and to suggest different solutions and just make sure that folks are all on the same page. Finding your footing and learning to trust your own judgment can take time. Advice can be a boon, but sometimes it can be ignored, right? In an industry where things change at a breakneck pace, how do you know when to heed warnings and when to just smile and nod. In this series, we're going to hear from people who've stumbled, grown, and come out the other end just a little bit wiser. Stories from industry veterans can help paint a picture of the realities of the job, the benefits of persistence, and the consequences of bravado. This is Compiler, an original podcast from Red Hat. I'm Angela Andrews. And I'm Johan Philippine. We go beyond the buzzwords and jargon and simplify tech topics. We're sharing stories from industry veterans about how they found their footing in the tech industry. Today, we're hearing two stories about projects not going as expected. Angela, do you remember your first IT project? No, sir. Oh. But I do remember some early projects. Okay. They might not constitute my first, but I do remember some of the high jinks that ensued. So tell me a little bit about one that stands out in particular. One in particular was: I was working at a new company and I was their first hire. Okay. And they were a company who left another company and then so that everyone knew everybody, but I was their first real hire and there were all of these other locations that needed new computers, and we had them set up. We started doing imaging and at some point they were being mailed out to other locations, and if they were close by, I was driving to all these locations and meeting all these cool people, and it was (to say the least) challenging, but I learned a lot. It was definitely one of those projects that kind of solidified that, oh, I can do this. I can definitely do this. So it was a huge confidence boost for me. That's great. Well, on the subject of learning things, I've got a great story for you. Okay. So Jennifer Scalf, who we heard from in the intro, she's a people manager on the technical account manager's team here at Red Hat. We call them TAMs for short. I'm sure you know them very well. I do. Work with them all the time. I do. I do. All the time. And being a people manager, she gets to assign projects to her team, but it wasn't always that way. She shared her experience with one of her first projects working for a University IT Department, one where she really dove in with can-do enthusiasm. Sounds familiar. I was given a project to install a wireless network using some open source software at the time that I don't know what it's evolved into, but the idea was I was given a set of RPMs or whatever back in the day. I was given a few machines, some wireless related hardware, some cards, little cards, back then, goodness gracious, it was 2004, so whatever those were, little dongles coming off the back and I was asked to set it up and I said, okay, I'm eager, and I wanted to learn this stuff. So I actually had enough challenges in the configuration that I reached out that the gentleman who had created it and he was wonderful, and we work together. So this was 20 years ago when it wasn't easy to set up wireless networks. No, it was not, and I was giggling to myself as I was listening to Jennifer. Oh, yeah. Oh, yeah. I still have one of those little tiny cards. Oh, yeah. Somewhere in here. Oh, in the box. The old technology. We talked about it a few series ago. Yeah. That one. Yeah. We didn't have kind of plug and play stuff that we have today. Needed to set up the wireless router, configure the network, install those little network cards, install the drivers, and on and on and on. It was a lot of steps, right? It was a process. It's much easier today, and this project was something that her bosses gave to her to kind of figure out what it is that they could do because they didn't have any wireless networks set up at all at the time. So this was kind of like a proof of concept thing for her. Jennifer had to learn a lot to get started on this project. I really didn't understand some of the fundamentals, and he was very nice and helped me through it. I got it working. It took a lot longer than it probably should have, and looking back on it, I'm like, why did it take me so long? But whatever. You persevere, you keep going, and just one challenge after another, learning how to debug some of this stuff, it took about a month. She's not sure if this month was while she was working full-time or part-time, but she was still a student when she started this project, and after juggling student activities and this work project, she finally reached the finish line. I finally get it working. So proud of myself. I'm connecting my laptop to it underneath my desk again. This was a very long time ago, so it was just like magic that this was working, and I go to my bosses, I'm like, "Look what I did. I got it working." And they said, "Oh, darn it." I said, "What in the world? Why?" Wait a minute. Did the scope change? She was doing well, she got it working. She did. But, question mark, what are we talking about here? It took a month. I don't know. Why darn it? No, it's working. I'm online. I can go to a website, whatever back then. They said you weren't supposed to get it working. We were trying to show that it wouldn't work so that we could buy some proprietary software. How could they? Yeah. They wanted her to fail. Not cool. Oh, sorry, Jennifer. Yeah. I'm sorry. This is why Jennifer is inclined to ask those why questions. Exactly. Why are we doing this? Exactly Good for her. Good for her. Lesson learned. I learned so much from this experience, which is number one, for my current role, find out what the users actually want. Don't waste your time. Don't spin your wheels for a month... and be a technologist. Love it. Love what you're doing, love the technology itself, et cetera, but step back and find out what do your users, what do your administrators, what does everybody actually want before you dive in head first and spend all this time and effort and whatever. This was a tough project at the time, and as she recalls it, the pressure to get it working was mostly self-imposed. Right? That makes sense there. They weren't really expecting it to succeed in the end, but there also wasn't much direction to say like, "Hey, it's okay if you don't get this to work." And without that guidance, the assumption is going to be we gave you a task and you should get it done. Right? Exactly. That's how we all think. We're usually given a task, and if we trust the person that's giving it to us, we're going to try to complete that task sometimes without knowing what the big picture is, because maybe we have so many other big pictures in front of us. Oh, I can just tackle this one. You know what I mean? And not need all of the backstory and that big why that she mentioned. I'm still feeling some kind of way about that though. Oh, yeah. No, I would be livid if I- Livid. Exactly. I just remember being young and eager and wanting to get it to work because it's interesting and as fast as I could. And then remembering all the times people have said, "Don't try to burn yourself out though. Take a moment. Don't work on it 24 hours a day, you got to step back." And at that time, we were all in person. There was no remote work, whatever. You're always driving in. So there was an end. Folks would come by and say, "Jennifer, you do have to leave. You can't stay. There's a time you got to leave." Otherwise, I probably would've been working on this thing for many more hours every day. Take some time to breathe and check in with your managers about timelines and expectations and communicate about what you need to get it done, if it needs to get done at all. Prioritization is so important. My husband has this saying, he says... When people are coming at him from different angles, he'll say, "Which one do you want done first?" And I think that's such a great way of tackling multiple projects and multiple things coming at you. You take the onus off yourself and you kind of put it back on the person who's delivering these tasks to you and you just put the ball in their court. You see, I'm juggling all these things. I'm going to let you decide where the priorities lie. But that still does not explain how they let poor Jennifer down this dark path. Yeah. Still doesn't explain that. Well, even though they weren't expecting her to succeed and didn't want to use this open source solution for their wireless networks, right? They wanted a proprietary one and say, "Look, we assigned someone to do it and it doesn't work, so let's buy this other thing instead." Even with all of that, Jennifer had a lot of really positives come out from this experience. Oh, good. Good. Now, maybe when you're young in your career and you have all the energy in the world like I did, you can do that and it doesn't matter if it works in the end or not, you've learned. I learned so much along the way from that project, but goodness gracious, at this stage in my life, 20 some years later, you better believe I find out what do they actually want before I do it? Lesson learned. Yeah. And Jennifer became a networking expert at a time where those skills were really in high demand, right? And she made some connections with other IT professionals and learned from them. But most of all, of course, she learned how to ask questions and how to take things in stride. I don't know. And that's another good life lesson though, is sometimes you're just not going to know. You have to kind of throw it to the wind and move on and not stress over it, and I didn't, right? I just find it to be a very amusing story now. No matter how prepared or curious or informed you may be, there's always a chance of an ulterior motive and there's not much that you can do about it in the moment. After the break, we're going to hear from one of our favorite guests about a project that she knew was never going to end well. Ooh, I can't wait. For this next story. We spoke to Tramaine Darby. She's a senior engineering manager here at Red Hat, and we last had her on the show for our episode about technical debt. When this story took place, Tramaine had quite a bit more experience than Jennifer did at the time of her story. She was about to transition from an individual contributor to a management role. The first thing to know about this project is that it was more of a company-wide type initiative. And so it really was around changing the way users were able to interact with us and making their ability to manage users more flexible. The example she gave us was that they initially had a system where they were only allowed to have a name and an address, but the system that they needed to have needed to be able to assign a variety of personas, roles and adjust the access that they'd be allowed to have. It was very rigid and they needed something that would be more flexible. This doesn't sound like an easy project. Especially when you've got a database that needs to be converted, also while making sure that new data can be entered, that can work with the old and with the new system at the same time. But that's the kind of thing that happens all the time in this industry, right, Angela? Sure. What could go wrong? This is one of those age-old challenges where you're trying to make something do something that it really can't do without a whole lot of tweaking and adjustment and programming. Yeah. I can't wait to hear what she says next about this. So Tramaine's team was responsible for a lot of user facing applications. They'd maintained the back ends, which made heavy use of the API that they were changing. Her team's work was necessary for users' products to work and their applications to function properly. And this project, when finish would ostensibly make everyone's life a little bit easier. They were all in on this idea. The purpose and the intent was great. We want to have a more flexible system for our users. Wonderful. The approach though was boil the ocean, right? While there were phases to the project, the phases were, do everything everywhere for this one thing as opposed to a feature at a time or phasing things in. That doesn't sound like a recipe for success. It does not. And remember Tramaine said that this was a company-wide initiative, and she wasn't working for a small company. Maybe the first phase was something simple. Phase one was everybody has to go over to this new API to take advantage of the new flexible model. And unless everybody is on this new API, we can't move forward to the next phase. That in and of itself was like, so you mean to tell me 20 teams need to be on the same page at the same time in order for the project to move forward? That was just a little bit of a red flag for me. No pressure. No pressure at all. Have you ever heard of something more impossible than what she just said? 20 teams! It gets worse. Okay. All right. So we have an idea of what the project is, how complex it is, and how leadership thinks it's going to roll out. Angela, how much time do you think they plan to spend on this rollout? If you say six months... I'm sure it's not enough time, let's put it that way. Well, it wasn't quite six months. It wasn't that unrealistic, but it was somewhere between three quarters to a year. Really? Yeah. With humans? With other people involved. Okay. Okay. So we have these red flags identified pretty much immediately for this company-wide project. Tramaine tried to raise the alarm. Good for her. And I found that there was a lot of other folks who had the same concern at the same time. I don't know that the concerns were ever voiced, and if they were, I didn't see any evidence of any type of adjustment for that. So I guess I was far enough away from the actual planning that it was very difficult for me to see what adjustments, if any, were ever made. So they voiced their concerns to their direct superiors, and after that, kudos, whether those got sent over to the higher ups. The train kept on rolling. They'd get on these huge calls with a bunch of people talking about typical stuff, what they're working on, identifying what needs to get done and what's blocking other teams from doing their work. The other 19. The other 19 teams, that's right. All on the same call at the same time. She mentioned it was messy and it didn't seem like anyone was listening to their concerns. I guess the only real signal I got is that deadlines kept moving, but as far as the structure of it and how it actually was being rolled out, that never changed throughout the whole thing. Now partway through the project, they had to start actually trying to use the new API, but of course not everyone was ready. And that made everything even more complicated. With the migration, you had to have both APIs kind of running at the same time. And we had to figure out a way to make the new one backwards compatible to the way the old one worked, because you're going to have them running in parallel. There was no way to move to the new one all at the same time. So Angela, help us out a little bit here. On a scale of, oh, it's fine to, this is fine, but the room is on fire. Where would running two APIs in parallel fit? Her story is having me lean toward the room is on fire. And we're just all looking around, nodding our heads, smiling like, we're moving forward, huh? This is us moving forward. So many red flags. This project basically was doomed from the very beginning. And to say that there were no adjustments being made along the way and the timeline was the timeline and yeah, this was room on fire type of scenario. Well, they were moving the deadlines back because obviously they weren't meeting what they needed to do. Really? Yeah. Well, it ended up being very difficult to run the system without everything locking up. Before even my team was able to get moved completely onto the new API, the project was scrapped. I'm assuming that with the difficulty we were having, other teams were having same difficulties or worse. We never got to phase two of the project. It never got off the ground enough. Angela, they worked on that project for two years before it was scrapped and they never got past phase one. Wow. And they'll never get that time back. It sounded unattainable from the very beginning, very unrealistic expectations. Yeah. But it was finally over. Good for her. Well, actually, you know how in a lot of horror movies, there's often a fake ending where you think the big monster's dead, but it comes back that one more time to haunt you and the hero. Yeah. It was kind of like that. What happened at that point is, oh my goodness. Now we're in a situation where we've got this Frankenstein monster of new API, old API, and we've got to get to new API anyway, because we can't move forward in this state. So we had to end up still completing the work just to get us off of this old one so that we could be on one single version of an API. They ended up having to finish that rollout, but they came up with a system that let them do so without crashing everything every day. It involves setting up feature flags and adding a library layer to switch between different API versions and using that to convert applications one at a time rather than trying to do everything all at once. Smart. So partial success, but due to poor planning, the project itself was kind of doomed from the start. So let's recap a little bit: We started with a story about a project that was expected to fail but succeeded despite an ulterior motive, after Jennifer put in the time and effort to get it running. She learned how to ask questions about expectations and desired outcomes, hopefully to avoid building something that no one actually wants in the end. Which they really, really didn't want her to build to begin with, but she persevered. Yeah. She got through it and she learned so much that really helped her out in the end. We ended with a story about a project doomed to fail because of poor planning. The intent was good, but the implementation was overly ambitious and criticism seemed to be ignored. Tramaine had the experience to recognize the warning signs that the project wasn't going to go well and spoke up. But sometimes even with that foresight, projects get pushed forward anyway. Yeah, there are bigger things at play. There was probably nothing anyone could have said, but the ultimate demise of the project that nothing else would stop the train unless the project failed. And it seems like that's how that was set up to be. It was never going to be successful in this fashion. It wasn't going to be. The planning was... It was not there. It wasn't sufficient, but I bet everybody involved learned something as well. I'm sure of it. My goal with pairing these two stories together was to highlight the skills you need to recognize the trajectory of a project, and that even when you correctly identify and raise the red flags that you see, you might not be heard, but success looks different for each of these stories, right? For Jennifer, it was learning about networking and learning to ask questions. And for Tramaine, it was making the best of a not so ideal situation and getting to a better place using creative solutions despite the project getting closed down. Success is very fluid and it depends on how it looks to you and how you're defining it. And in both of their cases, they felt like it was successful, no matter the time they put in, no matter the issues, no matter how many red flags they both persevered given the information that they had. So I think that's a teachable moment for all of us. Even in the worst situations, something good always comes out of it. If you look at it properly. They both learned a lot, how to trust themselves and how to move forward even when things don't seem like they're headed in the right direction. And speaking of trusting their own judgment. In our next episode, Kim is going to share some stories about people trusting themselves to take that leap of faith with emerging technologies. Hopefully, they had a parachute! But this was really cool. It was nice to hear these stories about these projects that were just doomed to fail from the beginning. And I know our listeners have stories like that in their mental Rolodexes somewhere. (Yes, I said Rolodex.) We want you to share those with us. Hit us up on our socials at Red Hat. Don't forget to use the hashtag Compiler podcast. We would love to hear some doomed projects that may have come in your career. We'd love to hear it. And that does it for this episode of Compiler. Today's episode was produced by Kim Huang, Johan Philippine and Caroline Creaghead. Victoria Lawton's projects are always well planned and never doomed. Never, never. Our audio engineer is Christian Prohom. Special thanks to Shawn Cole. Our theme song was composed by Mary Ancheta. Our audio team includes Brent Simoneaux, Leigh Day, Stephanie Wonderlick, Mike Esser, Nick Burns, Aaron Williamson, Karen King, Jared Oates, Rachel Ertel, Devin Pope, Mike Compton, Ocean Matthews, Paige Johnson, Alex Traboulsi, and Mira Cyril. If you'd like today's episode, please follow the show, rate the show, leave a review, share it with someone you know, share it on social media. It really does help the show, and we'd love to see your tweets and your messages about it. So keep doing that. We really love seeing your comments and your feedback, so yes, please keep doing that. Bye-Bye everyone. Take care.

More about professional development

Keeping up with changes in technology requires training and and engagement with learning opportunities—either in a traditional setting, or individually.

Publicaciones en el blog

Red Hat Named a Leader in 2025 Gartner® Magic Quadrant™ for Container Management for the Third Consecutive Year

11 de agosto de 2025  |  Sara Buffington

...

Containers

Publicaciones en el blog

Red Hat Named a Leader in 2025 Gartner® Magic Quadrant™ for Cloud-Native Application Platforms for the Second Consecutive Year

7 de agosto de 2025  |  Alexa Overbay

...

Cloud services

Programas originales

Fail Better | Command Line Heroes

Desarrollo y distribución de aplicaciones.
Desarrollo profesional
Historia de la tecnología

Programas originales

Command Line Heroes: Cuarta temporada: Una cosa más con Steve Wozniak

Historia de la tecnología

Sobre el podcast

Compiler

Do you want to stay on top of tech, but find you’re short on time? Compiler presents perspectives, topics, and insights from the industry—free from jargon and judgment. We want to discover where technology is headed beyond the headlines, and create a place for new IT professionals to learn, grow, and thrive. If you are enjoying the show, let us know, and use #CompilerPodcast to share our episodes.