7-month whirlwind

Before you start: I recommend reading this with the following soundtrack 

It started in February 2022 and ended in September 2022. Almost 7 months. Around 60% of the whole year. It was a long process and it felt like 2 whole years. 

It all started with a question: do you want to take a shot? It could be a big change for my whole family, an adventure. It could change 2 of the 3 Naval’s big decisions: where you live and what you do. I discussed it with my family and we were ready. Although we never felt that it could happen until 7 months later. 

The first phase was waiting for the process to start and getting the initial ok. It was not really hard but it took 3 whole weeks. Where 90% of the time was waiting. Still, we saw everything very far away. 

The second phase started at the very end of March. I was waiting for my car at the car wash early in the morning and checked my email. They wanted to do an interview. I almost jumped from where I was sitting. This was the next step. I had my fair share of rejections and bad experiences with interviews. I hoped that all those stepping stones would help me in this one. 

I studied a lot. I had help from my mentor and my wife. I tried to think where the interviewer would take me. I tried to find any blindspots or topics it could get tricky. I spent a whole Saturday reading and practicing. You never feel ready, but I was as ready as I could be for Tuesday. 

The interview experience was unexpected. We started a little bit late, which only made me more nervous. Once we started, the questions were different from what I had prepared. I overprepared. I took 20 mins when it was scheduled for 45 mins. I got the result fast. A YES! 

It took 2 weeks of waiting to make it official. I was out of the office one of those weeks, recovering from minor surgery and refreshing my mobile email client every 15 mins. The email arrived 2 days later. It was still a long way to go, I needed a visa. 

The third phase was from mid-April to early May. It involved a ton of paperwork, emails with lawyers, and navigating through complex government websites. I had a lot of doubts all the time if we were completing everything correctly. We tried to double-check every document and process, but we never felt quite sure. The biggest takeaway from this phase was the visa appointment in August. 

The fourth phase was 4 months of 95% waiting, 3% preparing, and 2% going to the appointment. Although the percentage of the appointment looks low it was the most intense part. I checked a website every 2 days for an earlier appointment, but never got lucky. 

One week before the appointment I had all the papers at hand and preparation started. This was more intense than the last interview. I had a guide of possible questions, I knew by hearth my answers and even the questions. I was really nervous about this interview, none of the people I knew had been rejected. I did not want to be rejected for something I said. I knew I could not control the result, but at least I could go prepared.

The day before the interview we went to our favorite coffee shop. We ate our favorite things on the menu and sat nervously for a long time. After that, we went to a shopping mall just to walk. We wanted time to go by. We both got sick the night before the appointment. We were really nervous. 

On the day of the appointment, we were nervous but we knew the logistics well. I received a lot of help from a friend who had gone through the same process a couple of months before. I knew even where I had to park. The appointment was very early and we arrived 45 mins earlier. The process inside was smooth and the interview was shorter than I expected. Approved! We were moving in 4 weeks!

The fifth and last phase was a whirlwind of preparations and getting things out of the apartment. We ran a lot. Ran a lot of errands and said goodbye to a lot of people. I get a little bit stressed even just remembering that time. We slept a few hours and did a lot of things. We were tired but managed to solve everything. We said goodbye to our first apartment, ate my favorite dish from my hometown, and jumped into a plane. 

It was after the whirlwind that I finally realized something. We were driving in Houston, down the car-packed 9-lane 45 highway at 65 miles per hour when I thought: oh man, I live here now.

Learning Overflow

Imagine being in a huge candy store, but you can’t taste the delicious sweets because you just had a big meal and your stomach is about to explode.

This is what learning overflow feels like. 

Since I was a geeky teenager learning about computers, I always felt like a kid in a candy store. Wherever I looked there were new colors, new shapes, and new flavors once I tried them. I felt the exact feeling when I browsed books about computers. I wanted to learn everything. My restless monkey mind swung from one topic to the other, riding the different waves. I just wanted to keep learning new things. I felt an authentic fascination to learn about these topics, my curiosity could not be stopped. I was on exploration mode, as an archeologist as Michael Ashcroft says. 

At some point, it slowly started fading away and it stopped. Until I got to a point I’m now where even browsing for something new to learn is too much. I cannot pick a topic, much less learn about it. 

I gave it some thought and discarded some causes:

• The number of new things: Tech is an endless stream of new things being created every day. Frameworks get updated and new ways of working are created. There is always a new fad. They come faster than you can learn about them. 
• Did I learn everything?: That is definitely not it. I know there are a lot of topics I have not learned about. I also lack depth in some topics I have started to explore. 
• Am I working too much?: I am working a reasonable number of hours. My weekends are free from learning tech-related stuff and I take regular vacations. 
• Am I bored with tech?: New topics look interesting. I just do not feel like learning about it. I just feel too tired to explore and play with new things. 

What does learning overflow feel like?

Imagine visiting the same candy store, where your eyes could not stop moving, but you’ve just had the biggest meal of your life. You do not want to see anything edible. Just thinking about the idea of eating something makes you sick. It does not matter how many new colors, shapes, or flavors the store has. Your stomach aches and you just want to leave the store. 

Let’s come back from the metaphor world for a second. That last sentence was interesting. If you could heal your stomach, would the candies start looking tempting again? Can you heal your stomach if you still are in the candy store? Do you need to go to a hospital? What would a hospital be in the real world? I’ve felt the pain in my stomach decrease, but it does not feel healthy yet. There is also the question: can this be cured? Or do people just switch to salads for the rest of their lives? 

There might be a correlation between learning overflow and burnout. I don’t think they are the same. I am able to perform at my job. Complete the required tasks and sometimes even propose new things. Could learning overflow be one of the first stages of burnout? Hard for me to tell right now, I don’t want to find out. 

It’s hard to discuss solutions when you have not solved your problem yet. I’ve read about the great benefits people get when they leave tech or just a corporate job. Although I heard it takes time for the healing to complete. In my case, leaving tech altogether would be a bit hasty. I would need a middle ground. Could I try a tech detox? Disconnect from Twitter for some time? Due to the nature of my job, I can’t leave tech for good, but at least reduce the exposure. I could start with a month. Journal how am I feeling and report back.

Maybe if I step out of the candy store and take a long walk in the park, will my stomach start feeling better? 

The secret to thriving in a doomed tech project

Hello! I know you’ve come for the secret and we’ll get there. We’ve all been in a doomed tech project. You feel in your stomach that this is not going to work, you can almost smell all-nighters approaching. Let me tell you a story that will make explaining easier. 

This was my first big project as a Project Manager in Software Development. The whole team was the victim of a poorly scoped and badly negotiated project. We had to do some overtime but were able to keep it on a reasonable amount. Even though the odds were against us, we managed to have a good vibe and enjoy our work. 

One day our main stakeholder calls me to his office. What he said to me next left me speechless: due to another vendor not being able to deliver their part of the project, we are going to pull the plug. We are going to pay for everything you’ve done so far. 

The secret is not for you to wait for an external event that solves your problems. This was pure luck, something we could not control. It’s a bad idea, expecting every day that your doomed project will be almost magically solved by other people.

The secret to thriving was positivity. Sounds easy now, but the landscape was really gloomy for some months. My attitude was something I could control. I could not control the contract, what the client said, or how fast we could progress. During the crazy hurricane, a positive attitude kept me grounded. Helped me find calm in all the turmoil.

Let’s think for a second about what could have happened without the right attitude. We might have gotten to the same point. But might have got angry between us, people might have screamed and we might have not been able to build a team. This badly planned project made us a great team and blasted us into the next project. Doomed projects break team, the right attitude made us stronger. As David Goggins says: to make a sword you need to put it in the hottest fire you can find. 

Being positive is not about being delusional. It’s not the person that it’s like in another world. It’s not the person who is saying: “Hey, this is perfect. This is cool, right?” And it’s 11 pm you’re writing code and when you should be with your family. You don’t need to be disconnected from reality. It’s okay to say, you know, this sucks. But at least what I don’t want is for you to collapse your awareness and just descend in a vortex screaming and say, Yeah, I hate this. You know, start cursing and doing stupid things.

Positivity means working hard with a nice attitude when everything seems lost and it looks like you’re not going to make it. Being able to remain calm, work hard be someone that people can look for you and say, yeah, he’s got it together. 

This is a meta-skill. This is something you can cultivate. You can try meditation, Alexander Technique, or gratitude journaling. You’ll find a lot of opportunities to practice this in the extreme sport of working in tech. The important part is the outcome. You want to have this. Because your career you’ll find this kind of situations and you’ll have to face them, you have to walk through them.

There’s another important advantage that if you are able to maintain that good outlook, work hard as I said, being a nice person. This will help you build relationships. You only know people in their darkest times when things get rough. You want to be near people who you can count on when things go south. You don’t want a screaming hurricane when things get difficult. 

As I mentioned in the beginning, I hope you are reading this for fun and not because you are facing a doomed tech project. But if you are, remember:  stay positive and calm, work hard and accept situations that sometimes suck. Don’t be the screaming hurricane, Be the kind of person you want in your team. 

The game of selling for introvert engineers

Hello! I assume if you scheduled this 1:1 you already heard about the sales quota. I felt the same, sounded like a scary big number. How can you go from writing world-class code to selling five figures projects? 

I was there five years ago. I’ve managed to play this game, closed big deals, and find my way through it. Selling is a big part of consulting. Someone has to get the projects through the door that way other people can write code.

Let me share some of the stuff I learned. We have finite time, I’ll share the lessons and a brief explanation. We’ll be able to dive deeper into these lessons in future conversations. 

Different games of selling

Selling groups a lot of different games. Your first task is to identify which are you playing. Then you can find out how to win. Some examples of these games:

• Selling to an enterprise client or internal team. You put together a proposal or pitch, you convince them your team can deliver the work, and explain how much money they are going to make. You can contribute a lot building the architecture and making sure estimations look realistic. There will be nuances between enterprise and internal, much more related to how much paperwork or how many questions they are going to ask.

• Providing people to other teams that are delivering big projects. Some people do not consider this selling, but these are the same dollars as the other game. In this game, you’ll look for the right person, prep them for the internal interview, and make sure their CV looks awesome. 

I do not recommend trying to play all the games, choose one and get good at it.

Your network is your biggest asset

Let me start by saying your network is big and valuable. You are thinking otherwise because you are not visualizing it and capitalizing on it. Let me show you how:

• Go into your inbox and search for people you’ve interacted with or helped in the past. Build a simple list with their email and the topic. Once you start selling add people who you’ve managed to sell or who you were not able to help (not enough capacity, a competitor won…)
• Now that you have your magic list. Start saying hello. Send simple emails periodically based on the level of trust. If you talk a lot you can do it every 2 weeks, if not you can move it every 3 months. 
• Use the holidays or press releases to find an excuse to say hello. Send a New Years’ message or congratulate them for being featured in the company newsletter. You do not need to sell on these emails just say hello. They will have you top of mind. 

Operational Excellence

This sounds a big complex word, but it’s pretty simple. Do what you said you were going to do. Move fast, when people are looking for something time is of the essence. This does not mean sending half-baked proposals or CVs. If they are not ready that is ok, but let them know in a timely manner. 

The best way to accomplish this is by building a system. Make sure the CVs are updated and organized. Make sure you have nice templates and boilerplate content for your proposals. Organize your time and meet your deadlines. Build trust by being someone they can rely on. If you said you will answer by EOD, show up even if you do not have the answer yet. 

Remember it’s a numbers game

There is no algorithm for sales. You can do everything perfectly and still lose. There are humans involved here and they are not rational. There is also luck involved. Do not feel bad if you lose, you’ll lose deals here and there. 

Think about sales as playing the lottery. You don’t know the winning number but you control how many tickets do you buy. You buy tickets by doing the right things. The more tickets you buy the more chances you have of winning. You cannot buy all the tickets. There is always a chance, even small that someone else wins. 

Closing advice

There is more advice but let’s start applying the ones we discussed today. In the following meetings we can talk about:

• Predict the problems they are going to have
• Doing the right thing
• If you confuse you loose 

These will have to wait, we need to move to our next meeting.

Get in the water, start writing some emails and help with some proposals. Let me know if you have any questions or you find yourself in a tricky situation.

Happy selling!

Easy way to screw up leadership in your team

Let’s start with a hypothetical situation. You are one day working as always and one of your direct reports needs to talk. Let’s assume you drop everything and can jump into a call. Your teammate needs some help: he applied to a conference and needs some day off to attend. This should be an easy one, conferences are fun and people always learn in conferences (this blogpost can also apply to a medical procedure or something similar). There is a trick, your project and your client (could be internal/external) might be impacted by this decision. Maybe there is not a lot of runway to make the decision.

What do you do now? The easy way is: “Sorry, we can’t do it this time. There is an important deadline/deliverable and we need you to reach it”. This is the easiest way out, you don’t need to talk with the client and there is always a conference next year. Maybe next year planets will align?

There is another way. You say: “I got your back. This conference is important, is a great opportunity and I will fight whoever I need to fight for you to take the days”. How confident you sound and how much you can promise will depend on your position in the organization and how much influence do you have. Sometimes you might need to say: give me some time and I’ll try my best. But what you need to do after that is fight with all that you have for him. Think about creative ways to reach the goal, maybe some overtime before the conference or maybe the whole team can help. 

The result is important but it is not everything. What matters is how you communicate and that your teammate feels that you are on his side. This can make or break a relationship. In tech job markets are always hot, you will not be able to always compete in salary but these little details can make the difference. 

Also there is something way worse you can do. Please never do this. You can blame the teammate. It’s sad but I’ve seen it in the past. Sometimes managers say: “Why did you do this? If I bring this up it can bring a lot of trouble. This is a big headache“. Please don’t do it. At least try to get the days for your teammate. 

How would you handle this situation? Have you had different experiences? 

How do you find your weak ties?

Weak ties are very important in your life. You can find some science here. Weak ties are people that are in your network but you don’t talk to them very often. Your strong ties are very important but you’ll get very interesting and more novel information from weak ties than your strong ties.

In the past, I found my weak ties in the office or simply by going out to the supermarket, shopping mall, or restaurant. Today because of the time we are living in (lockdowns and a pandemic) it’s hard to find your weak ties. Being most of the time at home reduces the chances to find those people.

The other place you might be able to find them is online, but this is a complex topic. I feel that leaving the chances of finding a weak tie to an algorithm has not worked very well in the past. There is a chance you find someone while you scrolling, but I guess those algorithms might be optimized to show stuff from your strong ties (to increase engagement and the chance of showing you ads). This could be incorrect but I don’t think there is a lot of value in optimizing for weak ties (or is it?).

I’ve been thinking about how to find these people in a more disciplined and systematic way. There might be an app already or one could use a spreadsheet. I would like to have a way to log the people I interact with on a daily basis. After some time one could find strong and weak ties, and try to reach out to the weak ties. Sometimes just saying Hi to a weak tie is nice.

This method might not help to find all the weak ties. It could leave the very important ones but is a start. Which method are you using today? Happy to hear about it in the comments or on Twitter.

From Networking to Machine Learning in just 10 years

2020 marks the end of my first decade working. It has been a great ride. When it started I had a very different idea of what was going to happen. I have learned a lot. For some reason, I never optimized for money (the journey would have been very different), always tried to do what looked fun, and followed my gut. I would not recommend anyone following a similar path, just wanted to share it in case you find something interesting.

• College: I studied Telematics because it did not want to be in front of a computer all the time. When we are young, we are naive and for some reason, I did not want to study software engineering. In college, I enjoyed a lot the Networking courses, Math and Physics. I took 4-5 programming courses and they influenced my working life a lot. 
• First Job: I worked for 3 years at a local Internet Service Provider. I learned a lot about leadership, networking, and professional life in general. My first code to run in production was a bash script I hacked in 45 mins, fortunately, it worked. At some point, I felt Networking was more about using technology than creating it. I started dreaming about programming and starting a startup. 
• Startups: I started a couple of startups after my first job. One was a SaaS product for tourism operators the other one was a tiny consulting firm in IoT. The main takeaway here was that I started programming full time. I had to learn a ton of stuff on the fly and was not very good at the beginning. I had some great teachers and was an avid user of StackOverflow. I thought the IoT startup was a product company, but we were actually in Consulting (I learned this like 5 years later). I had the chance to create some interesting products and watch them in production. I still feel happy that we did not break anything serious. I was young, reckless, and always said yes when people asked me if I could do something. There were a lot of long nights and fixing stuff on client datacenters. At the same time, I taught some classes at a local college (Mostly about networking and computer architecture). 
• First Consulting Job: After the startups, I needed some money and wanted a more regular job. By some interesting coincidences, I landed at a software Consulting firm that was opening up operations in my country. It was a fun ride. We did fairly large development projects and I learned a lot about leading and managing software projects. We worked at the client office and this taught me a lot. I also learned a lot about the Consulting business, given that it was a small operation there was an opportunity for me to learn and help in different parts of the business. I enjoyed helping with invoicing and other administrative tasks. I also burned out, grabbed more work than what I was ready to take. I learned some key lessons about worked in general. 
• Second Consulting Job: Before my second Consulting Job I did a quick pause to teach some more courses and learn other things (Executive Coaching). This pause helped me recover from burn out and prepare for my next adventure. I started taking some courses on ML (still remember when I finished Andrew’s Ng ML course). I got hired in my second Consulting Job to work on RPA projects. By pure luck, there was an opening in a new ML team. I jumped at the opportunity and kept studying. Had the chance to put a model in production and be with the team the whole process, from whiteboard to production. Also had the opportunity to work with some super smart Ph.D.’s and they were also very humble. I enjoyed working with the team a lot and learned a ton of lessons.

This is where I am today 10 years after starting to work at the ISP. I have enjoyed a lot this journey and am super excited about what is coming now. I am not sure if in 10 years I’ll be in the same place working on the same kind of problems. Hopefully, I’ll be able to come back to this piece and look back with a smile. 

If you have any questions/comments, feel free to reach me on Twitter.

Leading someone with more years of experience than my age

It all started at my first job. I’ve been around 6 months in the company and was happy getting used to the ropes of my current job. In those 6 months, I quickly pushed to prod (without even knowing it) and was learning very fast. I still remember when my boss called me to his office: We are going to do some changes and you’ll lead this new 3 person team. I thought to myself: Cool, I’ve learned some books about leadership, this could be fun.

The tricky part was the members of the team. They were a couple of technicians who had more than ten years on the job and more than twenty years in the company ( I was twenty years old). One of them was even a team lead recently. I did not understand the mechanics of that re-org at the time and still don’t have all the information about what was happening. I wish I had some cool story about why I was chosen to lead the team, really don’t know.

It was not a walk in the park, things started to get ugly before they could get better. As expected they pushed back a lot, they did not like the change, me, or anything that was happening. It’s funny, looking back I think my ego should have been hurt based on all the times they tried to avoid working with me and change things. I guess I was so confused with everything that I had no time for that.

When we started to work together, one thing was clear: they were not in the mood to take orders from a kid. I was not in the mood to give orders to them. This particular situation helped me a lot and shaped the way I work ten years later.

Given that it was almost impossible to give orders and avoid starting a world war. I started listening, that’s what I did the most in the first weeks. I listened and asked questions. Not like interrogations, more like curious questions. I think the key to the questions what that I wanted to learn from them. I was not a trick, I was very interested in what they were doing.

I still remember some kind of pranks they pulled on me. They would tell me they had run out of a particular material they needed. I had made a lot of calls and research to try to find it for them, then they magically found some in the warehouse or the car they used. I did not know these were pranks, I learned later when they had another team lead (I laughed that time).

With some retrospective, I think these pranks were not just to pick on the new guy. I think they were testing me. They wanted to see what I did, would I forget about the problem, slack off, blame it on them, or take ownership and be part of the team. Most of the time I came with solutions and discussed alternatives with the team. Some weeks later I think they started to trust me.

There was a point where I started to notice that I could help with some things. Not so much in executing, but there were some things they needed help with. Mostly operational excellence. They were relieved to have someone handle that. Every week we were becoming a better team.

Patience was a foundation for this team. At least from my side. I did not rush things out (I was not even sure how to do that) and never try to impose my ideas or way of working. I trusted a lot the team and things started to look better.

Not everything was perfect. We had disagreements and sometimes we preferred different approaches. This is normal in all teams, the good part is that we started to have a process. We had a daily meeting, talked about what we needed to do that day and we talked briefly at the end of the day. Every side learned to cede sometimes and when months have passed we were playing by ear.

Even though we were a productive team and technically very respected, what I always treasure from these experiences is human relationships. I still have a great time whenever I talk to these two people and we have a blast remembering the good old days. Based on what they say, they learn a thing or two from me, but I learned a ton from them and that experience.

I am writing an ebook about how you can choose a problem to solve and make money. Please let me know any feedback on Twitter.

A superpower every dev and data scientist should have

When you start your career in tech a big part is finding your superpower. At the beginning you might have to try different things to know what is yours. Some people are super happy working on databases, others like backend stuff, machine learning… you name it. A big part of your 2-3 first years is finding the intersection between what you like and what you are good at.

It’s normal that we look into tech-related superpowers. It’s what we do most of the day. But there is another superpower that can make you stand out. Does not matter if you are a developer on a big company, founding a startup or somewhere in between. I’ve found that this superpower can change your career and help you grow in some interesting directions.

The superpower is talking to business people or to other people in general. You might not like it but it can help a lot. You might need to communicate with them for different reasons: you might want to suggest a new feature, you think the team should spend more time on a specific topic or you might need to explain a delay in the development process ( I know this never happens :-)).

Understanding how much to talk, what messages to pass on, and how to structure them can be key in your professional development. And even more importantly, can make you enjoy your job way more. People will enjoy working with you, they’ll look to you for advice and you will enjoy working with them.

You don’t need to be a smooth talker. Just focus on your audience, what are they interested in? What do they need to understand? Don’t use big words. Don’t lecture them in Computer Science or Statistic complex concepts. Understand their metrics, what they are trying to achieve, and align your speech to those.

It’s never the same to say we need to implement SAML2 than to say: single sing on will make our customer life easier. Don’t say we need to re-vamp our whole backend to improve performance, say: we’ll lower our order processing on an average of X%. Those little tricks can help you get your features built and explain better what you are trying to achieve.

Before starting a Data Science project in the company you must…

You’ve probably heard about Data Science, Machine Learning, AI and all those cool buzzwords. You have heard that some of those technologies can help you use your data to predict the future: forecast your demand, avoid fraud and recommend products to customers. It’s great that you are thinking about starting one of these projects.

Most of the times teams start thinking about the how. They focus on the algorithm, on which kind of problem they are trying to solve. Is this a classification problem, clustering or regression? This might bring some undesirable results to the project. The team may optimize the how but forget about the fuel that makes it all run: data.

Before starting you should work on a Data Quality report. It does not needs to be very complex but it needs to answer the following questions:

• Can I trust this data?: Do you know where this data comes from? How was it collected? How much human intervention has it gone through? Is it external or from one of my own systems?
• Do someone on the team understand this data?: Are we sure we know the unit of measurements this data should have? Does the frequency makes sense for the kind of problem we are trying to solve? Can somebody tell if an specific data point is off the charts? (Imagine having a negative number on a sales table)
• Is the data good? There are lots of frameworks to evaluate this, but you can start with simple questions. Do I have a lot of empty rows? Do I have a lot of repeated data? Are the data types correct for all my dataset.

Once you are able to answer this three group of questions you will be in a better position to start your project. During this excercise you might find that you wont be able to use some of the data or asking around you might found about new data the you haven’t event thought about.