DEV Community: Manuel Obregozo

Evolving the Legacy

Manuel Obregozo — Tue, 20 Dec 2022 00:00:00 +0000

One of the benefits of working in product companies is watching your product evolve, nevertheless, that road won’t be only a matter of innovation but avoid things turning into impossible to mature legacy systems.

One of my favorite references to the term I came across, which also motivated me to write about this, is from a book called Kill it with fire which I truly recommend.

As Marianne Bellotti says in her book:

“To understand legacy systems, you have to be able to define how the initial requirements were determined. You have to excavate an entire thought process and figure out what the trade-offs look like now that the options are different. Simply being old is not enough to make something legacy.”

The reality of the moment something was created doesn’t mean we have to carry on all the decisions when making a refactor or an upgrade, as the definition says tradeoffs might take a different path depending on newer contexts.

Technology

Modernizing technology for the sake of using something newer can be mistakenly confused as a way of dealing with legacy systems.

Defining which part of our solution needs to be evolved is where the puzzle is. Switching product A to a newer technology doesn’t mean it will be easy to adapt to the new reality.

I have seen this situation happening in places where a framework is introduced as a result of a partnership or just because it’s trending.

Although it can have drawbacks, using a well-known framework can also have benefits, as, it will make it easier to get new people on board. Imagine that if we have to still provide support to an old system that developers are unlikely to find, we might end up blocked.

Identifying the steps

As part of the previous point, we need to identify and scope as small as possible which is the part that needs to modernize.

Things like refactors and revisiting past decisions, and old vs new requirements can become crucial in the way we define the parts that are considered legacy against just old but functional.

Having deprecation policies will help us in regard to communication with our customers or consumers. It will make innovation and migration a lot easier to handle.

We have to make people aware of the change by explaining, not turning this into a revolutionary change, provide context and data on which we based our decisions.

There was a time I worked on a project that involved convincing people to move to a mono-repo setup and it was quite important to emphasize the communication of it, explaining the reasons behind the change, in order to have everyone onboard by understanding the reasons and not only the technology implications.

Communication is key, in preaching the idea and the people that might be affected by any change we would like to introduce. Speaking a common language to convince stakeholders what needs to be done, will play an important role in the whole process.

Undocumented code

How often have you heard the phrase: “it has to work like this”?

In situations like this, where requirements are not set, and by looking at the code it’s tricky to abstract the decisions that were made while that was developed.

Moreover, as we cannot understand the context and historical decisions, is quite easy to drag errors or mistakes that were made back then and pull them into the new solution.

After going through this situation a few times, I try to remind myself to write conclusions and decisions that I have made when developing something. Rather than putting documentation that can be seen in the code, I focus on context. So that if someone is reading my code plus reads the story I tell, it will be much easier to avoid mistakes.

The same concept applies when submitting solutions for take-home type of code challenges in technical interviews. It will help the interviewer to understand my way of thinking and the tradeoffs I have to consider while thinking about the future, which could be completely wrong. But in a situation where the future is unknown and requirements are vague, it’s completely valid.

Institutional Knowledge

One of the things that people tend to forget when dealing with this situation is institutional knowledge (also known as institutional memory), and how tight these decisions of evolving a legacy are to the process and the culture of the company.

Having people who are long committed to the company culture, and have been working there for several years in multiple positions, will help to move the process easier.

As you can imagine in places with low retention and high attrition, having people leaving constantly will cause the institutional knowledge to be gone. Thus, having discussions or defining processes to move legacy systems would be more difficult to structure and move forward.

Politics and reorgs

A bit related to institutional knowledge, there are cases where evolving something legacy affects the shape of the organization as well.

Coupled software tends to be by definition, more complex to maintain, difficult to test and scale, and hard to adapt to new situations, among other technical advantages, but from a business and strategical perspective keeping the parts decoupled can benefit from outsourcing part of our solution, to name one example.

Let's imagine we have an e-commerce website, and we have our custom in-house logging system if that was coupled or de-coupled, it can make the transition to external solutions simpler or more complex.

Worrying too much in advance

Manuel Obregozo — Tue, 29 Nov 2022 00:00:00 +0000

As an engineer, if I have to pick something that I always struggle with, and seems like a never-ending problem, it's worrying too much upfront about an issue that hasn't happened yet, and probably never will.

In general, given the number of unknowns and uncertainty that life has, preparing ourselves and worrying about what may happen in the future is a natural reaction of our body. And that can have multiple implications in our day to day as engineers.

How does impact our daily work?

Generally, as we can’t predict the future, we might end up in situations where we are working on something that might have no importance in the future, causing our time management fail.

In my experience, breaks or coworkers are the ones who help me get out of those situations. Or at least they force me to tweak my time-investing strategy.

Although context switching might have the opposite effect and makes me lose concentration, it encourages me to have fresh starts and empowers me to recap and look at what is happening from a different perspective.

Following techniques such as Pomodoro often helps me prevent this from happening. A technique, which basically consists of doing 25 minutes of work, with a 5-minute break. But most importantly, I turn off notifications to make those workspaces more productive.

I must say that I don’t use any tool or software for time tracking. Being aware of it already does the trick for me, since sometimes 25 minutes is not enough to finish something that I can continue later.

On the one hand, being meticulous with details is positive, since things may seem simple, but in reality, the details are complicated and likely to cause problems. On the other hand, it could make us lose focus on the big picture. With time and experience, we will eventually find the right balance.

Let the problem become one

Like I said before, I tend to worry about details and possible scenarios that may or may not happen in the future beforehand.

How many times have you, as a team or individual, invested a lot of time on a specific problem or edge case that ended up not being a problem?

An example that I always recall when discussing this matter, was that time when I spent a week trying to figure out a CSS issue on Internet Explorer. And, over a cup of coffee, some stakeholders noticed my demotivation and told me that for that particular browser I shouldn't worry too much, as the analytics for that browser were lower than our official threshold.

Or even from another angle, sometimes I feel that in previous experiences I have foreseen performance issues because I was assuming how the users were going to use part of an application.

In both cases, the investment of time and effort didn’t pay off, and I could have used that time to develop other meaningful tasks.

These situations are not only discouraging in terms of technicalities, but also demotivating, as we realized too late in the process that what we have done in the last few days or hours, has a really low impact.

I also attribute this to the fact that we just like to be challenged, and the feeling we get after solving a complex is hard to explain, but maybe in the environment we are in and from a business point of view it’s meaningless.

In a nutshell, let issues become problems, and look for real evidence instead of gut feelings or making the wrong assumptions.

Did anyone give us feedback about that particular issue? Is it really an issue? Is it a blocker? Try to get the full context.

Speaking of getting the real context before jumping right into it, I remember one Christmas Eve I was on-call and got a phone call about a service not working. I spent 2 hours fixing the issue with the other person, and when I asked the counterpart to do a verification check, he sent me a QA link.

As you can imagine, that was the exact moment when I realized that it wasn’t a real issue and it was only affecting the QA or staging environment for that particular person.

Hope this doesn’t sound like I am against preventing, just being aware that sometimes we go too far down the rabbit hole.

Business breaks

As we progress, we begin to realize how important meetings or sync ups events are (whether they are synchronous or asynchronous) to align expectations and learn more about the business plan. As a result, it will give us the ability to make better decisions in the long run.

Iterations and metrics also play an important role here, as those two factors can be deterministic to define when, how, and where should we invest our time.

Lean on stakeholders or co-workers with higher views such as Product Managers, Engineer Managers, Project Managers, etc, when in doubt about something. Being autonomous is great, but it doesn’t apply to all scenarios.

In simple words, validate ideas up front before making big commitments.

Being preventive helps us prepare for the future, but if we turn that into a waterfall, we might be holding ourselves to deliver faster in a world without patience.

So, in case you spot a potential issue, simply save it to investigate later on when there’s less of a rush. And most importantly, avoid getting caught up in the scope creep of a task.

Mixing leadership, delegation, and accountability

Manuel Obregozo — Wed, 09 Nov 2022 00:00:00 +0000

When we start growing and moving through the laddering of promotions or switching teams, we start experiencing different types of leadership from diverse perspectives.

When referring to leadership, every company, or I dare to say even teams within the same company, define a level of accountability and delegation, that suits them better.

Rarely appreciated, this plays an important role when defining responsibilities. And, I believe it’s quite important to define and draw a line between accountability and delegation.

What’s what

Wait! Before we get immersed in the topic, let me try to clarify things a bit.

In my appreciation the one in the leaderships team is the one accountable, responsible, and who owns the problem (or whatever other subject), meaning that if something unexpected happens, although it’s a team responsibility, it will be mostly on that person's back.

Once that’s defined, in bigger groups where responsibility is shared, we would have some level of delegation depending on how flat the company/team is, just to name one possibility. This means that, for example, in flatter companies, responsibility for decision-making, the team is expected to get more involved.

But where do we draw the limit between delegation and accountability? Who should be the one making the decisions? Do I trust the team to leave the freedom to make decisions to something that I am accountable for? Is it only a matter of trust and experience? is it just a reflection of the sense of having control? If we go to the other extreme does it mean we are gatekeeping information?

As you can see, things are starting to get mixed up, that’s what I regularly see on teams when responsibility is shared, and this defiinition is not discussed or clarified beforehand, in some sort of team agreements or even an informal discussion.

So let’s rephrase and put it in one sentence, although the responsibility is shared, there will be always someone accountable in the laddering of management and leads if something happens, even if that needs to bubble up to the CEO.

Management has changed

If we go back in time and think about the old days, we might probably end up in situations where the hierarchy was defined in stone and hardly challenged by others.

Times when speaking out to managers, or being called “bosses” back then, were regularly seen as lack of proffesionalism. Or maybe, we just thought it was impolite, as I, at least, tended to believe they were not interested in knowing about my feelings or opinions.

Fortunately, management has evolved into something different, and we now can find places with the intention to follow other ideas. Yet not ideal, but better than the old days.

What I am referring to as the new management is where team members feel more engaged, empowered, and take responsibility for success as a group effort. In a team where suggestions matters, responsibilities fluctuate across the team and communication flows up and down with not much restriction or friction.

There are, of course, levels of interpretation, on how deep we want to go with delegation. We can ask for feedback and then the leaders will decide, or just let the team decide and the leader just agrees on it, just to name two extremes. That is exactly the level of delegation that for me needs to be stated somewhere, whether it's implicit or explicit, to avoid misunderstandings in the responsibilities scheme.

Usually, failures are probably the biggest trigger that forced us to think and set up a balance in the delegation levels we have during a post-mortem analysis.

Situations that by setting and preparing ourselves in advance could be avoided.

From another angle, the premise "we are in this together", easy to break, can fall apart when recognition comes into the picture. Who’s going to take the credit? Ideally, this shouldn't be the most important matter, but it can break the trust and commitment of the team if only the one accountable takes the prize.

Things are not always that simple, another problem I have seen with delegation is that leaders or managers, put pressure on the team, with the excuse of “we are flexible and modern”, just to prevent them from taking decisions and being exposed or finger-pointed by others. Which slowly turns into a lack of alignment, trust, commitment, etc.

Eventually, when you become a leader or manager (you name it), what took you there should be your mantra, not suddenly changing your spectrum and becoming what you normally hate.

As a side note, I have noticed that in the IT world most managers come from engineering backgrounds. I am not saying that they don’t have the skills but it’s funny how they can change career paths and become a senior manager in 1 year, and in most cases, that change is based on wishes over the skill set, myself included.

To highlight this topic, I sometimes use the word meritocracy to define that path we have to discover, but as it’s currently misused, especially in politics, I heard a replacement in a song that says that smooth seas never made a good captain which seems to emphasize how I experience things in a more elegant way.

The confusion between accountability and delegation

Within that transformation, there are certain misunderstandings that can cause a team to fight for the wrong problems or get lost in the processes.

We can all agree that there are different types of managers. But just making one segmentation between the ones that like to have everything under control and the ones who like to delegate most of their work, there is a balance that needs to be defined.

Ownership in the sense of I take responsibility, I trust you to move this forward, but I can't expose or blame you if in the end this never gets done

It’s the manager/leader's responsibility to make that happen, so that is exactly the point where I see the gap between accountability and ownership. I do agree that managing and measuring success as a manager is difficult. But as it’s a matter of delegation, it doesn’t mean it’s your responsibility now, and I (as manager) am out of the picture.

What have I learned

Enough about exposing the issues, what can we do?

If I were to become an Engineer Manager now, I think I just know what I wouldn’t do. I only have a little experience as a Product Manager, but back then although there was a lot of stakeholder management, I had no reporting lines coming to me.

Even considering that I just came back to coding, I do see myself in people management over something purely technical. Or at least that is what I have been told by former colleagues and my own vision and preference.

Having said that, what would I do if I get into this situation?

Build an environment where there’s no such thing as pressure or rush. I know that's difficult but If I can absorb that and abstract it from the team, I will.
No room for egos. A place where people feel comfortable sharing experiences and opinions. Where introverts are not afraid about sharing, and the ones with imposter syndrome can open up.
Transparency overall. When I know what to do or not, whether I am lost or not, the team will know about my feelings, and if I ever feel overwhelmed or incapable of playing the role, I will be the first one to admit it.
Not playing the blaming game, whether we win or lose, we are a unit, but if something goes wrong or expectations are not met, I will be the one to blame and take action to make things better.
If I ever have a strong opinion about someone’s career path I would ask in advance if they are looking for ideas or a piece of advice from me.
I would define expectations, and responsibilities by roles together with the team, and reflects on them from time to time.

Unfortunately, as with most of the human problems in industry organizations’ schemes, there’s no such guide we can follow. I based my recommendation on my experience from the other side of the fence.

But, just asking ourselves and clarifying the questions I have shared across the article, could lead to a better understanding of scoping the responsibilities accordingly within our environment.

The flaws of the interview process

Manuel Obregozo — Sat, 24 Sep 2022 00:00:00 +0000

Over the years there have been changes in the way interview processes are handled, which I believe are causing interviews to evolve into something unnecessarily complicated.

This observation, generally called "the broken process of job interviews", I wouldn’t personally call it broken as companies are still hiring, but! I won’t ignore there’s a lot of room for improvement.

Although every company develops its own custom interview process, there are common patterns in how the whole process is split. For that particular reason, I will divide this article into two different parts, one referring to the non-technical interviews and the other focusing on the technical parts we might encounter.

There's no particular audience for this article, as an interviewer or an interviewee I hope you can get something out of this.

Non-technical stages

Communication

Whether you end up getting hired or not, to me, communication across the interview series is the most important factor that will make a process potentially good or bad.

From a starting point, job descriptions tend to be a copy-paste from each other, which makes it hard to understand what are they actually looking for in terms of profiling.

Once you get immersed in the interviews, in most cases, expectations, focus, and takeaways from every particular interview are rarely shared.

And in case the result ends in a rejection, communication, sometimes, gets forgotten.

One of the most common examples of the last point is emails. I am talking about those template emails saying they decided to go further with other candidates, with no feedback whatsoever. Or even canceling your application from scratch without mentioning the reasons why they have decided to withdraw your application in the first place.

Not to mention the number of times I get ghosted after I ask for feedback.

Companies are in the right of doing this, but for me, this is already part of the culture, so if I spot some of those behaviors I won't probably apply again nor recommend this opening to another friend.

Unnecessary filter

Having big companies setting the bar high in terms of complexity and how difficult it is to pass their interview process, has side effects on other companies which follow the same approach and decide to take this as a metric of success.

Far from being the reason for their success, one of the main reasons why they are complex is due to the filter they are forced to make based on the number of applications they have. In the long run, this will give more false negatives, but companies who are getting tons of requests are eligible to take that risk.

The first takeaway of the article, avoid copying other companies’ processes! The big names are the ones dictating the way to do these processes in a way that fits their needs. But that doesn't mean this process will be useful for all companies.

I understand that in places that receive tons of applications with higher salaries in the market, there's a bigger filter that needs to be done. Meaning that if the salary you will end up getting is a life game-changer, I will expect it to be more challenging than others.

But why do others follow the same thing? As for my understanding, it is just because is trending.

Related to this, how many times have you got questions during the interview process but once you started to go deep into the company code, those good and amazing good practices were not even close to the reality.

The one I like the most in this regard is TDD, which is also something I tend to see on job postings as well. I got asked to follow TDD and BDD practices during code challenges, just to find 0% code test coverage on the company code after I manage to get the job.

This reflects a lack of customization and profiling in the process, rather than imitate and go for something standard, you can take this opportunity to look for a candidate that would fit YOUR daily tasks and team culture.

Inclusion and diversity

Inclusion plays a more important role in this equation than people regularly think.

The lack of empathy when companies ask you to invest time in applications or code challenges, without offering anything in return, always surprises me.

I have been told that I should invest more hours in the assignment, just because I have described some solutions with comments, or because my test coverage wasn’t 100%, among others. Is incredible how generous people are with the time of others, isn't it?

Furthermore, considering free time investment, what if I have kids? what if I am doing several interviews in parallel because I am in a rush of getting a new job? what if I have side jobs? Does it mean that I am not eligible for applying for these openings? That’s hard.

So, please make sure those requests are optimized, or consider offering a paycheck among other types of benefits if those tasks are time-consuming.

About this particular subject there's a book and also a newsletter that I would like to recommend, that it doesn't only apply to recruitment:

In this link, you can subscribe to weekly recommendations and check out the book, which has helped me to understand better the importance and complexity of this subject.

One simple starting point is to make your interviews inclusively friendly, by including minorities as part of the process, so that people reflect more, and get a sense of the environment. It will also help out to filter those profiles that show some flags during those sessions.

Duration of the process

I can understand that for companies, especially the ones offering visa sponsorship, where there is a huge investment/risk at stake, before submitting an offer they would like to be as convinced as possible.

Companies aren't doing us a favor when hiring us, we are just going to be paid for our work, it should be a bidirectional negotiation.

But lately, I have completed and started processes with up to 6 phases or sessions, including 3 only discussing technical-related subjects. Why are tech companies so obsessed with measuring and testing technical skills? Especially for senior positions, where tech-related subjects only imply a partial amount of our work, the rest is dealing with other problems where soft skills have a bigger impact.

I find it odd, that the senior and experience I get, the more complex it is to get a job. Crazy!

Side note, in case you are curious to know what defines seniority to me, you can find it here.

Slow feedback circles, make it easy for interviewees to get tired, and long sessions are an overflow of information.

Having these sessions can potentially lead to a lack of tracking of the process, difficulty in syncing the process with the people included, and difficulty finding the right and motivated people to do it.

Focus on the culture

Hire people not roles! Find what type of profiles meets your expectation without looking in-depth at technical implications, as that is the easiest part to learn in the long term. Soft skills are harder to change or adapt.

At a company I used to work for, the most important part of the interview process was in a bar or coffee place, depending on the candidate's preferences. A session where we spend some time chatting informally about work and life. It really worked both for us to check if there was a match, and for the interviewee to get a sense of what it was like to socialize with us.

Train the interviewer is important, and avoid forcing people to take interviews just because they have the knowledge. During a few interviews I did in the past, I had the feeling I did well but the interviewer didn't feel like doing the interview so I was just the victim that person uses to complain about him taking more interviews.

Moreover, make sure candidates take interviews from the company side, and represent the profiles you are looking for.

Technical interviews

Measure the knowledge (aka seniority) is tough. Just the fact that an hour interview is going to define the salary you will get makes people feel nervous, which is one of the reasons why I normally panic before taking any time-framed technical interview.

I believe the interview should be bidirectional instead, where we as interviewers also take a primary role, for which I recommend this article.

Be careful with the people you put to interview, first impressions are really important, and not all devs, no matter how senior they are, are ready to make interviews and assess a person, or even less able to provide objective and not biased feedback about it. This is definitely a skill outside of regular work that needs to be developed.

Pair programming code challenges

I'm not the first person to say that live coding interviews are far from reality and that the only thing it does is put a person in the spotlight, while the others are looking at you while coding and suffering because of the pressure.

No matter how hard you try, if there is one person being evaluated and the interviewers/s know the problem, its context, and its possible solutions, it's definitely not a pair programming session.

We can call it a collaborative session, where devs will help you to proceed if you get stuck.

These sessions are supposed to evaluate your communication skills, but I hardly ever do I feel comfortable

Although I am not a big fan of this particular type of interview, I must say they were cases where the result was successful as the interviewers were able to build and create a safe environment and the assignment was rather simple, as the main focus was on communication and in how to move things forward on iterations.

Rocket science algorithms

I am referring to things like Hackerrank type of exercises, that I would only consider as an option if it's a mandatory skill for the job opening.

As a frontend developer, it’s unbelievable the number of interviews I have failed because of those exercises, that I have never done on a job in 10 years. Or maybe I did, there was time for research and analysis.

So, please try to mirror problems that are likely to appear in the real job.

I am not ranting against performance, as a front-end developer, I invest time in practices on how to improve it, but only when necessary.

In real-life scenarios, I work on problems when they actually become one, or I have metrics that can potentially become one. The need to over-engineering everything just to prepare for every single case scenario is a flaw for the business, that could easily scale to something difficult to maintain.

Take-home type of test

Although is good because there no much pressure other than solving that on the spot (which is hardly a situation you will experience at work), it implies that you take extra free time to work on its solution, and not everyone is willing to do that.

In these cases what worked for me was to set an expected time to spend on it, otherwise is hard to measure if more people can spend more time on interviews than others, and the final evaluation won't be fair.

Scope the investment of time, evaluate comments, and don't be picky when looking for the details. Remember that usually, people don't have much time to work on this considering the context switch and iterations.

I prefer the take-home type of assessment, where you can also see the prioritization of the features and time management. And never ask for everything to be finished.

As in most processes, feedback should be mandatory. There was one time, that I spent a week developing a technical assessment from which I had good feedback first, but at the moment I was having the next round the interviewers started to ask questions without having an idea of my solutions. For me that was a lack of respect, I spent a week of my free time doing something they even didn't dare to check.

Close up

Those were the drawbacks I have noticed in the interviews I have done in the last few years, both as interviewer and interviewee.

Unfortunately, there's no only solution we can follow. We need to adapt the process to our business and provide different alternatives to the candidates so that we will improve engagement and inclusion.

Living with a low profile

Manuel Obregozo — Fri, 05 Aug 2022 00:00:00 +0000

Since I can remember I have been someone who is afraid to say that I am good at something. Not because I am modest, not because I am humble, it just doesn't come up.

That ability or weakness, has taught me different things across the variety of places that I have lived and worked at.

With time I have learned that sharing my vulnerabilities proves that I am aware of my weak points, or areas that I know I need and would like to improve.

And from another perspective, exposing and opening those black boxes, generally help managers and colleagues to share feedback with me.

The real world

Being that outspoken hasn't always worked the way I wanted, there were times when people took that weakness to their advantage to make me feel the hierarchy that was between us. In other words, making me feel inferior.

That's why, in different opportunities, I had to hold on and get back my confidence and self-esteem again because I was feeling undervalued.

I start with the baseline that we all have good intentions, and if I begin observing these behaviors I would probably ask for feedback, and share feelings with my personal manager. As we humans are subjective, those actions could also happen because of a misunderstanding.

Keeping an open communication is essential to staying aligned with reality. Surrounding myself with good people that I trust, with the same core values, and the ones I want to learn from ends up being my best tool to return to being calm and boost my motivation back up again.

Despite we most of the time blame it on people, toxicity isn't always because of the people, but maybe the environment which is triggering those survival and defensive mechanisms.

Talking about work environments, I have also been told once that I was too talkative or expressive, and work is a place where feelings and emotions need to be put aside, otherwise is a lack of professionalism. As old-fashioned as this might sound, these things are still happening.

(There's a book to help me go over this particular topic, “No Hard Feelings: The Secret Power of Embracing Emotions at Work”).

These situations are quite easy to spot, and because of this, I have developed a skill to read people the moment I start working with them.

The road to this point wasn't easy, it took me some time to understand, that I wasn't doing something wrong, and I just needed to find a place with a working culture that fit my profile. This is now the main factor from which I decide whether to take or not a new opportunity, putting things such as technology and money aside.

Feeling sorry for me

Another side effect is that whenever I share any of the previously mentioned feelings or emotions ( or anything linked to mental health), people feel sorry for me. And that, I believe, is one of the reasons why we hide or prevent sharing experiences like this one.

I think it is devastating to get special treatment just because I feel different about something. It actually has the opposite effect on me, and I will probably fade out of my presence there.

The same goes for any type of inclusion, people are not looking for special treatment or fake recognition, in the end, minorities want equality , without feeling judged.

On top of that, but now more under control, I have suffered a lot because of my insecurities and anxiety. So that I will never forget managers and co-workers who took my openness to help me out or land a hand without expecting any type of recognition in return.

You can always learn how to be good technically but those things, in my experience are way harder.

I'm not writing this to feel better than the others, to show off something nor is it something that makes me proud. But just the fact that I am able to share it, makes me feel relieved that I have learned how to live with this, despite the ups and downs.

As a side note, related to mental health, and to close this part I would like to state that we need to stop normalizing working 24/7 or burnout at work. Companies nowadays offering well-being programs are already a warning.

Anxiety at work

To whoever has or had similar feelings what has worked for me is, to try to control the environment. I don’t believe those who say that nobody can change the world working 40hs a week. Live your life, not the goal of others.

The taboo of ignoring the psychological aspect was there since day one, hiding everything under the carpet. Is this happening more nowadays or people are now feeling more comfortable and supported while sharing these things?

It's nice to see kids from younger generations referring to this subject without feeling judged. People from my generation are still in general a bit introverted about sharing emotions, it can also have some cultural and personality implications as well.

I do share my personal views, and how I deal with these things. But it was part of an internal introspection that probably the experience of living abroad accelerated, and took me some time to get the courage to open up this box and start learning and sharing.

From one side it helped me to be more conscious about stress in general, not only for me but with friends, family, and colleagues. And, how this was manifesting in physical manners, in my case insomnia, anxiety plus some eating disorders.

Unpredictable world

The change in paradigms and frameworks has also contributed to helping me feel better.

In the old times, when the most common way of working was the waterfall model, having the need to prevent and prepare yourself for every possible scenario was stressful as hell. And if any situation alternated the plan - that took ages to define - the effects were catastrophic.

Then agile came into the picture fighting the flaws of trying to prepare for every situation and just build and react faster. And the results speak for themselves that in unpredictable situations this is a better way of working.

While searching if I was the only one feeling this way I found this well-written article about the same subject https://matthewstrom.com/writing/agile-anxiety.

That level of transparency to understand that we can't predict the future helps us to be more relaxed, we have time to re-think, fail, learn, and understand that the worst-case scenario is not that bad, generally speaking. I can imagine that in some specific domains those variants that I exposed have a different impact.

Definitely, agile doesn't mean let's do whatever, and eventually, we will find our way. There are things like roadmaps, strategy definitions, and missions, that help us define a detailed short-term plan and vague long-term plan for the unpredictable future. This means that if something comes into the picture that we didn't foresee we will be able to react faster, without feeling that we spend much time preparing for something that never happened.

Believe me, having that as a premise for me was a game-changer.

Along the way, and learning the hard way I have managed to not blame myself for not being able to predict, but that urge is not something that I can give away that easily, even more, when we tend to congratulate people for predicting it, making me feel under-performing if something that I didn't see ends up affecting us.

Having a mix of planning and aligning with the business, and being practical when making changes even if the data that we have is not enough, helped me to fight that anxiety back.

Working as a social network

Since social networks became part of our daily basis, the working environment has been affected by some behaviors from that world.

Those concepts and behaviors are far away from being something new, but people, myself included, tend to show a reality that is not happening.

The show-off revelation, in different types of companies that I have worked for or others that I research about (culture-wise), seems to be a repetitive pattern. A phenomenon that can also be seen in the evolution of Linkedin. Nothing against the tool itself but the usage we got into.

Moments when decorating every situation we are in at work, putting ourselves on top of everything, rather than showing the reality or the learnings we have accomplished. Because not showing success all the time or focusing on improvements could be seen as signs of weakness or pessimism.

When did intentions, or fake results become more important than the actual outcome?

This situation together with gatekeepers contributes to me feeling bummer because I am the one not knowing the future, but in reality, we are all pretending to be comfortable with something we probably aren't. And this lack of transparency and alignment will slowly evolve into something toxic.

When autonomy becomes a silo

Manuel Obregozo — Mon, 13 Jun 2022 00:00:00 +0000

Ever since I started to work in this field, I have seen a transformation in the way companies shape their teams.

Of course, the nature of the business is the one dictating the form and the need of the teams towards a common goal. And we can iterate this into many different levels so let's move from macro to micro.

To close the scope, I will only focus on product companies. Companies that offer and develop a product to different customers, whether they are BTC (business to customer) or BTB (business to business).

Shaping the teams

The first factor that I would like to analyze is the size of the company, in the sense of when a role becomes a need over something the rest of the team can absorb.

It can also be considered as the timing where a company is in terms of its maturation and growth.

In startups, as the main goal is to validate if the product or hypothesis the company is building has a future or not, the common pattern is for people to wear multiple hats, as long as the team is productive enough.

In the beginning, this approach can look disorganized or a bit chaotic, but this is only because the focus is on delivery and nothing else. This for sure has side effects like growing the technical debt, lack of process, overlapping of responsibilities, etc.

In this particular environment, you might not specialize in a particular role, but you will learn about many other areas across the development cycle.

So, again, generally speaking, it's more common to see full-stack developers in startups, and the role of QA, just to name an example, is embedded in the team as a shared responsibility.

None of those embedded roles will be fully proficient, but as I said before, the focus is on delivering as fast as possible. So in case, we fail, we can re-adapt faster.

As the company starts growing, either by getting new customers, investments, or acquisitions, among other possibilities, the need for particular roles becomes crucial to the success of the company.

And here is when the situation starts to become a puzzle.

I guess this is growing up

There is a video from Steve Jobs, that sums up what I feel most companies suffer when growing in size.

The video is about the difference between process and content, process as the set of actions and rituals that took us to where we are today, and content as the output we have produced.

From his own words:

"You know what it is? People get confused. Companies get confused. When they start getting bigger they want to replicate their original success. And they start to think that somehow there is some magic in the process of how that success was created. So they start to institutionalize the process across the company"

It’s not easy anyway, but the less we focus on standardizing or institutionalizing the process, the closer we will get to our final goal.

As the company goes from a start-up to a scale-up, defining a structure becomes a necessary evil. Scaling teams is difficult from every aspect we can think of.

Culture

Hypergrowth, sometimes used as an argument to convince people to join a company, is in my experience something that I, as an employer, will try to avoid.

I am not a fan because this usually ends up with a lot of people entering at once, with no proper onboarding and focus; with a lot of new managers having to take on new roles and promotions due to the new vacancies being opened, a consequence of this growth.

Keeping the culture of what has made a company successful as a startup or scale-up is difficult, and doubling the size in months makes it even harder.

As a newcomer, getting used to a way of working takes time.

Splitting the teams

As the company continues growing there's a need to start dividing and conquering different aspects of the product, in order to reduce the scope and define bounded contexts.

Having that in place, teams can feel more empowered to deliver impact, by getting a better understanding of its specific context.

Splitting responsibilities and defining what's generally known as domains (mainly due to the book written by Eric Evans called “Domain-Driven Design: Tackling Complexity in the Heart of Software”) has become one of the most common patterns to promote what's called subject matter experts.

Whether you call it domains, areas, verticals, chapters, or even products, keeping the structure in sync slowly becomes an issue.

But, how does this affect delivery? The more people and teams we have, the more difficult the communication will be. There is a lot of try and error in this regard, as there is no framework that solves all the issues. So understanding the context and the tools is key.

The benefit of going in this direction is that we develop expertise in a particular subject, which in the end will help to develop more accurate and well-thought features and initiatives. Mainly because we are reducing the focus on the things we have to take care of, in other words scoping the knowledge, and responsibilities.

Similarly, we can think of the analogy when we try to split a monolith into microservices, sorry for the technical reference, but one of the drawbacks is how to balance autonomy and not create silos.

As a side note, I think when people say that every team has a startup feel, would potentially lead to misunderstanding as there is a lot of alignment that needs to be kept in order to fight for a common goal.

Creating unintentional silos

Once we have done the split, things start to get more complicated, and this is when for me the aim for autonomy can have a side effect on creating silos.

Teams will start looking down their own priorities and roadmaps. An aspect that has a magnificent benefit, but if we take alignment and general guidelines for granted this can end up in chaos.

Empowering the teams, and making them believe their impact matters is good, but it doesn't come for free. Having roles to keep those teams synchronized to reduce dependencies, to coordinate common problems with a holistic view of the product, ends up being something mandatory.

No matter how we based the split of the teams, business, or infrastructure, the necessity of standardizing and building the foundations (so we can align and speak the same language) will always be there.

One example of what foundations mean to me can be decided on the agile methodology, or the tracking and communication tools, we will use in every team.

At a certain level, delegating decisions and providing freedom to teams is good, but it all has to be aligned in a way in terms of direction towards the future. Clear communication and easy-to-understand guidelines can be a good starting point. The misinterpretation of these factors is a huge risk in big organizations.

Be cautious when making new steps, and move pieces incrementally and organically, rather than going for revolutionary changes, which are naturally hard to digest. Otherwise, you will spend most of the time organizing the structure of your system to shape it towards pre-defined domains.

Having a business purpose in sync and connected, usually helps to have control and guidelines for the teams. On one hand, they will have the autonomy to take their own decisions based on these key results, and on the other hand, they will avoid falling into silos as there is a common goal in every person's mindset.

Generally, it’s not a matter of only having the process but the people with higher overviews, taking care of cross teams initiatives that can spot where things are misleading, or when we see teams that are supposed to support each other running in different directions.

When things don't flow as expected, we might probably need to go over a re-organization of the team, towards a better setup that will make us work in an organized and meaningful way.

Re-orgs sometimes seen as a bad pattern, are a natural process that companies go for when changing directions or dealing with changes. Obviously, the overuse of this process will make people get tired.

Closing up this is just my view based on how things are seen from my perspective, my experience in the different places I have worked, the responsibilities I have had along with my career, and how these types of processes could affect motivation.

A letter to a younger me

Manuel Obregozo — Thu, 21 Apr 2022 00:00:00 +0000

This is a short letter that I would like to send to a younger me, who is frustrated finishing a degree in computer science, trying to land his first job in the IT industry.

I was planning to call this blog post "How to get hired as a Junior/Trainee" but since I am really fed up with those clickbait articles, I decided to take a down-to-earth approach and just turn it into a letter to myself.

The letter

Hey Manu,

How are you doing? before I start sharing things, I would like to tell you that you are doing just fine, don't be so hard on yourself, you are just starting.

Getting your first IT job will be difficult, but there are things that you can do to make this journey more pleasant.

With no juniors, there are no seniors. This is a fact.

Regardless of the reason behind this, being hired as a junior will always be hard. There is no such thing as a handbook for getting hired, but there are some useful tips that I put together based on feedback I have collected regarding this subject, from recruiters to managers, plus all the mistakes I’ve made, that I would like you to avoid.

Let's try to focus on what we can do to attract companies to our profile and let them compete for us.

Just a reminder, and something I learned from others, companies are not doing you a favor by hiring you, they are just paying for your knowledge and way of thinking

Enough introduction, let's go over the tips I got for you:

Set a personal goal

The overload of free available information is a fact, for the good and bad, and the exact reason why setting goals usually helps. Don't bite off more than you can chew. Try to understand that you can't know everything that relates to development. Some topics are ok to read-only in a high-level post. So before you get into something, try to specify in simple words what's the main goal you can get out of it.

Development is a huge topic, try to understand the different roles of the field, learn about the struggles and the challenges of each one, and self-reflect on which area you see yourself in based on your interests and skills.

Careful with the Bootcamps

The IT world is demanding a lot of people nowadays, and companies are promoting boot camps that sometimes trick people with fake hopes, like learning React (to name one technology) in a week. There is a lot of free material online when you’re looking for spending money on courses. Make sure to get feedback and recommendations first.

Avoid trying to know it all

Remove the ambition to know it all from your head. With time you will lose that spark and feel less guilty about not knowing about a subject that is getting some hype. Do not try to be the jack of all trades.

Mind the careers roadmap

Many developers have defined roadmaps that outline which technologies about which technologies or concepts you might have to study. Well in IMHO there is no such thing as a roadmap for developers. As they are subjective and we all have different objectives professionally. There could be some fundamentals to learn, but in general follow your own personal track, especially the road based on your interests and skills, and focus on the areas that you like and see yourself working in.

Ask for feedback

Ask people about recommendations for different paths. Do you know a friend with the same passion as you? Ask them for advice, and listen to people you care about. Look at areas of improvement but don't forget to enforce your strengths, those are the ones that will take you places. Remember to be honest with yourself at all times!

Take breaks

As trivial as it sounds, a break to refresh your thoughts is always important and I would say mandatory. Don't wait to be calm to take a rest, just at the time you are feeling super busy and stressed, that's the perfect moment to recharge batteries. Don't spend much time during the weeks studying. There will be people on social media saying that you have to study a lot to keep up with the market, well that is not essentially true.

Open-sourcing

Something that's for sure nice at any point of a dev career, but even more, in the beginning, help others to develop new ideas and contribute to the tools that you are using. And as a side effect, it helps to get you into the development world, team dynamics, ways of organizing your work and progress, and setting goals and objectives.

Definitely not mandatory, but it will give you exposure.

Learn about the environment

Development is not only about coding, there are other areas that will help to make your work more interesting. The surroundings, no need to make special focus but just be aware that there are other areas around developing and it is not always coding, even more, related to teamwork. UX/UI, communication skills, and learning English will open up many doors for networking and content.

Share your work

I am not telling you to turn on the spam mode and start sharing your work everywhere. Don't spam, this can cause the opposite effect. Think about this in a more organic way. Be active on social media, make sure you choose the most accurate social media regarding your content. When sharing about projects, or past experiences, make sure you say something unique, particular, or meaningful. Don’t copy things from the internet.

Make the conclusions as personal as possible. Focus on real work experiences, ask family and friends about how you can help them, and build something for them. And after all, share your learnings and conclusions about the process.

There is a nice episode of my favorite podcast that really goes into the details about self-promotion.

Build a CV that stands out YOUR experience

From every past experience, share your learning and takeaways from every job, not only what was your role. Focus on expectations, roles and labels meant something different in every place that I worked. Look at the article from Sarah Drasner about how to write a resume https://css-tricks.com/advice-for-writing-a-technical-resume/

Side projects

Same as having a portfolio, it’s not essential but it can potentially speed up the process. The key point here is No procrastination! Think about feasible things, not things that are way too ambitious that you might abandon. Build something small and then iterate, always write your ideas and thoughts somewhere. Start small, remember that you can always iterate! otherwise, it’s rather easy to get fed up during the process.

Try not to do only projects that teach you step-by-step what you need to do by copying and pasting, do the ones that make you think, be creative and learn (e.g. codewars). I took this as a personal project, to learn how to work solo, and then shared my experience about creating that. In the end, I wanted the have a place where I could share articles.

Try not to focus on the money only

Money is important, and most probably the main reason we all get into this, but at the beginning of our career prioritizing getting experience over trying to get into the best paying company in the market, can be a good exercise.

Join communities

Empathizing with others can really boost your motivation, and get energy from others that are going through the same. Communities are usually good places for networking, and where you can share your own journey making things smoother. Despite your daily doubts, they will make you feel like you belong here.

Massively apply for jobs

On my last try to get a new job, I applied to over 60 openings. I carefully looked for companies and sent a cover letter briefly explaining why my profile can be a good fit for them. Leave the imposter syndrome aside and let companies compete for having you onboard. Show your ambition!

Last but not least, take this with a pinch of salt! This is just a personal observation based on my experience. Don't let others tell you what to do and what not to do. Follow your instincts, ask questions, and learning by doing is more than enough!

Avoid falling into the building trap

Manuel Obregozo — Mon, 28 Mar 2022 00:00:00 +0000

As a developer, if you only look at a list of requirements to follow, building software products can look simple.

It's when we start looking at what's behind that list of requirements that things get more complicated.

In most of my experience, as a frontend developer, I was mainly concerned about the technicalities of the feature I was building, and not necessarily concerned about the reasons why we were actually doing that and the problem we were trying to solve.

From consultancy to product

Whether you like it or not, consultancy and product companies are different worlds, there are the ones that prefer to work on projects and the ones that like to focus on products.

Skipping the details, and generalizing it a lot, when I first started to work for what I called product companies, I realized behind the scenes of capturing requirements, there are other important aspects like making an impact, and delivering value.

These new areas of interest that I knew will help me to become a better engineer, definitely clicked at the time we decided to build our own product with friends, called ServiteOnline.

A lightweight e-commerce solution for stores to go digital in regards to the management of orders.

We have been in the market for more than 4 years, but in the beginning, as we were just building new features from scratch, coming all from a technical background, we fell into the so-called “Building Trap”

The building trap

At the time we started building a prototype we were just focusing on delivering and producing things, just for the sake of making new releases.

So we had developed some pretty cool features and put them as part of our nice shiny catalog on our marketing page.

Features that were only making our product more complex rather than more relevant to our customers.

Back then our main drivers were, making assumptions about something that can be potentially useful for customers, looking at competitors, and just random cool-looking features.

In other words, our mistakes were:

Assuming before asking and validating problems with customers.
Overplanning the perfect feature, covering every possible scenario instead of learning by doing and validating ideas before making them part of the core.
Iterate solutions instead of committing to big projects.
Getting into deep and endless discussions of meaningless features.

We once spent months developing a feature that nobody ended up using. And this, especially in small teams where capacity is low, must be avoided.

As soon as we started getting feedback from clients, plus our own discovery of the areas that I mentioned before, we switched the focus a bit and started to look at things to build from a different angle.

The first change we did was to be customer-oriented, identify problems and turn them into solutions. Using this as a starting point to bring new ideas to the table, whether they were brand new or just improvements and simplification of existing functionality.

Questioning ideas became part of our nature, what kind of value are we bringing? What are we trying to solve? Are we even focused on the right thing? In which way does this impact our main goal as a product? Is now the right time to invest effort into this?

By looking for answers to those questions I realized how important the role of a product manager can be. Some sort of mindset that in some cases is embedded in other roles. I have recently heard of the term Product Developers, referring to those devs committed to the idea of a product.

We ended up prioritizing ideas based on effort vs customer value, which led to better adoption of the features and improvements we have made over the years.

Don't focus on velocity

Something that is worth mentioning is that we also try to prevent ourselves to focus on velocity, customer value should be our main driver.

Being agile by delivering faster doesn't mean we are delivering meaningful decisions. Maximizing customer value, outcomes over outputs.

We shouldn't be looking at the amount features we launch into the product; the number of tasks we have closed, but the goals, strategically speaking, we have achieved as a product.

Sorry if this sounds repetitive, as I have shared my opinion on this particular topic before. But iterations and prototyping become crucial in the sense that we can validate ideas, and remove assumptions from the table quicker.

Dividing releases into smaller chunks and measuring the impact, give us the opportunity to react faster if the impact we were expecting didn't happen.

And if we can encourage and convince the rest of the team to think this way, it will help us to have more autonomy aligned to the main problems we are tackling as a product.

Being self-critical

Manuel Obregozo — Wed, 09 Mar 2022 00:00:00 +0000

Like every person who is self-critical, finding your way to improve yourself can differ depending on the role and responsibilities you have.

A process that can both make you better as a professional/person but also gave you the necessary visibility that you are performing well. Or basically, paint point to the areas to improve.

And on top of that, I do see this as a unique feature or skill to develop and one of the attitudes that took me to different places.

Funny enough, in the process of improving you might get into changes and reinvent yourself just to focus on areas that make you feel better.

Different roles

As a developer, measuring performance, the amount of software shipped, bugs created, the number of pull requests we have reviewed, the number of questions I was getting about my way of writing code, the amount of time we had to roll back a deployment, are some of the tangible metrics we can refer to while looking for results about how well we did.

Although not all of them depend on us, is just a metric to set a baseline.

So that, when looking for personal achievements, while having 360 feedback rounds, or performance checking, it becomes easier to get results or facts from which we can base whether we are performing under our expectations or not.

Or even define and choose milestones we have achieved over time.

Most companies have their own framework that enables them to define the goals we need to achieve or the responsibilities we have to develop in order to become more proficient.

A mix of something in the direction where the company is moving, and what will make you better as a professional for that particular role. Targeting a win-win situation.

In my personal case, having switched to another role towards management, with not many technical implications, slowly became a challenge.

A challenge as it is hard to understand whether my performance of the last quarter/month/week was good or not, and which are the areas where I should focus more.

This is when OKRs, KPIs, or things like that can look like a good option. But most probably they are not for a personal evaluation.

Forget about the business and make it personal

When thinking about performance and success, I am not referring to business progress but a personal indicator. Like a key indicator that I can refer to when looking back about how did I perform.

Link to the sense of how autonomous in my daily work I am.

Putting 360 feedback rounds and personal assessments aside, what can we use as a guide for a personal follow-up?

As I was saying before, using the company north star metrics as indirect feedback can also help, but hard to link that to our personal development.

Take into consideration that a metric could also be something that isn't measurable, but we need to make sure they are not binary.

So let's try to think which things do we normally look at when thinking about how good we are in a certain role.

As a dev, I used to focus on deliverables and ways to improve that process without taking shortcuts or compromising the quality of the products I have built.

There are a lot of options that we can observe and monitor regarding that. We can even think of looking at the tracking system we use and measuring success based on the tickets we close per sprint or month, depending on the work methodology we use. Despite the drawbacks, it is known as lead time.

But, what happens when things are not that easy to measure? What if the work we do as Product Managers (just to name a different role that I am familiar with) is not as easy to measure?

Well, that only means that we have to be creative.

Don't confuse personal success with team success, it can be that things don’t go as expected but our personal performance taking the learnings, was good. There are always external dependencies that are not under our control that directly affect the final results, but that doesn't necessarily mean that we did badly.

Measuring non-technical work

This is far from a final solution, but my first iteration is about things to look for when finding a way to measure success.

This came as a request from a manager but trigger some idea about how to accomplish such a request.

As someone insecure with a low profile, I am always looking back in time analyzing what things I could have done differently.

So finding a way to auto-assess myself became a complex puzzle to solve, but here are the things I took into consideration.

Measuring what for each one of us is a success can be diverse and this is a subjective matter. What being successful means for me can be nothing for others and vice versa.
Social media is out of the table, and as I am not a full-time content creator, metrics that I can get from it are not something I am going to consider.
Use retrospectives to understand when the team has feedback about issues that fit under my responsibilities.
Keep an eye on our autonomy, how much support do we need before making decisions or moving things forward.
Define milestones or achievements that qualify as something you can count as a success for your role.
Ask feedback to different stakeholders, especially to the ones outside of my team, and check how they perceived my role.

Beyond that, it is just about asking questions to ourselves.

How many times have we switched priorities because of poor analysis, and not necessarily related to business changes?
How many times have I had to re-defined use cases of a feature because they were not properly explained.
How many hypotheses I was able to validate or discard.
How many A/B tests have we performed?
How many times has the data we have collected proved that our assumptions were correct?

Putting aside those ideas I try not to set numbers because as a former dev I will unconsciously find a way to trick the system and meet those goals, by only looking at the numbers.

Prevent cheating the system

Defining metrics has drawbacks. When having them tight to promotions or salary raises can encourage people to tweak them in order to get better results, but not necessarily gain something out of it.

So from a manager's perspective, it’s always good and recommend to move money off this discussion.

Well, this has a name: Goodhart's law, from which we can abstract the following quote:

"When a measure becomes a target, it ceases to be a good measure"

The thing is, sometimes we transform metrics into our main target to the point that it stops bringing any value to what was our main objective.

Just to give an example of how targeting results can’t mean that our measured value is optimized would be by looking.

If I were to measure my success based on the number of hours I spend connecting with people over meetings, can cause me to change in the way I do meetings just for the sake of improving this measure but not necessarily improving my performance.

Other options that I have heard are the number of commits or speed of delivery that, as you imagine, can directly impact the quality of the software we deliver. Most people will focus on improving those metrics but not the quality of the code.

Most of the quantitative metrics can be gamed. You will end up with either someone that knows how to game the system or someone that gets along really well with higher-ups. But not necessarily improving your skills.

Overall there isn’t a single way to develop this, as it’s something personal, and we all have different goals and expectations about the future, so the bias can't be removed from this equation.

So, allow yourself to fail, try again, and whatever felt like a good metric in the past can be meaningless towards the future.

The hidden value of meetings

Manuel Obregozo — Thu, 20 Jan 2022 00:00:00 +0000

As a developer, as a PM, or as any other role in the IT world, we can find ourselves trapped in meetings where ideas are shared and decisions need to be taken.

During those, apart from having a clear agenda and a shortlist of topics to address, it is important to have different types of participants in order to have a successful outcome from it.

There is no worst feeling of having meetings that end with a phrase like "this could have been an email".

Getting back to the actors/participants of a meeting, there are the ones who promote the ideas, the ones who take the notes, the one who leads the session, the one that promotes introverts to share their own thoughts, and many others we can think of.

Even though some of them might sound familiar, today I will focus on three different aspects that I do appreciate when people do it during meetings.

Devil's Advocate

This is a quite old position that is becoming more and more common during meetings.

Having a brainstorming meeting without people sharing ideas can feel a bit less unproductive.

But what will happen if there's only one idea and we all commit to that idea without making any sort of challenge?

This is when the devil's advocate comes into the picture, and can help us to find and predict problems in an early stage.

The devil's advocate reflects someone challenging an idea just for the sake of opening a debate and challenging the person who shared it, looking for weak points or encouraging the presenter to convince the rest of the audience.

It is important to mention that this sort of challenge is being done in a way that the person is not necessarily against the matter.

You might consider asking about edge cases, grey areas of the proposal, how this new idea can fix different scenarios, among others.

The elephant in the room

It is a metaphorical idiom for those questions that need to be addressed that can take courage to ask. In other words, those which make you feel uncomfortable to ask because they are controversial or sensitive to the audience. Usually, a topic that most people know but no one dares to put on the table.

Well, those types of questions are also known as tackling the elephant in the room.

This can help speed up things as there is a person asking or referring to the root cause of the problem, the topic that everybody in the room knows but is afraid to talk about and keep running around it.

These types of comments or questions are well appreciated by managers or stakeholders because they bring transparency and honesty to the room. And I must say that in modern times I have never heard of someone being fired for asking questions, even less now when companies tend to be more flat and horizontal rather than hierarchical (generally speaking).

Although I’m not a big fan of stereotypes, I must say that in the time I have lived in the Netherlands I have improved a lot in this aspect, as in Latin America, we tend to send hidden messages to avoid the main subject forcing people to get the message by reading between the lines.

The introverts

Last but not least, as I mentioned earlier, we can not forget the role that cultural implications and personalities play in this game. As someone who used to be an introvert, having people that make sure your opinion is heard and shared with others during meetings can be helpful, and teach us to feel more outspoken without feeling forced to do it.

And from another perspective, we can also consider cultural differences as something to consider while having meetings as expectations and how the meeting is structure could differ and cause different feelings and interpretations.

Regarding this last aspect, I really recommend taking a read to the book Cultural Map from Erin Meyer, in which she explains these topics in real-life scenarios.

Last words

As well it is important to have profiles with that initiative to help resolve things faster, it is crucial to create the environment for those things to happen. If we don't encourage or promote these sorts of activities they will never happen.

Outside working hours, when doing interviews this can be also aspects to take into consideration, going directly to the point, addressing directly sensitive topics like salary range, or even challenging the interviewer with questions about the company/product can be very much appreciated from the interviews.

Honesty can be a great weapon only when used carefully and in good manners. Despite being tough sometimes, in the long run, people tend to appreciate more, or at least I do.

Take care of your soft skills

Manuel Obregozo — Wed, 29 Dec 2021 00:00:00 +0000

I’m not sure how unpopular this opinion is but I believe that for most of the positions I have covered, soft skills were way more important than technical aspects.

As long as you are willing to learn, and motivated enough you can always get better technically speaking.

But soft skills, that is a different topic, where it doesn't matter how much you read about it, it is mainly always related to behaviors and manners. I am not telling that this can’t be taught or learned, but it's definitely harder.

If we look back and think about our previous experiences, we tend (or at least I do) to remember them as good or bad based on the people and project as a whole and not linked to a specific technology.

The fun fact is that, on average, companies normally assess soft skills deeply (usually called cultural fit or behavioral interview) at the end of the round of interviews. While for me this should be the first filter. Hate to call it "filter” but it makes it easier to understand.

Both types of interviews are really hard to make and assess, people doing interviews should be trained, and paid to do it. This is a different skillset to have and doing these types of sessions can produce context switching chaos, causing the interviewee to have a bad first impression. More to come on this subject soon, so stay tuned!

Whether you are a senior or a junior developer if you were to measure the time you spend coding and not coding, what would be the result?

With not coding I mean, any agile meetings you can think of, whiteboard discussing with colleagues, reading and understanding problems, helping others, etc.

Well, in my case taking a hard guess based on what I have seen in my calendar and doing high overviews estimation I would say I spend only 40% of my time coding solutions, sometimes less. And the rest of the time is somehow linked to activities where my soft skills are way more important than technical skills.

And that's the main reason why whenever I get the question about a career path or what people should learn when taking their first steps into this field, is to focus on the processes, communication, and the people. The technicalities will come with time, you will eventually feel more comfortable and get better at it.

Learn about how to give and receive feedback, lean communication, learn English if you are not a native speaker, feel comfortable about sharing that you don't know anything about X, how to put the team over your personal opinions, how to listen to others, how to respect and support unrepresented groups, among other things to keep in mind.

Be the person that you would like to work with, not the one you will possibly avoid.

Content Online

I do believe that writing/blogging about technical things is important and necessary. But since there is already much technical content I took a different path to where I think I can give more to the community and decided to start writing about other skills or social related topics, also known as soft skills.

On a daily basis, we focus too much on technical aspects and we tend to forget or to put aside other aspects of this combination of social and behavioral abilities.

During the last few years, after having so many people getting burnouts, or maybe being open to sharing it, it has thankfully become a serious topic, and just like that, I started to see more people caring about subjects such as open communication, proactivity, teamwork, mentoring, frustration, work-life balance, just to name a few.

It is not always easy, and it will never be! Even more now with this globalization/internalization booming in the market we often see this cultural barrier (on top of different personalities) making relationships at work even harder.

How do you deal with your day-to-day relationship, are you afraid of asking for help? This can be more important than you think in order to have good relationships with your pairs.

During a round of interviews I was asked:

How would I react in case I have to ask something technical to other colleagues, would I feel bad for not knowing that specific thing?

As you can imagine, my answer was clearly not, but in other situations, I would have just spent a useless amount of time trying to find an answer on my own. But today things are different, I am not afraid of what people might think about me because of the questions I ask.

Selling yourself can be also considered as part of a nice soft skill to have, negotiations and believing in yourself and the way you explain things to others could be a game-changer in your professional life. Or even when having 1:1 type of meetings with our managers, the ability to communicate what are our goals and expectations, might change the way you progress through your career.

A story I can relate to this is that one time I got mad or thought it was unfair that a person was getting way more money than me and we were actually doing the same work on a daily basis. Well, that was a wrong assumption. Thing is, I was only looking at one side of the coin and looking and the technical expertise. But truth be told, that person was way better than me when managing expectations, communications, presentations skills, and most of all negotiating his own salary.

Like many other situations that you can imagine, I just thought about sharing some of them to show the impact your social or soft skills can have on your daily work.

Think outside the box

Manuel Obregozo — Tue, 30 Nov 2021 00:00:00 +0000

Since I started to work in the IT field, there were two stories/analogies that marked me in the way I see software as a process, mainly because there were real-life situations.

The main takeaways from these stories are about the mindset and how our way of thinking can affect the way we build our software.

I am not sure who owns these two stories but I do know from whom I heard them.

The first one is from a teacher, and he shared this story with us back at the university when we were studying Design Systems from a software architectural point of view.

The story was about an industrial team working on a new car.

Once they got the car finished and ready to be presented they were impressed by their work and prepared a whole presentation and went through all the things they have achieved.

At the end of the presentation, there was a video of the car running where the engine was making actually no sound so that the only thing you can hear is the tick-tack of the clock in the car.

The whole audience/team started clapping except for one person that was quietly thinking and raising a hand up.

At the moment everybody got quiet again, this person exposed: “I know how to stop the sound of the tick-tack”.

As silly as it sounds, this taught me to always be ambitious and have a sense of continuous improvement because there are no limits. Recognitions are always good, but the software is an ongoing thing, and this is where the phrase that I normally use comes from " always beta version".

The second story that I would like to share, is from a former work colleague, who told me a story about a problem that a factory was facing with its conveyor belt taking up empty boxes.

So in order to fix this problem, they had to figure out how to extract and remove those empty boxes from the mainline.

After analyzing complex solutions with x-rays, scales, and even robotics a curious person walked by and said: - Why don't you put a fan next to the conveyor belt and that will blow away the empty boxes?.

As simple as that, the main takeaway from this story for me is to always take simplicity and creativity over over-engineering solutions that may look smart but also unnecessarily complex or inefficient.

The reason why I like these two stories, and the reason why I always like to highlight them is that they reflect how curiosity, creativity, and continuous improvement can make you think outside of the box.

But wait a minute! How do we think outside of the box, what does it mean?

I really like this paragraph from the Grammarly Blog, https://www.grammarly.com/blog/think-outside-the-box/

The problem is that we’re creatures of habit and most of us prefer the comfort of familiar routines. Thinking outside the box can mean challenging long-held beliefs. It’s about answering “These are our best practices” not with a nod but with a raised eyebrow.

Other things that I normally hear from friends and also helped to encourage myself to think outside of the box are:

Change the domain of the problem, ask kids or elders about how they will assess the problem you are dealing with
Explain the problem to someone from the outside
Don't always look for solutions in the same portals
If it's a known problem, check how people used to solve this issue in the past without any technology
Think about how to overcomplicate something and then try to take shortcuts
Put the solutions into a drawing
Think about the worst-case scenario
Try not to get immersed in the routine and change small habits
Think about what would you do with infinite resources
Think about the ideal solution and try to reverse it

There is no handbook for this, but these few points always helped me to tackle things differently. Try to create your own list, without making it a routine!

We, as engineers, tend to overcomplicate things, because our mindset is built and shaped in a way that we always have to go to the optimal solution, and sometimes solutions are right in front of us and simpler than we think.

I hope you enjoyed reading this and that it has helped you come to any personal conclusion, but in the end what I wanted to share is how by listening to these types of analogies between life and coding you can change the way you think and build your software, because at some point what we do is try to solve human life problems.