Episode 010: Finding Your Voice in the Project Lifecycle

Steph and Claire discuss how their experiences re-inforce that regardless of methodology your team is using, it's important to find your voice in the process. If you're on a team, you're working to make the best product you can and that requires good communication and removing blockers.

Transcript#

Claire:

Hi.

Steph:

Hey,

Claire:

I'm Claire

Steph:

and I'm Steph.

Claire:

And this is Word Wrap.

On today's episode, we're going to talk about project life cycles. So think about like how a thing goes from being designed to being developed, to being released, um, and everything in between. Um, Steph and I used to work on a team about six years ago, where it was a typical in house marketing, uh, team where, you know, we were pushing out websites. We were pushing out like graphic designs and stuff like that. And her and I both were developers on, on that team. Two of three developers actually. Um, and we weren't waterfall, we weren't agile. We weren't using scrum. We weren't using, we actually weren't even using GitHub at the time.

And our process at that time was very interesting, but I see it in all the other different methodologies that we end up like, um, officially using at different companies that I've, that I've been at since then, um, like scrum, like agile. Uh, and so I kinda wanted to talk about that today, um, and make the case for engineering should always be part of the, um, different parts of those and, and as well as everyone else in the, in the, in the whole life cycle. It shouldn't just be a waterfall kind of thing where design is like, okay, I'm going to chop this up and to make this work. And then we're just gonna throw it over the wall.

It's never like that. Everyone has their own, uh, wheelhouse, if you will. Um, you know, engineering, uh, front end engineering might know a lot about accessibility and designers may not have as much context in that. Um, or, you know, vice versa, like product might not understand that this feature that we need to get out in a week, uh, needs actually a little bit more review because it's a huge thing from engineering and engineering, just, you know.

There, there are several different things that um, that happened throughout the life cycle that, uh, cause uh, things. So we're going to, we're going to talk a little bit about that.

Steph:

So when Claire and I worked together, um, even though we had like approximately 30 person marketing team at that time, um. You know, we had copywriters, we had designers, we had project managers. And so in some respects, you know, there's some similarities between that and a product team just without the formal ceremonies that you have with agile or something. And, you know, there's pros and cons to that. The pro to that environment was we were super collaborative. Um, because since we didn't have like those ceremonies, it was, and we were a small team and we were all in one location. All those things combined, you know, you're able to directly talk to somebody like a designer or a copywriter when you had a question and, and, you know, work something out.

Um, yeah. But there is downsides because without those kinds of structures, we were missing some features that we both enjoy immensely now. Um, particularly things like version control. We just didn't know about it because without being in kind of that more formal developer environment, you know, we basically didn't have anybody to guide us to that solution. Which is just like, when I think back on that now I'm like, Oh man, so much pain could have been alleviated, but you don't know what you don't know, right?

So I think part of what we were talking about when we were discussing this topic today is that there are those stark differences between being on different kinds of teams. And you, you know, I think that's one of the benefits of being able to grow in your career and change environments is learning those new practices that you may not discover if you happen to be like us where you're mostly self-taught. So you rely a lot on that environment.

And the other kind of thing with that is you have to learn everything on the job about how to talk between roles and how to do those sessions.

And I think a really important point here is that no team has this perfectly figured out. Not small teams, not startup teams, not even super large enterprise teams.

Um, you know, even with formalized structures like agile or, or what have you, um, I've seen that fall down too. Right? So like it's all in how you put it into practice. And I think at the end of the day, it's about communicating between those teams and not blocking communication. That's my 2 cents.

Claire:

Yeah. I think that's a great point. I feel like a lot of these methodologies and just overall practices are an attempt to, um, make the human communication process a little bit more rigid, a little bit more reportable if you will. And human communication is different between everyone. And so a point that you mentioned Steph is that enterprises have, they might have processes and stuff like that, but those things break down pretty easily if not everyone's bought into it.

And I find myself really wanting to collaborate with all different partners of the team, not just kind of how those methodologies, um, you know, set up, uh, different things such as, you know, like scrum ceremonies. Or, or whatever, when you have one meeting to talk about the requirements and stuff, and especially in these remote environments nowadays, where, uh, everyone's just kind of, you know, available only via Slack or, you know, you know, just an impromptu call.

You can't walk over to their desk and say, hi, Hey, uh, this thing it's wrong. You know, I can't really do that as well. And so I think that... and, and, and this comes from someone that I literally am working at a company where we're trying to figure out these processes. And we were trying to figure them out before the pandemic.

And so the pandemic kind of just flipped everything on its head. And I know that my company is not the only company that's dealing with this. And so that's why it's top of mind that I think the biggest paramount thing that you can do is just talk to people and have empathy with them, especially with what they're going through and, you know, understanding that everyone's trying their best.

And so I think a, a couple more things that I wanted to mention was that, you know, a lot of the things that we do in front end engineering specifically, don't just come down to a specific step in the process. You know, there are, um, like I said earlier, everyone has their own kind of wheelhouse in terms of information and knowledge.

And let's say something is designed that isn't accessible. You know, then the front end engineer has to go back and say, we can't do it this way because X, Y, and Z. And that doesn't make any process any better. So, you know, having a project kickoff, having some sort of, you know, communication channels that are established, be like, this is your point person for this, this is your point person for that really helps, especially in a remote environment. And I know that was kind of a word salad of things as I'm literally just thinking about them. But I think the biggest thing that we want to hammer home is communication is key, no matter what, uh, thing you are working on.

And especially like, even in a single environment where you're just working on something, you know, and you're, you're thinking about these things and stuff like that, you would write them down probably. And then, you know, in a couple of weeks he was like, what in the heck is this, uh, it's, it's the same kind of thing. But you know, in a waterfall environment or a scrum environment, it's like, you look at a ticket and you're like, What is this, this is not even accurate anymore. And then the process starts to break down. So it's that, it's that, um, need for constant communication that, uh, I think is just paramount in any team.

Steph:

Yeah. And I think another key in this that you made me think about was, um... You will - as you advance in your career, you will better learn to spot when there might be a communication problem, or when you need to have more information.

You're not going to know that day one as a junior, you know, you're going to absorb that. Um, my, my first mentor - like that, I would actually consider a mentor - the biggest thing I learned from them was how to ask good questions. Like when I look back, I'm like, you know what? They were constantly showing me just in their natural way of doing things like how to ask good questions and how to spot those problems. Um, so absorb that from your team members of any level, you know, that's a skill that I think one of the few skills you can kind of absorb just by paying attention and, and, and learning, um, how to assess requirements. And, um, or maybe assess up front-end mock-up or what have you.

But, you know, and I think the other key here though, is that. If communication channels, don't empower every role to speak up about problematic issues you know, that's where you can also see things start to fall down. Because when you, when, when project requirements are laid out, I guarantee no one has all of the answers.

You will discover things and you will discover them at different stages of the project. Um, so having that kickoff or having some method where everybody can get on the same page, which might be a literal page, you know, some sort of document. Or maybe it's a collection of tickets or whatever system you use, but, you know, making sure you're addressing those things.

And being able to, we know when you spot issues with accessibility, with usability. If you, um, in your own unique role, spot something within your area of expertise, being able to, hopefully you feel empowered that you can raise those issues. And you know, every organization is going to be different on who exactly you're going to talk to about that.

But I think, I would think that regardless everyone would like a smoother process would mean it takes effort. That's that's the thing is it takes effort to find that process. And it's not going to be one-to-one with one, you, you know, read a book about basically or reading an article about. Because your team is going to be composed of different people.

Even if you have a designer and developer, front end developer, a back end developer or QA specialist, accessibility specialist. Even if you have all these roles, your team dynamics are going to change how you actually, at the end of the day, get through these processes.

Claire:

Yeah, I think that's a huge point to make, because you know, all those people also have different personalities. They might want to be interacted with in a different way than someone else, for example. And I also think to back up on one of your points, you should feel empowered to speak up based upon your knowledge, because at the end of the day, why did the company hire you? If you are not supposed to speak up... like you literally are a subject matter expert about whatever your craft is so that is why you are there.

So for a front end developer, you know, divs is buttons. No, that's not correct. You should speak up about that. You know, other things. Accessibility experts or accessibility specialists should speak up about, you know, something. And don't think about blocking the process because at the end of the day, the process is to get something out there that's working and working for everyone.

So. It, it, it should not be, you should not ever feel like a blocker. You should not ever feel like you're holding up the process. And the reason why I say that is because I have felt like that. I have felt like that at a company before where I knew that the points that I was making were valid. And, um, I would have to go back to, you know, a designer or I'd have to go back to, you know, even a product person and just say, we can't do it this way, or we shouldn't do it this way. It was more that we shouldn't do it this way, then we can't. But, I digress.

You are there to make, you know, things work well. And so like that is, uh, that is your job. And if, if it slows down a timeline, it slows down a timeline. Because at the end of the day, like you're not there to make bad product. You're there to make, you know, as best as you can do. Cause as, as I said earlier, everyone's trying their best. So if that's true, then here we are.

Steph:

Yeah. And I think that, um, I've been fortunate to be in a extremely harmful toxic environment, but there's definitely been things that I look back and I'm like, Oh man, that was a bummer. But one of those things that comes to mind that you reminded me of is people who may think that something can't be done because it's always been done one way, right? Like this could be a whole tangent. I'm not trying to take us down a whole tangent, but you know, like to Claire's point, like you were hired to do a particular job. And you should, I hope, you know, again... we could probably have a whole thing about toxicity in the workplace and things, but, you know, and we're kind of getting away from my main topic anyway. But you know, that empowerment of being able to speak up when you notice something that's not quite right. And, and, and hopefully finding, you know, other, other folks who are like willing to reassess the process and, and make those changes, whatever they might be.

Even and sometimes it usually does come back to communication, right? It's usually saying, Hey, we could do better for the user here, you know, and that hopefully can you know, help you make your case. Like I'm talking about the user I'm talking - or I'm talking about our developer experience. And if we do this, we can find some efficiencies. Sometimes you have to learn to use corporate speak or whatever, you know? Right. Like, but if it makes, you know, the process smoother, if it gets a better product out the door, if it enables your product to be more inclusive. Yeah. I, you know, that's, those are all terrific reasons to suggest changes to the process or, you know, raise concerns.

Claire:

Yeah. And, and I think that, uh, you mentioned that you felt that it was a little off topic. I don't, I don't think it's off topic at all. Because I feel like a structure that we are we're we're talking about, which is the project life cycle kind of eludes to, you know, a certain person has, uh, has ownership over one thing. And then a certain, another type of person has ownership over a different thing. At the end of the day, it's a product that we're all shipping. And so even though a project manager might have an idea about this is the way it should work, an engineer might have a better idea that should be considered as well. And same with the designer, same with the QA person. Those are, we're all equal team members at the end of the day. And, another reason why I bring this up is because I've worked in environments where back-end is King basically. And so a front end engineer doesn't really have the ability to state that this is a bad pattern, or this is a bad thing to do. Because at the end of the day, if a back end person says it's not, then people listen to them.

And that... that is, that is toxicity. But it's also enforced by the project structure and it's enforced by the project life cycle. And so I think all of these things are intertwined. And I think at the end of the day, if you're not empowering everyone to have an equal voice, then the structure itself, uh, is, is not equitable. It's not a, it's not a good structure.

And, you know, I think that like scrum, agile, all of these different like project life cycle, like, like methodologies, they don't address any of this. Because what I just addressed was politics, but not like, like Democrat or Republican, I'm talking office politics, which we could have an entirely different conversation about. But at the end of the day, that's what impacts your project structure and your project life cycle. So I just think it's something to keep in mind and yeah.

Steph:

Yeah. I think that... You know, I hope that anyone who's early career, we haven't scared you off from working in a team environment. I think, I think that, you know, whatever path you choose solo or team environment is of course valid and is a very personal choice. And, um, I think I've gained a lot of benefits from being able to be on different teams. Um, learned to think about things for sure in in different ways. Like I said, even just learning how to assess a project, you know, in ways better than I ever would have come up with hammering away solo.. Um, you know, so teams are, you know... I have a lot of thoughts going through my mind right now, but ultimately the team experience, you know, is, is a worthwhile experience to have, even if it's not, you know, where you stick around your whole career.

But I think we explored a lot of good - good topics today. Any final, final thoughts, Claire?

Claire:

Um, no, I think you put it, uh, together nicely. I think one thing is that teams... I've worked on a team environment since 2015 since we worked together. And that has made me a stronger developer. It has made me a stronger person. It has made me just a better overall contributor to my space. So I don't want to, like you said scare anyone off because I don't think it's a scary thing, but I do think it's a challenging thing. And I think those two things are different and, um, challenging is, is in my opinion where you grow. Um, and, and, yeah.

Steph

Thanks for joining us on another episode of Word Wrap. Be sure to subscribe on your favorite platform, or pick up the RSS feed on wordwrap.dev. You can also catch us as @wordwrapshow on Twitter. Until next time!