Pragmatism, prioritisation & patience: skills for success in start-ups

Discover how pragmatism, prioritisation, and patience can boost QA engineer success in start-ups [View this email in your browser]( [3 eyed character with a QA trophy in space]( by Amy Stuart | [Read online at Ministry of Testing]( This article explores the specific skills that are beneficial to consciously practise and improve if you are joining a start-up. Additionally, it provides a clear illustration of what working in a start-up is like, and how it compares to the experience of working at established companies. We will discuss what can be the same, what is different, and what skills and knowledge are transferable and useful. Alongside defining the skills for success, and providing insights, there are descriptions of the challenges from my general experiences of working in start-up and similar fast growing environments. Finally, I will provide insight into the positive impact refining those skills had on the way I worked. Turning challenges into opportunities at start-ups! Start-ups are companies in the early stages of operating as a business often going through exciting stages of growth. Working for a startup can be an exciting opportunity to get involved in the beginning of a business’s story. However like any project, getting involved in the early stages comes with unique challenges related to figuring out what works, and what doesn’t. As someone working in a quality role, it’s important to know how this affects you specifically. Start-ups face challenges that established companies do not, or may experience similar challenges more frequently. By their nature they are new businesses, and this comes with an increased element of risk. Many start-ups fail, or experience turbulence in their first few years of operating. Action is necessary to keep up with changes in the market in order to succeed. Company structure may change to compensate. There could be changes to teams, including people joining, transferring, or leaving. There may be product roadmap pivots to keep up with market changes or competitors. To be a start-up, is to be in a state of operation to prove a business idea works and is viable, and big changes are sometimes necessary to prove this. Change can be exciting, but it can also feel disruptive to those impacted. As a result, many who decide to work in start-ups tend to be ambitious and driven people with a tolerance for this increased risk. As well as challenges affecting and causing change across the whole company, individual contributors face challenges in their roles and responsibilities. Contributors may wear several hats in their day to day role, develop new skills on-the-go to fill knowledge gaps within a team, or have a wider scope in terms of responsibility than would be usual for the same role at an established company. So, how do companies in their early stages differ in reality from companies who have operated for many years? - Processes might not exist in some areas of business, or may be informal, i.e. not documented. - The pace of work may be faster, you may work on new projects frequently, whole teams or individuals might be expected to context switch more. - Individual contributors may be expected to be more independent and self-starting. When applying for a job within a startup you might wonder how it will differ from the experience of working at an established company if you have not worked for one before. On job adverts you might frequently see the words ‘flexible’, ‘self-sufficient’ and ‘challenging’ - but what realities do these words actually represent? How is your day to day role going to be different compared to when you worked at a company that has been around forever? Being an effective QA Engineer within a startup requires carefully applying previously learned behaviours and expectations. If you’re coming from an established company, there may have been specific quality standards the company expected the product to adhere to in the form of processes and documentation. You may have your own personal standards that you believe a feature should meet. You might have beliefs about what is and what isn’t acceptable when it comes to quality. Let’s explore how this experience may affect your transition into the start-up world. Let pragmatism be your guide When you move into a start-up, your external context changes, which means you may need to adjust your approach to protect quality within a team. The quality expectations which are applicable in the context of a company with plenty of resources and time, may come across inflexible and difficult in the context of a startup. For example, it’s important to Quality Assurance Engineers that we prevent as many bugs as reasonably possible from reaching production. Consider a situation where close to the end of a project you find a bug you believe should be fixed so it costs the business less overall. In the context of an established company it might make sense to fix this bug before it goes to production. But in the context of a start-up, the immediate need of the business to release the feature may overrule the desire for a ‘perfect’ product. The reality may be that the feature is released and the bug fixed later on. This is not an ideal situation, but start-ups operate in constantly changing environments that require flexibility. It’s important to consider many factors in making this kind of decision such as: the severity of the bug, who it affects, and the impact. You do not need to change your personal opinion about which bugs should be fixed and when this should happen, but you should consider challenging your existing expectations and reconsider if they are realistic and useful in this new environment. To challenge your existing pre-conceptions is a strength! Your personal opinion can stay the same, it’s a strength to hold your beliefs in favour of quality even when others do not think the same, but you also need to know when to compromise when it’s the right decision for the product and users. Take every situation as it comes and be balanced. 👋 TestBash is our annual conference happening in September in Brighton, UK. As we like to say, our network is your network, we'd love for you to join us. We will have 2 days of learning and community as testing professionals share what they know about testing, AI and more! [Explore the TestBash Experience]( Examples of practising pragmatism One example of an opportunity to use pragmatism is when discussing requirements for a feature with a product owner. You may disagree on the importance of catering to a specific, less likely user journey. You may be of the opinion that the journey should be covered, but the product owner informs you that due to time constraints and low resources (which are more likely to be a challenge in start-ups) it is not realistic to cover it now. It’s important to continuously consider the wider context in these situations and approach discussions in a pragmatic and balanced way. For a second example, imagine a situation where you find a bug which occurs only in a very specific situation. Let’s say it occurs on a certain page, when a device is turned landscape, and only when that device has a specific screen height! After investigating and reviewing the device statistics for your product, you find devices with this height are popular, the user journey involving this page also involves turning the device landscape, and so this actually represents a significant portion of users. You may need to challenge the misconception that just because a bug is niche or an ‘edge case’, does not mean it’s irrelevant and doesn’t affect users. You may need to persuade others to prioritise bugs like this by backing up your assertions with data. If you lead with always keeping the user’s best interests in mind, you can’t go wrong. Practically implementing pragmatism Knowing when to be firm versus when to allow leniency will become very important. Consider having a candid conversation with the three amigos, usually the QA engineer, developer, and product owner. It could illuminate whether a bug should or shouldn’t be fixed. Changes like focusing more effort earlier in the development lifecycle to reduce the chance of bugs occurring at all may be beneficial. Use data to inform your decisions. The phrase ‘choose your battles wisely’ is useful to keep in mind. We have touched on the time-sensitive and fast-paced nature of start-ups. In this context, it can be difficult to persuade others to your idea or solution if they aren’t convinced of the benefits. Your views around bugs, project ideas, and feature improvements may be harder to implement considering these factors. In these instances, speaking to individuals one-on-one to understand their viewpoint and any concerns, gives you the opportunity to refine your idea (or revisit it entirely) and alleviate any concerns. By speaking to people individually and hearing out their concerns, and directly alleviating them, individuals are more likely to agree with your ideas. If you persuade individuals, then you persuade the team. It may be more effort to take this approach, however, it may assist you in being successful at protecting the quality of the product in the end. We should take care not to become overwhelmed by this context change and forget our main role as quality advocates. We need to educate on the cost of fixing bugs at each stage, correct misconceptions, and continually advocate for quality. Taking the time to think of new ways to be an effective QA in your unique context, to find the areas where you can practically apply yourself, will help you adapt to the challenges of your new environment. How to use prioritisation strategies to manage a high workload When you join a startup, your prioritisation skills will be put to the test. There is a virtually endless supply of work, but limited resources to go alongside. Start-ups tend to be formed of passionate and hard-working, but small teams. You might be asked to help out with ad-hoc requests or other projects if necessary. With so much work to go around with a smaller number of people, it’s easy to become very busy, very quickly! Personally, my to-do list increased in size more often than I checked items off it. Start-up sprint teams may have a high ratio of developers to QA Engineers. And, if there are few QA Engineers across the company, it increases your likelihood of being called upon for meetings, advice, and general ad-hoc requests for help. If the QA function was introduced to the Engineering team after development had begun on the software then there may be a significant number of features which were released with only the basic functionality and user journeys having been tested. Now you, a QA professional, have joined the team with expertise in testing, it’s likely they’ll want you to take a look at and find any bugs in these legacy areas. This is in addition to the ongoing sprint tasks completed by developers, which also needs testing! This results in an always busy QA engineer, constantly occupied, and then some. The prioritisation superpower of saying ‘no’ Saying ‘no’ improves your prioritisation skills, and helps the team more in the long run. Saying ‘no’ is a super power you can use to avoid your to-do list growing too large, to avoid slowly gathering action items that aren’t really that important, and could be completed by another engineer on the team, improving efficiency all-round! If you feel bad about saying no to a task you think you won’t get around to, consider how by protecting your own time, you are making yourself a more efficient asset for your team. You are ensuring your expertise and skills are used on the tasks they are most needed for. Simultaneously, allowing that task to be picked up by someone with more time is a positive thing, as it increases the throughput of important tasks. It also allows others in the team to learn new skills and develop their knowledge of areas they may not otherwise. Transparency builds trust between yourself and the others in your team. Others will respect your honesty if you are candid when talking about your workload. By saying ‘no’ and seeing the tasks you do agree to through to completion, it shows you are accountable and reliable. This is positive for your reputation within your team and your relationship with other team members. On a personal note, it was difficult for me to accept that I couldn’t get around to everything I saw as my personal responsibility, or as part of my role. I needed to assure myself that I was working on the most important tasks with my limited time. Clear communication about your workload within your team during standups, managing expectations in sprint planning, and receiving input from stakeholders on priorities on an ongoing basis, will help you remain assured that your limited time is being spent on the correct tasks. Patience: a virtue and a skill At startups, processes, tools and documentation are not given, as opposed to many established companies. After joining a start-up, you will probably be expected to help create new processes and select tools to help the team succeed! In my experience joining a QA team at a growing company was a rewarding experience, it allowed me to develop my skills and leadership qualities by developing solutions for the unique needs of a start-up. I was able to use my prior knowledge from my previous experience and make an informed decision on subjects such as: what tools to use (such as, how I wanted to handle test cases); the formation of QA processes (such as triage and regression testing); and more technical decisions such as the approach to automation. Joining a team where there are not yet set QA processes or tools means in many cases you can shape them how you want to, and this is very empowering. To revisit the wider context, you face the challenge of assuring quality in the early stages of a development team. This means there could be more challenges you face as a QA Engineer such as: - Issues you’ve resolved or otherwise avoided in a previous team might now occur more frequently and require finding a solution in this new context. - Early or existing processes might be imperfect and require close attention to attain improvement. - Engineers may never have worked with QA before, it may be up to you to introduce them to the purpose of a Quality Assurance Engineer in a team. There may be gaps in knowledge around QA. Any misconceptions and misunderstandings may require correction. It’s true that these things can occur anywhere, but in my experience are more frequent at companies that are newer or growing quickly. You need patience and the ability to deal with these hurdles in a proactive way. Finding solutions that work for your team will involve trying new ideas and occasionally these may fail. Which is okay! You may come across many of these situations, but on the positive side, this means you can be a true asset in helping to resolve them and make things better. It is a good opportunity to get to know your team better as a whole and as individuals, understand their perspectives, and work together to form ways of working that fit the team. Patience helps reduce frustration Patience will allow you to face the ongoing challenges without becoming flustered or frustrated. Remaining calm and positive, by reminding yourself that it's a fantastic opportunity to be a part of helping a team grow, will be motivating for the rest of your team. It is important to remain determined, and be an active participant in making improvements. Be on the lookout for dangers, and use your prior knowledge of dealing with problems and forming solutions, to help your team get there as smoothly and as quickly as you can. Furthermore, a start-up being a new business in the early stages of operating with limited funds, may not have had a QA team for long (or at all!) prior to your arrival. This means the individuals within the team may not have worked with QA Engineers recently, or potentially ever! Patience will be required in this situation too. Team members may not be familiar with what a QA Engineer needs in terms of information in order to work effectively, or they may not be used to receiving such in depth feedback about the quality of the features they deliver. If you are a knowledgeable and experienced QA Engineer, it’s important to impart this knowledge to the team in a supportive way. Use the tools at your disposal to fix the problems you see, understand the touchpoints you can use to make a difference: - Raise points in retrospectives - Feedback in channels - Talk with and educate team members in 1 on 1s Ensure you do this in a kind, understanding way for your points to be received well. Starting difficult conversations is not easy, but it is the first step in resolving problems and in making the team the best it can be. To wrap up This article is written from my own personal experience of previously working in established companies and moving into start-up and fast-growing business environments. My account may differ from your or others’ experiences, but I hope the insights explored are useful. If you would like to get in touch and share your views, feel free, I’m always interested to hear about others’ experiences! Finally, to summarise the three skills: - Pragmatism, being practical in the varied, possibly turbulent environment of a startup. - Prioritisation, being red hot on ensuring your to-do list only contains vital tasks, protecting your time, and communicating openly. - Patience, being mindful of yourself and your team whilst you work together to reach company goals. 🪐 "I found a community in the Ministry of Testing, a form of belonging which helped me grow personally and in my career." — Kim Knup [Upgrade your software testing career with Ministry of Testing]( [Website]( [LinkedIn]( [YouTube]( [Twitter]( [Instagram]( Copyright © 2024 Ministry of Testing, All rights reserved. You have opted to join this email list. Our mailing address is: Ministry of Testing 19 New RoadBrighton, East Sussex BN1 1UF United Kingdom [Add us to your address book]( Want to change how you receive these emails? You can [update your preferences]( or [unsubscribe from this list](.