Uplevel

Software development employment is projected to grow by 17-18% over the next decade. For small teams, integrating a few new members comes down to good onboarding. For large teams, growth means constantly warring against complexity and unnecessary bureaucracy. How do you keep engineering teams productive and nimble, at scale? 💡 Don’t fall for “Yes-And” syndrome 💡 A focused team will run circles around an unfocused team every time. This is true at small startups. It’s true at large multinational conglomerates. And everything in between. Focus is the ultimate sign of a strong dev team. And focus starts at the top. Beware “Yes-And” syndrome. This is when managers of large teams begin to take on more projects than they should reasonably handle. Everyone loses focus. Projects take longer to launch. They launch with less impact. 🛠️ Track what matters 🛠️ Complex engineering teams can’t track progress like scrappy startups. New scale means new tools. How your team spends their time matters. You can tell a lot about your team’s productivity by the tools they’re using. The dev who constantly jumps from meeting to meeting or Slack ping to Slack ping won’t produce as much as the engineer who spends most of their day in a code editor. That’s why Uplevel helps you see where devs spend their time. If you expect your dev team to grow, then now is the time to think about future complexity. Stomp it out in advance.

“Your day is under siege by interruptions. It’s on you to fight back.” - Jason Fried I talk a lot about leadership and setting priorities. When a dev team is unfocused, and each contributor is juggling a dozen projects, it’s a sign that leadership hasn’t done their job. Specifically, the two factors that will increase developer productivity the most is: 1️⃣ Ability to focus on coding features, AKA deep work time. 2️⃣ Very clear prioritization of which features to work on and why. Working as a dev, writer, designer, or any other creative role today requires clear priorities and time for deep work. Deep work is the meta skill of proficient white collar workers. If code is the primary skill for your job, then I would argue that maintaining your focus time should be what you have to master. Today, everything vies for your attention. Slack messages. Social media. Email. News. Doing good work means putting away those distractions to do the work that counts.

Every adult has seen a child stack their plate in a buffet line, knowing full well half the food will be uneaten. The parental joke of “your eyes are bigger than your stomach” is often applied. Somehow over time, most of us get better at only ordering what we will actually eat. But as we get better at estimating these basic human needs like eating, we often struggle with estimating our work. Most people have an innate desire to work hard, deliver value and of course impress our bosses. This can result in missed goals - we have to reduce the scope or extend the deadline. It’s basically the grown up version of boxing the extra food up for the next meal. Why is it so hard for us to learn this and set expectations at reasonable levels? We have developed countless methods of estimating work and comparing to actuals that span almost every function. Story points and t-shirt sizing for devs, plans and quotas for sales, engagement metrics for product and marketing, etc. And despite all this, we all know people who just seem naturally good at estimating their capacity, even for unknown work, and others who seem to continually struggle. Maybe it’s more of a DNA thing than a learned skill? The thing I’ve noticed is that when ambitious goals are not met, it’s typically due to the unplanned getting in the way of working on the plan. Like always, it tends to come back to focusing on the main objective, and saying no to the rest. 📜 Ruthlessly prioritize tasks. 💡 Block off time to work on these tasks 🚫 Say no to everything else Basically, only put what you can actually eat on your plate. Come back for more after you’re hungry again.

“Your day is under siege by interruptions. It’s on you to fight back.” - Jason Fried I talk a lot about leadership and setting priorities. When a dev team is unfocused, and each contributor is juggling a dozen projects, it’s a sign that leadership hasn’t done their job. Specifically, the two factors that will increase developer productivity the most is: 1️⃣ Ability to focus on coding features, aka - deep work time. 2️⃣ Very clear prioritization of which features to work on and why. Working as a dev, writer, designer, or any other creative role today requires clear priorities and time for deep work. Deep work is the meta skill of proficient white collar workers. If code is the primary skill for your job, then I would argue that maintaining your focus time should be what you have to master. Today, everything vies for your attention. Slack messages. Social media. Email. News. Doing good work means putting away those distractions to do the work that counts. #deepwork #focus #developerproductivity

The most important part of a build pipeline is generating fast feedback. You want to give engineers feedback on their code as soon as possible, before their context shifts to the next task. Here’s why: Developers can act quickly on changes while their mind is still on the project. You remember what you wrote and where you wrote it. You know why you added a particular line of code (and omitted another). Receiving feedback when the project is still a lingering memory is advantageous. The context is still in your “cache”. After enough time has passed, the “cache” for that task is cleared. You lose context. The memory fades and it takes longer to dive back into the work. It requires more time and energy to implement the same feedback. This isn’t a novel idea. Most devs know they should have fast checks in place. But knowing the best practices and implementing them are not the same. It’s very easy to have those times grow unchecked. Hmm… maybe I should go check our build times. 🤔 #engineeringmanagement #CTO

Marty Cagan distinguishes between two types of teams: the mercenaries and the missionaries. The mercenary teams are the "ticket takers". They're just doing the next thing in front of them, checking off the boxes without much deeper investment. They're content to churn out features and fix bugs, but they lack that true sense of purpose and ownership. And then there are the missionary teams. These are the ones who are deeply invested in the customer experience, driven to solve real problems and make a meaningful impact. They're the ones who challenge assumptions, dig deeper into user needs, and are constantly seeking to understand the "why" behind the "what." Now, I'm not saying that mercenaries are bad or that missionaries are the only way to go. While I believe a missionary team will deliver better results - and is a joy to be part of - I’m coming around to the fact that there's a time and a place for both. The distinction is a helpful gutcheck. Because managing a mercenary team like a missionary team just makes everyone miserable, and you’ll spin your wheels, losing productivity entirely. You can’t just flip a switch. Meet your team where they are at and give them the support they need the way they need it. At the end of the day, it's not about checking boxes or hitting deadlines. It's about creating something that truly makes a difference in people's lives. That kind of work, the kind that comes from a place of deep passion and purpose, can take many different paths to get there.

New engineers: How should you interact with your first manager? The engineer-manager relationship is an important one. If you take advantage of it, your manager can put you on the-fast track to success. Like all relationships, it requires some initiative. There are many paths you can take in the software field. The more direct and cogent you are about communicating your goals with your manager, the more help they can offer you. In my experience, this is as simple as starting the conversation. Meet deliberately with your manager to discuss where you want to go and what you aspire to achieve in your engineering career. It's rare to meet a manager who isn't excited to accelerate the career of an ambitious engineer with a clear sense of direction. But we don’t know your ambitions until you tell us. #CTO #engineeringmanagement #softwareengineering

“Plans are worthless, but planning is everything.” I love this quote. Even the best-intentioned plans often have to change when the work starts. Without dedicated time for planning and strategic thinking, developers are left to reactively code their way through unclear requirements and shifting priorities. Lack of communication and shared understanding leads to rework, technical debt, and frustrated teams. Sometimes there are very clear signs of poor planning — some of my favorites: 📅 Lots of meetings with design and product management, even after the design work and tickets were supposed to be complete. 🖥️ A very high abundance of comments on Jira tickets and PRs due to lack of clarity - one of our devs calls these “drama” work. ⏳ Waiting for dependencies - “we need to call an API but the API isn’t done.” What other examples do you see? Measuring planning time is more critical than measuring development time. Yet somehow — because it’s hard to measure planning time — we don’t. We rest on our laurels. We stick to measuring the “real” work (code, tickets, …) but not the planning and design meetings. Measure what matters. That means don’t skimp on the planning. #CTO #planning #softwaredevelopment