“The 25 Micro-Habits of High-Impact Managers” is a wonderful article highlighting wisdom from various managers across various industries. The article also reinforces an important universal idea—the details always matter. I subscribe to this idea and believe it can be easily re-applied to individual contribution.
At any given company, the criteria for promotion can be bland and frustratingly opaque—consistently deliver value turns into create impact for your team, which quickly evolves into create impact for multiple teams, and somehow leads to create impact for the entire company and drive its future. These large expectations are difficult to break down. It’s easier to start with the details (“micro-habits” if you will) and see where that takes you.
Before continuing, I highly recommend reading, “On Being A Senior Engineer“, which provides a holistic set of expectations on what it means to be “senior.” With these expectations in mind, the following is an opinionated list of micro-habits exhibited by high-impact software engineers. I’ve broken them down into 4 themes, each with 5 habits.
- Leadership & Culture
- Execution
- Scope & Complexity
- Communication
20 Micro-Habits Of High-Impact Software Engineers
Leadership & Culture
#1 — Incident Root Cause Analysis
You proactively dive into incident root cause analysis. You value software quality, measure problems in terms of customer impact, and make long-term improvements to engineering operations. Incident root cause analysis is often valued above incident response itself. It is also a clear sign of technical leadership.
#2 — Steps Up For Project Duty
You proactively step up for project management duties. Not all companies have technical project managers to help coordinate success. These responsibilities fall upon gracious product managers, designers, and engineers willing to fill in the gaps. Organizing meetings and tracking action items sit alongside coding as essential work.
#3 — Vocal About Tech Debt
You are vocal about tech debt and are opinionated about its relative importance compared to day-to-day project work. Technical debt is pervasive. Product managers will inevitably push back and question its value; you must persist and pay it down. What’s important is not only the debt itself, but also how you showcase your values—quality, follow-through, engineering excellence.
#4 — Elevate Teammates
You make time for your colleagues and voluntarily lend your expertise. You give thoughtful code review comments, proactively ask for pair-programming sessions, and tactfully deliver feedback. You do not assume your colleagues will naturally come to you for help.
#5 — Vision For The Future
No matter the scope of work, you have a technical vision for the future. Things can always be better! This might be a long-term strategy for how the engineering department does hiring or it could be a set of best practices for how your team writes tests. Similar to technical debt, this is important not just as a vision, but as a symbol of how you value the evolution of your work.
Execution
#6 — Clean Pull Requests
You create clean pull requests that are focused and tell a story. You avoid large changes and provide as much context as possible in your descriptions. Simplicity takes effort.
#7 — Release Plans
You acknowledge how tricky releases can be and spend time with your product manager to create release plans. How will your team safely release this feature? How can you safely roll back if something goes wrong? Are all stakeholders informed? Creating a release plan signals that you value thoroughness, safety, and collaboration.
#8 — Follows Through With TODOs
You are a good citizen of the source code and follow through with your TODOs. Sift through any codebase and you will find thousands of “delete this section after migration” and “temporary fallback behavior” littered around the source. Lingering TODOs quickly cause cognitive overload for other developers.
#9 — Observability
You consider observability by default. How will you and your team know your code is actually working? You install a level of observability that matches the context of the work. If a feature is in alpha, there is no need to add 5 new alerts that might wake up your colleagues at 3am. When a feature moves into general availability, you ensure a well-thought-out set of on-call responsibilities is created.
#10 — Work Auto-Scheduler
Within your scope, you do your best to prioritize and schedule incoming work. When a customer support specialist brings up a fresh bug, you evaluate if the issue is critical and needs to be front-loaded. Prioritization is crucial at every level of the company and it starts with how you choose to spend your time. Any effort spent on prioritization will be greatly appreciated by your manager.
Scope & Complexity
#11 — Best-Effort Estimates
Despite knowing that estimates are always wrong, you still put in the time to establish them. You break down tasks, create milestones, and enable your non-engineering counterparts to plan their timelines. As you build, you maintain a pulse on new requirements and ongoing progress, quickly updating your stakeholders if any timings significantly change.
#12 — Constantly De-Risking, In And Out Of Software
While working on a complex and long-running project, you ingest all input and constantly de-risk the project. You are keen to hear about new requirements—a design tweak, a new auditing standard, or a nuance in revenue recognition may all influence how the technology is built. Armed with as much context possible, you are able to evaluate any new information (not just software-related) for potential risks.
#13 — Works Through Unknowns
You’re able to make forward progress on a project despite have 20% of the information you need. As a beginner, you’re expected to handle a stream of well-scoped tasks with clear acceptance criteria. As you grow, you will be sent in a general direction where the unknown heavily outweighs the known. To work through these unknowns, you begin to build relationships, explore technologies outside your immediate domain, and continuously developer your Debugger’s Mindset.
#14 — Leans Into Dependencies
You lean into dependencies and constantly grow your understanding of the entire software ecosystem. High-impact engineers are sent in general directions to deal with complex problems. Complexity comes hand-in-hand with dependencies. When you’re handling integrations with multiple teams and vendors, you refrain from siloing your work and never throw things over walls. It’s easy to say, “Hey, we’ll emit an event when this {important_operation} happens; the rest is on you.” It’s harder to lean into dependencies and fully grok the integration. This has the wonderful side-effect of strengthening your personal relationships with different teams.
#15 — Writes Often
You understand that writing is not just a medium for communication, but is also an opportunity to organize your thoughts. You look for opportunities to write beyond the technical planning during the onset of a project. Don’t understand how multiple software components fit alongside an abstract architecture diagram a Staff Engineer just shared with you? Try writing about it.
Communication
#16 — Provides “The Why”
When sharing, you remember to accompany your content with “The Why.” Why is this even important? You may know why something is important for a colleague before they even know why.
#17 — Avoids Loose Language
You avoid loose language. “I’m not sure why that’s happening; it might because of a recent commit” is completely unhelpful. If you’re unsure, communicate explicitly that you are unsure and that you will follow-up with an answer. Loose language is cumbersome to sift through, introduces red herrings, and is potentially disastrous during incident response. Ensure your communication is precise.
#18 — Bookmarks Conversations
You remember the context of conversation threads as you schedule between them. At any moment, you will be interacting with a variety of different people. You’ll catch up with a designer over a new prototype then immediately jump into a white-boarding session for a new software architecture. For each conversation thread, save the context and create a “bookmark” of where you left off. This streamlines communication and signals that you value 1-on-1 communication. Constantly starting conversations with “Could you please remind me again why…” is a waste of time.
#19 — Correct Context, Correct Medium
You thoughtfully choose the correct communication medium based on context. You’re aware of the pros and cons of Slacks, emails, and meetings and transition between them based on communication requirements. The level of information you share is fluid; creating a document for peer engineering review is different than creating a document for executive review.
#20 — Shares When Appropriate
You find opportunities to share your work despite your packed schedule. Sharing does not have to be delivering a full-blown presentation with slide animations. When a coworker is starting to integrate with a new cloud service, you proactively schedule 30 minutes with them because you went through the same integration last quarter. Effective sharing is the culmination of tiny sharing activities.
Conclusion
These “micro-habits” are more than habits. Habits affect your actions, actions affect how you operate, and how you operate culminates in how much value (not only lines of code) you add as an engineering professional.