Two weeks ago I had to write the yearly reviews for my team, and I quickly realized I had two choices:
- Spend an hour per colleague filling out the generic company feedback form, the same one used for every job function (the easy route), or
- Spend a couple of days building a framework tailored to evaluating a software developer on an agile team (the hard route).
As always, I chose the hard route with the better long-term outlook over the short-term fix.
I have high expectations, high standards, and a comprehensive yardstick for anyone carrying a senior developer title. And since all my team members are seniors, I had to work out a set of principles that make a software team exceptional, a team that’s the 80/20 rule made flesh for our company’s development department.
The Pareto principle (the 80/20 rule) says that for many outcomes, roughly 80% of the consequences come from 20% of the causes, the “vital few.”
The result? Here’s how I think about an excellent developer:
excellent developer
Results
what you deliver
Quality
functional
- Meet the product and technical requirements.
scalable
- Follow relevant design patterns and principles.
maintainable
- Consistency: follow agreed conventions, linting and formatting, and cover the work by tests.
- Simplicity: produce code that is small, independent, reusable, and testable.
peer reviewed
- Code review by other devs.
- Behavior and UI/UX review by QA.
Timely
- Meet deadlines and deliver work as committed.
- Regularly update progress, break tasks down into chunks, and communicate potential delays before they land.
Collective
- Prioritize team delivery over individual delivery.
- Actively look for struggling teammates to offer help.
Attitude
how you work
Growth seeking
level up yourself
- Expand expertise by working on unfamiliar topics and domains.
- Attend courses, get certifications, and read books to stay current.
- Experiment with new tools and tech to enhance productivity.
level up the code and product
- Find bad user experiences, bugs, and defects, and report them.
- Automate, refactor, increase test coverage, update dependencies.
- Monitor security vulnerabilities and tackle them.
level up teammates
- Pair programming, sharing knowledge (tech talks), and documenting how-tos.
Ownership
- Take start-to-end responsibility for delivering user stories.
- Seek, question, and improve product and technical requirements.
Effective communication
- Listen, sympathize, and choose your words kindly.
- Actively participate and contribute in scrum ceremonies.
- Communicate progress, issues, blockers, and ideas clearly and promptly.
scroll or +/− to zoom · drag to pan · esc to close
In short, the things that matter most to me are:
- Consistently delivering quality, timely, collective results, while sharing knowledge, collaborating, and communicating effectively with colleagues.
- Demonstrating a growth-seeking mindset, personally and professionally, with an ownership attitude.
- Acting like a senior: taking initiative to improve the reliability, maintainability, and scalability of the product and the system.
Once I finished the framework, the next question hit me: How do I share it with the other team leads in the company so they can benefit from it without much effort?
The answer? Build yet another internal app.
With some help from ChatGPT I created an app, “Dev Excellency,” and added it to the internal toolkit I’ve built since joining censhare, called “AgileKit,” which helps our development teams with agile (and even some HR) processes.
The app gives team leads (engineering managers, in some companies) an organized way to evaluate developers against the framework. You create an “assessment,” pick a team member, and the system pulls metrics from Jira (epics, user stories, story points, average velocity, and more) into tables and charts, so you get an overall picture of what that person achieved across the year. Then you work down a list of principles, rating performance on each. When you’re done, the assessment lands in the developer’s dashboard.
I ran it for all my devs, and the response was striking:
Almost all of them said they’d never received feedback this detailed in their career. They were happy that every small thing they did over the year, to help the team and the company, was noticed, captured, and counted in their evaluation, and that they now had meaningful, actionable items to improve on.
I think the way we give feedback in the software industry is broken. This was my first attempt to fix it on my part.
What do you think of this framework? How was the last feedback you got at work? Was it fair? Was it detailed? I’d love to hear your thoughts.