GitLab Digital Experience, 6 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Digital Experience Team Retro - May 6, 2021

Description

Sprint Retro Doc: https://docs.google.com/document/d/1kMNiUF2UDuSrMDuzLyRi8OEhVxry_MJoYi38RmmWafY/edit?usp=sharing
Digital Experience handbook page: https://about.gitlab.com/handbook/marketing/inbound-marketing/digital-experience/
Inbound Marketing handbook page: https://about.gitlab.com/handbook/marketing/inbound-marketing/

A

Hello we're the digital experience team in inbound marketing. This is retro 13 uh for uh the two-week sprint ending today may 6. uh we're gonna, kick it off with uh by talking about things that went well. um I have the first point on the list here. um I enjoyed tag teaming the install page with laura. um We were super quick and efficient with um some of the choices we've made and just getting that off the ground. It was so seamless. Despite some of the noise around us, um laura has a little point.

A

There feeling is mutual plus one I'll vocalize for tyler um I'll read off what he wrote. I feel like this time around. I really got a handle on appropriately scoping and planning work. I only had to push one issue to the next sprint and one of my mrs ran long with the help of barker and tina. We were able to ship and iterate, and I plus one that as well uh jess.

B

I had a pretty great sprint because it was kind of low-key. I had a lot of things out there, but it was just kind of like keeping tabs on like copy and coming in as needed, and so I got a chance to actually catch up on everything like catch up on the research that I did a month or two ago that I never got to actually do the readout for and make some slippers changes that I've noticed for like months. But I haven't had a chance to like talk with steven and get them done.

B

So it was just really nice to have that time to catch up and feel like I'm not constantly, just like in a fire drill, um highly recommend it yeah.

C

I want to call out the the workflow when you have css work when working um from slippers to www is like super easy like when I'm working on a page, and I update the package.json, and I literally like copy paste the code snippet like it just all works so like good for us to get to that point like we were not there like three months ago, so, like super great work, this quarter in terms of getting to that point.

D

Yeah and then I'll just finish up with saying, it was great collaboration with all of our team for q2, getting together, shooting ideas back and forth and then sort of level setting and getting a good uh pulse check on where we're going.

A

All right um anyone else, okay, we can move on to things to improve on. um I have the first note so um cross team collaboration, so our internal team collaboration is um is pretty good uh and during our q2 um kickoff we talked about ways that we can improve, um collaborating with each other, but we haven't actually talked much about how to collaborate with everyone else in the gitlab ecosystem.

A

I have you know no thoughts at the moment, but I'm definitely flagging that as something we need to work on um moving forward. Starting today, um laura you have a point. There.

B

Yeah, because this has started coming up, we have people who are not on our team looking to make changes, and some of the changes are very helpful. We want to encourage collaboration.

B

um Some of the changes were put there like they shouldn't be changed kind of thing, um so just making sure that we're kind of in the loop I mentioned to on one of these, mrs that came in kind of externally three things that people should be doing if, if they're, making changes to the marketing site is number one link the issue um just so we have some context.

B

Sometimes it's just an mr that we get tagged in and we don't really know the context so link the issue um tag a digital experience, engineer like one of the engineers to do engineering code view and tag, one of the designers to do a design review. um So those three things I don't know if we want to add to a handbook, I don't know if that's like a hard and fast rule.

B

I just I think that some pages are like really high visibility and, if they're like okay, our pages and stuff too, that we should probably kind of let people know like just loop us in like to give it a little check. You know, just let us know- and you know it ties in with the racy stuff that we've kind of been talking about also, but I think javi has the next point.

C

Yeah, I just want to follow up briefly, just because I also have the next point, but I want to say that, like I think, if we have okr stuff related to it, I think, like we have ownership over that, and I don't know if that necessarily means we're like the dri for stuff like that.

C

But I just I think that, like if we have okrs attached to it like we should have some say I I don't know that gets into really tricky murky water when there's other people that also probably have okrs attached to it, but like maybe that's something that we can like iterate on further. um I have a very strong opinions on this um um yeah.

C

uh I would, I would just say that, like for stuff, that's like outside of our own krs, I think that, like having brendan in this role of like product technical product owner will help. um I think that, like essentially, the big takeaway for me on this stuff is just that like we should not take people's requests that come our way as gospel.

C

I think like as a collaborator as a collaborating party like we should have ownership to say, like this part of this request, doesn't work for this reason like we need to scope down this, and that- and you know I wrote like reject requests but, like I, don't even see it as rejecting a request, it's more so like. How do we make this request fit within our schedule um and like at what timeline uh do we need things to get worked on?

C

I have like a little point on like I think that it makes sense to have like an established process for requests like that, so like having something like kickoffs is really popular having something like you know, other stuff that like happens within that, um I could keep going on and on, but just I think we need to be a party. That's like consulted throughout the entire process. I think we need to be included in, like the problem definition point of like why something needs to be built out.

C

I think it's really common for people to be like build a page here, whereas, like is a page, the right solution to the problem that you're trying to solve like what is your desired outcome like, and I think, if we're working on agency related stuff like we need to be included in that conversation, and that's like a strong opinion that I have.

B

um I just added in a question which is I'm wondering if some of the issue around people coming in and doing an iteration is that it's so quickly following some another iteration that just happened um and we're not getting the chance to evaluate the initial iteration on how it like improved the or didn't improve uh whatever we were trying to change.

B

um I'm wondering like this is totally hypothetical, so I'm just putting it out there, I'm wondering if we need like a code freeze for like two weeks after a big change, just to say, like hey, we're, trying to evaluate this thing um and if you're coming in with another change, we can't evaluate the first thing unless maybe like a a small spelling error or something might be okay, but like if you're trying to like to make a big change on the page that just got a big change. It's like too soon.

B

I don't know any thoughts on that.

D

It sounds really interesting because it gives it time to bed in and set or settle like, and then we get more data that way like whatever we can measure. We can manage better. So if we're changing things too early, we we don't know if we're actually making correct changes or taking the right approach. I like that, as a concept, I think it's a, I think it's very strong.

B

I'm I'm into it. I yeah I, whether it's two weeks or some some amount of time but like in our example. We did have a page that was like agreed upon by content and design and engineering and everyone, and we all work together. We built the page todd signs off on it, looks great um and then we ship it and then the next day we're getting mrs for changes that we don't have any context around.

B

You know we had a whole team that kind of agreed on this and- and this hasn't yet hasn't settled, so maybe a a freeze on on that, but I don't know if we need a hard and fast two-week rule. If we, if we're able to do that, I don't know I like it, but and also I put two weeks out there. Sorry, just because, like that's when you normally do like an a b test to evaluate it depends on the traffic you get on the page, but like the average is like a two weeks.

B

So that's just random two weeks.

A

Yeah, that's what I was going to say like we have to make sure that if we implement something like that that we're actually measuring stuff- and not just like leave us alone for two weeks.

E

The only case where I would like advise against the two weeks is when there's regressions, so we we deploy something big and it's like. Oh that was broken like when the blog template went out and was like. Oh the click to tweet component. Isn't there probably need to add that you know.

B

That's true, I guess there's like a distinguish between like bugs and improvements if you're thinking, you're making an improvement like did we just improve this page.

E

Yeah yeah copy and design iterations, I would say like two weeks: definitely you know a code regression um might want to do that sooner.

A

um Next is tyler unless anyone else has any more points on this point, um I'll read off um for tyler, um based on q2 the q2 kickoff conversations it feels like. Maybe we're not communicating completely to michael or others about what certain types of work are and what their impact is. I'm not sure what the action item is here, but it sounds like we are missing context inside and outside the team um and jess has the first point related to this comment.

B

Yeah um we're kind of just talking about this, but um we didn't do something that I'm used to doing in quarterly planning, which is like actually estimating the size of the work before we agree to it, um and I feel, like we kind of forgot to do that- maybe this time around, especially with that, I think we've all talked about the 15 page, one which seems like very big, and we all had a different definition of done.

B

um So it's very difficult to like accurately say like. Yes, we can get this done or no. We can't because we weren't really sure you know, like we said, like one page, isn't necessarily equal to another page like one could be very small, one could be very large, and so just saying, like 15 doesn't really mean 15. It's like this is a one. This is a five and like yeah. So it's hard to evaluate- and I feel like we just missed the step there yeah.

B

I just kind of added in that, um when we did the exercise where we held up our hands and put like a confidence level based on our fingers um that opened up a big dialogue about like why we were so not confident a lot of us weren't, confident in what we could deliver in that time, and I think that was really helpful and we started a conversation around it.

B

um So having some sort of mechanism, whether it is like loose uh t-shirt, design or t-shirt uh sizes, small, medium, large um or whatever it is, but something that's like we have a say in what we think the the work will be and and what counts is done, uh javi or no jess. That's me um yeah, so yeah. I also just want to add on to that, because um something we did at lululemon and I thought they did a very good job of quarterly planning.

B

There was yeah different thing um was that they did both t-shirt, t-shirt, sizing and the fist of five, which is the you know. I think five or four three two um and it was like an iterative process. So like first, you estimate with the t-shirt size and then, like we all say: okay, one, two, three!

B

What's your first to five and like if you come everyone for the sake of three you're like okay, we need to go back again and maybe take something off the list or iterate it and say we're only going to do like this version of that and make it a smaller estimation. And then you do the fist of five again and once everyone's like at least out of four, because it's very rare to get five. um Then you're, like okay, cool, we're solid on this. So both of.

E

Those things are valuable.

E

uh I had some points um strong agreement. I actually just added this to my 101 verbatim with michael, um but with like the comparison pages, which is in our okr, which is actually like 80 pages, not just one. um I navigation implementation, the events template which is on deck for like now. um I think it might force us to implement things the cheap and dirty way, um and is that okay? Is that not that's just kind of where I'm like it's like? Okay, um we could do. We could do it that way.

E

um So it feels like we're um we're building a house. We have some of the foundation, but it's not complete um and we're pushing the hard stuff off and it just keeps getting pushed off and out and then not to mention netlify cms, just totally breaks like on gitlab 14.4, unless we fix the authentication and 14.4 is in like three months it might break next month and like that was just nowhere in q2. So I'm like okay, we'll just throw out all that work: cool um yeah, that's where I'm at.

B

Can I just add to that too, because I brought up another good point of things we maybe forgot to do was um add a list of dependencies for this quarter like what are other teams doing. Are there anything outside of our organization like netlify, is making a big change that might affect us. We didn't really talk through that either.

B

And we're down asanmi and going to be training a new nathan, so.

C

Yeah, um I did. I just wrote a little note at the end of that point. Just like. I think there should be like another page that we collaborate on the handbook on specifically because it's like, if this keeps coming up like we should have like some some artifact that like communicates this point, that I think like should be more publicly visible and I think, like the handbook, the handbook page would be like a good place to start with that.

A

D

Yeah, um I guess we kind of talked about it before, but like understanding what slippers is and what it does, it's not this broad stroke solution to absolutely every problem that we have and don't have right now, it's a tool that we can use to enhance our workflow. But it's never really done because we're always going to add and edit and enhance this thing as we use it as we do with any experience.

D

Basically- and I mean it- needs continuous uh love, care and maintenance, and as we do this, it advances us through the the product versioning.

D

So like we're at 0.11 right now, at the end of the next round, we could be at 0.12 because we've made an edit and we can add these things as we go so the more we continuously work on it, the more it brings it forward and adds new features and supports different teams and- and then some sub points to that which is I've already had questions, and I think michael has had some questions as well around like. When can other teams use this and I'm a bit scared about opening it up to them?

D

Just yet, with our lack of accessibility and lack of documentation and how to use it, so we're obviously very familiar with it because we built it, so we have the highest level of that knowledge and- and as a result of that, then that puts us into a kind of a quasi-support role because we're now the design system team, even though we are the output team, so once that happens, we're going to get bombarded with questions. How do we take them in? How do we action them? How do we measure them? Are they important?

D

Are they not? Are they questions on how to use? Are they questions on how they can enhance something? What happens when we give it to a team and they don't see what they want? You know myself and jess are familiar with these questions that come in thick and fast, and you end up being like neo in the matrix, dodging all the bullets, and so we have to help teams, implement and use the system and then simple things like we need to enhance it over time, which is like adding animations and interactions.

D

So it's not just a bunch of static things on the page, so as the brand begins to flesh out more of what the brand vision is. That's when our design system can really kick into gear and really add more interaction, which then makes experiences a bit more palatable to users at different stages, and it just makes uh our.com just that much nicer that bit more nicer overall, so um yeah, it's just a fear of that. People think that this is done. It's not!

D

It's never really done it's just at a stage, and now it needs to be maintained.

B

I mean technically, it's uh like. We haven't actually released version, one right. Typically, like version 1.0 is okay. This is ready for public consumption right and so the fact that we're still on zero point, whatever um is, is our way of saying like this is still a beta thing. You know, um and so yeah I do think like it needs a bit more a bit more time before it's there. um But yes, design systems are ongoing for years. You know so give.

D

A bit of context on that as well, I tell us it took two years and 50 releases to get to 1.0, so I mean we're already far further ahead of that and there's a couple of reasons for that. Like the tool, the tooling is different.

D

We have storybook and we have tailwind and there's more refined processes, and people have more experience on how to do these things, but that's an idea, and that was a dedicated team with an agency so like it was far bigger than anything that we've had it's probably about four times the size with a budget of about 25 million. So it gives you an idea of just like the sheer scale of it, but, of course a telco that is publicly traded will have more dependencies on it.

D

C

I mean like uh I just wanted to speak very briefly on like emotion and whatnot, like it's hard to priorit like this is like gonna sound bad, but it's like the truth.

C

It's like it's hard for us to prioritize things like accessibility and motion when, like we can't even get this system on pages, if that makes sense like, if that's a struggle like it's hard to get everything else in, you know like there's work that still needs to be done in terms of like figuring out how to integrate this nicely with about gitlab when the technical debt for that has been. You know, I mean you, I can go back eight years and see the first commit you know, and there was no.

C

There was no one doing stuff like us before that, so it's like it's gonna, take a while to chip that all the way, and I think that's like what is slowing us down a lot. Is that, like we have things outside of our control that are just like making every change, we want to make a massive lift.

E

I uh that resonates with me, you know I had to take a lot of medicine on tuesday I was like ah we're not actually gonna separate the handbook um which is get cool. I understand why, like, is that really gonna? What pushes get lab stock price through the roof? I don't know, maybe not like, and that's what we got to be focusing on um so maybe reducing like the emotional response. I have to the work that I'm doing um is something I'm personally going to be working on.

A

Are there any other action items we can associate with your your comments, stephen.

A

Let's get into.

D

We can get into it, but, like nothing, give me a minute, I need to no problem cheers.

A

Let's review the other action items, then, if we're, if we're done here um so just to kind of wrap up this retro, uh we don't have a whole lot here, but um javi you have the first one.

C

Yeah- and I think this just goes with, like you know, being handbook- first, writing, mrs for the digital experience handbook page on cross team collaboration and quarterly planning stuff. Like definition of done, comes to mind, um I think those are like quick, easy wins, get people to get the ball rolling on that. um It also makes it easier for like say for onboarding someone new for them to have an artifact of like these discussions that have happened beforehand. So yeah tina.

A

Yeah, I wrote two here but they're from jess um explore code freezes um just kind of take a look at that idea, see if that could work for us.

A

As lauren pointed out, we really want to do code phrases mostly on design and and copy, not on um code regression uh and the other one is uh we need to talk about adding a list of dependencies to our q2 okrs. I think that's a great idea.

B

I have a question around the first one you mentioned about the code freeze for that install page. That was um had a quick uh request iteration after that, did you guys have like a feedback issue for the install page when it launched.

A

uh The issue was the issue, but the uh feedback change came didn't come in in a natural way. It came in as changed code in an mr from a slightly outside party yeah. It was kind.

D

Of hard to define.

A

That situation yeah it's not at all, like all of the other situations we've been through for sure.

B

You could say no go ahead.

B

Yeah I was just gonna say it was something that um originally todd had opened up an issue saying: let's, let's fix this header page um and that led to two or three different kind of iterations and then we we all agreed and then it got kind of re-changed again.

A

B

A

Todd by like someone else that changed the code.

B

A

Created an mr for laura to approve.

B

I know becky often like when we're launching something we'll create a separate issue, like literally just for feedback, be like okay, we're launching this thing. Interview feedback put it here, I'm wondering if something like that also could have helped this situation. Unless maybe you did have that and I just misunderstood but like you could be like. Oh hey, great idea, let's put it in this feedback issue and we can like get it into our um process or something it is.

A

Yeah, that's a good idea.

B

A

B

Definitely different than that yeah because we have mentioned a few times like this page is also one of those 15. Okay, our pages that we're kind of looking at so we have mentioned like. Oh, this is going to get updates like go over here and post post your thoughts in our okr. You know um so there wasn't necessarily a feedback issue, but there there is like a okr issue that you know we did. Let everyone know that that this will be like iterated on, but yeah like in general.

B

If there is no other planned work on the page yeah, we can just open up feedback issues, link it to the original issue, close the first one, then close, the second one. Some number of time later, yep.

A

D

Sorry and yeah, like with the way we've been talking about, you, know, defining the system, as you know how we can open it up and one point, though, like it's probably a good idea to begin to understand, like what is the definition of what one point always and then different, and if, if we know where we are- and we know, we need to be, what are the markers understand that we can hit to get to 0.4 or 0.5 and then all the little subsequent ones that happen after that?

D

I think that that would probably help us yeah as just as a definition of done, and that would help us like communicate more to people about how, when they can start to begin to see their usage of the system and how we can contribute um and there's more to 1.0 than just more blocks more components and more elements.

D

There needs to be documentation, there needs to be accessibility, standards and needs to be code standards. So there's still like a lot of work to do, however, we can still use the system as it is for our use like it's. Not it's not like. It's so far away from being used properly that it basically uses our concept. It's still something that we can use ourselves, but then, outside of that, it's a bit sketchy about really giving it to other teams, because we need to have support models set up.

D

So I it would be good to do. Maybe something like how do we? How do we get to 1.0 based on where we are so we know what the journey is, um and it would be great to somehow define different steps that we can have throughout the next sprints and what people are doing if they can contribute small bits and sort of like divide and conquer.

E

E

ah I get the next one, I'm gonna start with. Like I love git lab, I love working here. I think it's like the best thing ever, um but something I'm personally going to work on. um Possibly a team is to reduce uh emotional investment in projects.

E

There's certain projects that I start doing and I'm like wow, like you know, I'm going to bed thinking about it, waking up thinking about it and I'm. I just think it's the best thing in the world and um that's great, but sometimes I think it silos me into just really being all about that project, um and this is I mean it's a. This is a job. You know this isn't like real life.

E

It is real life, but not you know what I mean like so yeah, um so reducing the emotional investment in that and then also reducing the response that I have the emotional response. If their decision comes that, I don't agree with and not being um just really sad about it just being like. Okay, there's a decision made, that's the decision. Now you got to go forward with that um and that's something that I'm going to work on.

A

Yeah, I plus one that that resonates with me- and I just you know the something I I use. A lot is like what I think a lot is like I'm a duck like when water falls on me. It just rolls off my feathers, and so, if I get like I'm a duck, I'm a duck.

B

I added in the disagreeing commit in there link, um I think it's something amazon originally came up with, but it is helpful to just like say your piece fight for what you want, but then, when the time comes and it's like not up to you you're like okay, I totally disagree, but I'm committed and I'm going forward with it, and it doesn't necessarily help with the emotional aspect of it, but maybe a little bit I mean.

B

Sometimes it is hard to get separated from something you really believe strongly in, um but it is a path forward.

A

Thanks, I love that you always have a link for everything. Jess.

A

um I guess that wraps it up um wraps up our retro last retro of the quarter. I guess see you in two weeks.