Uplevel

How do you feel about “vibe coding?” Andrej Karpathy tweeted last month, “There's a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” The programming community didn’t take to the new term well. In my experience, engineers are always a bit skeptical of new tech. We know how the sausage is made. We know the create-debug-create-debug cycle of making anything. So when a cofounder of OpenAI claims that anyone can code using just… well… vibes, you know there’s bound to be skepticism. And probably some anger and pushback. I vibe code. I think it’s semi-useful for the right projects. But that’s the problem: I know when it’s useful and when it’s a waste of time because I know what the code is supposed to do and look like on the other side. So, vibe coding won’t replace the need for engineers or the need to understand the tech of engineering. To code anything of quality beyond an MVP, only engineers can get what they need from vibe coding in the first place.

Many engineering leaders set goals to improve developer productivity by, say, 10%. That’s great—except that the number is almost always arbitrary, and they haven’t defined how to measure it. It’s basically a made up number and then they ask their teams to create a way to measure and show the improvement. I’ve seen this at companies with teams of 100 to 10,000. Setting a goal without defining what it actually means. Most of their teams come back with some combination of factors like: ??? 10% less bugs? ?? 10% more time coding ??? 10% more releases? ??10% higher engagement scores? (The list can go long here.) None of these are wrong… but they also aren’t right. The core challenge is like measuring the productivity of an artist. Even the best methods are messy and subjective at best. There are hundreds of online forums and experts discussing how to measure productivity, and we do the same at Uplevel. But what I find interesting here is that leaders are setting the goals before the measurement is in place. Why do they think it’s bad enough to set a goal for improvement if they can’t measure it in the first place? What if the team came back with data and showed everyone was operating at maximum effectiveness — would the goal be dropped? It’s as if the goal is getting set on intuition, feeling or some other non data-backed pressure. It could still be the right thing to do, but I find the method in which it’s happening a real sign of the growing pressures on engineering teams.

A Tale of Two Kitchens (Engineer Edition): The Cheesecake Factory and In-N-Out Burger are both successful restaurant brands. But they operate on entirely different menu philosophies. The Cheesecake Factory boasts over 250 offerings. In-N-Out Burger? Only 6. (Which kitchen do you think is more efficient?) One of the most important jobs of any engineering manager is to select the optimal workload for your team. Does each engineer juggle 3 projects at once, or 13? I’ve seen both approaches applied to various organizations. And nearly 10 times out of 10, the more focused team comes out on top regardless of the size of the organization. What might work on menus doesn’t work for minds.

Should companies return to the office or stay remote? Maybe we’re asking the wrong question. McKinsey’s latest research shows that employees—whether remote, hybrid, or in-office—are struggling with the same five problems: ? Poor collaboration ? Weak connections ? Stifled innovation ? Limited mentorship ? Lack of skill development And yet, business leaders keep pushing return-to-office (RTO) mandates as if the location of work is the problem. It’s not. The real question isn’t where people work. It’s how they work. Here’s what we’ve noticed at Uplevel: The best companies aren’t focused on attendance—they’re focused on making work work. That means clear prioritization, removing distractions, optimizing deep work, and giving teams the right data to actually improve. If RTO isn’t fixing your team’s biggest challenges, maybe it’s time to rethink the solution. https://lnkd.in/gGcdBC79

At Uplevel, we've been closely watching the evolution of AI tools in software development. What’s struck me most is how these tools have shifted from being "search engines for developers" to "sous chefs" that handle mundane tasks like refactoring code or updating dependencies. Right now, we’re deciding how best to implement these tools internally. Adoption isn't as simple as handing out licenses. Among developers, there seem to be three groups: ?? Newcomers who embrace it as a learning tool. ???? Experienced engineers who resist it, preferring their own methods. ? Veterans who selectively use it to accelerate their workflow. Our team is mostly in that middle category: highly skilled but skeptical. As leaders, how do we encourage experimentation and bridge that gap between initial resistance and productive use? For us, it's about structured rollouts, respecting intellectual property, and creating space for curiosity. 2025 will be our year of experimentation. We want to see who thrives with these tools and who might need more support. How is your team navigating the growing list of AI tools?

Big news at Uplevel! Since day one, we’ve been on a mission to help engineering teams be a highly efficient, innovative, and reliable driver of business growth. Uplevel highlights areas for improvement in your engineering org, providing visibility and insight where it’s hard to find the signal in the noise. But the full picture requires full context — and making real change depends on more than metrics alone. That’s why we’re excited to announce a new chapter for Uplevel. Starting today, we’re expanding our platform to encompass both the technological and the human elements of engineering transformation. With the Uplevel Method, we’re adding hands-on support to help you lead change efforts and make them last: ?? In-depth, 360° assessments of processes and team dynamics based on Uplevel’s platform data, developer surveys, and stakeholder interviews ?? Recommendations and implementation plans based on our proprietary WAVE framework for engineering effectiveness ??? Change enablement support to align stakeholders and engineers, use Uplevel data to find opportunities and track progress, and gain buy-in for organizational improvement across the organization With Uplevel, you access both the data and the guidance to act on it. From streamlining processes to eliminating blockers and scaling sustainably, the Uplevel Method helps engineering leaders turn insights into action — and now, action into results.