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.

00:01 — Jennifer Scalf
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?

00:12 — Johan Philippine
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.

00:28 — Jennifer Scalf
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.

00:57 — Johan Philippine
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.

01:35 — Angela Andrews
This is Compiler, an original podcast from Red Hat. I'm Angela Andrews.

01:41 — Johan Philippine
And I'm Johan Philippine.

01:43 — Angela Andrews
We go beyond the buzzwords and jargon and simplify tech topics.

01:47 — Johan Philippine
We're sharing stories from industry veterans about how they found their footing in the tech industry.

01:55 — Angela Andrews
Today, we're hearing two stories about projects not going as expected.

02:02 — Johan Philippine
Angela, do you remember your first IT project?

02:05 — Angela Andrews
No, sir.

02:06 — Johan Philippine
Oh.

02:06 — Angela Andrews
But I do remember some early projects.

02:09 — Johan Philippine
Okay.

02:09 — Angela Andrews
They might not constitute my first, but I do remember some of the high jinks that ensued.

02:18 — Johan Philippine
So tell me a little bit about one that stands out in particular.

02:21 — Angela Andrews
One in particular was: I was working at a new company and I was their first hire.

02:29 — Johan Philippine
Okay.

02:30 — Angela Andrews
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.

03:16 — Johan Philippine
That's great. Well, on the subject of learning things, I've got a great story for you.

03:20 — Angela Andrews
Okay.

03:21 — Johan Philippine
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.

03:31 — Angela Andrews
I do.

03:31 — Johan Philippine
Work with them all the time.

03:31 — Angela Andrews
I do. I do.

03:34 — Johan Philippine
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.

03:51 — Angela Andrews
Sounds familiar.

03:53 — Jennifer Scalf
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.

04:33 — Johan Philippine
So this was 20 years ago when it wasn't easy to set up wireless networks.

04:38 — Angela Andrews
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.

04:49 — Johan Philippine
Oh, yeah.

04:50 — Angela Andrews
Somewhere in here. Oh, in the box. The old technology. We talked about it a few series ago. Yeah. That one.

04:57 — Johan Philippine
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?

05:10 — Angela Andrews
It was a process.

05:11 — Johan Philippine
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.

05:27 — Jennifer Scalf
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.

05:46 — Johan Philippine
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.

06:01 — Jennifer Scalf
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?"

06:22 — Angela Andrews
Wait a minute. Did the scope change? She was doing well, she got it working.

06:30 — Johan Philippine
She did.

06:31 — Angela Andrews
But, question mark, what are we talking about here?

06:33 — Johan Philippine
It took a month. I don't know.

06:35 — Jennifer Scalf
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.

06:51 — Angela Andrews
How could they?

06:53 — Johan Philippine
Yeah.

06:54 — Angela Andrews
They wanted her to fail.

06:56 — Johan Philippine
Not cool.

06:57 — Angela Andrews
Oh, sorry, Jennifer.

06:59 — Johan Philippine
Yeah.

06:59 — Angela Andrews
I'm sorry.

07:00 — Johan Philippine
This is why Jennifer is inclined to ask those why questions.

07:04 — Angela Andrews
Exactly. Why are we doing this? Exactly Good for her. Good for her. Lesson learned.

07:11 — Jennifer Scalf
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.

07:39 — Johan Philippine
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?

08:05 — Angela Andrews
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.

08:36 — Johan Philippine
Oh, yeah. No, I would be livid if I-

08:38 — Angela Andrews
Livid. Exactly.

08:42 — Jennifer Scalf
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.

09:15 — Johan Philippine
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.

09:28 — Angela Andrews
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.

10:16 — Johan Philippine
Yeah.

10:17 — Angela Andrews
Still doesn't explain that.

10:18 — Johan Philippine
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.

10:43 — Angela Andrews
Oh, good. Good.

10:43 — Jennifer Scalf
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?

11:04 — Angela Andrews
Lesson learned.

11:05 — Johan Philippine
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.

11:23 — Jennifer Scalf
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.

11:37 — Johan Philippine
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.

11:55 — Angela Andrews
Ooh, I can't wait.

12:05 — Johan Philippine
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.

12:27 — Tramaine Darby
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.

12:50 — Johan Philippine
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?

13:27 — Angela Andrews
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.

13:50 — Johan Philippine
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.

14:12 — Tramaine Darby
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.

14:42 — Johan Philippine
That doesn't sound like a recipe for success.

14:44 — Angela Andrews
It does not.

14:45 — Johan Philippine
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.

14:55 — Tramaine Darby
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.

15:28 — Angela Andrews
No pressure.

15:29 — Johan Philippine
No pressure at all.

15:30 — Angela Andrews
Have you ever heard of something more impossible than what she just said? 20 teams!

15:37 — Johan Philippine
It gets worse.

15:37 — Angela Andrews
Okay. All right.

15:39 — Johan Philippine
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?

15:49 — Angela Andrews
If you say six months... I'm sure it's not enough time, let's put it that way.

15:57 — Johan Philippine
Well, it wasn't quite six months. It wasn't that unrealistic, but it was somewhere between three quarters to a year.

16:05 — Angela Andrews
Really?

16:06 — Johan Philippine
Yeah.

16:06 — Angela Andrews
With humans? With other people involved. Okay. Okay.

16:12 — Johan Philippine
So we have these red flags identified pretty much immediately for this company-wide project. Tramaine tried to raise the alarm.

16:20 — Angela Andrews
Good for her.

16:23 — Tramaine Darby
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.

16:54 — Johan Philippine
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.

17:16 — Angela Andrews
The other 19.

17:18 — Johan Philippine
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.

17:30 — Tramaine Darby
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.

17:47 — Johan Philippine
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.

17:59 — Tramaine Darby
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.

18:30 — Johan Philippine
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?

18:42 — Angela Andrews
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.

19:16 — Johan Philippine
Well, they were moving the deadlines back because obviously they weren't meeting what they needed to do.

19:23 — Angela Andrews
Really?

19:23 — Johan Philippine
Yeah. Well, it ended up being very difficult to run the system without everything locking up.

19:29 — Tramaine Darby
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.

19:54 — Johan Philippine
Angela, they worked on that project for two years before it was scrapped and they never got past phase one.

20:00 — Angela Andrews
Wow. And they'll never get that time back. It sounded unattainable from the very beginning, very unrealistic expectations.

20:12 — Johan Philippine
Yeah. But it was finally over.

20:14 — Angela Andrews
Good for her.

20:14 — Johan Philippine
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.

20:29 — Tramaine Darby
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.

20:56 — Johan Philippine
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.

21:17 — Angela Andrews
Smart.

21:18 — Johan Philippine
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.

21:52 — Angela Andrews
Which they really, really didn't want her to build to begin with, but she persevered.

21:57 — Johan Philippine
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.

22:25 — Angela Andrews
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.

22:59 — Johan Philippine
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.

23:32 — Angela Andrews
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.

24:06 — Johan Philippine
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.

24:25 — Angela Andrews
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.

25:09 — Johan Philippine
And that does it for this episode of Compiler.

25:12 — Angela Andrews
Today's episode was produced by Kim Huang, Johan Philippine and Caroline Creaghead.

25:18 — Johan Philippine
Victoria Lawton's projects are always well planned and never doomed.

25:22 — Angela Andrews
Never, never. Our audio engineer is Christian Prohom. Special thanks to Shawn Cole. Our theme song was composed by Mary Ancheta.

25:33 — Johan Philippine
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.

25:53 — Angela Andrews
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.

26:09 — Johan Philippine
We really love seeing your comments and your feedback, so yes, please keep doing that. Bye-Bye everyone.

26:17 — Angela Andrews

Take care.