What makes a good leader, and how I will become one

Much of my job experiences have been heavily influenced by the leaders and managers I worked with. This seems to be a relevant topic, as you can also read many case studies of the heads from very successful companies scrolling through our social feeds. There are even science talks about the impact leaders have in organizations! So I decided that there are some thoughts I want to share on the subject.

I have met a wide array of leaders on my career, both being directly managed by them or feeling their effect in the company. But there are few who I consider had a lasting positive impact on my life! I remember having a manager who shielded us from external pressures so we could have the biggest impact, and how much that impacted our daily Job. Other times I felt heard and supported, allowing me to focus on my tasks. And I loved seeing how they embraced playfulness, fostering a funnier (and more engaging!) environment.

Most middle management is pushing for more productivity and longer work hours, without taking into consideration the impact that has. There are many traits from traditional management that really put me off, even when they sugar coat it with phrases like “we will share the success together!”. I understand there are deadlines. I know we are talking about work, and many times it will feel like a chore. But if we are trying to make something creative, that style of leadership will alienate me instead of bringing my best self.

Luckily, there are some leaders who are taking a completely different approach, and you can clearly see the effects. When I feel inspired by a mentor, I bring my A game every single time. It can be because I can focus on my small area of expertise while feeling supported on all those that make me struggle. Other times, I just have so much joy (and respect for their work) during my interactions with them, that I can help but look forward to meeting and working together!

What makes an inspiring leader

So, which traits define these magical leaders? They can be many and varied. Some have such a passionate vision that most of us can’t help but jump on their wagon regardless of what is required from us; like Elon Musk and his contagious passion. Others show how they prioritize their life and family, earning my respect and making me dream of becoming like them one day; like Jeff Bezos talking about quality over quantity of working hours. There are also the ones who include some level of playing or showing how to deal with a problem by setting themselves as examples; like Dick Costolo and how improvisation made him a better leader.

What do I value the most from a manager, then? Bringing a well-defined vision makes a huge impact on me. When they believe in the direction we are heading and feel passionate about our goal, I easily get on board. And that is no easy task! A big part of my job is offering counter-arguments and adding reality to our vision, and I feel that passion is the best way to win me. Another thing I strongly value is showing real competence, while still deciding to trust and delegate some of their tasks to the team. I feel empowered when I am trusted with a task by someone who is capable of doing it but recognizes their value of focusing on what they can impact the most.

What makes me run away from a manager? Feeling micromanaged easily makes me lose the motivation, even if I understand the value of checking for progress regularly and finding blockers early. Being managed by someone who focuses heavily on a strict process, without really understanding how it affects the rest of the team and lacking the fluidity needed to grow. I can also have difficulting if I am led by someone who doesn’t show expertise on our tasks, making it way more difficult to share success stories and explain the difficulties that I am facing.

Am I ready to become a leader?

I am approaching the point in my career when I am no longer scared of management tasks, and I really want to understand what shall I focus on if I want to become a manager. I would love to learn more from game theory and gamification, to create rewarding and engaging environments. And I should improve the ways I give and receive feedback, being a critical part of any leadership position.

If you are interested in the topic and you would like to learn more, there are many books which have inspired me on the subject. As I previously mentioned, Essentialism: The Disciplined Pursuit of Less taught me the importance of focusing on your biggest impact. Difficult Conversations: How to Discuss What Matters Most helped to build your tools in those moments that matter the most. There are also many skills from improvisation that easily translate to team environments like focusing on listening, embracing the fact that you will have to drop your ideas, the joy of playing or focusing on this exact moment; just to name a few!

Let me hear from you!

What do you value from a manager? What would you recommend to some of your previous managers? If you are a leader, what do you struggle the most with? Do you agree with the points exposed here? Please, I would love to hear from your experience!

Three steps to improve the quality of your development process in a startup

I’ve been working in the IT industry as a QA engineer since the start of my career. Sometimes, my position was just hands-on testing in a waterfall-like process; other times I worked closely with the developers to write all the automation needed before the feature was considered done. Every company offers a different approach on how to increase the quality of their product, and I’ve also seen companies trying the same thing with completely different results. But there is always something that kept being constant: when a company reaches enough user-mass or the codebase gets big enough, the conversation about ensuring quality gets more and more important. Speed and productivity matter less if you alienate the users with buggy releases, and your engineering team gets afraid of areas in your code which changes _always carry side effects_. That is the moment when the way of _just getting things done_ that has worked till now starts getting on the way of a healthy product. That’s the point when the organization thinks on increasing the QA headcount.

Currently, I’m facing this situation again, with the difference that I feel way more prepared. Of course, every company has a different way of working, but starting to be a veteran in the industry allows me to recognize common troupes and analyze the situation with frameworks which worked for me on previous cases. For some of these steps, I highly recommend finding a person who will bring the expertise on automation or testing principles in your team, but a lot of these steps can be performed without by anyone, especially if you already count with a Quality-crusader in your ranks. And that’s what I’m going to help you with right now, giving you an example of the steps you can take to start improving the quality of your product and processes by yourself.

Before starting, I would like to share the first step I take when joining a new startup, particularly if there’s not a defined Quality process in place. I always start finding the Quality Crusaders currently working with you, those bright knights who, regardless of their work title, push for a quality-first approach of working and cares about following best practices. I even ask for them during my interviews when considering a new job. Having allies who will share their view on how to improve the current situation is invaluable. So, find them, and involve them in these first steps!

Step one. Describe the development process.

Ok, so we are all making software here. And the process seems pretty straightforward, doesn’t it? Some people sit in a corner. They write some code. They push that code somewhere. And our users enjoy it. Pretty simple. So let’s add a little bit more flavor to it, shall we?

I like to start naming the different the different states that a task (bug fix, feature, etc.) goes through before our users enjoy it to pieces. Of course, this is more of a guideline than a cooking recipe, but I’ll describe an example as broad as possible so hopefully, you can get inspired. In this case, a task can come from a bug report, a new feature requested on some work that we want to do internally (tech debt, etc.). At some point, an engineer will pick it up and start working on it. It will land the codebase. It will be deployed to some testing environment. And finally, it’ll be in our user’s hands. So, without caring about actions and transitions, the states would be:

Coding – Code on the repository – Testing environment – Production

Now, let’s start the fun part. If we know that our code will go through these steps, how can we improve the quality adding actions or extra transitions?

Step two. How can we inject that quality?

This will drastically change depending on the previous experiences of your team, as well as what are they currently doing. Involve different people in this step, as they’ll offer valuable insight from their previous works of things that worked and didn’t. This is an example of what I’ve proposed in previous occasions. I usually include a short description of the different steps.

Copy of Quality Process

For instance, involving people with different expertise on a Design Document before starting to work on a feature has worked with great success for me. That document can take any shape, but having a little discussion on what is the problem that we’re trying to solve, where does it interact with other modules, what is the threshold needed to feel the implementation is good-enough helps A LOT to most engineers when working on it. Just having “what might go wrong” in the back of your head while you’re coding a solution can work wonders.

Another key element, apart from the description, is figuring out the owners of those actions. As I said, many don’t require any new technical expertise in your organization like Design Document, or Demo Testing where the developer runs through the solution with a peer or a product person to spot errors and understand how others verify that feature. Others really benefit from a specific skillset. That’s why, for instance, I took the ownership of working on the automation that will provide a smooth and reliable way to assess a solution. I’d work on building and improving the frameworks (Unit, Integration, End to end, Performance testing…), as well as working with the team so we can all embrace quality.

I also recommend that you don’t try to tackle all solutions at the same time. Set priorities, where can you get more bang for your buck, which skillsets do you already have, etc. All of these solutions will go through different cycles, and spending enough time and energy to set a nice foundation will help with the resistance that every organization faces when introducing change. Focus on feeling a constant momentum of change an improvement, instead of the speed of that change. Personally, the workplaces where I could focus on a steady pace, end up having a way more impactful change in the end.

Step three. Measuring the impact, reviewing and improving.

This is, in my experience, the hardest part. It’s really difficult to measure the impact of shifting to a quality-focused development process. Are you having more bugs because the engineers are working on a harder problem? Or did we get better at finding those bugs? As a quality engineer, part of my job is also finding ways to measure the impact of any change, so we can iterate through them and find a better approach. We all share a common goal: develop a product that will bring more value to our users, and doing it in an environment that we enjoy working at.

Spend some time profiling the process so you can get data on it. Sometimes, it’s as easy as holding periodical meetings where people discuss how it worked or didn’t work for them; or you can find entry points of measurements to take a data-driven decision. Be mindful of how hard this task is. If people feel that they would be reviewed by these metrics, they would be reluctant of iterating and embracing them. This is not about pointing fingers, but devising a way to improve the process for everyone.

As in most tasks I usually work on have more an internal impact than an external one, I like to measure my success on the perception of the codebase by our engineers. Of course, I hope that changes in frameworks and automation will impact the end user experience; but I like to focus on our team first. Examples on measurements that I use are: periodical surveys to the engineering team on how much they like working in our codebase, or how safe they feel when doing a refactor or change based on our automation; pairing with different developers so I can see how they work and their interactions with the frameworks; workshops on how to approach different bugs or problems; etc.

Another thing to be mindful of is that, at this stage in a startup, Quality is a buzzword used as an escape goat quite often. Most teams had to focus on quick and “dirty” deliveries on their first steps as an organization. When the conversation about Quality starts arising, it’s usually because that speed has started to produce difficult releases, and “the lack of a QA in your team” is frequently used as an excuse. Having people with different expertise always bring value, but it’s everyone’s responsibility in following the best possible practices to their knowledge, and voicing their complains about the current process. This situation can also create a toxic situation where, after hiring someone who that expertise, it’d be required from them to just fix everything.

Final notes

To wrap it up, I want to finish that this is not a magical tool that will increase your productivity and ensure the quality of your product by itself. This is a progressive change of mindset. It’s about changing how we work to spend more time on “how we can ensure and verify the solution”, and less on “how can we get done with this as soon as possible”. I personally believe (and I’m backed by plenty of evidence) that an increase of the efforts regarding quality will also bring speed on the long run, as it will require less of the VERY COSTLY redoing and fixing, that can also undermine the spirit of our engineer team.

If you’re starting to ask these questions in your organization: congratulations, you’re going through a change that your users will thank, and will produce less churn on your engineering team. But, I’m also really curious about your approach. What is the situation that brought you to start talking about Quality? What are the current solutions that your team is working with? Which are the points are you most struggling with?

Defining our QA process

As I mentioned before, we’ve been going through some structural changes recently. If we add to the equation a really tight deadline where we decided to drop the process and survive however we can; now we have some madness around. And, one of the craziest fields is quality and testing.

That’s why I spent half of today in a meeting room discussing how can we do, what can we try and why is so important. And, guys, I have to admit that I’ve enjoyed the experience. This is one of the first times I have to propose and implement a process on my own and… Such a shame I can’t share with you all the details and products from that meeting. But I can tell you what worked and what I learnt.

I always fancy starting with why we need the change; this helps to highlight the issues, stating that it’s not only impacting the people involved and we have to work together the solution. I started detailing how every team is dealing with quality right now (without process, every team has adopt QA on his own way), summarising it in bullet points as potential solutions and asking a really simple question afterwards: “right now, if you have to develop a new feature or refactor a piece of code, would you be confident enough to push it to production right away? “.

Obviously, we don’t want to push things blindly, even if the developer promises us how complete and awesome the solution is. But, if the one doing it doesn’t even have the confidence to make the step… Something is missing. So we start discussing why that was happening, and what it needs to change to get there. As you assume, the first solution was obvious.

Automation. We know how useful it is, especially helping us trusting a refactor and preventing regressions. As you should know, the team less confident about their code changes was the only doing less (none) automation. In my opinion, the main reasons were: lack of expertise, and without knowledge is easier to see some practices daunting and don’t realise its value; and a more complex automation problem, because UI are always more tedious to programmatically test, and without expertise you don’t know how to build testable products.

We discussed how to incorporate automation in our process, how can QA (just me) and Product leverage the task, and some technical details about the challenge. As some teams are using BDD, I propose The Three Amigos technique to define the tests, and I’ll provide them with examples, guidance, and support during their implementation; although they were really vocal about being the ones trying different frameworks and solutions. Fair enough, it’s going to be your child, I understand you want to choose it. Automation, checked. This will prevent some of the regressions, build back some trust and make them realise how untestable their current solution is, keeping that in mind for future builds and projects.

But, I’ve already told you that Automation is not the one and only solution, and there are some circumstances and problems where automation is just the inefficient and overkilling solution. You won’t write every possible test in the code, as it would be impractical. That’s why testing it manually, particularly new features, and getting feedback and soon as possible will help us meet Agile speed. Remember what I said of Quality Assistance).

That’s why I proposed QA Demos, where the developers show the new feature to Product or QA, and we try to break it in front of them for some short period of time. This way we can get the obvious feedback really fast, and developers can learn how we test. If we do it enough times, there is going to be a moment when they’ll be able to do it autonomously, knowing that their releases will contain fewer bugs, and building a better product because they have tested in mind. It’s a huge win situation, although there are some challenges (the biggest one I want to talk about it in my future post: Developers Archetypes).

This solution was less popular. They were sure that asynchronous solutions are more efficient, so deploying something and testing it whenever we can makes things faster (apparently, the industry doesn’t share that statement). Luckily, we decided to try it out in a couple of stories per sprint and check how it goes.

I finished the meeting with the QA manifesto, wrapping the actions, discussing some of the details and feeling that I’ve made a huge step in my career. I’ve done it on my own, and now I’ll try my best to achieve a process where we can trust our changes, and hopefully where the Quality Assurance role is not needed because everyone is ensuring the Quality of our product across all the journey. So, guys, I encourage you, if you don’t agree with the process, if you spot lacking points, try to change it. People is keen to improve what they neither like. They’re more supportive than you think. Well… Sometimes.

May the force be with you,

Is moving abroad a company perk?

I know that Internet is saturated with this subject, but I got asked several times about it and having a post to share instead of hand crafting a response is going to be really handy. I’m going to keep it as personal, funny and anecdotical as possible, making it different. Also, you know that I’m following the 10-idea movement, so I’m going to use the same schema to detail 10 tips I want to yell to my 5-years-ago self. Let’s do it!

  • Build your core group. You’re going to need people, so start building
  • Avoid your hometown ghettos. I’m in a different place to meet new people, to learn from new cultures, not to build a Guetto of Spaniards abroad. Also, pro tip: I’ve found that people become their contry “cultural cliche” when they move abroad.
  • Walk the city. It’s the best way to discover its secret. It’s free, you won’t stay that much time at home and it becomes handy when visits come!
  • Ask for recommendations and try new food. Your hometown food is not going to be the same here, so avoid visitting those places. It’s time to experiment!
  • Don’t be afraid of digital platforms and tools, they’re handy to meet new people. They are groups, apps, meeting software..
  • Every company has a mad employee, so join that colleague. At the beginning, it’s going to help you learn what you like and what you don’t from the city, as you’re going to try a lot of weird activities accross several places!
  • It’s easier to socialise with other ex-pats than with locals who has all their life here. It’s a shame, because sometimes I feel that I’m not learning the culture of this place, but a thousand different ones because of the people who I spend most time with!
  • On a personal note, try to find a local significant other, that’s the best way to improve the language, get involved in their culture and discover even more secrets of that place!
  • Most capitals will have loads of meet ups, don’t be afraid to join them, particulary when they relate with one of your passions!
  • Share as much as possible with people you won’t find elsewhere, because it’s the best chance you have to learn from them!

Seriously, for me, this is by far one of the best perks a company can offer to you. I won’t work for a company just because it reallocates me to a new place, but when I find an amazing opportunity, having to move is a HUGE plus!

May the force be with you,