After 18 years in tech, I’ve seen documentation fail in almost every way possible. From outdated wikis that no one reads to massive Google Doc graveyards that make your eyes glaze over. But I’ve also discovered what actually works. Here’s the real deal on documentation that people will actually use.
The Hard Truth About Documentation
Let’s be honest: most engineering documentation is terrible. Not because engineers can’t write (though some of us certainly prefer code), but because we’re thinking about documentation all wrong. We treat it like a checkbox to tick off rather than a tool to help our teams move faster.
Video Documentation: The Game Changer
Here’s my “personal fav” approach that has consistently worked: Record short, focused videos. Why?
It’s faster to create. You can record a 5-minute technical deep-dive in… well, 5 minutes. Writing that same content might take an hour.
People actually consume it. Engineers are more likely to watch a quick video showing how to set up a local environment than read a 20-page setup guide.
It captures context you can’t write. When you’re explaining why you made certain architectural decisions, tone and emphasis matter.
The Documentation Stack That Actually Works
Here’s my hierarchy of documentation, from most to least important:
1. README.md Files
Lives with the code
Explains how to get started
Lists core dependencies
Shows basic usage examples
Must be maintained or CI fails
2. Quick Video Walkthroughs
5-10 minutes max
One specific topic per video
Screen recording + voice explanation
Perfect for:
Debugging common issues
Setting up development environments
Walking through new features
Explaining architectural decisions
3. Living Architecture Documents
High-level system design
Core architectural decisions
Update when major changes happen
Keep it brief – link to videos for details
4. Runbooks
Step-by-step emergency procedures
Must be tested regularly
Include common failure scenarios
Link to monitoring dashboards
Make Documentation Actually Maintainable
Here’s what I’ve learned about keeping docs alive:
Treat documentation like code:
Version control it
Review it during PRs
Test it (yes, really)
Delete it when it’s obsolete – make sure you have a forcing function to revisit old docs
Write less, but better:
One source of truth
Link don’t copy
Update or delete
No “TODO” sections (we all know they never get done)
The Documentation Workflow That Works
Here’s my actual process for creating documentation that sticks:
Start with a video:
Record yourself explaining the concept – I use OBS since it’s free and lets me record myself, my screen, and pairs nicely with a StreamDeck that I use to do everything in a single cut.
Share with the team
Get feedback
Iterate if needed (I use FinalCut Pro to edit my videos, but I try to make net-new videos if possible)
Extract key points:
Turn video insights into bullet points, link to timestamps in your video.
Add to README or architecture doc
Link to the video for details
Create runbooks from real incidents:
Document while solving problems
Update with each new incident
Include links to relevant videos
Common Documentation Pitfalls to Avoid
Don’t make these mistakes I’ve seen kill documentation efforts:
The “Someone Else Will Do It” Trap
If you’re working on it, you document it
No exceptions
The “I’ll Document It Later” Lie
Document while you work
Use screen recording to capture your process
It’s never “later”
Add a calendar invite for an hour in your own calendar to make sure it gets done, set it to recurring on a daily basis as your reminder.
The “Everyone Knows This” Fallacy
New team members exist
Future you will forget as your brain attic gets cluttered with more stuff
Document the obvious, it’s not obvious to everyone – teaching others will help you retain and learn too
Make Your Documentation Count
Here’s what I tell every team I work with:
If you’re explaining something more than once, record it
If you’re recording it, keep it under 10 minutes. Don’t record meetings, be purposeful about what you record, meetings and questions can drone on, but your succinct video is to the point – you can always have follow-up meetings to chat live about something.
If you’re writing it, make it searchable – search and AI-generated content from what you make now is going to be commonplace in the next 5 years.
If it’s not maintained, delete it
The Bottom Line
Documentation isn’t about writing novels. It’s about helping your team move faster and making your systems more maintainable. Start with videos, keep your docs close to your code, and ruthlessly delete anything that’s not providing value.
After 18 years in tech, from NOC Engineer at Lockheed Martin to senior engineering roles, I’ve learned that goal setting isn’t just about ticking boxes on a performance review. It’s about strategic thinking that separates senior engineers from the pack. Here’s how to approach it properly.
The Problem with Traditional Goal Setting
Most engineers fall into one of two traps:
Setting vague goals like “improve coding skills” or “learn new technologies”
Treating goals as a checkbox exercise for their manager
This is the engineering equivalent of implementing a feature without considering scale, maintenance, or customer impact. Let’s fix that.
Think Like a Senior Engineer
Senior engineers don’t just write code – they solve business problems. Your goals should reflect this mindset. Here’s my framework:
1. Impact Metrics First
Before writing a single goal, answer these questions:
How many users will this impact?
What’s the revenue or cost savings potential?
How does this affect system reliability/performance?
A junior engineer might say “Implement database migration to BigQuery.” A senior engineer says “Reduce query latency by 40% and cut storage costs by $50K/month through BigQuery migration.”
2. Non-Functional Requirements Matter
Don’t forget the unsexy but critical goals:
Security improvements
System reliability targets
Technical debt reduction
Performance optimization
These often have more impact than flashy new features. I’ve seen entire teams get derailed because they ignored these fundamentals.
3. Automate Everything
For every project goal, add an automation goal. Ask yourself:
What manual processes can I eliminate?
How can I make the next person’s job easier?
What repeatable tasks are wasting team time?
4. Uplift Others
The best engineers are multipliers. Set explicit goals around:
Mentoring junior engineers
Creating documentation
Recording technical deep-dives
Improving team processes
Remember: your impact scales dramatically when you help others improve.
Making It Concrete
Here’s what bad versus good goals look like:
Bad Goal: “Learn Kubernetes and improve our deployment process”
Good Goal: “Reduce deployment failures by 50% and cut deploy time from 45 to 15 minutes by implementing automated Kubernetes deployments. Create runbook and train 3 team members on the new process by Q2.”
The Reality Check
Review your goals and ask:
Can I measure this?
Does this improve our business metrics?
Will this make the team more effective?
Is this actually achievable in 6 months?
The Bottom Line
Your goals shouldn’t just be about what you’ll do – they should be about what will change because of what you do. That’s the difference between coding and engineering.
Remember: as you become more senior, your manager won’t set these goals for you. You need to think strategically about where you can create the most value. Start practicing now.
What are your thoughts on goal setting? How do you approach it differently at your level? Drop me a comment – I’d love to hear your perspective.
First, not many people are familiar with how layoffs are performed – now I don’t have all of the answers for every company here, but generally speaking – here’s what happens in the larger companies that have a dedicated HR team…
Managers have “a list” that is essentially stacked ranked
They give that list to their manager
That manager adjust the lists and combines it with the lists from other managers
This process continues as the lists are merged and sent up the chain of command
HR or “People teams”, as a non-biased third party comes in with their formula that leverages some data they have from finance. HR uses a formula, because that removes bias from the layoff equation (as long as the formula is unbiased, but that’s a topic for another day). A layoff formula might have these variables and weights:
Variable
Weight
Location
Is the person colocated with their team? Some companies believe this is important for performance and productivity.
4 = Remote, 3 timezones or more away 3 = Remote, 2 timezones or more away 2 = Sometimes visits office 1 = In office 3+ times a week
10%
Performance Ratings for Software Engineers
What have been the last two performance ratings for this employee? Companies have a bias for performance (even if performance reviews are biased and inaccurate). This is part of the McKinsey 9-box model since the company uses this to judge/rank performance.
4 = Last two ratings have not met expectations 3 = One of last two ratings have not met expectations 2 = Both of the last ratings have met expectations 1 = One of the last ratings have exceeded expectations
20%
Productivity
Some companies track overall productivity for employees either by tracking statistics on their work on “spyware” on their computer.
4 = Employee is not productive during the workday 3 = Employee is productive 50% of the workday 2 = Employee is productive 75% of the workday 1 = Employee is productive 90%+ of the workday
20%
Salary
If the company is looking to cut budget, you can expect this to be part of the calculus. This is where senior people who have been with the company will be analyzed. This is also where employees based in higher cost areas might be targeted more than others.
4 = High Salary (over $350,000 total compensation) 3 = Medium Salary (over $250,000) 2 = Average Salary (over $150,000) 1 = Below Average (under $150,000)
20%
Progression
Has the employee been stagnate in their level for a long time? If someone is at the same level for 5 years, this could indicate a productivity problem and a lack of performance and potential (from the McKinsey 9-box).
4 = No promotion in 10+ years 3 = No promo in 8 years 2 = No promo in 4 years 1 = No promo in < 4 years
10%
Cost Center or Profit Center
Is your team making the company money (Profit Center) or part of Operational Cost (Cost Center). Companies looking to save money will likely cut more teams that are a Cost Center instead of a Profit Center.
4 = Cost center 1 = Profit center
10%
Team/Product/Org Investment
Does the company plan to invest in this team or area in the next year? If not, it’s likely they will look to make cuts here.
4 = Product/Org/Team needs to shrink 3 = Some investment likely, need to keep product running 2 = Investment needed 1 = Must invest
10%
How a company might calculate layoff targets – note that this is only an example
The 9-box plays into career progression and performance assessments
The McKinsey 9-Box Model
From what I’ve seen, most companies will use a 3 point scale on each axes for Potential and Performance where Low is 1 and High is 3. To avoid any ties and to clearly articulate value, you might see a prioritized 9-box like this:
7 Enigma
8 Growth Employee
9 Future Leader
4 Dilemma
5 Core Employee
6 High Impact Performer
1 Under Performer
2 Effective
3 Trusted Professional
A prioritized 9-box where 9 is the most prized/rewarded employee (think: raises, bonus, RSUs, etc.) with high performance and potential
This might play a factor as part of stack ranking, bonus assessments, and overall performance management so it’s important for you to understand how leadership will use this mental model.
Example 9-box Scenarios
So now that we have the weighting and the 9-box, let’s try some examples using IDEs as our employee names.
employee
formula
score
possible story
Eric Clipse
4 Location: Lives 3 timezones away from core team or manager 4 Performance: Last two reviews have not met expectations 2 Productivity: 75% productive – clickity-clacking 4 Salary: High salary over $350,000 2 Progression: No promo in 2 years 4 Cost/Profit Center: In a cost center 2 Org Future Investment: Some investment needed in the future
3.2
Story 1: Senior engineer that has been around for 10 years, and relocated during COVID, since being promoted to very senior level, they have struggled to be productive (see Peter Principle) because they may have been promoted without appropriate considerations or their managers have been biased in previous years to rapidly promote.
Story 2: Even though Eric went remote, there was a re-org and now the team is 3 timezones away.
Xavier Code
Everything as above, but change from 4 to 2 salary
2 Salary: Average salary over $150,000
2.8
Story 1: Average software engineer position as they came over from another company. Could have been a bad hire through the interview process since they have had 2 reviews that have not met expectations.
Story 2: Joined from another company and thought this company and team was great, but the manager and work is not what they thought it would be so they have underperformed.
Ned Beans
Everything as Eric Clipse, but change: Location 4->2 since they sometimes visit the office.
Performance has met expectations the last 2 reviews, so 4->2 when compared to Eric.
Also similar salary to Xavier.
2 Location 2 Performance 2 Salary: Average salary over $150,000
2.2
Came from another company with some experience, average performance and salary.
Vince S. Code
2 Location 2 Performance 4 Salary: High salary over $350,000 4 Progression: No promo in 10 years
2.8 (Same as Xavier)
Story 1: Has been with this company for a very long time, has been promoted, pretty average reviews, goes into the office sometimes, and has a high salary due to living in a high cost location.
Story 2: At one of the most senior levels, they are not interested in being promoted past this role, they love their job and have a good work/life balance.
Example scenarios with fun names
To recap, we have the following list where the higher the score, the most likely to be laid off:
Eric: 3.2
Xavier: 2.8
Vince: 2.8
Ned: 2.2
For the sake of simplicity, let’s say this team is 10 people, and we’ll duplicate these four people assuming that there are similar cases.
Eric: 3.2
Xavier 1: 2.8
Xavier 2: 2.8
Vince 1: 2.8
Vince 2: 2.8
Ned: 2.2
Ned: 2.2
Ned: 2.2
Ned: 2.2
Ned: 2.2
Now, let’s say a layoff comes – typically this occurs behind closed doors away from front-line managers and their teams to limit knowledge and the amount of damage any employee could do knowing they were going to be terminated – it covers the company from any potential issues, but now leaves front-line managers helpless. HR comes up with a target, 10% – so in our case, Eric having a score of 3.2 would be the one person to leave this team, but let’s add another team to this mix:
team 1
team 2
1. Eric: 3.2 2. Xavier 1: 2.8 3. Xavier 2: 2.8 4. Vince 1: 2.8 5. Vince 2: 2.8 6. Ned 1: 2.2 7. Ned 2: 2.2 8. Ned 3: 2.2 9. Ned 4: 2.2 10. Ned 5: 2.2
1. Xavier 1: 2.8 2. Xavier 2: 2.8 3. Vince 1: 2.8 4. Vince 2: 2.8 5. Vince 3: 2.8 6. Ned 1: 2.2 7. Ned 2: 2.2 8. Ned 3: 2.2 9. Ned 4: 2.2 10. Ned 5: 2.2
Another Vince-like person added here – maybe for one of these reasons:
1. Manager is less critical during performance reviews, so this team has fewer people not meeting expectations.
2. Similar to (1): Manager has been managing this team for awhile and is now friends with everyone so performance reviews are less critical.
3. Manager is unaware of what the team is doing so doesn’t provide critical assessment of team and thinks everything is awesome.
4. Team is more colocated than Team 1
Example scenario
Now the same layoff hits both teams with a 10% target, with 20 total people, HR would have to select 2 people to be impacted, from before we know Eric would be selected, but now we have 9 people with the same 2.8 score:
Xavier-like people may not be performing, but are paid average: 2.8 score.
Vince-like people have been performing at expectations, but are more senior and have been with the company for a long time: 2.8 score.
When faced with a tie, likely one of two things happen:
HR uses a stacked rank to determine the next person to be impacted
Since the scores are the same, one person is selected at random
Both of these sound pretty terrible – a stack ranked list of people comes with a ton of bias since this is usually done by managers, then merged, then ranked, then merged as it goes up the chain.
Random selection isn’t any better either – no one wants their career to be determined by Math.random() when their performance, passion, and drive hasn’t been random. You can see that in either approach, a faceless algorithm will likely decide fate.
So what do you do? Let’s dive in.
1. Hack the 9-box
You want to be in the right && top of the 9-box
7 Enigma
8 Growth Employee
9 Future Leader
4 Dilemma
5 Core Employee
6 High Impact Performer
1 Under Performer
2 Effective
3 Trusted Professional
You want to be 3,6,8,9
There are too many variables at play here. In the past I’ve seen:
Someone who was happy in their role and not interested in being promoted perceived as having less potential
A team who was doing more mundane work perceived as having higher performance
Teams who create problems for them to continue to solve appear to be heroes and have higher performance
How can you avoid most of this? Keep your head down and focus on delivering results and value. This will put you at either 3 Trusted Professional or 6 High Impact Performer. Although it might be appealing to target that middle (5) box, if you are consistently seen as someone who has both average performance and average potential, you won’t be rewarded as much and will be average in a stacked ranked list (which we’ve learned above: middle or average 2.8 for Vince and Xavier could create a situation where you’re somewhere in a layoff list).
Here are some other options:
Boost your performance
Find low hanging fruit that’s being ignored and fix it.
Look at how your team talks about your victories – are they aligned with business priorities?
Is the work you’re doing attributed to those victories?
How can you deliver results above expectations? Can you do something faster? Deliver earlier? Reduce the complexity?
Be consistent with performance. Someone who is productive only when asked, or has sine-wave ebs of productivity is not going to be doing themselves any favors when compared to consistent performers.
Boost your potential
Come up with interesting and innovative ideas that make sense, are low return on investment and drive the company’s bottom line, even if you don’t think your team can work on it right now. Write it down and publicize it.
Educate colleagues on what you know, about the company’s products or infrastructure/hardware that it’s built on.
Educate yourself – take classes, read books about new topics, stay informed of new technologies. I love Tech Radar.
Find gaps in the work that others do or enhance existing ideas.
Sign up to do things that no one else wants to do.
Be a giant supporter of the company, post a lot of positive things on social media, recruit people to join you, give external talks.
Since the 9-box is used during performance management (for companies that have been McKinsey’d), where there’s likely a bell-curve forced ranking applied, you want to understand where the people on your team might fall and ensure you’re doing something to get you uniquely into one of these boxes.
7 Enigma
8 Growth Employee 1 person max
9 Future Leader 1 personmax
4 Dilemma
5 Core Employee 3 peoplemax
6 High Impact Performer 1 personmax
1 Under Performer 1 person min
2 Effective
3 Trusted Professional
An example forced-rank curve applied to the 9-box – this is for a sample 10-person team where 7 are shown above and 3 more (not shown) need to fall in other positions [1,2,3,4,7]
2. Be closer to your team
It sounds weird, but if HR is using location as one of the weights (likely because your company has some sort of return to office policy), you should try to be closer to your team. The farther away you are – the more you will be scrutinized and the more you’ll need to focus on being present and performant.
If you’re a remote employee, you should make sure you over-emphasize:
Constant communication – use chat and documents constantly. Make it a point to communicate something valuable every day to be visible.
Purposeful meeting time – setup time with people, you won’t run into them in the halls of the office, so you need to think more about who you need to spend synchronous time with.
Use async communication to your advantage – record demo videos, videos that ask questions and gather input, educational content. You don’t need a meeting to contribute value. Be concise in your messages – don’t create noise and don’t create work for others.
Volunteer for things – if your commute is from your bedroom to your office, you are saving hours of time that your other colleagues are spending driving into the office. Use that extra time you have by effectively by helping the team.
Be a meeting superstar – if you’re remote and others are in the office, you have an advantage of taking notes and paying attention to meetings – you have no in-person distractions. Take meeting notes, summarize key points, speak up during meetings to assert your opinion or ask questions. Don’t let in-person people not hear you – speak up, keep speaking up if you aren’t heard.
3. Make sure your product/org has a future
Be selective for the team you join. If your product has a known end-of-life or is consistently losing revenue or costing the company more money than it’s worth – and you might be a “4” in other areas of the layoff calculations – try to find something else. Yes, you may not be as stressed on this team because you’re just keeping the lights on, but that runway is limited (you could also join this team and come up with an amazing idea that turns the ship around).
HR might look at positions that can be eliminated to save cost. If you do jump into a team with a limited future, make sure you’re also reading the room to know when to jump to another team. If your company is publicly traded and the stock continues to decline, that may trigger a layoff, so position yourself well before that happens.
4. Be part of a profit center or a cost center that significantly avoids financial pain
A cost center that provides revenue safety is almost as important as a profit center. Most companies don’t want to leak money if it can be avoided. Here are some example teams that would be cost centers:
Quality Assurance (QA) Team: Focuses on testing and ensuring the quality of software, incurring costs without directly generating revenue. Any bugs caught before hitting production would avoid a revenue loss. Some bugs can be hilarious though, like the time PayPal accidentally credits man $92 quadrillion.
DevOps/Site Reliability Engineering/Production Engineering Team: Manages the infrastructure, deployment, and operations of software applications, primarily a cost to ensure smooth operations. Any downtime would incur revenue loss and/or brand impact to the company (see PayPal’s Outage in 2004 or this PayPal Outage from 2015).
Security Engineering Team: Works on securing software applications and systems, which is a necessary cost but does not directly generate profit. Any public security issue might negatively impact brand (see Roku’s Data Breach) or create a fine for the company (see Equifax Data Breach Settlement). This also includes security bugs like this PayPal SQL Injection Vulnerability.
Technical Documentation Team: Produces documentation for software products, a necessary support function that incurs costs. This could be a public facing team that works on developer API documentation (see Square’s API docs), for instance or it could be a team that focusing on education of internal employees.
Internal Tools Development Team: Develops and maintains tools for internal use by other engineering teams. Anything that would be built or maintained by a team inside the company. For example Splunk or other monitoring tools deployed on-prem would likely require a team to maintain it.
On the flip side, here are some teams that would be profit centers:
Feature Development Team: Develops new features and enhancements for a software product that can directly drive sales and revenue. This is a pretty common team for most companies.
Custom Software Development Team: Creates custom software solutions for clients, generating revenue through bespoke projects. This might a team that drives sales using the companies product to show how it can be used.
Product Engineering Team: Builds and maintains the core product(s) of the company, directly contributing to sales and profit. Likely a core feature that is known to make money with small enhancements.
Platform Engineering Team: Develops and maintains a platform used by external developers or companies, generating revenue through platform usage fees or subscriptions. This is likely a Software-as-a-Service (SaaS) that might drive recurring subscription revenue or a product that charges based on usage (like AWS, Google Cloud, etc.).
5. Be productive
Quite simply: get work done. Use tools and systems effectively, don’t be a hindrance and always add value.
Try to be responsive to messages, don’t forget about commitments – don’t drop the ball too many times.
Wrap Up
As I’ve discussed before, the 9-box model is inherently flawed. Ask around to understand if this model is being used at your company, then ask questions to validate that there are enough checks and balances (discussed in the linked article) to attempt to make the field more fair.
If your organization is using some variant of this system, be sure to check yourself on where you’re at – since the 9-box can be used for many things, and could be foundational when it comes to algorithmic layoff determinations, I hope this empowers you to take hold of your career and make daily choices that help you.
The current push to bring employees back to the office after the COVID-19 pandemic is reminiscent of the motivations behind the construction of the Uffizi in Florence during the Renaissance. Just as today’s corporate leaders emphasize the need for physical presence to ensure productivity and maintain company culture, the Uffizi, built by Giorgio Vasari in 1560 under the commission of Duke Cosimo I de’ Medici, was a strategic move to centralize and exert control over the administrative and artistic functions of the Medici government.
The Uffizi, originally intended as offices for Florentine magistrates, symbolized the Medici family’s authority and their desire to consolidate power. By bringing all key administrative functions into one grandiose structure, Cosimo not only streamlined operations but also kept a close watch over his subordinates, fostering a sense of unity and direct oversight. Similarly, modern organizations aim to bring employees back to a central location to enhance supervision, ensure alignment with company goals, and foster spontaneous collaboration that is harder to achieve in a remote setting.
Furthermore, the Uffizi became a cultural hub, reflecting the Medici’s patronage of the arts and their role in nurturing the Renaissance’s intellectual and artistic growth. This parallels how contemporary companies leverage the office environment to shape corporate identity, drive innovation, and build a cohesive organizational culture. Just as the Uffizi’s physical presence was a testament to the Medici’s influence and vision, today’s office spaces are seen as essential to cultivating a strong, innovative, and collaborative workforce.
2. Senior SWEs Stubbing out Code
In the world of Renaissance art, the most critical and intricate parts of a painting were entrusted to master artists, while their apprentices and junior artists handled the less crucial sections. In The Baptism of Christ, Verrocchio painted the central figures, ensuring the highest quality and artistic integrity, while Leonardo contributed by painting the angel on the left, demonstrating his burgeoning talent under the master’s guidance. This division of labor not only maintained high standards but also provided a structured learning environment for junior artists.
The Baptism of Christ: In this Renaissance masterpiece, Andrea del Verrocchio and his pupil Leonardo da Vinci collaborated, with Verrocchio painting the central figures and Leonardo contributing the angel on the left, showcasing their combined artistry and the mentor-apprentice relationship typical of the era.
Similarly, in modern software engineering, senior software engineers (SWEs) often take on the most complex and critical components of a project, leaving more straightforward tasks to junior developers. This approach ensures that the most crucial parts of the codebase are developed with expertise and precision, maintaining the project’s overall quality. Additionally, it allows junior developers to learn and grow under the guidance of more experienced colleagues, fostering an environment of mentorship and skill development.
Returning to the office amplifies these benefits by facilitating closer supervision, spontaneous collaboration, and immediate feedback. Just as Verrocchio could directly oversee and influence Leonardo’s work, senior SWEs can more effectively mentor their junior counterparts in a shared physical space. The proximity fosters an environment where knowledge transfer occurs more naturally and efficiently, accelerating the learning curve for less experienced team members.
3. Competition Creates Innovation
The Medici family’s strategic establishment of the Uffizi not only centralized control but also fostered a competitive environment that spurred innovation and excellence during the Renaissance. This principle of competition driving innovation is equally relevant in modern software engineering.
During the Renaissance, artists and intellectuals competed for the patronage and recognition of influential families like the Medici. This competition pushed artists to refine their techniques and innovate, leading to masterpieces that still inspire today. The Uffizi, by bringing together the best minds of the time, became a crucible for creativity and progress. Notably, artists like Leonardo da Vinci and Michelangelo thrived in this competitive atmosphere, producing groundbreaking works that defined the era.
Similarly, in the realm of software engineering, competition is a powerful catalyst for innovation. When developers and teams are brought together in a shared space, a healthy competitive spirit often emerges. This can drive individuals to push the boundaries of their skills and creativity, resulting in cutting-edge solutions and advancements. Just as Renaissance artists were motivated by the presence of their peers and the desire for excellence, modern software engineers can find inspiration and drive from the competitive yet collaborative environment of the office.
Returning to the office reintroduces the dynamics of in-person competition and collaboration. The spontaneous exchange of ideas, the immediacy of feedback, and the visible progress of peers all contribute to a vibrant and stimulating work environment. These elements are harder to replicate in a remote setting, where the isolation can dampen the drive for innovation.
Moreover, competition within a team can lead to a collective push towards higher standards and innovative solutions. When engineers see their colleagues tackling complex problems and coming up with novel ideas, it creates a ripple effect, encouraging everyone to elevate their game. This is similar to Renaissance workshops, where artists working together inspired greater creativity and skill.
We recently took our 3 year old to Italy (MXP, Milan, Lake Como, Florence, MXP) and after several hours of research, I think we found the right combination of luggage and stroller (here’s our previous Italy trip before kids, and the top 5 things to do in Florence that we repeated for this trip).
Much like the train, the Micro luggage is easy hop on and hop off. If you add this iPad holder, it will loop around the luggage so they can watch their favorite show – something you’re going to need while you wait in line for passport checks.
For trains: put the stroller away in the bag (wear this as your primary backpack, and put your other one in front of you) and use the Micro Luggage Easy.
Works well on escalators
Easy to get in and out
Fast to get from the luggage rack and expanded for use
No issues on cobblestone and uneven streets and even gravel
Retractable sun cover was great for rain as well as bright sun during naps
Minimal storage, but it’s better than nothing
Easy to jump up and down from street to curbs which you’ll find yourself doing a lot
Reclines (which you want if you’re going to be out during the day) to allow child to sleep when you’re out (worked about 50% of the time for us – much more effective to head back home for a nap)
One thing that continues to bother me while working in big tech is the gap in resources and cost-effective talent that nonprofits have.
Cost: nonprofits can’t afford $100k/year salary for a software engineer, they also can’t afford to pay $30/month for software that takes away from their bottom-line
Complexity: recent AI advancements are amazing, but a nonprofit staff of five won’t have the time to both learn and understand how they can benefit
Identification: without technical support, a nonprofit may not recognize there is room for software to improve their workflow
Opportunity Hack aims to pair programming talent with nonprofits for free. From now until September, we’ll be collecting issues that are facing nonprofits via the form at apply.ohack.dev.
In this article, I compare the cost of owning an electric car: is it worth it in the short-term? What does five years of ownership look like? How do you factor in the cost of electricity versus gas? Let’s take a look!
tl;dr: Considerations for Electric Cars: Phoenix, AZ
I like to start just by sharing the results – if you read nothing more, read this.
I have used the Hyundai Kona and Kona Electric as examples, since they are available with both powertrains. I have also assumed that you drive 15,000 miles per year, which is the average for U.S. drivers.
Don’t consider an EV if you need to upgrade your electrical panel to support a Level 2 (220V/20A) charger. The costs may offset the cost of owning a gasoline car (it’s still unclear how long you will need to own an EV car to offset the carbon emissions that it costs to create it and its battery so that’s not considered here).
If federal and state EV incentives go away, it likely won’t be worth it to own an electric vehicle.
Here’s what the cost of ownership looks like over 5 years.
Cost Item
EV (Kona Electric)
Gas (Kona)
Purchase Price
$35,295
$22,595
Federal Tax Credit
-$7,500
$0
State Tax Credit
-$2,500
$0
Maintenance
$1,830
$3,030
Electricity
$2,830 for power usage $1,700 for install
$0
Gasoline
$0
$12,830
Total Cost
$31,655
$38,455
The EV is cheaper to own than the gas vehicle by $6,800 over 5 years. This is mainly due to the tax credits and lower fuel and maintenance costs. However, this may vary depending on the model, driving habits, electricity and gas prices, and other factors. Electricity Cost:13.478 ¢/kWh for Phoenix, AZ Electric Installation: Installation of a Level 2 charger (that needs 220V / 20A) which will likely cost $500 ($1000 for the unit with 30% IRS refund + $250 rebate from APS/SRP) with an average installation cost of $1200. Gasoline Cost:$4.79 per gallon for Phoenix, AZ
Upgrading your electric panel: The only other edge case to consider is if you need to upgrade your electrical panel to support a Level 2 charger (you’d spend over 24 hours recharging on a basic 112V Level 1 charger). If this is your case, you’ll be spending about $5000 parts+labor to replace your panel which will put you at about $1000 less expensive than gas.
Cost of a replacement battery: Hyundai offers a lifetime warranty on their batteries in the US. So as long as you select a car with the same warranty, you won’t have any additional unexpected large costs (see the Electric Calculation section below for more details).
Can you tell which one is electric? I have no idea – this is AI-generated.
Gas Calculation
To calculate $6,285 for gasoline over 5 years, I used the following formula:
Gas cost = (Miles driven per year / Fuel efficiency) x Gas price x Years
For the miles driven per year, I used 15,000, which is the average for U.S. drivers. For the fuel efficiency, I used 28 mpg, which is the combined city/highway rating for the Hyundai Kona. For the gas price, I used the average gas price in Phoenix, AZ, which is $4.79 per gallon. For the years, I used 5.
Plugging these numbers into the formula (also this calculator), I got the same:
Gas cost = (15,000 miles per year / 28 mpg) x $4.79 x 5 years
Gas cost = $12,830.36
Electric Calculation
Annual mileage = 15,000 miles Number of years = 5 Efficiency = 28 kWh/100 miles Total electricity usage = (Annual mileage x Number of years) / Efficiency Total electricity usage = (15,000 miles x 5 years) / (28 kWh/100 miles) Total electricity usage = 21,000 kWh
According to the EPA, the Hyundai Kona electric has an efficiency of 120 MPGe(miles per gallon equivalent), which means it uses 28 kWh of electricity to travel 100 miles¹. Assuming you drive 15,000 miles per year for 5 years, that means you will use 21,000 kWh of electricity in total. The cost of electricity for a Hyundai Kona electric depends on the electricity rates in your area and the time of day you charge your vehicle. Using 13.478 ¢/kWh for the average cost in Phoenix, Arizona, the estimated cost of electricity for a Hyundai Kona electric that drives 15,000 miles per year over 5 years is $2,830.82. However, this cost may be lower or higher depending on your actual electricity rates and charging habits.
In terms of charging at your home, you’ll need to consider having a Level 2 charging station (costs of hardware and install already discussed above):
With a battery capacity of 64 kWh, charging a Hyundai Kona Electric at home from 20% to 80% can take up to 28:26 hours with a 1.9 kW level 1 charger, or between 01:56 to 03:52 hours with an 11-22 kW level 2 charging station. With fast charging at a public station, the vehicle can be charged in about 16 minutes.
Cost of a replacement battery: A big variable for an EV is the battery: Since they have not been on the market that long, we have to hope they will last longer than 5 years. The high-voltage battery (not the smaller 12V one) is the main component of an electric vehicle and it usually has a long warranty period. For example, Hyundai offers a lifetime warranty for the high-voltage battery of the Kona electric in the US. However, if you need to replace it out of warranty, it can be very expensive. The cost of replacing a Hyundai Kona high-voltage battery is estimated to be upwards of $6,000-7,000. So again, pick a brand with a long warranty and you should be safe.
Double Check
After doing the math by myself, I went looking for a calculator and the first one that I found roughly matches what I calculated.
It’s 3.375 times more cost effective to drive an EV with today’s gas prices.Even when gas gets down to $3/gal, you will still get double cost savings from an EV.
Maintenance Costs
The maintenance of an EV versus a gasoline car is generally simpler and cheaper, as EVs have fewer moving parts and fluids that need to be replaced or serviced. According to various studies (see Consumer Reports), EVs cost 30% to 50% less to service than gasoline cars over their lifetime. Some of the maintenance items that EVs do not require include:
Oil changes
Spark plugs
Fuel filters
Timing belts
Exhaust systems
Emissions tests
Some of the maintenance items that EVs do require include:
Cabin air filters
Brake pads
Tires
Suspension components
Battery cooling system
The estimated cost savings of EV maintenance depend on the type, model, and usage of the vehicle, as well as the location and labor rates of the service provider. However, some studies have provided some average figures for comparison. For example, one study (Business Insider) found that EVs cost 6.1 cents per mile to maintain, compared to 10.1 cents per mile for combustion-engine vehicles.
Another study found that EV owners spend an average of $77 on maintenance per year, compared to $228 for gas vehicle owners.
A third study found that EV owners can save an average of $4,600 in repair and maintenance costs over the life of the vehicle compared with a gasoline-powered car.
That’s it – I’ve probably missed something, but ideally it’s benign and doesn’t impact the overall assessment. Gas and electricity prices will change over time, with no clear historical prediction yet. I don’t yet have an EV.
The unspoken advantages for electric cars
No more gas stations
You get to fuel up in your garage! No more trips to the gas station – you get to zip from home to work or school without having to worry.
Less things to go wrong
This is hard to quantify, but you have more peace of mind knowing there is no combustion going on in your car. Combustion (explosions) by nature within your engine and the fluid needed for engine + transmission creates more room for things to go wrong. With EVs, you get to use the DC motor as a brake assist too – so you should have less wear and tear on your brakes, and get to regenerate energy as you slow down.
Having to stop on a road trip might actually be good
Having a forcing function to make you stop along a trip might be good to stretch and decompress during your drive.
Electric cars and charging in Arizona
As of August 27th 2024, there are new charging stations coming that are funded through the National Electric Vehicle Infrastructure program, or NEVI, which is allocating $5 billion in funds nationwide through the U.S. Departments of Transportation and Energy, including $76.5 million for Arizona (see article on AZDOT.gov).
Urgent requests from executives can disrupt software engineering teams and lead to rushed implementation.
Scarcity mindset and cognitive load impact attention and decision-making in such situations.
Cultural differences and hierarchical leadership styles in lower-cost outsourcing destinations can further complicate decision-making processes.
Strategies for mitigating these challenges include having strong product managers to shield the team, maintaining a well-prioritized backlog, and physically separating external requests from the team’s ongoing work.
Having solid product manager principles, conducting market research, prioritizing features, and working closely with the development team are essential for effective product management.
Using tools like Asana, Jira, or Google Docs to maintain a well-organized backlog helps balance immediate tasks, future goals, and customer transparency.
Avoid letting the backlog become too large and regularly review it to ensure efficiency and focus.
Physically separating external requests from the team’s work creates a buffer and allows for better prioritization and evaluation of their importance.
Applying techniques like the Eisenhower Matrix, First Things First, and Habit 3 of The 7 Habits of Highly Effective People can aid in prioritization and decision-making.
Without strong leadership, urgent requests bottleneck a team
In Episode 145 of No Stupid Questions “Do You Have a Scarcity Mindset or an Abundance Mindset?” Steven and Angela touch on this important part:
DUBNER: One thing that really catches my ear as you’re describing the Mullainathan et al. research is about attentionand how more of it is required — or more cognitive load, you might call it, is required — when you’re under scarcity because you’re trying to solve a huge set of problems. I mean, when economists talk about scarcity, that’s the problem with scarcity. Things get more expensive. When it’s a product, when it’s a good or service, and it’s more scarce, it costs you more. But also in the mindset mode, it can take your attention.
Steven talks about scarcity impacting your attention when you’re under cognitive load
This applies well to software engineering, where knowledge workers are under cognitive load trying to design new features and solutions for their customers. When a new request comes in that seems urgent, this becomes a time scarcity problem, people drop things to pickup a super-important-from-a-VP-request (Chief-Level, C-Level requests or C-Requests). Different teams have different coping mechanisms for this: one team that I worked with had an engineer oncall rotation only to handle C-Requests so they could show a great time to resolve.
The amygdala also activates the fight-or-flight response. This response can help people in immediate physical danger react quickly for their safety and security. For example, the fight-or-flight response helped early humans respond to threats to avoid injury or death. Today, that fight-or-flight response is more likely to be triggered by emotions such as stress, fear, anxiety, aggression, and anger.
Picture this, your team manages a customer monitoring solution. You’re in the middle of a large data migration from one storage solution to another, for example Hadoop to Google BigQuery. Front-end engineers are scarce, and are focusing on the next generation of UI.
A request comes in, it’s from a Vice President, they ask for you to change the functionality of the legacy monitoring solution so that when you click on a specific area, you can perform an action. Without a strong request shield in place, this request is made directly to a software engineer on the team, and because this VP wants to ensure it is fixed, they also message another lead on the team without telling these two people.
Now you have a request from an executive, sent to two individuals, that appears to be urgent. What happens? A. Both engineers talk to one another, and decide to put this in the backlog B. The two engineers drop what they are working on to appease an executive From what I’ve seen: Option B.
They rush to implement this feature, one of them finishes it first, and the other notices a similar code change when attempting to merge. Now they talk and realize they both had the same request, the first person to commit wins, the code is merged, and they go back to their regularly scheduled Jira Story. They have victory for that day, but no quality control, no design, no communication, and no future-thought was put into this. This feature is never rolled into the new system, and creates bugs for edge cases on the legacy system that will plague the team for months.
Cultures handle authority differently
With a focus from most companies to reduce costs, we have seen layoffs and outsourcing to places like Mexico and India (ref). What comes with this are some cultural changes that don’t combine well with authoritarian requests from Vice Presidents. Look at the graphic below – from research from Erin Meyer et al. we see that the countries that tend to be lower cost also avoid confrontation as part of their cultural norms.
Meyer, E. (2014). The culture map: breaking through the invisible boundaries of global business. First edition. New York, Public Affairs. Page 119.
This means that, left unchecked, executive requests will likely make the bulk of the feature requests that are prioritized, leaving more important features behind and potentially introducing more bugs. Once more, take a look at the next image below – this shows that these same countries are used to hierarchical leading, where the boss calls the shots. This goes counter to the quote “Those closest to the problem are closest to the solution, but typically furthest from the resources and power to do anything about it.” (DeAnna Hoskins).
You typically want high-value knowledge workers solving problems who are the most familiar with them – not high-level executives.
Meyer, E. (2014). The culture map: breaking through the invisible boundaries of global business. First edition. New York, Public Affairs. Page 76.
This is why you might see an emphasis on buying tools instead of building them. When knowledge workers who avoid confrontation are setup to be integrators of purchased tools, all executive feature requests then go through the vendor and not software engineering team.
Strategies for avoiding amygdala hijacking at work
When you have calmed down or feel less stressed, you can activate your frontal cortex. Begin by thinking about what activated the response, and how you felt. Then, consider responses you can and should have. These will be more thoughtful and rational responses. If you still feel emotional in the moment, give yourself more time.
What you want: Product Managers and Engineering Managers that constantly shield the team from urgent request that aren’t important
Product Managers (or just the mindset) can serve as a great frontal cortex by providing protection from amygdala hijacks.
Have solid product manager principles
You may not have the luxury of a full-time Product Manager for your project, either because they are split over multiple product lines or your team lacks general investment in this role. What’s critical is that someone upholds these principles to focus the team on only the features and products that will bring value to your customer.
Define the product vision: This involves identifying the problem that the product will solve and the target audience for the product.
Conduct market research: Gather and synthesize information about the target audience, their needs, and the competition.
Develop a product roadmap: Outline the key features and milestones for the product.
Prioritize features: Prioritize the features based on their importance and impact on the product.
Develop a product backlog: Work with engineering teams to maintain list of all the features that need to be developed for the product.
Work with the development team: The product manager should work closely with the development team to ensure that the product is developed according to the vision, OKRs, roadmap timelines, and feature backlog.
Test and launch the product: Hands-on, thorough testing to ensure that it meets the requirements. Once the product is ready, it should be launched to the target audience.
Analyze metrics: Ensure features are delivering based on projections, prioritize improvements based on these metrics.
Have a well maintained backlog using tools like Asana and Jira (or even GDocs)
Having a good balance between what needs to be done now, next, and the future is important. You’ll have to merge and adjust these lists as you think about new features. Giving your customers transparency on what your backlog looks like gives them confidence that you care. Being proactive with your backlog and release notes are great interrupts to avoid constant status meetings.
Being well organized also exudes outward confidence to senior leaders that you’ll work on the most impactful things. When “urgent” executive requests come in, you can speak logically against your current set of work to illustrate where this new request fits in (now, next, feature). You may need to do some analysis before accepting an external request – and that is okay. Executives might think they have the best idea since LLMs, but only the data should confirm or deny this.
Don’t let your backlog get too large. The maximum number of backlog tasks should be 50 – use Google Docs or Confluence pages that describe additional work the team needs to work on, but it not yet in your backlog. Being prideful for a large backlog is the wrong culture to have – a large backlog shows wasteful hygiene. Review backlogs bi-weekly.
Physically separate the teams work from external requests
Don’t pollute the work the team needs to do with external requests. If partner teams and senior leaders want to contribute, give them a separate place to do so – either convert emails/DMs to updates to existing Google Docs, or maintain a distinctly separate customer feature backlog that allows for transparency and even voting for the most important new features. Review these monthly. This is your physical buffer that shields the team from unnecessary escalations that seem urgent but may not be important (also read more about The Eisenhower Matrix, First Things First, and Habit 3 of The 7 Habits of Highly Effective People).
Good managers will always encourage you and tell you that you’re doing a good job. Great managers will challenge you to mature as a software engineer. In my career I’ve observed EMs who “silent fire” someone by not spending enough time as a coach. The goal of this article is to remove this veil for software engineers so they can improve their manager’s effectiveness. Managers: your team is your responsibility.
One rower in a boat can slow down the team.
Having good optics as an engineer can help you navigate through ineffective managers. Photo taken at Museo Galileo in Florence, Italy.
A great engineering manager maximizes these key traits: 1. Problem solving 2. Project management 3. Effective communication 4. Emotional intelligence 5. Great attention to detail 6. Technical skills 7. Delegation skills 8. Time management 9. Maintain a good work/life balance 10. Provides effective feedback 11. Fosters trust 12. Motivates
All of these twelve are important, but an engineering manager’s ability to be a multiplier as a coach and mentor relies on effective communication and feedback.
Have you ever received feedback like this:
1. The feedback I received from others is that you aren’t meeting the bar (but the specifics of that feedback are left out) 2. You could be doing better (but better is left up to chance) 3. We need to see an improvement in the next few weeks (without providing specifics) 4. You are doing great! Do you have any plans for the weekend? (Where a discussion about your performance is shunted to weekend chat) 5. I don’t think you’re ready for this project, so I’m going to put this other person on it
The abstract things that bad EMs say
Indirect and abstract feedback creates a negative flywheel, downward trend, 📉 that looks something like this:
1. An engineer has a clear gap in ability where coaching could help 2. During several 1:1s an engineering manager lacks radical candor (caring about someone enough to give direct feedback) to rumble and have a direct conversation about it 3. The engineer continues to fail because this gap isn’t addressed 4. Performance reviews come and a poor rating is given with abstract and unhelpful feedback 5. The engineer doesn’t feel valued 6. The manager is asked for a ranked list of talent on their team 7. The company decides to make budget cuts and sets a 10% layoff target for low performers (likely with other qualifiers like: in a high cost location, not near an office, working on a product that isn’t returning on investment or hasn’t been delivered fast enough). 8. The engineer is caught in a layoff
The keystone here is the manager. A manager who doesn’t dare to lead will eventually find the truth, but it takes years for that truth to play out while engineers who might have contributed more to the company are let out the door.
Without any additional mentorship force, an engineer’s career will continue to fall along the same trajectory. Photo taken at Museo Galileo in Florence, Italy.
One of the clearest patterns I’ve witnessed is the “nice manager”. Someone who is extremely personable, makes friends with everyone, and is mostly optimistic about the company and people. This creates a halo effect: engineers see them as an ally, the manager is well-liked. During upward feedback surveys, direct reports tend to give glistening feedback. During calibrations this manager believes that every single person is performing above their level. Since they have a halo effect, people tend to take them at their word (another reason for checks and balances in a calibration system). Outside of this team, people question why milestones are missed and quality is poor – on their merits, the team may not be producing, but it’s challenging for that feedback loop to have any impact. This manager is “silent firing” because they never provide valuable feedback for fear of their kind image. Left undetected, correction can take years.
The second pattern is the “lack of trust” manager. This manager doesn’t believe in people from the start and limits their opportunities, but also doesn’t give them feedback to improve. For engineers that become managers, it’s hard for them to risk slowing down their project deliveries by migrating away from a known-good workhorse on the team who might have more experience in a domain. These managers “silent fire” by not coaching people who have low task relevant maturity. In a 9-box system, this expediency bias (and these others) limits the potential the manager sees in the employee.
As a manager, how can you avoid this?
Practice giving direct feedback. You can still be well-liked and give good feedback.
Listen to others around you. Model your behavior after leaders who you see giving clear feedback to others. If you can’t figure this out on your own, ask another engineer: what was the last impactful feedback you received? You rely on tools to debug memory leaks, why not rely on others as a self-improvement tool?
Fix your scaling problem. If your team is too large (more than 12 people) and doesn’t allow you to go deep in 1:1s with each person, look to hire another manager or instead of load balancing over everyone, only focus on specific people for a given week. Take notes in your 1:1s and follow-up – write-to-disk, trying to keep everything in-memory will not scale.
Debug external feedback. Did you receive feedback about someone on your team? Ask for specifics. Try to understand if it’s a pattern or a single event. Take notes for each person on your team like you’re preparing a research paper without a due date. During your next 1:1, say “hey, I received some feedback about ______ and wanted to discuss this more with you.”
Ask others for 360 feedback for each person on your team. Put it through your own filter: not all feedback is valuable or actionable. Over time, identify patterns and create an action plan to address them.
Give people on your team a chance. Start newcomers with smaller projects, test the water with longer tenured people by giving them projects outside of their comfort zone. If everyone on the team is extremely specialized, you cannot effectively pivot to new asks, and at some point not providing opportunity will undermine your potential as a manager. You ramp features in production, why not ramp your trust in people?
Check your peers. If you see that teams aren’t consistently performing because of a “nice manager” or “lack of trust” manager, give that feedback directly to that manager. Not providing this feedback prioritizes short-term gains, look to influence over the long-term to keep that team engaged and people performing well. Ignoring deprecation warnings will eventually bite you.
Engineers, what can you do?
Check yourself. Are you checked out and not contributing to the team? According to this HBR article, by checking out, you might be creating a self-fulfilling prophecy where your manager is likely to “silent fire” you. Turn on your own linter.
Apply BFS to your work network. Ask for feedback outside of your team, find a mentor where you observe admirable traits.
Improve your survey responses. In the upward feedback company survey, make it clear by selecting the lowest options available for questions that indicate you’re not receiving quality coaching. If you can, add text comments that validate this. Most company surveys are anonymous, as long as you don’t add specifics. If your manager keeps dangling carrots for “just this one more thing” to justify a promotion, you may bias towards giving a great upward review – check your own biases each time you’re asked to review your management chain.
Feedback horizon. If you’ve been on a team for about 4 months, you should have received some kind of feedback about the work you’ve been doing. At a minimum, after 6 months, a manager should be giving you feedback on your strengths and opportunities. You wouldn’t push code without a logging statement to validate your feature is working, why would you go months without instrumenting logging in your job?
⭐️ Ask for specific feedback. That presentation you gave, that document you wrote, that product you pushed to production – ask for some direct feedback on an artifact that you created. This is a good unit test – it should force your manager to give you feedback and can be a warning sign if this doesn’t occur. I added a star to this one because I think it’s the most important. If your manager can’t give you specific feedback for growth, ask them for more challenging projects or stretch goals. Think of this as pen testing – keep testing until you find a way in.
Humble brag about yourself. In public docs (like a Wiki), maintain a table of contents that link to everything you’ve worked on. Make it easy for leaders to see that canonical document so they can jump to various artifacts and give direct feedback.
The 9 Box Matrix is a tool developed by McKinsey in the 1970s to help GE prioritize investments across its business units. It evaluates the units on industry attractiveness and competitive strength. In recent years, Human Resources teams have adopted the model as a talent management tool, replacing the two industry axes with performance and potential to categorize employees and determine which to promote, retain, and invest in, and which to reallocate. The HR version of the model is not standardized and there are variations in circulation.
It can take years to find the goldilocks zone for performance
I only figured out these secrets as early as 2015, where I’m not familiar of how calibrations were performed in those orgs at the time. So while I’ll share what worked for me, this is not a checklist of things that are guaranteed to make you successful.
The shift from technical efficiency to organizational restructuring
If your company has been in contact with a consulting company like McKinsey or Deloitte in order to reduce costs (read “improve efficiency”), you can sure bet that this model is being rolled out at your company. For some companies, there may be a theme of efficiency that started around 2018 with brainstorms of how to drive down cost mostly by improving data center efficiency. In the years that followed a Chief of Staff might have came in from one of these consulting companies and changed the way you looked at cost savings, at some point the 9-box model was likely introduced.
When we began to use this for calibrations, it also came with a suggestion that only 10% of the team should be in the “Future Leader” or Box 9. The general logic is that bonus should pay people for high performance and RSUs (e.g. with a 3-year vest) should compensate potential. The “Under Performer” or Box 1 also had a similar 10% guidance that aligns with the Vitality Curve created by Jack Welsh and misused since then.
This 9-box may have worked with GE as they prioritized their investments, but doesn’t fit to calibrate engineers, specifically because potential measurement in people is different than with capital expenditure investments. This adds noise to the process.
For example, these could be used to determine potential: – “Next level” (e.g. at the levels higher than their current role) abilities and motivation – Skills and mastery – Ability to determine future target state – Thinking beyond themself – Automation – Team player – Learning – Drive
Performance likely looks at: – What they have worked on – How they have done it
You may have heard the saying “pay for performance”, but that was more like “bonus and merit increase for performance, RSU for potential”. In some organizations, merit increases were essentially taken away from managers in favor of an HR algorithm that looked at role, level, and location and gave managers a value that was typically less than 3% unless someone was being promoted, then it was less than 9%.
The baseball card process with the McKinsey 9-box
Summarize an entire year on a PowerPoint slide. Created with stable diffusion with prompt: davinci style front of sports card modern with graphs and laptop with pcb circuitboard background
Every organization is different, but some teams may be asked to pre-fill this 9 Box before calibrations.
During calibration meetings, managers presented a PowerPoint Slide that looks similar to a baseball card.
It might have sections like: 1. Box Number (e.g. Box 3 “Trusted Professional”) 2. Outcomes – things they worked on (notice I didn’t say completed work) 3. Skill dimension attributes like customer centricity, technical skill (design, quality, requirements, expertise, proficiency, efficiency), collaboration and an icon to indicate which level they performed at: developing, proficient, accomplished, and expert. 4. Basic details, like time in role (e.g. 5 months), level (e.g. E4, L5, MTS1), and date of last promotion
Shoehorn
Now we have two things: a 9-Box rubric and a PowerPoint slide for each person.
This step of shoehorning now attempts to assign each person a Box as engineering managers meet. Each manager, who doesn’t know much about other software engineers in other teams now needs to read an extreme summary of mutually exclusive information like “They worked on a database migration from Teradata to BigQuery” or “They are doing a great job as a scrum master”.
Given twelve different skill dimensions, and a baseball card summary, managers then decide how that related to being a “Core Employee” versus “Effective”. This is where much of the final decision rested on the manager’s ability to: 1. Present their case 2. Defend their case 3. Know what engineers worked on 4. Draw comparisons between other engineers
If someone is strong in their collaboration skills, but weak in their efficiency where does that put them? There are too many variables at play to be able to translate them into a single box. This is different than how GE may have used this by reviewing their portfolio of products to align on a box by compare revenue and growth estimates.
What can do you do as an employee? Humble brag about yourself, all the time, and keep a record of it. Record how significant your achievements are and make sure your manager, other managers, your skip-level, and other people know about them. Ask for a copy of the template your manager is using: fill it out for them. Use specific wording and highlight key achievements. You know the most about what you did, the goal of a calibration is for those achievements to be compared against others. Personally, I would want to control my own destiny as much as possible and over the years I’ve filled out my own promotion slides and calibration documents several times.
Rating all employees on one dimension at a time (in this example, safety) exemplifies a noise-reduction strategy we will discuss in more detail in the next chapter: structuring a complex judgment into several dimensions. Structuring is an attempt to limit the halo effect, which usually keeps the ratings of one individual on different dimensions within a small range. (Structuring, of course, works only if the ranking is done on each dimension separately, as in this example: ranking employees on an ill-defined, aggregate judgment of “work quality” would not reduce the halo effect.)
Kahneman, Daniel; Sibony, Olivier; Sunstein, Cass R.. Noise (pp. 293-294). Little, Brown and Company. Kindle Edition.
Ranking reduces both pattern noise and level noise. You are less likely to be inconsistent (and to create pattern noise) when you compare the performance of two members of your team than when you separately give each one a grade.
Kahneman, Daniel; Sibony, Olivier; Sunstein, Cass R.. Noise (p. 294). Little, Brown and Company. Kindle Edition.
How should it be done? Engineering Managers, here is my advice to you.
1. Reduce subjective skills that are assessed. Twelve different axes is too noisy. If this can be reduced to 5, then managers can provide an assessment of [Does Not Meet Expectations, Meets Expectations, Exceeds Some Expectations, Exceeds Most Expectations, Exceeds All Expectations and Beyond]. These scores should be transparent and specific for all of the 5 attributes and should be calibrated among all engineers. 2. Transparently weigh performance more heavily than potential, or remove it all together since most potential assessments in their current form are subjective. Use promotions as the time to look at potential at the next level using historical evidence, but use annual calibrations for salary/bonus/RSUs to consider performance. 3. Be more strict representing people. Move from PowerPoints to Documents with strict templates for sections, headers, length, and content. PowerPoint allows people to change font sizes, and change the sizes of sections: reduce noise by tightening the restrictions on managers. Add a total word requirement per section: Outcomes should be larger, subjective sections should be smaller. Give everyone a fixed amount of time to read the content for each person and also provide a fixed time for discussion for each person to keep calibrations efficient. 4. Look at some software engineering stats as directional, but not the only metric. Things like number of PRs opened, PR closure time, PR comments given may draw out outliers that will force a longer discussion if they are also in one of the top talent boxes. It may also force them down from the middle box if the justification is light. I have seen a few engineers where the number of commits dropped, their deploys dropped, and it triggered a discussion on productivity – as a manager, you need to be proactive here: don’t let this wait 6 months. 5. Have someone designated to check bias. “She was a rockstar and knocked everything out of the park” would likely bias others if a manager said that – and this kind of comment is subjective. A person who checks bias would stop this discussion from continuing. A less biased way to say that would be “She delivered all major milestones ahead of time with performance unlike anyone else within our team and at her level”. 6. Take notes. We would spend hours calibrating, but some managers would not keep their own notes. This creates a negative flywheel when they go back to the software engineer to discuss strength and growth areas. Feedback should be normalized during this process so that everyone receives it irrespective of their manager. This is different than promotions, where that process should, by default, collect decent feedback to folks seeking promotion. 7. Get rid of the 9-box. Come up with an anchor case, and rank engineers above or below that anchor case. Refer to rankings for each attribute as part of the calibration and determine how five different attributes will be averaged to create an overall rating. If your organization didn’t plan their budget effectively, and can’t manage the budget, and can’t be creative with solutions (okay, maybe not even creative, but humane) to avoid a layoff – use this ranked list, and a set of specific algorithms determined ahead of time, to determine where to eliminate roles. Key here: the 9-box system is noisy, especially for engineers: using this as your method for layoffs is a failure. 8. Don’t keep your performance management practices a secret. Everyone should know what specific actions are taken to determine top/mid/low performance. If you’re rating someone’s potential (don’t do this unless this can be objective), they should be getting consistent feedback on how they can increase that potential. 9. Practice, especially with new managers. Don’t do a single calibration. Create anonymized versions of each level and rating, then remove the rating and have managers rate them independently until you see a consistent final result. This has the side-effect of a more performant process as people get more task relevant maturity.
Goal Posts
Regular goal posts are immobile, so should your criteria for calibrations: Created with stable diffusion with prompt: painting of moving goal posts that are blurry
This section deserves it’s own discussion as I’ve seen this happen numerous times over my 7 years as an EM.
Research suggests that a combination of improved rating formats and training of the raters can help achieve more consistency between raters in their use of the scale. At a minimum, performance rating scales must be anchored on descriptors that are sufficiently specific to be interpreted consistently.
Kahneman, Daniel; Sibony, Olivier; Sunstein, Cass R.. Noise (p. 297). Little, Brown and Company. Kindle Edition.
Here are some examples that have come up in calibration meetings:
Not aspirational enough: Should a senior engineer who is delivering the most challenging projects, before deadlines, and helping raise everyone around them be penalized if they aren’t aspiring to be an even more senior software engineer?
Critical project: Should someone who delivered a critical project be rewarded more than someone who delivered multiple projects during the same timeframe?
Program Manager Software Engineering: Should a software engineer be rewarded for scheduling meetings with the team, and managing the backlog, but isn’t delivering any significant code?
Responsiveness: Should someone who is responsive at all hours of the day and night be rewarded when they haven’t been able to deliver a project?
Design over delivery: Should a senior engineer be rewarded for designing multiple systems and features when delivery of them has faltered?
Delayed impact: Should someone be rewarded for designing a roadmap if that is for next year and unable to be proven out until then?
All of these questions should be answered with a sufficiently specific anchor, as Kahneman points out, for each level of performance.
For example, for a Senior Software Engineer, emphasis should be on both design and delivery of their projects. Equally weighted: where if the team is not delivering quality solutions fast enough, no amount of brilliant design will improve the rating. For Junior Software Engineers, design may not be as important, but consistent and quality delivery should be.
The key point here is that these discussions should not happen when you’re already in calibration sessions. Get together as a team and make sure you talk through these cases.
If there is an HR guideline (read: forced ranking) for who can be a top/mid/low performer, each person should be ranked against each other so that logical lines can be drawn at the respective cut-off points. What you don’t want to see are last minute attempts to figure out who to move into different buckets where goal posts get added just to justify a rating change.
Rewarding
One of the fundamental questions you should ask if you leadership team is: How are bonuses/RSUs/salary increases distributed? Does the VP make the decision or delegate budget to Sr. Director, Director, or Managers? If budget is distributed all the way down to each manager (ideally in a completely fair way, split equally), you could be missing out if you’re going the extra mile.
If budget is split among managers (instead of Directors or Senior Directors), this restricts the overall bonus that top talent can receive.
$1000 split between 5 managers allows each manager to give $200 as they see fit.
Taking that same model, but allowing for the $1000 to be pooled where 80% of that is given to 5 managers ($160 to distribute instead of $200), then leaves $200 to be distributed to top talent.
As a manager, I would prefer for the money to be pooled at the Senior Director level, with a fair calibration system, so that top talent can receive a larger bonus for going above and beyond. Unfortunately, at some companies, this is left up to the organization to determine on their own, so people are rewarded differently.
9-box for people or factories
“We can’t choose our fate, but we can choose others. Be careful in knowing that.” Photo taken at Harry Potter Studio Tour in UK
Factories, like the ones General Electric used their 9-box for have physical machines and capital. Small changes to production lines, machinery, and formulas can improve performance. New equipment or future tech can improve the potential of that factory. Engineers aren’t the same as factories.
Engineers are curious learners, they can change their focus, improve systems, and deliver results. Communication is what helps engineers thrive. A failure of communication doesn’t mean engineers don’t have potential. A poor engineering manager may not create an environment where people are curious. Senior engineers may be overworked, stressed, and don’t give junior engineers something to aspire to: that doesn’t mean that junior engineer doesn’t have potential. Withholding opportunities for engineers to thrive is the fault on the potential of the leadership, not the engineer.
A manager who cannot accurately determine performance or potential introduces noise to the 9-box system. An industrial engineer assessing the performance and potential of a factory leverages a rubric with measurable criterium: you can’t say the same for performance reviews of software engineers. Don’t force-fit processes from one system to another because a consultant says it works. Don’t outsource your own brains to find the way to measure performance – if it doesn’t work at first, iterate – that’s what great engineers do.
FAQ
Why only engineers? I have the best knowledge of day-to-day engineering expectations, but I imagine a similar case could be made for Product Managers (PM), Program Managers (PgM), User Experience (UX), and Business Operations (BusOps).
If you remove the 9-box, what should be used? Only leverage your existing career ladder (for example, Square). Having two different frameworks creates overhead. As discussed in this article, slim down the amount of skills within that ladder to five or less.
