Uplevel

“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

How often do you get away from your desk to think? I call this “walk the dog” time. Here’s the problem: 🖥️ Spending time behind a computer doesn’t mean you are productive. 🔒 Staring at a problem for an hour doesn’t mean you’re making progress. Sometimes the best way to write the article, solve the bug, or make the decision is to step away. Stepping away from the computer—whether for a meeting, a walk, or just quiet reflection—sparks the clarity of thought that leads to better code. Think through the problem. See the big picture. Make forward progress by stepping back. Take a walk.