All right. Hello, everybody. Welcome to the UX at GitLab webcast, a deep dive into GitLab's UX process. Very quickly, I'm just going to go over the speakers that you'll be hearing from today. First is myself. I'm Sarah Vesloff. I'm the UX manager here at GitLab. Catherine Okapara is our junior UX researcher, and Tori Davis is our staff UX designer. Dmitri Hookstra, who won't be speaking, will be helping out by sharing links along the way. So as we talk about specific resources or issues or things that we'd like you to visit, he'll go ahead and put those in the chat. And feel free to post your questions using the Q&A feature. We're going to answer them all at the end, but you can post them anytime. You should see that little Q&A feature on the menu bar. So if you're not familiar with GitLab, I'm going to tell you a little bit about us first before we dive into the UX team itself. At last count, the entire GitLab team, at last count being yesterday, I think, the GitLab team consists of 339 team members and there's 78 pets. We're a remote only organization, and we currently have team members in 42 countries and regions. So we have no home office, there's no central location, there are not offices in different countries. We all work remotely from our homes or co-working spaces or wherever is convenient for us. As an open source company, we do everything in the open. And just like our product, our team handbook is open source and 100% public. So anyone in the company or outside for that matter can suggest changes, additions, and make edits to it. So that includes you. If you see something, you see a typo, or you think something could be worded better, go ahead and make a suggestion. And most likely we'll make a change. And you should see a link to the handbook in the chat. So the handbook also includes an entire section devoted to the UX department. We're going to go over a bit of that here today. But if you're interested in some full details or maybe there's something we don't have time to answer at the end, I suggest you peruse through the UX section of the handbook. It has a lot of really good juicy details on our day-to-day operations and how we think about the work we do here. As of right now, the UX department is made up of two UX researchers and 10 UX designers. Together we expand eight countries and six time zones. We are hiring. That's why I say as of right now. So please stay tuned at the end of the broadcast to learn more about these open roles and be sure to post any questions you have about those roles. So if you're curious about what it is we're looking for or what kind of skills you need, we're more than happy to elaborate on that at the end. So how we work. I wanted to make a quick note here. You're going to hear me use the term UXer during this webcast. We kind of went back and forth on whether to use it. It's how we refer to members of the UX department, both researchers and designers here at GitLab. So when you hear me say UXer, that's anybody that is on the UX team. Just out of habit rather than saying designer or UX designer. It's kind of our little short code. So just an FYI. And I do want to touch just a little bit about on GitLab itself. I think it's important for context to understand what GitLab is and what we do if you're not familiar. And that will help you understand a little bit more about the unique way that our team works. So GitLab is a single application for the complete DevOps lifecycle. It's the first single application built from the ground up for all stages of the DevOps lifecycle. It enables the team to collaborate and work from a single conversation instead of managing multiple threads across disparate tools. It provides the team a single data source, one user interface and one permission model across the entire DevOps lifecycle. This allows teams to collaborate and significantly reduce the amount of time that they need to work together. And as you can imagine, given what we do, our user base is broad. It consists of developers, project managers, UX designers, product owners, office owners, and business owners. And it allows the team to work together and work together. And it allows the team to work together and work together and work together. And it allows the team to work together. And it allows developers, project managers, UX designers, product owners, operations management, and many more that I don't have time to list. There's a lot of different people that use our product. And here at GitLab, UX is actually part of the engineering team. And that means that each team stage has a dedicated UX designer. Oops, I started a little bit late. Let me back up a little bit. We do have two departments here at GitLab. We have Dev and Ops. And within these two departments, we break things down further into team stages. So each of those team stages will have a dedicated engineering team and product manager. And since UX is part of engineering, that means each stage has a dedicated designer. So the UXer on each team is responsible for the same features that their PM oversees. The UXer will work alongside the PM at each stage of the process. That means planning, discovery, implementation, and further iteration. And the area a UXer is responsible for is part of their title. So you'll see UX designer plan, UX designer release. And you can see each of these aligned in our team org chart. And you should have a link there to go see our team chart. You can filter by UX and you'll be able to see where every person works. UXers can also serve as a backup designer for other areas of the product. The area will be listed on the team org chart under their title as kind of an expertise. So you may be the UX designer for plan, but you're also a release expert. And that means that you can kind of pinch hit if someone is unavailable or we have an unusual amount of issues in one area at a time. And we follow a monthly release cycle. So we ship on the 22nd of each month here at GitLab. We plan and track these monthly releases using milestones. Our release timelines are overlapping. So for example, when a release is shipped to production on the 22nd, the scope for the following release has already been established earlier in that same month. This visualization here kind of gives you an idea. It's one of the hardest things that I had to learn here at GitLab when I was starting. I had a really hard time with what milestone are we in? Because you're really wrapping up one as you begin another. So each month the team, meaning the UXer on the team, the product manager, the front-end and back-end engineers will communicate in the issues about scheduling and prioritization. So they'll have conversations back and forth about what we know, what we don't know, and whether this can be done in one release cycle. Once the issues in a milestone have been set, the UXer will assign themselves to the issues in the area that need UX attention. And they'll try to gauge whether they have time for all of the issues, or they have to go ahead and push some off to the next release. And as a 100% remote company, we do work asynchronously. So we use GitLab issues to propose and discuss UX improvements across the product. All of our discussions happen within the issues. This includes adding notes from Slack conversations or the occasional asynchronous or synchronous meeting. So we'll go ahead and make sure that we're linking to a document from a meeting or linking to a Slack thread so that everyone is involved on the conversation and no one is missing out. Collaboration is one of our core values here at GitLab. It's about helping each other when we have questions, need critique, or need help. It's not about brainstorming or waiting for a consensus. As we work through individual issues in a milestone, we involve the entire team in the discovery and design process. That means engaging engineers, product managers, community members, customers, and other UX designers on the issue for critiques and input. However, we do make the final decision. So again, it's not a design by committee, which can be disastrous as we all know. It really is about collaboration and getting all the information you need before you make that decision. So the UX department has a shared project on GitLab. This project houses all of our work in progress and finalized files along with prototypes. So this shared repository helps ensure that we're able to find the files and designs whenever necessary without needing to reach out to another member of the department. They're always there in the repository. Each issue is different, but we'll often begin with designs and sketch. You will see pictures of sketches. So we'll take images of sketches maybe that we drew by hand or wireframes from other programs or even wireframes that we made in Slack. Whatever makes the most sense for the issue we're working on. And we share those designs in the issue, asking for feedback and iterating on it until we get it right. Once it's complete, that design is implemented inside of GitLab. So we've talked a lot about how each UXer is dedicated to a product stage, but they're still part of the larger UX department. We meet together on a weekly basis to discuss announcements, initiatives, design ideas, process improvements, pretty much anything we think is important. We'll share articles, we'll share redesigns that we think are really cool. It's kind of our opportunity to socialize and talk shop. This helps us stay aligned on our vision and goals for UX at GitLab. And these calls are recorded in attendance is not mandatory. Important to note as an async company, we try to accommodate everyone's different time zones and schedules and family needs. So as a manager, I will meet each member of the department in a bi-weekly one-on-one. It gives us the opportunity to talk about challenges, opportunities for career growth or personal growth here at GitLab and beyond. And finally, the most exciting, of course, the entire company meets about every nine months somewhere in the world for the GitLab summit. The summit allows us to get FaceTime, build community, and get some work done. Our next summit will take place next week in Cape Town, South Africa. And there should be a link for you to check out the details there. So next I want to touch on iteration. It's an incredibly important value here at GitLab, particularly for the UX department. So I'm sure that you've heard the term iteration. It's very common, common in design, common in agile methodologies. Here at GitLab, iteration means making the smallest thing possible and getting it out as quickly as possible. So small and so quickly that it sometimes is painful. We know it's painful. You might feel embarrassed by how unfinished or unpolished your suggestion seems, and that's okay. If you're doing iteration correctly here at GitLab, it should be painful. It should hurt just a little bit. Working like this is extremely important for us. It allows us to reduce the cycle time and get feedback from users faster so we can continue to improve quickly and efficiently. And iteration isn't just one of GitLab's six founding credit values. It's one of the foundational concepts in design, thinking and user experience. Planning too far ahead without getting real-world feedback can cause you to build something that just doesn't meet user needs. It wastes valuable time and it can bring the team so far off track it can be hard to recover. And there should be a link here to our values. It's an interesting read if you have some time. And we really think that iteration is especially vital in an open-source community. Keeping changes small and iterative makes it easy for anyone at GitLab or in the community to contribute, and that means you. We keep a list of improvement issues that are actively seeking contributions from the community. They're small in scope and they allow the community to contribute designs or code to issues. And I'm going to talk a lot more about this later on and give you an idea of how you can contribute here at the end of the presentation. So I'm going to stop talking for a little while and give Catherine a chance to talk about how we do UX research here at GitLab. Take it away Catherine. Thanks Sarah. Okay so let's start with the general overview. The goal of UX research is to understand the needs and concerns of users often by observing how they interact with the product and other times by gathering data through methods such as surveys and user interviews. Our UX team specifically strives to meet the needs of our users while balancing product requirements and milestones. Now this can often be difficult when you need to juggle a lot of different opinions and expectations. So having user research to back up design decisions will keep you from second guessing yourself when you receive feedback. Next slide. If someone is interested in exploring your research question, we encourage them to create a new issue using the search proposal template in our UX research project. This template encourages contributors to describe their questions and identify any assumptions or theories they may have. After reviewing proposals, we determine the types of studies to conduct. Some of our most common UX research methods include survey research, usability testing, user interviews and card sorting. A great way to choose research method is to ask yourself what you'd like to learn, who you need to reach, and how you want to communicate your questions to the participant. For example, that could be visually, verbally or both. Next slide. After deciding on a method, we recruit participants from our research panel and conduct a study. When a study has been completed, it is important to analyze the data and interpret the results in an unbiased way. It's often helpful to outline the factors, if any, that could have influenced the results and discuss other possible interpretations. This helps us keep a balanced view of the situation and prevents us from confirming only our own hypotheses and assumptions. At the end of each study, we create a report and communicate these results to everyone involved in the issue. From that point on, we use the results as a way to identify actionable steps forward. Discussing the results of our research with other designers and product managers helps us prioritize feedback and determine the next steps to take to implement the findings. UX research is an important aspect of product design that can occur in different phases, whether exploratory or evaluative. UX research is a valuable way to gain a deeper understanding of the users. Next slide. GitLab's navigation redesign is a great example of the product area that has benefited from research and design iteration. From March to April 2017, we conducted three usability tests to observe how users navigate throughout GitLab and to understand where they encountered issues. These tests were moderated, which means that a researcher was present as the user completed different tasks. The initial test highlighted a large amount of usability issues in various aspects of our UI, such as the project navigation, sidebar, and search bar. This gave our designers a detailed report on problem areas and open issues that needed to be addressed. The follow-up usability tests were conducted as a way to test how much progress had been made after improvements were implemented. These tests showed us which issues still remained and which issues were successfully resolved. Next slide, please. After highlighting a large amount of usability issues related to contextual navigation, we then conducted card sorting tests. Card sorting helps you discover how people understand and categorize information. The goal of these tests was to determine the optimal structure of the contextual navigation at a project and group level. 72 users participated in an open card sort of project level items, while 46 users participated in an open card sort of group level items. Users were asked to organize navigation-related content by creating categories and organizing the content in those categories. After analyzing the results, we created a recommended contextual navigation structure based on the way that the majority of users categorized the content. Next slide, please. We conducted a round of tree testing after the card sorts to test how well users could find the information they needed when using GitLab's existing contextual navigation versus the optimal one we highlighted in the card sort. Tree testing is particularly useful for tracking and mapping the different paths users take when they are searching for information. We used the results of this study to identify five key changes that could be made to the project and group level contextual navigation. This study helped us organize the menu items in a more intuitive way, and it also just gave us general insight on the ways that users interpret the names of items we include. Next slide, please. As a result of these continuous efforts to improve our navigation, users who were once frustrated by their experience navigating GitLab became supporters and contributors to the effort. As we move forward with our user research, we now have qualitative data to measure future improvements against. A key part of our practice moving forward will be gathering baseline data on features before introducing changes. Next slide, please. We have created an archive in the GitLab handbook to serve as a place for all product contributors to learn about the reasoning behind design decisions, and also to see a history of the progress we've made. The UX Research Archive is a collection of all the reports from all the studies we've ever conducted. Feel free to take a look through it to learn more about UX Research at GitLab. Next slide, please. The research panel is our database of both GitLab users and non-users. We send out invitations to participate in surveys, interviews, card sorts, and more. If you want to get involved in our research, please join the GitLab Research Panel using the link in the chat. Next slide, please. And now I'd like to introduce our next presenter, Tori Davis. Tori is a staff UX designer at GitLab and a design enthusiast that years of experience. On to you, Tori. Thanks, Katherine. So one of our major initiatives that we started last year was our design system. And for those who are unfamiliar, a design system has multiple different parts that often include content guidelines, usability patterns, foundational styles, and reusable components. And these are a lot of things. We knew that implementing a design system into GitLab, an already pretty complex application, would be challenging. And we thought that even though it would be a lot of work, the benefits definitely outweighed the time investment that it would take. Next slide, please. So to start, we identified some of the primary benefits that a design system would give us. We knew that by shifting our focus towards system thinking, we would be able to create consistency throughout the product as well as predictability among our experiences. We also knew that designers, engineers, and product managers would spend less time reinventing the same solutions, and that would give us more time and energy to focus on the problem that they were trying to solve. And with a set of reusable components, we would also simplify our code base and create more autonomy among the teams because the clear documentation that we were writing would give everyone the ability to reference and use without having to ask someone on the UX team for clarification. Next slide, please. So I mentioned before that a design system can simplify your code base, and we knew even before starting this process that we had a lot of duplicate code on the front-end side. There's also a lot of minor inconsistencies that you can see throughout the products that we're completely aware of before we even started this process. We did an inventory of the application and found that we had 82 different variations just of the color gray. We also had over 32 different typography styles, which actually isn't that many if you take into account all the different states like hover and active states, but they're also defined in percentages, rims, and pixels, so there wasn't really a cohesive or predictable type system in place. Next slide, please. So Pedro, who is also a designer on the UX team, worked on an interface inventory, which documented all of these inconsistencies that we were finding, and many of these were issues that we were all aware of, like I mentioned, but it was nice to kind of get them all in one place to visually see. If you've never done an interface inventory before, it's pretty easy, although a little monotonous as well. You just go page by page and take screenshots of all the variations of a certain component and then paste them somewhere so you can easily reference them later. Next slide, please. So from there, we were able to start looking at what made up the foundation of our designs, and this included a solid typography system along with a structured measurement rules and color guidelines. And for us, building this foundation first was really important because it was the base that allowed us to build the rest of our components. Next slide, please. And we didn't nail it right away at all. It took us some discovery to really figure out what worked best for our product. Typography was a huge one and we ended up creating a series of three typography systems to use, depending on the application. We also introduced an outlier within our measurements that you can see in this slide, which gave us the ability to have better horizontal spacing for things like forms and buttons. So in this example, you see on the left, we started with 16 pixels, but it was way too wide and then eight was too narrow. So we ended up going with 12 and that was our outlier number. So even though we started with these base styles, we made sure to apply them to some of our components and make sure that they would work well. And then if they didn't, we just adjusted them along the way. Next slide. So a large part of the shift was to start thinking about design systematically and in order to do that, we use Brad Frost atomic design principles, which is fairly well known and common now. This approach breaks components down into atoms, molecules and organisms. Atoms are essentially the smallest piece of your product. So a button, icons, things like that. And when combined together, you get molecules. And when you combine molecules together, you get organisms. So here in this slide, you can see an example of the molecules that make up our contextual sidebar. And the modifiers you see are the different states that a molecule can have, like a hover or an active state. So by using this system, we were able to start building out the most commonly used atoms in order to create, then create the molecules and organisms. And we did this within sketch. So now we have a pattern library that we can reference as we build out our documentation and actually implement the new system. Next slide. So a design system is more than just a pattern library within your design tool, right? To get all of the advantages, we knew we would need to include these three parts, usage guidelines, front-end guidelines and live code examples. And one of the key differences between a design system and a pattern library are those live code examples. We don't include images in the design system because they can easily get out of date and are difficult to maintain. So instead, we're really focusing on creating a system that has these live coded examples, which will also be used in our products. So they're always in sync with each other. Next slide. So we've already started writing usage guidelines for multiple of the areas of the design system, but there's still a lot to do. We have a lot of work ahead of us still. We're working really closely with our front-end team to implement our system iteratively. And if you look at the system right now, you'll see there are a lot of to-dos. And that's because at GitLab, we don't really believe in keeping everything hidden until it's perfect. We have everything out in the open, and we're constantly making changes and improvements as we go. Next slide. And right now, we don't have a dedicated design system team. Every designer on the team is writing usage guidelines every milestone. So we each pick at least one issue within our issue tracker to contribute to the project. And our front-end team is working on laying the foundation that will allow us to implement the updated components throughout the product. So even after all the to-dos are filled in, we know that the design system will never be finished. And it's open source just like the rest of GitLab. So everyone is encouraged to question any of the decisions we've made or contribute by making things more clear or adding missing content or any other way. And now I'll pass it back off to Sarah. Awesome. Thanks, Tori. Really appreciate it. So now we're going to talk about how you can contribute to GitLab. Probably the most exciting part for me. So again, as an open source company, we believe in transparency. We share almost everything we do. Anything that we can share is shared. Source files, artifacts, deliverables, case studies, UX research, and our findings. And you might be asking, why? Why would you share so much of the work that you do? And it's because we believe that we can do more together. Being open source allows the community to learn from us and for us to learn from the community. So why should you contribute? I think there are a lot of reasons. But I pinpointed a few here. First, contributing to GitLab gives you a chance to collaborate in an open community and to work with passionate people from different parts of the world. It's an unusual opportunity. I can say that this is the first time I've ever worked in a company like this. And it has been inspiring. That sounds really cheesy, but I mean it. I'm just astounded every day. I'm challenged every day by the experiences and the different viewpoints of the people that I work with here. And I think it's something that if you have the time to dig in and be a part of, it's really worth it. And another thing, if you're just starting your journey as a UX designer, you'll have the opportunity to work alongside the entire UX department here as well as engineers within the team to solve real-world problems. I think one of the biggest things that I hear when I go, when I do mentoring and I speak to those coming out of boot camps or just finishing up their degree is how do I get experience? I have this degree or I have the certificate and I have the drive and the passion, but I can't get a job until I have the experience. And I can't get the experience to get the job. And so this is a really fun way on your terms to contribute what you're interested in, work on things that are interesting to you and gain some experience that you can take with you into the job market. And if you're a seasoned UX designer, you'll have the opportunity to explore new problem spaces and mentor junior designers. Maybe where you are right now, you kind of feel stuck, stagnant. I've been there before where it's like, ah, I know how to do this. I've been doing this a long time. Maybe even I could do it in my sleep, you know, and you want that challenge. You want something that makes you sweat a little.  They're really interesting and complex and require a lot of thinking. So it can be really challenging and interesting to help work on this product. Anyway, not be sure where to start. I think it can be overwhelming, particularly when you look at the DevOps lifecycle and all of the things that we do that can seem complicated and intimidating. They're not and we're here to help you. So we're going to link in the chat to a list of issues that you could start with that I think are a nice ramp up. They're issues that have been labeled accepting merge requests and they need some UX work. So accepting merge requests is a label that we give to issues that have an idea we really would like to implement in GitLab, but we just can't prioritize at the moment. So we'll mark it with the accepting merge request label to let the community know that we would love for someone to pick it up. And when you see the UX label, it means that it also needs the attention of the UX designer. So in some way, shape or form, it has an effect on user experience. We want to make sure that we think about that before someone goes and actually does a merge request to add the code for this. Most of these are very small issues and it's the perfect starting point if this is your first time contributing. But you may also have an idea for your own UX improvement. Maybe you use GitLab at work or you've used it casually for some projects that you've been working on and there's something that just drives you crazy or really bugs you. We welcome your suggestions. In fact, I can't tell you how much I look forward to issues that are created by our customers and by our community. They're important because you're the user.  So to suggest a new feature or user experience improvement, we actually opened a new issue in our Community Edition project. There should be a link in here for you to check it out. So you want to start before just jumping in and opening an issue by doing a quick search and just see if anyone else has made the same suggestion. It happens a lot. So we try to make sure we're not making duplicates. But it does happen, so no worries if it's a duplicate. We can always merge them together. But once you're fairly certain it isn't, if you weren't able to find anything else referencing the problem that you're having, you can create an issue using the feature proposal template. Just fill in each section of the template, describing the problem you're trying to solve and your proposed solution. And you want to make sure to follow the contributing guidelines outlined so that you can add the correct labels. So make sure to check out those contributing guidelines. Who to pay? You can reach out to the UX department for help and guidance on any of this. Simply use the at-gitlab.com or gitlab-com forward slash gitlab-ux. Not exactly simple to remember, but it's there on the slide. If you insert that into a comment or in an issue, it automatically pings the entire UX team and lets us know, hey, someone needs your assistance. Someone has a question for you. So use that to bring attention to your issue or bring attention to something that we're interested in working on. And we'll try to get back to you as soon as we can. And finally, we do currently have three open positions for UX designers. We're looking for UX designers with an interest in our product. So whether that's the development side or the ops side, if it's a code review, portfolio management, continuous integration, Kubernetes, we have a lot going on and we have something really to offer for anyone. So if you're interested in checking out our openings and seeing what it takes to get on board here at Gitlab, please take a look at the links. There should be a link to the description for a UX designer here. And then there's also a link to apply. The slide shows the open teams. So we're actually recruiting for specific teams that are going to need a lot of UX work. So right now that is our release and verify, monitor and secure teams. And I just want to thank everybody who has come to listen to us, talk about UX here at Gitlab. It is definitely something we really enjoy talking about. And I really appreciate you taking the time out today to listen in and hear about what we have to say. It looks like there's some Q&A. I'm going to go through and answer some of these. And I'm not sure how to do this Q&A. So let's go ahead and do this together. It looks like some of the questions people want to answer live. So does somebody want to jump in, Tori or Dimitri and open these up and answer? I think it might be smart to begin with the first one. The oldest one has been asked and go all the way back. The first question would be, what do you currently feel is the biggest UX related challenges at Gitlab? Would you answer, Sarah? I knew you were going to kick it back to me. Thanks, Dimitri. Yeah, it's a really good question. So I think one of the biggest challenges that we have right now is growing the entire department at the same time that the company is growing and trying to make sure that we're able to address all of our plans for the vision. So there's a lot of features that we have planned and there's a lot of improvements we want to make to existing features. So you kind of have to do this balancing act between adding value to the product and making sure that we're doing everything we can to be useful. At the same time looking at issues or not issues, but features that are already out there that need additional improvements. So that can be a really challenging thing, right? It's like, do you do this or do you improve this? Which is going to give you more bang for your buck, more for your time spent? So we do a lot of that. And I think that's a lot of the challenge that we face as individual designers on the team, kind of that push and pull between improving certain things and then adding additional features. I'll just go down and read some of the questions. Tmitri, Tori, Catherine, if any of you want to jump in and answer any of these, please let me know. So the second question, you mentioned sharing the sketch in the issue in the beginning and the iterating based on feedback. Do you get customer user feedback at this point? Yes. We get a lot of feedback from customers, from community members, as well as from other engineers and designers on the team. So it's really interesting. So you'll have this conversation in the issue. So it starts with a description like this is the problem we're trying to solve. This is how we think we might be able to solve it. Go. And then you start talking back and forth of maybe I don't think this is the right solution or have you thought of this? And at some point it gets to the stage where you actually want to sketch it out. And once we do that, we'll put that in a comment and say, what do you think of this? Does this solve the problem? And that's when people will chime back in. And often help drill down to the actual solution. A lot of times we find that over time, our solution gets smaller and smaller, which is actually better, right? We're stripping away all the things that we don't need to do and we're concentrating on just the thing that's going to solve that problem. So here we go. When you put out something very crude early iteration, do you roll it out for everyone? Or how do you roll it out usually? Quite often we just roll it out. Again, iteration is painful.  Oh, I'd like to do this and I'd like to do that. And I wish that I had time to do this, but you have to resist that temptation. It's really important to get it out there early and make sure that you're on the right path. So often there are things that will roll out as long as it is an improvement over the existing user experience, we will roll it out. If it's something that could have a high impact, so there's a lot of risk to rolling it out, we will be more careful. So the navigation redesign, for instance, there's a lot more risk in that, right? People use the navigation every day to get from one area of the product to another. And hindering them is dangerous. So that we did roll out in a beta and allowed people to opt in. So progressive disclosure, right? People could opt in. We created a feedback issue for our customers and the community and other Git labbers to say, hey, this is working or this isn't. And it allowed us in two releases to completely redesign the navigation and roll it out for everyone. We're also utilizing feature flags for some features that may be more risky. So we implement a feature flag and we can roll it out to a specific portion of Git lab, but we do try to make sure it's an improvement that everyone will not feel like is risky to them. So we don't have to use feature flags that often, but it is an option for us. Thanks, Tori. So the next question. For people starting out in UX, what's your main recommendation to get skills on? This is a good question. There's so much. It could feel overwhelming, right? I think that for UX, getting experience on several fronts is really important. So one is the basics of design thinking and design skills. So understanding how as a designer, you're going to approach a problem, think through a problem, and try to get results and solutions. How are you going to visualize that problem? So wireframing, typography, color theory, layout, those kinds of foundational elements of design are extremely helpful. I see a lot of people come from other fields and they have transferable skills that they can use. So experience in research, whether it's through a degree that you were pursuing that included research, or just something that you enjoy doing for yourself, kind of researching different topics, that's a big help in UX because so much of what we do is about asking questions and analyzing the answers that we get. I also think that if you intend to work on, in the technology field, it is important to at least have a basic understanding of development. That doesn't mean that you have to be a developer. I'm not saying in any way that to be a UX designer, you have to also develop. But it's important to understand how your designs are going to be implemented. So even if you're not working for a tool like GitLab, which is for developers and for people that are working in code every day, it has to be implemented in code, right? Somebody's going to have to build it in HTML, or CSS, or USAS, or maybe they're building in React and they have to componentize everything. Understanding that as a UX designer is really helpful when you're putting things together. It's going to make that handoff and that conversation a lot easier. And it looks like the next question is good for you, Catherine, maybe the next two. So the next one is, how do you combine analytical data in UX research? Sure. A good example of that would be, say if you have a problem area in your site, like a certain feature isn't being used a lot, you could run analytics on that feature and try to get the baseline data for how many people visited this feature and has there been any big change? Like, did we just make an improvement to it or basically a change that might have impacted someone's opinion on it? So you can get a baseline data and then run some research to test, okay, how did people react to this change? What did they like about it? What did they not like about it? So you can mix that together as a way to kind of balance the analytical approach with more qualitative approach. That's what I'd say. That's a good example of that. And for the next one, how did you recruit users for card sorting, tree testing, and et cetera, and do you compensate them? So yeah, so we maintain a UX research panel. Basically, we have a sign up link on our, on our marketing website where people can opt in to receive invitations about different studies that we send out. And every time we have a study, we basically ping a list on MailChimp and say, hey, if you want to participate, you have a chance to enter a prize draw for Amazon gift cards and whatnot. And so that's usually how we handle it because we receive a lot of responses. So it'd be difficult to pay every single person in the case of a survey, for example. So we do a prize draw. If it's a smaller group of participants for something like user interviews or usability testing, then we'll pay each participant. That's usually how it goes. And next question. You mentioned wanting to gather baseline data before introducing changes. How are you thinking to approach this? I think I'll answer this as well. We're looking into different analytics solutions that we can use for different features on JetLab. It's a little challenging because we need open source options. So we're still trying to figure that out, basically. But basically, the best approach to that would be actually installing some kind of analytics tool that's gathering data in the background so that we can check and see how often people are using certain features and kind of when the different changes happen. So did usage of a certain feature change after a certain release? Why or why not? What was different around that? What was different in the context we could use to make those plans positioned? Yeah. And on to the next question. Yeah, I can. So I'm going to pass this off to the next question to Clement, who is here from the front-end team. It's regarding our internal structure and thoughts based off of the View One Year Later blog post. Just our choices made with View, View X, and maybe other approaches related to that structure. That might have changed or improved since then. But do you mind answering that one for this person? Yeah, I can answer. I'm not 100% sure what the question is, because I haven't seen that blog post in a while. But basically, with the design system, the front-end team is also trying to set aside time to build components that implement the design system as well as CSS framework that influence the design system so that both code bases for Hamel, non-View code can still use our styles, as well as View code can use our styles. And as we create more deliverables, create more front-end work, there's a higher degree of view stuff that's being written. So there's still a possible chance that one day maybe GitLab will be an all-view application, and then all our design system stuff will be view components. But for right now, since we still have a lot of things in Hamel, a lot of our design system will be more CSS-based first. But we also have these components that automatically have the styles. So we kind of have this dual approach for now. But yeah, that's kind of where we're heading at this point. Thanks. And next question, I think, is back to you, Catherine, about our research panel and sourcing. Right. And I'll pass this one on to Sarah O'Donnell, who is a senior UX researcher at GitLab. So this question is in relation to how we manage the research panel at GitLab. So what we currently do is actually we recruit users through a MailChimp link, and then the details of the users are stored within MailChimp. We segment the list within MailChimp, so we don't send too many campaigns to users and bombard them. We want to keep active users on the research panel as well. So we're looking at how many studies they kind of take part in and how many they've completed recently, because we don't want any kind of bias. And we don't want to kind of hear the same voices over and over again. And again, and then we just kind of offer incentives ourselves. We pay normally through Amazon gift card. There's a lot of manual management of a research panel. I'm yet to find a good solution out there. So if anyone has any recommendations then please do let me know. It is a very manual process, but it seems to work for us so far. Great. And next question is about how we keep and maintain our library and sync with the current production code. And this is something that we are working on right now. Essentially the code will be synced between the design system and the product. So it'll just automatically be in sync all the time because it's using the same code. I don't know, Clement, you want to add anything there or not, but essentially it's just using the same code. So it'll always be in sync. I think, I think a side note to this question would be that perhaps this can be seen as like, how do you keep the pattern library in sync with the production code, right? And sorry, could you perhaps elaborate the question from, from that perspective? Yeah, so the pattern library, we, if we make a change then the change is coming from the pattern library typically. And where we want to get to eventually once the design system is in place is that we don't have to worry about the sync between the pattern library and the design system because we're all working from the design system. So it's not about like keeping everything and sketch completely 100% what production is because we have the design system in place and we don't need to do that anymore. The pattern library is really a step to the design system. And then once we're there, that's what we'll be working from. And it's really a chance for designers to kind of make prototypes in the browser more easily and things like that. So we won't be relying on sketch so much as we are right now. Hopefully that answers that question. Thanks Dimitri for pointing that out. I didn't realize that's what I was asking about. And then Sarah, you want to take the next one. Sure. So the next one is, is there a recommended timeline that you follow for each iteration to the product? I'm going to say no. I think anyone else can chime in here. You know, there isn't a prescribed timeline. It's not as though we have an idea for something. And then we decide that we're going to iterate this and this milestone and then this and then this and then this. Really, we do approach it milestone to milestone. So we try to make the smallest change possible, something that's doable for the team inside of that milestone and get it out there. And then in the next milestone, if it's still priority to continue iterating on that, we will. Sometimes it may not be. Sometimes the goal is to get it out there and then gather feedback and see what do people think of this feature. Are they using the feature? So that allows us to go and work on other iterations of other features or new features. And so in that way, I wouldn't say that there's a recommended timeline. Really, the baseline is, are you making the smallest change possible? Are you making sure that you're getting things out in a quick timeline so that you can gather that feedback quickly? And that's kind of our barometer for how we're iterating. And the next one is really interesting. I think it's a really good question. So the next question is, how do you tackle the somewhat primal need, I love that word, of being physically present when discussing some topics, such as brainstorming, co-planning, or prioritizing? How do you actually collaborate during a sprint cycle? Oops, I think jumped. There we go. Does it change if it is a microtopic versus a macrotopic? I'm going to answer a little bit on this. And then I'd love it if Tori or Dimitri or Sarah or Katherine wanted to jump in here. I think that there is this urge sometimes to have a meeting, right? You're talking back and forth in an issue. Maybe you're not sure if you're completely understanding what the person is saying. And you kind of have this go to of, well, we'll just jump on a meeting and talk about it.  The problem with that is that it's just you and that other person, most likely. Other people are not privy to this conversation. They're not going to hear the what, the why. Even if you get a summary put into the issue, they could miss a lot of the context. And it's just not efficient, right? Having to wait for people to be able to get together and actually be in the same space just isn't productive. It slows us down. So all of our collaboration is really done within the issues. Do we have meetings? Absolutely. Sometimes there'll be a kickoff meeting, which really isn't about brainstorming so much as the planning and the prioritizing. But we try to minimize that as much as possible. Tori, Dmitri, anybody else want to jump in here? No, I think that was great. We only have seven more minutes and a lot of questions. So we can just keep going through, I think. Okay. All right. Oh, a great question about research. So Sarah, I think the other Sarah, not me, obviously, you want to jump in here. Sure, Sarah, could you tell me what the question is? Oh, so this one was about design focus issues that people can contribute to. So I don't know if you have issues that you can link for them to contribute to, Sarah. Oh, for research. Yeah, the question is these don't really seem research focused. What if you want to help with research related problems? Is that something that we're going to put together? Do you think Sarah, do we have maybe some time to gather some stuff that people could assist with? Yeah, if people want to be involved with research, by all means, we are always interested in people who can help us with things like competitor analysis. We are even happy to do some usability testing if they're willing to kind of work alongside a researcher at GitLab. So we can definitely put something together if people are really willing to be involved in research. That'd be fantastic. Awesome. And the next question, sorry about that. No, you go. And the next question is how would you describe the UX research demand versus output capabilities? And how does it tie into the current amount of UX researchers? Everybody wants research at GitLab. This is why we don't bother an extra pair of hands. People who would like to help contribute towards the research efforts at GitLab. We would love to speak to you. You can reach out to me directly at GitLab. My pin name is at Sarah Odi. And tell me what kind of research you've done and what you'd like to be involved with. That's awesome. So the next one is what is something you wish you knew when you were starting out as a UX designer that you know now? I'm going to kick this to Tori. Okay. Something that I wish I knew when I started out as a UX designer that I know now. I think that I, the focus is on problem solving. So something that I may not have fully realized when I was first starting as a UX designer is that it's not really about the solution. It's about the problem. So as long as you are actively trying to figure out what, what is the real problem here that you're trying to solve, I think you'll be in a much better position to ask the right questions in order to find the right solution. Let's see. And then the next question is as UXers in the engineering part of the company, did you have to create the live coded examples instead of sketch slash static images? We're working with our front end team to do that. So this also relates to the next question about who's coding the live examples. The bulk of that work I would say is on Clement and his team. So they're working on the actual JavaScript components and they're working on that. And then on the designer side, we do, we're hiring for designers who have some development background so that they can contribute in terms of like HTML and CSS and JavaScript is capable. So it's kind of a joint effort, but mainly the front end engineers are working on those live coded examples. And how long does it take commonly take to resolve a UX issue? We work in monthly sprints. So we have, if it's a large issue, we will make a specific product discovery issue for a month in advance and work through that issue with product and engineering and design altogether. And then it's scheduled for the next milestone. So then you have a month to implement it. So depending on whether it's a smaller, large issue, maybe two months, but if it's a smaller issue, then you work on it and with the, with your team and then you implement it in that same milestone. How many of us are on the UX team? Oh man, I think there's like 10 of us now. Or 12. Oh, it's on a slide. I know that I, this is the worst question because I have to use my. Okay. All right. Thank you. That's awesome. So the next question, and we only have a couple of minutes. There's so many good questions. Are you open to looking at candidates that have diverse professional backgrounds for UX roles, business analyst, or only specifically looking at UX experience tires. We're always open to transferable skills. Right now it is important though, that you do have some UX experience. We don't really set a time constraint on it. So if you're someone that changed career fields and you've been doing UX for just a little while, but you want to fur your hat in the ring and see, please do. And we will give you feedback on why maybe right now isn't the best time for you to join the team. So it's, there's no harm in applying and, and seeing what the answer is. And that's coming directly from the hiring manager. So you heard it straight from the horse's mouth. So the next one is how do you use customer insights to influence the direction of get lab? That's a really good question. I think that's a really good question for product managers. I don't know Tori. If maybe Tori has some more insight into this. I do know that we, we do a lot of customer calls. We meet regularly with customers. We're often asking them for their input and to look at things that we're proposing and get feedback. And so obviously that feedback does have a really big impact on, on where we go and what we do. But a lot of those kinds of conversations are definitely done in the realm of, of the product management sphere. And it looks like we only have one minute left. So let me see. I mean, if anybody here asked a question that did not get answered, please find me on Twitter, LinkedIn, go ahead and connect, ask me your question, or you can find me at get lab at SSL off is my handle or should be my handle. If I'm remembering it correctly, I'm pretty easy to find though. It is the top of the hour. So I want to say thank you to everyone that attended. We'll go ahead and get this recording sent out shortly so everyone can review. And I hope to see some messages in my inbox. Thank you everyone. Bye bye.


Just before we went for a break, we were looking at how God prepares us even as he gives us his dream and his vision and we looked at the preparation process in the lives of Moses, Paul, Joseph, David, and Jeremiah. So we see that during the preparation period, it's actually a waiting time for the execution of the fulfillment or the dream, the vision that God has for us but during this waiting time, waiting time is not idle time. You know, when you wait, you're just sitting and waiting for the train or for your interview or you're waiting for your turn to come. You're just idle but it does not mean that you're not doing anything when you're waiting and in a preparation process. During the preparation process, you should be actively involved. What should you be actively involved doing?  So getting actively involved in the preparation process and what God was assigning you to do so you know that this is God's plan and purpose so you go and roll for courses, you get yourself prepared, your personal life, you get into order, your family life, management, time management plan you have. You look at various aspects and you get yourself ready. Look at one example we can look at is during Joseph's waiting time, you know, we see that he served with excellence, right? Whether he was in Potiphar's house or whether he was in the prison, he was serving. He did his work very diligently, sincerely and that is why God caused Pharaoh and that is why God caused the jailer to look at Joseph. Not because God had chosen him, God had a plan and purpose and so he was, you know, divinely orchestrating things. What if Joseph had thrown a tantrum saying, hey, I'm not slave material, I'm not a slave son, I've never swept, I've never swabbed, I've never cleaned in my life, I'm not going to do this, I'm just going to sit here and when Pharaoh came into the house, he would just pretend as if to say he's cleaning. Now God looked at Joseph's attitude, of course the Bible does not say it but we know it because when we look at the internal factors, God looks at our attitudes and our motives, why we are doing what we are doing and that is why God also brought him to that place of fulfillment of his dream or to sort of delay things and also we know that David was tempted but he did not give into temptation. That's another aspect that we need to keep in mind. So we see even Moses when he was in the wilderness, what was he doing? He was not just sitting down idle, he got married, he had children, he also was taking care of his father-in-law's sheep. So David during his time when he was running away from King Saul, he was engaging in warfare, he led his 400 men, he was training his men up, he was engaging in warfare, he was positioning himself as a leader, as a confident leader so that his men could believe and trust in him and also remember when we learned in the publication, I think it was Code of Honor I think or receiving God's guidance, the second lesson, we learned how David inquired of God, at various instances he inquired of God, how important it is for us to inquire of God. We also see Paul during his waiting time, he preached, he taught in synagogues, even though he was persecuted, his life was threatened, he did not run away and hide, he was preaching, he was teaching, he also received revelations which he wrote down. So every season is actually a preparation process for the next season of life, so we need to be in a constant state of learning, of growing and maturing in the things of God even in the practical aspects. The fifth one is that the unfolding of God-given vision may differ from our expectation. I'm sure that when David was anointed as king, he would never have thought that he is going to be running away to save his own life and he is going to be like a restless wanderer, protecting his own life and staying in the wilderness rather than being a king. So during those times, what do we learn from David's life? When God imparts dreams and visions and gives us his heavenly goals and destinies, don't let go even if the journey towards them is difficult and hard and there's hardships and difficulties and it is not how you envisioned it, how not how you expected it, it's longer than you thought it would take. You need to stay the course and you will see the vision fulfilled. So that is about David's life. What about Joseph's life? Joseph, he never thought he would be sold away as a slave by his own brothers and he would be falsely accused by Potiphar's wife, end up in prison but all of that elevated him to be the prime minister of Egypt. What about Moses? He never imagined that him acting and taking justice in his own hand and being fair and being just by protecting his brother would rest in him being in the wilderness for the next 40 years and being a restless wanderer. So even as we go through various challenges and difficulties or when God gives us a vision, we can be very excited but when we go through problems and difficulties, don't think that it's not God's vision or plan for your life. Stay the course, see his vision to see his vision fulfilled because what God is about to unfold through our lives is not dependent on who we are, what we are, what skills we have, but it is God's glory that is going to be revealed in and through us. Even as we are weak vessels, even as we might be frail, even as we have our own limitations, our own difficulties, sometimes we might be so foolish, so weak, you know despised by the world nothing but God will fulfill his dream and vision and plan for our lives. The sixth one is the Kairos moment for a God given vision gets delayed when attempted by self, like what Prince asked his question. So we see 40 years it delayed in Moses's life. So can there be delays in our life? Yes because we are all human, right? We all make mistakes but what do we do when we make those mistakes? There can be delays, there can be disappointments, there can be detours, they can bring a lot of discouragement but we need to hold on. What should we do? First thing when we make a mistake is what do we do? We repent, we ask God for forgiveness and when we ask that God is greater than our mistakes and there's nothing that is too complicated for him, nothing that he can't resolve. Look at what the psalmist says when he found his feet in a net, when he was trapped in his own temptation and his weakness. What did he say? He says, my eyes are ever towards the Lord. So when you are caught up in a net, in a mess, you're tempted, you're falling in temptation, you're ended up in a failure. What do you do?  Sometimes our problems can end us up in a mighty pit where we can't get ourselves out, we can't pull ourselves out because of repeated mistakes that we are making. Look at what the psalmist says. He says, I waited patiently for the Lord. He heard my cry and he pulled me out of the horrible pit. So God, when we make mistakes, when we go back to him, he's a God who restores. He's a restorer of our lives, our souls, our time. What he can do in 10 years, he can do it in one year. Jesus, just three years, he did the ministry. For Paul, he started in the age of 50, just did wonderful ministry later on. So God can accelerate things. What takes many years to accomplish? God can fulfill in a much shorter time. All the years, the locus that we think God can restore. So what should we do? When we make mistakes, we ask for forgiveness. We don't live in the past. We don't live in our mistakes. We move ahead. We learn from our mistakes. We become wiser and we continue to pursue God's plan, vision for our lives, the plan that he has put into our lives. The seventh one is we have 11 to go. So we have the seventh one. The God given vision may not be understood by everyone. Now, for more in the life of Moses, we read in Acts 7, verse 23, that God put in his heart when he was 40 years old to lead the people of Israel. But we see that when Moses tried to help his own brother, Hebrew brother, they could not understand. His own people could not see God's hand. They could not see the purpose why Moses was in leadership, why he was in Pharaoh's palace, why he was raised up in Pharaoh's palace. People did not understand, but we see that also in Paul's life, when Paul became a believer, he encountered Jesus. There are many from the church who were still doubtful and suspicious of Paul. They did not want to do anything with Paul. So we see that Paul spent a lot of time alone. Look at what he says in Galatians chapter 5, verse 16. He says, I did not immediately confer with flesh and blood. So sometimes when God births a vision, a plan, and a dream, we might have to just keep that within ourselves, pray about it, spend time understanding it. Don't immediately confer with flesh and blood. And God given vision does not necessarily mean that it needs to have the approval of God. I mean, sorry, approval of people. It should have the approval of God, but sometimes people will not approve of it. They might not understand it, but you can still hold on to it, but God will send people who will help you, counsel you, guide you, show you the way and help you to execute the plan and the vision that God has for your life. Point eight, a God given vision will face demonic opposition. So in the case of Nehemiah, it was not easy for Nehemiah, right? When he went to build the walls of Jerusalem, was it easy for him? No, if you read the book of Nehemiah, he faced a lot of problems and difficulties. The Arabs, they tried to try to do things where they could accuse him, they could trap him. Even Jesus, the Pharisees and Sadducees, tried to ask him various tricky questions that they could trap him. But we see that in respect of that, Nehemiah was able to fulfill God's plan and purpose. So we know that when God gives us a plan and purpose, a devil is not happy with the authorization you get from heaven to build God's kingdom. He will do whatever it takes to oppose, to hinder, to divert us away from the work of the kingdom. So how can Satan divert our attention? He can distract us. He can get us to do things that are good but not seemingly good that is going to fulfill or birth God's plan and vision through our life. So we need to be very, very careful. Sometimes Satan can very subtly lead us to do good things but those good things are not going to really help us to fulfill God's plan and vision. So that is a distraction. And what does distraction do? It breaks our vision, it breaks our focus. It results in wasted time and energy and resources. Doing a good thing but will not help us fulfill God's purpose, a distraction. Now for example, God has called you to raise up, you know, be a pastor for a church, okay. He's called you to be a pastor, okay. So you can do that but then also you're somebody who loves business. You love business, you like to do engage in business. So maybe you can get distracted in, you were already running a business when God called you to be into full-time ministry, a specific call to be a pastor to leave your business.  I can raise a building. I can support myself. I can support my family but there's nothing wrong in doing that. We learned we can do it if you're struggling financially.  It can lead you away from what God has called you to do. So sometimes you can be doing good things but then you can be doing the wrong things at the wrong time in the wrong place, okay. Or sometimes you can say God wants you to start a church here in Bangalore City but you get an opportunity to go to the US to work with another pastor or leader and you say maybe God is using and you're excited to go to the US. You're looking at it as an opportunity to go to US but you're saying that it's a good thing God is actually preparing me to be under the leadership of another pastor so I can learn.  So you need to discern or you need to discern whether you you start the son or you want you get an opportunity to go to the US to study something.  So for me my distraction was you know when I was in full-time ministry you know my sisters they live in the US they used to spend so much of money buying all of those you know the forms and everything for schools to get me into counseling because I was interested in counseling. I was interested in counseling God did not have me as think of me as a counselor okay. So they had spent quite a lot of dollars in buying all of those booklets and you know all of those handbooks from various colleges and I wasted everything. And even now when I meet some of my my classmates in Bible college they're shocked that I've never done a PhD I never even done sorry I never did an MPH I never landed up doing a PhD and they were wondering why I was just stuck up with only a BD and I and they told me you have even the opportunities your sisters live in the US and I told them God had never led me to do another course not to do an MPH not to do a PhD but always to be in the ministry and I never looked at those counseling courses. So that can also could have been like a distraction I could have easily gotten and I could have gone to the US and lived there and continued into counseling but that was not God what God wanted for my life okay. So there's diversions you know demonic opposition can bring diversions and these can be like you know these diversions can be huge gaps or distance that can that Satan can bring in our mission that he has for us okay and you know sometimes even disputes internal disputes that we have people we are the vision bearer people God brings in people sometimes we bring in the wrong people we need to be very careful and they can cause a lot of strife and dispute and we can find ourselves fighting against them okay disputes and strife and you know even with our own family even with our spouse children they can be dispute so you know all of these things can be very subtle ways that God brings and when you have people like that in your team who come in and they're trying you know they're trying to bring in disputes and strife don't fight them you know I've learned from managing teams with the children's church and catalyst I've learned not to fight with people you know I know what they're doing behind my back but I know and I say God I don't have the time and the energy to fight them and fighting them is going to be a wastage of my time and energy and it's going to bring about this unity I just want to maintain unity and I've just prayed about it and I've seen how God just removes them so beautiful God will fight your battles you let him fight it is his kingdom it's not my kingdom it's not my ministry I'm just here to serve I'm just here to do things right in the way God wants me to do things that is right that is to keep unity in the team I keep unity I I'm nice to them but I still know what they're doing and how they're trying to bring in this unity and I've just seen how beautifully God just takes them away he just fights your battle okay and the other thing is discouragement you know Satan can bring that very easily when we get discouraged we just want to drop everything run move away we just want to leave you know sometimes it is very very difficult discouragement is something difficult is very difficult to encourage yourself because you keep oscillating between encouragement discouragement encouragement discouragement sometimes it's so fed up you just want to leave everything and run okay I remember at one point of time in my ministry I wanted to just leave not ministry and run but I wanted to leave that place where I was ministry and God was taking me to the life of Paul as a missionary and the difficulties and the challenges he faced and at the end of that one week I said okay God you know I'm going to go back in this same ministry and I'm going to minister there even though things are challenging and difficult for me and then after one day I saw things you know I get back to discouragement and I said God I'm not going back and that's when God gave me one line which was like a punch line punched me on my face says ministry is not a matter of convenience it's a command it's not your convenience I want to go back I don't want to go back it's not your convenience it's a command God saying go back and I know that at the right time God took me away from that place and let me somewhere else so you know even when we are discouraged we need to learn to strengthen ourselves in the Lord our God that is what David did remember when he came back and he saw all of his wife the wife children all of his 400 men's wives and children all his property everything that belonged to him taken away his men and he were crying and mourning and his men were thinking of killing David and what did David do he strengthened himself in the Lord his God you know what did he what he would have done by strengthening himself he would have just worshiped God he would have loved God he would have shown God love somehow he strengthened himself so it's very important for us in our ministry to you know be connected to to God to be strengthened okay then the ninth thing is a God given vision is always bigger than the individual okay so we see that even in Nehemiah's life the building of the wall was a very big vision okay but we see that Nehemiah says that he when he went to Jerusalem he never shared with anyone what was in his heart he kept it as a secret he surveyed the entire place but when the right time came he told his people okay look at what he says in Nehemiah chapter 2 verses 18 he says let us rise up and build then they set their hands to this good work so he says come let us rise up and build the walls of Jerusalem okay so the right time he tells the people and they all come in and they pitch in and they work even if you look at the life of Paul we see that Paul was not an Nehemiah myself man you know I'm the apostle I'm great I know everything you know I don't need anyone but we see that he had many people who were working along with him and he called them at various names he called them as fellow workers you know partners fellow helpers fellow laborers fellow servants fellow prisoners and he always at the end of his letters he always mentions people who are with him in the ministry okay so you know sometimes you know we all want big vision to give us a big dream big goal big plan and purpose which is very good but we need to have big hearts why big hearts because the big vision requires a big heart which means it requires other people to come alongside to help you sometimes we don't want other people to come alongside because we think they will rob us of our the fame the name and the applause that we need to get okay so we need to connect with people bring the right people into our vision okay and even as they come into our vision you know we need to celebrate them we need to encourage them we need to build them up also as well and we need to you know share the vision with the right kind of people in the right panel so that they can step in and even as some of them come in we need to celebrate some some who don't want to step into our vision we shouldn't be angry with them okay we should not get upset with them we should not do away with the allies is because god did not you know have plan and purpose for them to be in our vision okay whenever somebody steps into the two projects i handle and they want to leave i always thank them and bless them and send them because it's not my project it's not what i'm doing it's god's kingdom it is his church his work that i'm doing and if he's taking them away god will bring somebody else and god has purpose something else for them so release them and send them no use of fighting okay but we need to be cautious and wise who we need to share and who we need to invite if you don't be cautious if you're not smart that can create the most problem for you okay people kingdom building is all about building people but also people can be the greatest hindrance and barrier and can also destroy your peace of mind so much so that your health issues are you know so come to a place where you can't even do ministry anymore okay two more points tenth one is other people find and fulfill their lives calling by participating in your god given vision god will bring other people into your vision you need to be wise to choose the right people but even as they come in don't use them okay make use of their skills and their ability don't use them for your own benefits for your own privileges for your own fame and name okay acknowledge them keep their interests in mind also okay and they collaborate with you give them the rightful place and the due honor that they also require okay the leavened one is even as god gives us dreams and visions it's all interlinked with each other okay it's interlinked with others dreams and vision in the body of christ so we are all having our dreams and visions that god has given but it is all for the purpose of building and enhancing his kingdom the church okay so we need to partner with each other and build god's kingdom not saying that i do it in isolation that is wrong but build together partner with others and we will fulfill what god has called us to do okay any questions on this lesson chapter four online students any questions you all have Rin is looking at how much more we have to cover well look at it it's a nightmare for me myself i'm just praying that i'll be able to finish it in time sorry yeah yes i'm just sticking to what is there in the notes i'm not doing anything extra yeah pastor i have one question pastor can you hear me yes jack in very clearly please go ahead so pastor when we when god brings in people and you know that god calling is there in their lives and we try to encourage them and bring them up but we see that sometimes they are not they get discouraged and they actually don't see where god sees them so at that point in time how much can we as people or like encourage them or we know for sure that you know god has a calling for them but uh you know i don't know like how to say because they they are willing but they get discouraged so easily so at that point in time do we just pray for them and leave them alone or should we keep a i mean like continual touch with them or like how do we deal with such people pastor yeah good question thank you jack in so there's an extent to where we can journey with people you know we can't we can't come to a place where we can think for them make them do what we want i think even god does that with our own lives right he's given us the free will to choose the moral free will to choose you know so he tells us what is right and wrong but then he says hey if you want to choose this you choose you go your own way i will let you go your own way okay so that is even god dealing with us you know the way he deals with us he tells us what is right and wrong we he's given us various parameters he's given us his word the holy spirit he's given us our conscience nature roman chapter one says nature even talks about the divine attributes the godhead so we are without any excuse but he says in roman chapter one irrespective of that people have chosen license of the truth they have given exchange of glory of god the glory of man made things and so what does god says i give them up you know i've i've given them up i let them go their own way so what we can do with for people is to an extent we can journey with them helping them but if we see them you know coming back to the same place we're self pretty you know and all of those things there's nothing more we can really do rather than just pray for them and you know ask god to work and the holy spirit to work in their lives because ultimately it's not our words it's not we are gives us skill and our charisma so holy spirit working in them so if the holies they're not listening to the holy spirit then you know they can't even listen to us so we just pray and leave them and i think you know god will orchestrate situations in life where they will learn through those situations and you know ultimately listen to the what the holy spirit is saying yes did that help yeah okay thank you jack in that was a good question we told about god gives people in our life like we need our people like god places some people in our life to fulfill the purpose or so like if uh if that relationship was broken like if uh god attached it to people like like to be a successor for someone or help them in their vision and if because of their heart attitudes or because of their behavior their relationship got broken and they got separated so so is it like god find some other person or god restores would god find someone else yes he would find somebody else to bring that person in god always would want to restore that person the holy spirit will continue to work though they're not yielding and hard-hearted and stubborn and they're not willing to listen to holy holy spirit and god would let them be but he still would want to restore their lives yes he is a restorer he doesn't want anyone to perish yes okay any other questions okay there are no more questions we'll move on to chapter five okay we look at kingdom builders lifestyle okay um oh as kingdom builders sometimes we are so caught up in building god's kingdom that we forget that god is more interested in our character in our lives and who we are then what we are doing okay so who we are and the life we live as kingdom builders is more important to god than what we are doing okay so we're going to look at three main areas godly characters spiritual maturity and stewardship okay um what is um character character is basically your attitudes your nature your behavior your temperaments your personality okay your who you are as a person okay um and it is not who you really are before people but who are you in the secret quiet uh okay in your own quiet space okay and your character is revealed through your actions your behavior to your conduct okay um and your actions and your reactions actually reveal your character your actions and your reactions in difficult and unexpected circumstances actually reveal who you are as a person it reveals your nature your character your temperament your um uh you know your disposition your personality it reveals who you are especially when you how you react um to in difficult and unexpected circumstances okay your secret choices also reveal your character your words attitudes and decisions also reveal your character your value systems what influences you also reveals your character so let's look at an example of Joseph okay now we know that Joseph served faithfully for 11 years in Potiphar's house but we see that you know he had a very difficult time there and he was tempted by Pharaoh's sorry Potiphar's wife okay but we see in spite of the repeated temptations what was Joseph's stand he had the power to say no and why do you think he had the power to say no fear of God and because he had a strong model character his character was no this is not right okay we see that in verse eight okay he refused uh and said to his master's wife look my master does not know what is with me in the house but he has committed all that he has to my hands okay your conscience will also keep you accountable to God when no one is watching I love verse nine you know um when when Joseph says how can I sin against God I when I read this the first time in my life I just it just I stuck with me and saying but this young man you know um in when repeatedly facing this temptation in the face of temptation thought about how can I sin against God and I was looking at my own lifetimes when I have sin have I ever thought man and I if I do this sin it is going to grieve the heart of God it is going to break the heart of God I think and if we think that we will never do we really love God we will never do that whatever it is okay so he had um um his conscience you know uh uh towards God conscience towards his master kept him accountable even when nobody was watching okay and he was he had the ability to say no because he had a strong character you know without having a strong character you can say not say no to anyone and everyone's difficult you need to have a strong character okay and a strong character cannot be weakened and will not give in to continual temptation okay so we see here that he was continually tempted but he he did not give in to his temptation okay so how his character developed we look at um another example in the bible that of Daniel okay now we see that Daniel when he was very young okay he in his early teens he was taken to Babylon as a captive but he was taken to the palace okay and in this palace there were 10 10 uh Israelite boys who were from royal families were chosen who were to be taught everything about the Babylonian language science math everything and the end of three years you know they were supposed to be given food from the king's table everything end of three years Pharaoh is going to give them a test and then he's going to choose officials from his from these 10 uh Israelite boys all young teenage boys and when they were served food from the king's table you know this is another example that has stuck in my life you say no uh what did Daniel and his three friends do Shadrach, Meshach and Abednego they decided they will not eat that the food from the king's table you know I was thinking what would I would have done you know I would have said hey you know this is a king's order I can't disobey the king's order I will die you know you're living in the palace you have to eat the king's food um you know and it's good food and all of those things okay but here they said we don't want this food why because it was not according to the standards of uh the Israelites what God had asked them to eat and I was thinking even in the area of food where some of us would think no should we honor God with food you know we should honor God in other things what we watch we should in watch say thoughts all of those things in an area like food so we see that even in a simple thing like food Daniel and his three friends wanted to honor God when they were just teens you know teens the teenage years they just want to eat and eat and eat and eat and indulge in a lot of food you know but here are these three young men so you know what do we learn that character is developed at a very early age when you stand by your convictions and we see that God honored Daniel and his friends and they were they were able to answer all the questions that the king asked and king thought they were too super brilliant they were not just super brilliant but God gave them the wisdom God honored them for honoring him and I think God even looks at us when the way we honor him in a simple thing like food you know and I'm thinking God will also honor us in the way we dress the way we conduct ourselves no simple things in every area of our lives God wants us to honor him okay and it's never too early to start you know developing a godly character okay we also see that our characters influenced by our friends so we see Daniel you know Daniel and his three friends they decided they will not eat from the kings the food but the other six guys they said hey let's enjoy let's feast you know come on belt it you know enjoy but these Daniel and his three friends they resolved in their heart they will not define themselves by eating that king's food so a character also is influenced by our companions the friends that we have okay and a character is built over time through discipline and practice and we see this in the life of Daniel you know when the when the king gave the order for the next 40 days nobody should pray to any other god what does Daniel do as was his custom in his early days it says you know Daniel chapter six verse 10 you know now when Daniel knew the writing he went home in his upper room opened the windows to a Jerusalem bent down his knees three times a day and pray and gave thanks as was his custom since his early days so you know to get children to practice things from a very early days is something that they will not forget becomes a practice okay so he in spite of that order he went and did what was his ritual what was his custom okay and strong moral character is strengthened through adversity even through challenges even through difficulties look at what Romans chapter five verse three and four says can somebody read that these Romans chapter five verse three and four Romans chapter five verse three and four and not only that but we also glory in tribulations knowing that tribulations produce perseverance and perseverance character and character hope amen okay so we should what did she say we should glory in tribulation that means we should you know praise god we should be worshiping we should be happy when we are going through what tribulations you know something very difficult for us to do why because tribulation produces perseverance and perseverance character and character hope okay now why is character very very important okay we see that godly character is a prerequisite for kingdom ministry okay if we look at first Timothy chapter three verses five one to fifteen Paul is actually writing to young Timothy who he leaves there in the church and he's saying you know at Ephesus and he's saying you know I wanted to choose good leaders and he's saying choose bishops and so what is he saying the choose bishops who are godly who pray five times a day who fast huh he's saying that who read the Bible the Torah you know they're always in the church is he saying that no what is he saying he's talking about that there should be husband or one wife temperate sober minded good behavior hospitable not given to wine not violent not greedy for money gentle not quarrelsome not covetous you know able to rule their own house take care of their own children you know not puffed up with pride so he's just not you must be reverent not double tongue not given too much wine not greedy for money look at all that it's all talking about basic moral character you know your attitudes your behavior he's not saying hey there should be someone fasting five times a day uh they should be knowing the Torah they should be you know doing this they should be doing that not spiritual rituals so to say but talking about lifestyle okay so you know uh and he says likewise deacons you know what deacons what deacons help us like administrators in the church and look at the look at the list what he says for them in verses 11 to verse 15 I just want all of you to quietly read that for yourself verses 11 to 15 in first Timothy chapter 3 verses chapter 1 verses 11 to 15 and look at what Paul is writing to Titus you know who he left at Crete to oversee the churches at Crete he's saying you know I want you to choose the right people for leadership in the church and look at what he's telling them just read verses 6 to verse 9 for yourselves again please so important sorry yes Titus 1 5 to 9 so read first in Titus 1 5 to 9 and also first Timothy chapter 1 verses 11 to 15 so he's not talking here about how anointed how gifted how much they can speak in tongues you know they're flowing in all the gifts of the spirit which is the ministry office they're called to but he's talking about their lifestyle right he's talking about their character so in kingdom building God is looking more for not just our anointing because he can pour the anointing he can pour but if he pours in a vessel that is not having a good character the anointing will be wasted it will ruin and break the hearts of many that is what is happening around the world look at what Jesus says in Matthew chapter 9 verse 17 can somebody read that please Matthew chapter 9 verse 17 Matthew chapter 9 verse something not do they put new wine into old skins or else a wine skins break and the wine is spilled and the wine skin are ruined but they put new wine into new wine skin and both are preserved we learn this amen we learn this in ministers foundation right the anointing is the wine a character is the wine skin if the character is weak the wine skin is weak what will happen the wine will break and burst and wine will be wasted the same way if our character is weak the anointing will be wasted okay and we also learned in the ministers foundation in that publication you know your gift can take you where your character cannot see you if you don't have the good character you might be the most gifted anointed person but it can you know you can't stay too long it will not hold you there so we need strength of character to help us you know to the great heights that God takes us or brings us into okay we stop here we just have one more minute any questions any questions okay so you can you can be the most you can like you can be a very gifted person in in some area okay you can have all the skills the gifts that is required for that ministry whether it's worship or you know youth ministry or children's ministry but if you don't have a your character your character in the sense you are you know you're a gospel loudmouthed you you know you lose your patience you can't handle people you're very bossy you're very dominating you're very rude you know you are not somebody who's I me myself everything has to be about me you know and all of those things then what is the point of your gifting it you can't last long in that ministry in that place nobody would want you people will be rebelling against you there'll be striped there'll be disunity there'll be you know a break disorder and so you have you're a very gifted person but your character is not able to hold that gifting then there's no place nobody would want to work with a boss like that right nobody would want to work with a team leader ministry leader a pastor with with this kind of an attitude who's talking down bossing you know dominating not patient bringing about division gossiping behind people not living a honorable and holy lifestyle you can see through people right and it's not going to hold your gifting nobody would want to even come and pray for ask you to pray or you know you know even you won't even want to go to a church and listen to such a pastor or you won't even want to serve under such a ministry leader or a team leader so you can be the best gifted person but if you don't have your character your gifts cannot hold you you know in that place of position and authority okay okay thank you everyone for joining class we'll continue next week okay some important things we learned today hope you can implement that and practice even as we are in the process of kingdom building okay thank you have a blessed day and a blessed week everybody God bless


Hi everyone, Joe for Jaspy's casebreaks.com coming at you with our last filler to unlock that one box immaculate basketball break This is cello pack break number 212 Again, big thanks to this group for making it happen There are all the teams in right there. We'll do the break first and then second dice roll will be for the giveaway part for names and teams four and a one five times one two three four And a one fifth and final time Four and a one five times for the teams one two three Four and a one. All right, there's the first half of the list right here And there's the second half of the list right here It's interesting to see Tiger Woods. He actually plays at the Masters. I'd be I'd be incredible Even if it's just for a round or two that would be that would be amazing an amazing comeback All right, there's the final printout This will be in a separate video KG Silver Ricky Robeo Rubio Green Too crazy here, but red, white and blues. Yes On Saturday Yes So we didn't have any on Saturday night. They're back on the site now I don't know why they'd be back on the site unless more came in today More must have came in they would never be in here remember there was a good that was that was the mixer That's why that's why I pulled them. Yeah All right, so nothing too crazy there. Let's flip back over here and Let's gather everybody's names for the second dice roll and let's roll it and randomize that list Four and a one five times again top ten after five. Good luck one two three Four and a one fifth and final time So sad times for this group very close Brian not quite though, but I think you got a lot of spots Hopefully your name still in the top ten But sad times from 11 through 30 We'll get them next time Happy times though for the top ten Nick is happy. So is Michael Brian.  This is the last filler. So we'll see in the next video for the break itself Jaspiescasewrakes.com. Bye. Bye


I tell my recruits all the time, every day is your training day. They realize that they just work together and everyone pulls their own weight. The log's not that heavy and the task at hand is about it. You can tell yourself that you gave it 110% the entire time then you should be proud of yourself for that training day.