Sergio Visinoni’s Post

You either own your process or get owned. I learned to do the first. Here's how to do the same: Before learning this lesson, I had my engineering teams do the work according to requirements. A project would come in, I would set up the team, and we went to build. And more things never stopped appearing. We sold something new, a new client appeared out of the blue, something went wrong on a project, or someone needed a report. My calendar felt swamped with meeting requests. I felt trapped. Overbooked. Without control. Here's the problem. I was reactive to the needs of others because I didn't understand my place in that organization. It was my fault. Here are the key things I had to change to go from reactive to proactive. I had to: 👨🏼💼 Define my role. 🎯 Define my goals and my values. 🪢 Define a process to gather my peers' vision and help them achieve it. 📆 Schedule regular meetings with my peers and get a feedback loop going. 💼 Start talking to the CEO weekly to get inspired by his vision and report my progress. Once people had the space to be heard, the ad hoc meeting requests dropped significantly. I had a process in place, and if someone jumped past the hoop, I could confidently say: "Here's the proper way to do things." Bonus: I also learned to take in their vision, understand the motivation behind their ask, and give them a better solution according to my expert knowledge and way of doing things. But that's a whole other post. __________ 💡 I write about leadership and adopting a business mindset in tech teams. 💬 Reach out if you have a tech team who could use that. I work fractionally. #fcto #ctoinsights #softwareengineering #leadership

We’ve all heard of the “glass ceiling,” but let's be honest—it's not glass. It's paper. Thin, flimsy, and the worst part? We’re the ones holding it up. In tech, especially among us engineers, we build our own barriers, convinced we’re only as good as the last project, the last line of code, or the last technology we mastered. But what if I told you that the reason you’re not getting that dream opportunity isn’t because you’re unqualified? It’s because you’re not reaching. We get so stuck in our routines, our familiar tech stacks, our “safe” roles, that we stop pushing. We stop daring. We stop growing. Think about the last time you saw an opportunity pass you by. Did you tell yourself, “I’m not ready,” “I’m not experienced enough,” or “I’m not what they’re looking for”? Let’s be real—that’s the paper ceiling. It’s the voice inside that tells you to play it safe, to stick with what you know, to wait for the “perfect” moment. 🔥 Newsflash: the perfect moment doesn’t exist. The only moment that matters is the one where you decide to act. The key to breaking through isn’t just about more skills, more certifications, or more experience. It’s about having the guts to put yourself out there, to go after something even when you don’t have all the answers. It’s about the courage to say, “Why not me?” So, the next time you see an opportunity, stop making excuses. Stop underestimating what you bring to the table. Instead, throw yourself into it, head first. Speak up in that meeting. Apply for that job you think is out of your league. Take on that project that scares the hell out of you. The only thing standing between you and the next level is a little piece of paper. And trust me, it tears easily. 👉 Like if you’re ready to break the ceiling. Comment with your thoughts—what’s holding you back? Share this with your network if you believe in pushing beyond self-imposed limits. #Engineering #Leadership #Innovation #CareerGrowth #LeadershipDevelopment #CompanyCulture #TalentManagement

I’ve managed or being part of many teams in my software engineering experience. And every team has got problems or challenges in their own unique ways. Let it be communication issues, team that don’t deliver, team that’s micromanaged and whatnot. This is completely fine. What’s more concerning is, if they are facing same old (O) problems every time and leave it unaddressed, new (N) problems adds up. Team’s worries = O + N… At the end of the day? - Team feels overwhelmed and sinks further. Solution? 💡Acknowledging current worries and taking actions before it goes out of hand. Who’s responsible? - It’s YOU. Leads, Managers, Engineers and everyone else in the team. Talk about what’s not working in your team, what’s pulling your team’s performance down and what can everyone of you do about it. Taking actions only ensures you’re addressing old problems and ready to tackle newer ones. You’ll always have new and bigger challenges to tackle. Staring at the same old problems will not take your team anywhere further. #team #management #softwareengineering #leadership

😱 Feedback is overwhelming, but listening to what you do baddly is crucial! As a founder, seeking advice is part of the gig, especially early on. But it often leads to total paralysis. You're bombarded with conflicting opinions, leaving you stuck and doubting every move. The low point for me? The endless cycle of revising our pitch deck based on ever-changing advice. It was maddening, paralysing, and slowed us down in every way imaginable. Drowning in feedback is a rite of passage for first-time founders. We ask around because we're aware of our gaps. But remember, ask ten people for feedback, and you'll get ten different responses. Finding the right feedback involves cutting through the noise. I started asking a handful of trusted sources, comparing their insights, and focusing on the 2-3 points they all touch on. Those become the priority. Also, be selective about whom you ask. Not all feedback is created equal. (i.e. difference between a pitch deck for a VC or for Angels) And here's a final piece of advice: cut yourself some slack and follow your guts, acknowledge your weaknesses, but don't undervalue your strengths.

"Stand in their shoes, not just by your desk!" Allow me to let you in on a secret - empathy is the unsung hero of successful engineering management. Not merely a 'soft skill', empathy is a critical tool for effective leadership. As software engineers, we're wired to solve problems - often forgetting that understanding the people behind those challenges is a part of the solution. Why does your team member keep missing deadlines? Is it workload or personal issues? A quick code fix or a deeper problem? Empathy helps us read between the lines and see beyond the screen, enabling a more supportive, productive environment. Remember, your team isn't just made up of developers. They are people, with unique experiences and perspectives. Tune into these and watch your team's synergy skyrocket! If you got value from this, please follow me! I write daily about engineering management, team dynamics, and processes needed to build engaged and successful teams. #EngineeringManagement #Leadership #Empathy #TeamDynamics ----------------------------------- Check out the full article, written by Jason Bliss, at https://lnkd.in/grEXkjpy

The next hard-earned Hard Knock for today - 2. Not doing enough to foster trust and open communication in a startup environment. It's so easy to believe that you're communicating enough, or that everyone is on the same page or has the context they need. Here's what happens with this hard knock: Impact: Reduced Engineering Velocity and Missed Deadlines: Poor communication leads to bottlenecks, confusion, and duplicated effort, ultimately slowing down development speed. When engineers lack clarity on priorities, context, or ownership boundaries, it results in wasted time and missed deadlines. I think of situations where a lack of clear communication about project status or potential roadblocks led to last-minute scrambles and delayed launches. Impact: Inability to Scale the Organization: As a company grows, relying on informal communication and ad-hoc processes becomes unsustainable. A lack of structured information flow, decision-making protocols, and clearly defined roles and responsibilities hinders the organization's ability to scale effectively. This can manifest as an over-reliance on you as a leader to make decisions, creating a bottleneck that stifles growth. Impact: Poor Product Decisions and Misaligned Priorities: When communication breaks down between product and engineering, it often results in products that don't meet user needs or align with business goals. Engineers may lack the context to understand the 'why' behind product decisions, leading to frustration and suboptimal solutions. Similarly, PMs may be unaware of technical constraints or feasibility issues, resulting in unrealistic roadmaps and misaligned priorities. Impact: Erosion of Trust and Morale: Perhaps most importantly, a lack of transparency and open communication can create a toxic work environment characterized by suspicion, resentment, and low morale. When employees feel like they are not being heard or that decisions are being made arbitrarily, it breeds distrust in leadership and undermines team cohesion. This manifests as a rise in "shadow Slack" channels, passive-aggressive behaviour, and a general sense of unease within the organization. Over-communicate! Tomorrow in part 3 - let's talk about when perceived urgency faces off against importance... #LeadershipLessons #StartupAdvice #TechLeadership #HardKnocksLeadership

When you join a new org or switch teams in the same, it is quite an unsettling and borderline anxious experience. Here are a few things that I did to ramp up faster. 1. I consciously made an effort to remain unblocked 2. I read a ton of code and its history, sometimes even unrelated 3. I asked questions about the past, the present, and the future 4. I took up relatively mundane tasks - cross-team work, tests, and docs 5. I extended a helping hand in whatever capacity I could 6. I proactively met skip-level leaders and managers to understand the vision Some companies do have a culture of pairing up with someone existing in the team, but even if you do not get a mentor, it is important that you still navigate the situation and ramp up as quickly as you can. The above list is not exhaustive, by any means, and hence you can always add things that you find helpful in your context. but the lowest common denominator is to show extreme intent and interest to get output and drive outcomes. #AsliEngineering #CareerGrowth

This is great! To build on this, I think it's also important not to come in suggesting changes or questioning decisions without context. I really like the concept of keeping a WTF notebook, so you can keep a log of all the things that make you go "WTF" and then address them with the team later when you have enough context to talk about them. The "fresh eyes" perspective is super valuable, but it's worth taking some time to pair it with context. I heard about the WTF notebook here: https://lnkd.in/gg6KMYcU

Failing is not cool. Trust me I've tried. In life and in building products there is such a thing as useless pain. We talk about "a fail fast mentality" in modern Software/Product Development. But, risking stating the obvious here, that's not the goal. Toxic positivity about failure is not the way. Yet it is what I've observed in many fellow Product Managers. PM: "At least we learned something!" me: "Okay, what did you learn?" PM: "What do you mean? We always learn from failure." me: "Did you? What exactly do you know now, that you didn't know before?" It's uncomfortable. But I have that dialog with others, and myself, regularly. It's honest to say: Damn, we didn't learn a thing here. We just failed. I personally failed when just delivering a big project without Discovery years ago. For 6 months I laterally pushed the team to do their best work every day. 6 months later nobody used the features we've built. Did I learn? I knew why we do Discovery before. I guess I relearned that lesson. Great. "Failing fast" is often turned into toxic positivity around not really trying. We want to foster a "risk taking mentality ", a "trying things mentality". Not a "do stupid things fast" mentality. While it seems obvious, like so many LinkedIn posts do, I suggest you try to observe the subtle differences in mindset and what effects it has on mindset and team psychology. And in the end on team outcomes. Fail smart not hard this week 🧨 -------- I post 5x a week here in an attempt to get 1000 companies to do weekly Product Discovery. I'm at 21/1000. Which is more than four weeks ago. Follow along to see if I make it before turning 90 - and shoot me a message if you need a little help to get your Discovery rolling. Ah, and check out Juttu if you want to automate your weekly user interviews.

Sometimes, it feels like a slow corporate grind and bureaucracy, though I feel some things are worth the effort to repeat for the betterment of the product/company. Maybe it's being called pedantic, maybe it's challenging the Dev team stance 'but its consistent' approach. How Does Continuous Improvement Work? So often we convince ourselves that change is only meaningful if there is some large, visible outcome associated with it. Whether it is losing weight, building a business, traveling the world or any other goal, we often put pressure on ourselves to make some earth-shattering improvement that everyone will talk about. Meanwhile, improving by just 1 percent isn’t notable (and sometimes it isn’t even noticeable). But it can be just as meaningful, especially in the long run. (https://lnkd.in/eMz7HaN3)