ray-garcia

Latest posts from Ray García y sus cosas de cada día

• The Pains of Being Pure at Heart

  Nov 18 ⎯ I'm not going to lie: the topic came before the title. My extreme creativity led me to connect it with the name of a band I've been listening to lately, leveraging the incredibly complex relationship of... using the same word. Now I have to build a narrative that fits and pretend it was all planned from the beginning. I know, I'm a fraud. But these days, what isn't on the internet? At least I write my own articles. The Pains of Being Pure at Heart is a New York band formed in 2007, with a very authentic lo-fi sound. They self-released their first EP, self-titled, uploading their songs to MySpace. In fact, at their first show they played five songs in ten minutes using a backing track as drums. It was lo-fi, imperfect, scrappy. The thing is, it worked. They soon got picked up by Pitchfork, were named "Band to Watch" in 2007, and their career took off. This is where you discover the sad relationship between the narrative and what I actually want to talk about. Validation as a Proxy The main goal of validation is to reduce uncertainty. It's making sure what you're going to build has the fewest possible cracks because the cost of validating is much lower than the cost of building. Therefore, validate first, build later. Although in reality, "validate" is a confusing term. Validate what exactly? That the problem exists? That your solution solves it? That people will pay? Each discipline interprets it differently: the designer validates with prototypes, the engineer with technical tests, the PM with usage metrics. But they all share one assumption: validating is cheaper than building. There are exceptional cases that took validation to the extreme, like Fireflies.ai, now valued at one billion dollars, which started selling "AI notetaking" services for $100 a month. But they had neither AI nor product. It was the two founders manually joining video calls, camera off, pen in hand. They took notes, typed them into Word, and sent them ten minutes later. Was it extreme? Yes. Ethically questionable? Also yes. But it was effective. Because they needed to validate that the problem was real before building complex technology. Validating today is a whole different ballgame. The cost of building a functional MVP has plummeted. You no longer need weeks of interviews before writing code, because building something tangible takes days. Moreover, the act of building the product forces you to confront the flows, the end-to-end, and the technical capabilities and limitations much more consciously. Why not validate with the product in hand? Conversations are more honest, questions more specific, and you can iterate very quickly. Let's Talk About Generalism A generalist is someone who knows a little about many different areas. Enough to connect the dots but perhaps not enough to dive into the depth of the concrete with agility. A generalist is not good at vertical (that's why they're a generalist, not a specialist), but excellent at horizontal. They know a bit of frontend, backend, design, business, marketing... In the current scenario, an LLM can perfectly cover the gaps. Want to design something? Lean on Lovable or Firebase Studio. Define the frontend? Force Claude Code to use Shadcn with Atomic Design. Maybe a simple backend? Supabase might be the right option. The generalist knows the tools, understands how things should be built, and could dive into the details if needed. Well-directed, an LLM can handle it. A generalist understands what's a hack job and what's overengineering. They understand the tradeoff and accept it consciously. And in that sweet spot, I believe, lies the virtue. Nothing will be pure, but it won't be dirty either. It sits in the right place where something can serve as a "beginning." Let's not kid ourselves, the tradeoff exists, but it's a tradeoff worth accepting when you're validating an idea. Purity comes later. Purity is the Destination The goal is to find the treasure. El Dorado. The ideal route should have two lanes, preferably paved, and avoid being winding so our trucks can go to the village to load up the treasure. But this required months of planning: Maps, satellite photos, exploration teams, local guides, hostile indigenous people. It's... too much. In this new scenario, your cousin has a helicopter and can drop you off at the edge of the jungle, walk a hundred meters, and pick you up for free, because he just paid off the last installment of the loan and is on vacation. Plus, it turns out he's close friends with the indigenous leader. Maps are still useful, but the information you get from being on the ground is invaluable. When stepping on the terrain costs the same and is just as safe as studying it, why not do it? The Pains of Being Pure at Heart There is pain in pursuing purity before validating you're on the right path. The band understood this: they uploaded songs to MySpace, played with backing tracks, self-released their first EP. It wasn't pure, but it was real. And it worked. Purity came later, with renowned producers and professional studios. But first they made sure they had something worth polishing. The Practical Example This reflection comes from my own experience. My reality has changed. A few weeks ago I left my position as Engineering Director at Factorial. And now I find myself in a new place, unfamiliar to me. I need to find my next big challenge. But searching isn't easy and I found myself with an existential question: Is my resume good enough for this job I'm applying to? So I got to work. I pulled out my generalist soul and tried to create a product that would solve my problem. Is it ideal? I don't know. I think it solves my case, and probably others'. And what's the best way to validate it? I built it. It's here: https://evalua.cion.es Shall we validate it?

  

• Farewell, Factorial

  Nov 04 ⎯ After more than three and a half years, today I'm saying goodbye to Factorial. I don't intend to make a drama out of this. I won't be the first or the last to leave a company. But given that this is my blog and I'm the one writing, allow me to add all the epic flair my heart desires so this entry serves as a keepsake for my future self. The reasons are quite simple. Factorial's remote policy prevented me from continuing as Engineering Director. I was offered a very interesting alternative (for which I'm tremendously grateful) that moved away from what I love most. I love creating, I love being in the details, I love inventing. I love the blank page. I love knowing I'm capable of solving a problem I have no clue about. All of that, in one way or another, would be lost in this new scenario. Therefore, I decided it was time to leave and face the vast ocean. I'm taking a lot from Factorial. But like any relationship, I believe there's a certain reciprocity. I'm also leaving something of myself there. Let this entry serve, then, to take stock of it all. What I'm taking with me I joined Factorial in May 2022. I came from being co-founder of a startup (TeamEQ). Things weren't going badly, but they weren't exactly booming either, and after almost 7 years of grinding, my body was asking for a change. It was by chance that when I started having internal debates about what to do with my life, a good friend I met in Barcelona's startup ecosystem (quite a feat considering I'm from Murcia) reached out. Oriol Blanc sent me a Twitter DM that I still keep. You can imagine the conclusion. A first call with him, a pretty intense technical challenge, and an offer letter. The beginnings My beginnings were humble. Extremely humble. The density of talent around me made me feel tiny. Engineering at Factorial (at that time under Pau's leadership, who happens to be the creator of this very tool I'm using to write this entry) had achieved something I had never seen in my life. It wasn't about one or two extremely good people. There were many. And best of all: an atmosphere of humility and camaraderie prevailed that, despite feeling small, made me feel a warmth I had never experienced before. Imagine. I was clear that I wanted to measure up. So I took on the challenge with ambition and a lot of hunger, and I grew. The growth I started my journey on the Documents team. A product widely used by Factorial's customers. There, together with my team, we did some really cool things that took the product to the next level. I won't stop to detail the features we developed, I'll just say that thanks to the work we did, I had the opportunity to grow. In May 2023, the company told me they wanted to promote me and make me Engineering Director. Imagine everything that went through my head. Going from one team to managing several? Do I even know what being a director is? Will I be capable? Will they finally discover the fraud I am? Impostor syndrome knocked on the door, walked into the living room, served itself coffee, and put its feet up on the coffee table. The challenge Factorial is not an easy place. Growing at the pace it does is within reach of very few. And it's not by chance. It's intentional. Factorial is intense. Very intense. The pace is high, the volume of work is high, the level of demand is high. And I don't think any of that is bad. Quite the opposite. So I took those constraints and embraced them. Made them mine. I understood the challenge ahead and transformed it without losing my essence. There are many ways to translate intensity and pace to an organization's teams. I chose an approach where humanity, trust, humor, and Radical Candor were the cornerstones. To achieve the challenge placed on my shoulders, I understood that the first thing I needed to accomplish was for everyone to believe in it. Fostering a sense of belonging as a catalyst for everything else. If everyone feels their products are "theirs," the rest would be easier. So I rolled up my sleeves and got to work. Friends and affection 8 hours a day, 5 days a week, for over 3 and a half years goes a long way. Enough to do things, but also to get to know people. To meet incredible, skilled, intelligent, funny people... I'm not taking away "work colleagues." I'm taking away real friends. Friends with whom I've shared much more than work projects. Friends you regret not having met sooner. Those with whom you connect deeply. In ways of thinking, in hobbies, in coherence and integrity. There are many, but they know perfectly well who they are. And I’m taking them all with me. What I left there During this journey, I experienced Factorial from many angles. Engineering Manager, then Director. Core's technical depths, then Talent's creative scope. Different challenges, different hats, same commitment. If I had to summarize my legacy, it would be in three areas: Talent density At Factorial, I helped build strong, cohesive, committed teams where there was always room for humor and laughter. To achieve this, I hired a lot of people. I can say without fear of being wrong that in my two and a half years as director, I conducted over 200 interviews. I can also say with pride that I was part of the hiring process for the current 10-15% of engineering at Factorial. I don't intend for arrogance to invade this post. It's simply a fact I'm tremendously proud of and therefore has a place here. But I also fired people. Firing people sucks. I don't think there's anyone (maybe some psychopath) who enjoys firing people. It cost me sleepless nights, extreme worries, and constant doubts. I can also say that the decisions I made were the right ones and that the people who left, despite having caused difficult personal situations, needed to leave to maintain the initial challenge the company asked of me. I also helped people grow. I drew scenarios where I took people beyond their boundaries and encouraged them to cross them without fear. From these challenges, projects were born that are key to some strategies today and that allowed those who took them on to grow, get better positions, better salaries, and more strength for what was to come. I want to believe that my drive helped increase talent density. Processes In a hyper-growth environment like Factorial's, it's sometimes difficult to keep culture and processes fixed, without them becoming perverted. I don't know how it is in other companies, but in Factorial's case, speed took its toll. From my newly minted position as director, back in 2023, I contributed my small grain of sand to reestablish them. I worked hand in hand with Ilya (CTO) to define a coherent and well-reasoned promotion system, defining a process that required clarity and synthesis to demonstrate the impact of the person whose manager recommended promotion. I also helped establish a new hiring process. In it, apart from collaborating on defining the different steps, I documented my approach to manager interviews, capturing the philosophy and tactics that worked. If you want to see it, it's available here. Together with Miquel (Senior Engineering Director and one of those friendships I'm taking with me forever) I helped define the new career path. I won't lie, the bulk of the work was on his shoulders (and it was a huge job), I helped shape the narrative, the definition of different roles, growth expectations, rubrics. All of that is public, you can see it here. Results Results are nothing more than the accumulation of everything else. When things are in their place, facts are reflected in numbers. Two and a half years later, I can say with pride that through the Talent domain I led together with Alba first, and Marta later: We significantly increased eNPS We increased retention We contributed a substantial increase to ARR We never stopped innovating There's no word that describes the feeling when you see things, step by step, falling into place, when you see your strategy taking shape and crystallizing, when you see your plan working. So, what? For all this, and more, I can only say THANK YOU to Factorial. To Bernat, Jordi, and Ilya mainly, for trusting me. For believing in me. For allowing me to contradict them when necessary and letting me fight for what I thought was right. I also thank each and every one of my colleagues, who after so many adventures gave me one of the most beautiful goodbyes anyone could wish for. I left overwhelmed, full of affection and kind words. What’s next? You may ask. The truth is I have no idea. I'm open to exploring new opportunities, but in the meantime, I want to pick up certain routines I had abandoned. Writing is the first of them. The third part of The Only Truth trilogy won't write itself, and although everything is already finished in my head, I need to put it on paper. I also want to recover the cion.es project. I have some ideas to execute on some subdomains like vaca.cion.es, so I'll get to it. My time as director had distanced me a bit from code, which I was forced to recover on my weekends and holidays. Now I can be full-time during this interlude. I'm leaving, but not without remembering something that's important to me. That has been key in my development and in my way of seeing life both personally and professionally. Something I want to endure, and if you've made it this far, to be etched in your brain. ALWAYS BET ON PEOPLE.

  

• The Manager Interview

  Nov 04 ⎯ During my time at Factorial, we tried to centralize and normalize our engineering hiring process. We created a Slack channel (#engineering-bar-raisers) where the name said it all. The challenge was getting as many people as possible to share the same concepts: how to hire and evaluate candidates, why someone is good and others aren't... In the end, it was about having the same message, the same expectations, and the same ways of evaluating. And it worked. But the reality is that the process had tradeoffs we needed to improve. Hiring is one of the most powerful tools in terms of culture. It's the place where you share the company vision, the way of working, the way of doing things. Where you make candidates fall in love, but also where you get feedback from others, different ways of working, etc. The complete process is more complex, but I'm going to focus on the manager interview - the gateway to everything else. The Manager Interview It's easy to think about this process with the mindset of "We are hiring someone." This makes us start our interviews from a position of strength. I honestly think this approach isn't ideal. We're hiring someone, but at the same time, they're hiring us as well. I saw great candidates say no because they had a different offer. We need to win this battle from the beginning. What should happen in an interview? Here are some points I found valid during the first interviews: Being humble Being clear about expectations. During the first interviews, I usually wanted to answer two things: How deep is their knowledge? Technically, but also from a management perspective (if applicable) Do I want to work with them? I also tried to make them answer with a strong yes to the second question, regardless of the result: "Wow, working here would be cool." Paint the company and product space with detail People don't know anything about you. They're usually intrigued, but cautious about questions. This can be deactivated if we work on the first point. If we talk about "conversation" instead of "interview," and we create the right climate, questions will arise, and conversations will occur organically, which is great because you can gather more info and be more confident about your intuition if people show up as they are. But you know what's even better? Answering their questions without them asking. Talk about the company. Mission, vision, size... Talk about Product. How many are we? How are we distributed (Domains)? How are teams defined? What's their way of working? Talk about Challenges. Quarter by quarter. Ownership. Deliveries... Talk about the engineering process. Continuous delivery, Release trains, challenges we're facing, stack. This is usually the easiest part. We know it deeply. Talk about role expectations. Usually, the concept of Product Engineer worked well at Factorial. We were far away from the 'tickets engineer' profile. It was a great space to talk about craft, about caring for the whole... Then, pass the mic. We need to check if our expectations will be covered. What do we expect from a candidate? We only have 1 hour for the manager interview, and you've already consumed 10 minutes. Knowing that we want to have space for them to ask questions, we only have 30-35 minutes for this. Is it enough? Well, it depends on how we manage it. Giving them the mic means they deliver what's in their head. This can be okay (or not!), but it's important to kindly warn them that we're going to stop them constantly because we want to dig into some of the topics they're telling us. Because if not, we won't have the answers we need. There's no script here, but some situations usually appear. We can categorize these situations into one of the following areas. Soft Skills Imagine you know someone who has been working with the candidate in the past. The best indicator will be a strong yes to the question: "Do you genuinely want to work with them again?" However, this situation doesn't happen often, so we're the ones who need to answer this question. Think about teams you've been part of. The ones that worked amazingly well. What made them special? Usually, it comes down to the people. That's exactly what we're looking for here. So you need to be paying attention during the entire conversation. This isn't the kind of thing you need to ask directly. Some of them appear organically in the conversation. You can get this information by reading between the lines of what the candidate is telling you. Some key points are: Shows authenticity. You can feel it when someone is being genuine during the conversation. Are they sharing real experiences or just buzzwords? Do they talk about failures with honesty? Great candidates make you feel like you're having coffee with a colleague. Listens actively. It's not just about waiting for their turn to speak. Do they build upon your comments? Do they ask thoughtful follow-up questions? This shows how they'll interact with the team daily. Brings positive energy. Not in a fake way, but in how they approach challenges. When they talk about hard situations, do they focus on solutions? Do they show enthusiasm when discussing potential improvements? The goal here isn't to tick boxes. It's about imagining this person on your team tomorrow. Would they make the team better? Would others enjoy working with them? Would you? Remember: your gut feeling matters. If something feels off, dig deeper. The best candidates might not have perfect answers, but they'll make you excited about working together. Hard Skills Don't forget. We're interviewing technical people. They usually go through their experience in a very superficial way, mentioning some technologies, migrations, or similar stuff. Here, we need to stop: "Wow, that migration sounds hard. What was the main challenge? How did you make the change? Was there a moment when both technologies lived together? How did you achieve that?" "Why did you choose NextJS? I understand the reasoning behind this, but how does this scale? How many concurrent users do you have? With this amount, have you thought about an alternative? If so, which one? And why did you finally go through this path? Is there something you would change now that this is already done?" The main challenge here isn't to understand if they know about something specific but, more importantly, to understand how they think. Do they have great reasoning behind their decisions? One thing I tested in my last interviews (and it worked quite well) was asking them to share their screen and show us some code. It helps a lot and gives you a clear picture away from theory and buzzwords, helping you dig a bit better into how they work. Management Skills (only for EMs) An Engineering Manager is a profile that can differ depending on where you ask. Some companies only need 'People Managers,' others need fully hands-on managers (more of a Tech Lead profile). In my experience at Factorial, the profile that suited us best was one with a great mix of assets: great on the technical side but equally great on the people side. Even if we wanted to, I didn't see an Engineering Manager doing full features. I saw them working closely with their team, going deep, helping to make decisions, challenging them, evaluating progress, solving bugs, fixing tiny things, pushing the last mile... ensuring in the end that things happened in a timely manner and covered business needs properly. So, for sure, we needed to measure the technical side. That's the Engineering part of the title, but what does 'Manager' mean in this context? A good manager: Coaches individuals on career growth and skill development Gives clear and actionable feedback Creates learning opportunities through project allocation Translates complex technical concepts for different audiences Sets clear expectations and goals Maintains transparency about decisions and changes Practices active listening and empathy in 1:1s Excels in prioritization and resource allocation Anticipates risks and mitigates them as soon as possible Makes data-driven decisions Builds trust through consistent actions And many more. So we needed to get as much as we could from these topics. Spoiler: With the time we had, you can't. So, you need to build a set of three or four questions that cover as much as possible. Some examples would be: "Tell me about a time you helped a team member grow into a more senior role. What was your approach?" "Describe a situation where you had to deliver difficult feedback. How did you handle it?" "Describe your approach to 1:1s. What makes them effective?" "How do you prioritize competing projects with limited resources?" "Share an example where you identified and mitigated a significant project risk." "What metrics do you track to measure team health and performance?" "You notice declining code quality but increasing velocity. How do you address this?" The most important thing is to train your intuition. Sometimes, "checks" aren't enough. You should be thrilled to work with this person because if you are, engineers will fall in love with them. Bringing It All Together The manager interview isn't just a filter, it's our opportunity to set the tone for the entire hiring process. It's where we establish mutual respect, showcase our culture, and make that crucial first assessment. Remember these key points: Approach the interview as a two-way conversation, not an interrogation Be transparent about who you are and what you expect Look beyond technical skills to find authenticity and cultural alignment Trust your instincts:u the best candidates make you excited about working together Getting this phase right pays dividends throughout the entire hiring process. It helps ensure we're bringing in not just skilled professionals, but people who will thrive in our environment and help us build something exceptional together. The technical evaluation comes next, but without this solid foundation, we risk missing out on the human elements that truly make teams great.

  

• Resistance Creates Beauty

  Oct 21 ⎯ If there's something I'm especially proud of, apart from being a father and the incredible title of this post (What a title, eh?), it's writing a book (well, two, because you can never brag too much). It was precisely there where I learned, in a totally unexpected way, this lesson that has stuck with me ever since like acne on a teenager. Let me give you some context first. I came here to talk about my book! The Only Truth is a story told in first person by Martina, a young woman who soon discovers she's trapped in a time loop. No matter what she does, at the end of the day everything resets to its original state. In short, nothing remains. This is the framework. These are the self-imposed limits. In a reality where nothing endures, how can I make things remain? These boundaries forced me to be creative. Martina soon discovers she's not alone. Within this reality, this loop where no one seems conscious, there are others like her. People who remember between repetitions. Who aren't "reset." I called them, in another burst of originality, the awakened (see how creative I am?) These awakened have managed to dodge the strict laws that the cyclical passage of time imposes on them within the loop. They've organized themselves in such a way that they're able to, at least, minimize this enormous problem. That's where the figure of the "retainer" is born (once again being incredible at naming things... I don't do it on purpose, I swear, it just comes naturally) whose only job is to memorize. Where only memory endures, memory becomes the most powerful tool. This way, these awakened built their own "database"; a group of people destined to memorize events, situations and important information, and respond to pertinent questions for the development of our protagonists. If you want to know more, La Única Verdad[ES][EN] and its second part, La única realidad are for sale on Amazon. Limitation as Catalyst See where I'm going? The limitation forced me to be creative. I discovered this through the process (I had to live it firsthand), but it's been with us forever. Let me give you some examples. The Evocative Power of Haiku A haiku is a Japanese poetic form of 17 syllables distributed in three verses (5-7-5) that expresses an image or moment with extreme brevity and precision. Think about it. 17 syllables to convey the essence of a moment, an emotion, or a universal truth. The magic lies in the violence of the restriction: You can't express anything, only suggest There's no space for filler, each syllable is life or death You must hope the reader completes the powerful image you're trying to paint In 17 syllables, Bashō captured silence, solitude, nature, the vital cycle... none of this would be (or work so well) without the brutality of the restriction. Koji Kondo and 8-bit Music In the 8-bit era, musical compositions were limited by the processing capabilities of the first video game consoles: simple sound waves and few simultaneous channels. You probably don't recognize the name Koji Kondo, however, I'm absolutely convinced you know his creations. He's the composer of works as recognized as Super Mario Bros and The Legend of Zelda. Like any composer, Kondo would have wanted to use complete orchestras, dozens of instruments and sophisticated effects. But 8-bit consoles only allowed him three simultaneous sound channels and a few basic waves: square, triangular, and noise. Kondo embraced the limitation. Technical poverty forced melodic richness, and today, his works endure. The Elegance of the Cage You won't see me trying to turn this into a motivational act. It's simply a formula that works for me and that I (generously) share with you. In return I only ask that you buy my books. What less could I ask, right? RIGHT?? The next time you face a project and feel you lack resources, time or tools, smile. You've just found your best creative ally. Embrace those restrictions. Don't try to hide them or dodge them, build around them. Make them the pillar of your creation. It's not about running freely through infinite meadows, but about dancing elegantly inside the cage.

  
  • creativity
  • product
  • +1

• Run & Relax

  Sep 16 ⎯ My grandmother (wiser than seven management books put together) used to say: "el que mucho aprieta, poco abarca." She had cleverly flipped the traditional Spanish saying, and would explain it to seven or eight-year-old me: "child, running faster won't get you there sooner." It's curious how this stuck with me, and when I came across this story I'm about to tell you, the dots connected and I suddenly saw her again, like Ego in Ratatouille. The Story behind Usain Bolt I promise that bringing Usain Bolt here has a reason, you'll see. Glen Mills already had an established career when Usain Bolt approached him back in 2004. The coach immediately recognized the massive potential of the young prospect. However, he also identified a significant problem: Bolt's sprint mechanics were deficient. The athlete was trying too hard, tensing his muscles and maintaining a rigid position that, paradoxically, slowed him down. Mills' solution wasn't more training or greater effort. It was surprisingly simple: relax. Well, let's be realistic, I'm probably swinging wildly here and it turns out there are a thousand other things apart from the sprinter's own ambition, but it's my narrative, let me take it where I want. There's Science Behind the Paradox When we tense up, we lose range of motion. Tension interrupts fluid movement in athletes, reducing flexibility and natural flow. This same relationship exists between the cognitive tasks we perform daily. Stress deteriorates our decision-making and limits our creativity. The strange conclusion is that sometimes, less effort can lead to better results. Do you see how well everything is connected 😎? The Early Celebration In the famous photograph of the 100-meter world record (9.69 seconds), Bolt began celebrating after 70 meters. While his competitors were visibly straining, he was running relaxed. Despite the early celebration, his time from 70 to 90 meters was practically identical to his later fastest races. The 90% Rule and "Good Enough" Engineers aren't the only ones who tend to fall into the perfectionism trap, however, I do believe that statistically speaking we might be in the upper range of this "never enough" spiral. And while attention to detail is important, perfectionism can lead to diminishing returns and missed deadlines, therefore, to creative environments that aren't very relaxed. I'm not telling you anything you don't know; the Pareto Principle exists for a reason. "Good enough" requires critical thinking about the product we're building. It doesn't mean settling for something mediocre, but creating something we're proud of but that's sufficient to deliver value. It's key to identify and focus on these high-impact elements, as they can produce better results and will allow us to face the challenge with the right tension so as not to ignore our creativity. Historical Examples of "Good Enough" The Sony Walkman didn't have perfect sound quality, but it was portable: the first time we had truly mobile music. Amazon's first website was basic, but it allowed the company to start selling books online quickly. The first iPhone lacked features we consider basic today: it didn't have copy and paste, or 3G connection. However, it was good enough to change the entire smartphone industry. Dropbox started as a simple file synchronization service, but it was good enough to validate their idea and grow rapidly. Recognizing Good Enough I could expand this article talking about Idea Generation, Analogical thinking, Problem Solving, Project Management, and how everything I've discussed applies to engineering, but that would be falling into the very trap I'm talking about. I learned long ago when something is good enough. My grandma taught me that.

  
  • effort
  • relax
  • +3

• The Gas Meter Check

  Sep 14 ⎯ As I approach retirement (which I look at with greedy eyes, I only have 22 years left), I'm going to get a bit grandfatherly to tell you a story. One you haven't asked for, but which makes it clear that the writer here is a rebel who doesn't listen to reason. So much so that it's probably not even true. I only saw a thread on Twitter and adapted the story to tell what I wanted to tell. Therefore, disclaimer, it may be that nothing I tell below is true. I don't think you care either. Once upon a time (hehe, I wanted to start like that) there was a neighborhood on the outskirts of Amsterdam. One of those where all the houses are identical, and from a bird's eye view form grid patterns, where everything seems to be measured to the millimeter by an obsessive architect who cares more about symmetry than good living. During the energy crisis of the seventies, certain researchers (don't look for rigor in this story, I'm warning you) discovered something fascinating about energy consumption patterns. In that idyllic neighborhood, some homes consumed a third less energy than others, despite having the same structure, size, and layout. The only difference was the location of their gas meters. an old gas meterHouses with meters in the basement consumed 30% more energy than those with meters in the hallway. The reason was simple but profound: visibility generates awareness, and awareness drives action. Residents who could see their consumption patterns daily naturally became more conscious of their energy use, while those whose meters were hidden in basements remained oblivious to their consumption habits. The Awareness Problem Having access to information is not the same as being aware of it. In most organizations, information exists somewhere, usually buried in what we could call "free documentation dumps" like Notion, or scattered across various dashboards and systems. However, accessibility doesn't guarantee visibility, and without visibility, there can be no meaningful action. For effective cross-functional collaboration and communication, information must be more than findable; it must be inevitable. Just as Amsterdam residents needed their gas consumption data in their hallway, teams need critical information directly in their line of sight, integrated into their daily workflow rather than requiring active searching. The Gas Meter Check Framework This analogy (which I don't own but I take advantage of) of the gas meter helps provide a framework for evaluating information exchange within organizations. I've taken the liberty of calling it The Gas Meter Check, and it consists of three essential components: 1. The Hallway: Visibility and Accessibility Key information must be positioned where people naturally encounter it during their regular activities. Information that requires deliberate searching or intentional navigation doesn't pass this test. Like the gas meter in the hallway, critical data should be impossible to ignore, whether you "come home" after exercising or with your hands full of bags from your trusted supermarket. Like Thanos, this information must be inevitable. 2. The Dial: Clarity and Relevance The most effective gas meters don't show pressure readings, temperature data, or technical specifications that might be relevant to maintenance engineers. They show one thing very clearly: consumption rate. Similarly, shared information should focus on what matters most to the audience, eliminating technical details that may be internally relevant but externally confusing. Less is more when it comes to actionable intelligence. 3. The Neighborhood: Active Communication and Shared Learning Individual awareness only provides partial value. True power emerges when knowledge becomes collective. If a neighbor discovers that opening blinds during sunny hours and closing windows at sunset reduces energy consumption, this knowledge should flow throughout the community, preferably avoiding waiting for one of those desired neighborhood meetings. Organizations need mechanisms to share discoveries, best practices, and insights across teams. Practical Implementation Rather than trying to solve organizational communication comprehensively, this framework suggests starting small. Most teams (especially if we're talking about development teams like the ones I help manage) already use metrics and monitoring systems, but these serve internal purposes with little consideration for broader organizational understanding. The first step involves creating "hallway" versions of existing dashboards. Essentially, simplified views that communicate key metrics in language and formats accessible to anyone in the organization. This isn't about replacing, this is more about simplifying to complement: landing views, simplified and designed to increase awareness between teams. When teams create understandable metric hallways, domains (or whatever you call a group of teams in your house) can aggregate these into higher-level views that help the next organizational level understand broader patterns. This creates a reverse cascade effect where information flows upward through organizational levels while remaining accessible and actionable at each stage. Building Organizational Gas Meters This analogy aims to demonstrate that small changes in information presentation can drive significant behavioral improvements. By applying the gas meter check to your company's communication (ensuring information is visible, clear, and shared) teams can achieve better collaboration without requiring massive systemic changes. The framework begins with a simple question: Does this information pass the gas meter check? If people need to actively search for it, if it's saturated with irrelevant details, or if discoveries aren't being shared across teams, then there's room for improvement. This anecdote first appeared in Donella Meadows' 1992 column "Let's Have a Little More Feedback" and later became famous through her posthumous book "Thinking in Systems" (2008). Meadows was a Harvard-trained biophysicist, MIT researcher, and lead author of "The Limits to Growth," one of the most influential environmental books ever written. She died in 2001 while working on the systems thinking primer that would cement her legacy as a pioneer in understanding how small changes in information flow can create profound behavioral shifts.

  
  • business
  • data
  • +1