A Better Joel Test: The Developer Culture Test

I've talked with dozens of software developers about what they like and dislike about their workplace - team, and company - professionally. I'm starting to see an interesting trend in the environments that make people happy and thriving - and have them stay longer - versus ones where people feel miserable, even when they're there. I've been paying special attention to people at the same company for 4-5 years and more, who are not interested in exploring other options. What makes them tick and want to stick around? And the people desperate to move, what is pushing them away?

I'm surprised to see not much done to quantify these observations in 2020. We have the Joel test that is still attached to the Stack Overflow job listings, most job adverts claiming to have 11 or 12 out of those 12 points. But the Joel Test, written in 2000, feels too outdated and doesn't address things that are important for productive developers in the 2020s, like autonomy, code reviews, or continuous professional growth. So I took a step back and re-imagined what a test like a Joel-test would be in the 2020s: predictors of a workplace that has a great developer culture.

With this, I give you the Developer Culture Test: 3 areas with 5 questions each for a healthy organization, where developers thrive. In my experience, any tech company you'd call decent company should have the 3 basic points nailed, and cover at least 4 out of the 5 points in each area.

The Pragmatic Engineer's

Developer Culture Test

Basics: Safety, fair compensation & common-sense flexiblity.

Clarity, Autonomy and Collaboration

1. Understanding the "why"
2. Backlog / roadmap and engineers contributing to it
3. Direct communication in solving problems
4. Cross-functional collaboration
5. Celebrating taking initiatives

Sustainable Engineering Culture

1. Functionally complete != ready for production
2. Code reviews and testing
3. CI and CD or developers deploying to production
4. Healthy oncall
5. Internal open source

Career Progression

1. Technical managers who build trust
2. Career ladder
3. Parallel IC & manager tracks
4. A culture of feedback
5. Investing in professional growth

Basics

These are things that all decent companies have in place. If your company doesn't have even one of these, you're probably already looking for a new job, and you definitely have your shields down.

1. Psychological safety and a blameless culture. Do people feel safe being themselves and voicing their opinions, even if they might disagree with others? Is paying attention and acting on microaggressions and unconscious biases part of the culture? When something goes wrong, do you run a blameless process, focusing on the systemic root cause over who caused it? This can be for outages, technical issues, or failed decisions.
2. Fair compensation. Does your company pay a fair wage, that's more or less on par with the local market?
3. Common-sense flexibility on working hours. Can engineers work in a flexible way that works for their team, as well as for them? This might reasonable WFH guidelines, being flexible on short-term schedule changes and personal circumstances, focusing on the work getting done over what time people starting and end the workday.

I won't waste too much time on the first two. On the last one, common-sense flexibility, some might wonder why I'm adding it here. It's because flexible work arrangement for software engineers are everywhere. There is an explosion of remote roles, WFH is mainstream since Coronavirus and any company that's hanging on to the 9-to-5 or something similar will find themselves being a minority. And people at these places will (and should) ask why they wouldn't change somewhere else where this kind of flexibility is present.

Clarity, Autonomy and Collaboration

Companies that get this right will have innovative and autonomous people thrive. Those who don't will see these people leave over time.

1. Understanding the "why". Do you have a process in place to share the business reasons for work to be done with engineers? This could be things like roadmaps, OKRs, company- and org-wide goals and others.
2. Backlog/roadmap and engineers contributing to it. Do teams have a clear backlog/roadmap, making it easy to answer "what will we work on next, and why?" Does the top-down planning also meet a bottoms-up planning? So can engineers bring suggestions to the table, that end up on the team's roadmap - either as supporting the "why" or as part of the engineering work budget? Do reasonable tech debt payoff suggestions get prioritized this way?
3. Direct communication in solving problems. Are developers encouraged to solve problems directly by going to developers on other teams? Versus having to go through their manager, who talks with another manager, who talks with the manager of the team who talks with...
4. Cross-functional collaboration. Do developers work directly with users, designers, product managers, data scientists, and other stakeholders without going having to rely on a proxy (e.g. their manager)?
5. Celebrating people taking initiatives. Are people taking initiatives to make things better celebrated or rewarded over this seen as unnecessary distractions?

Sustainable Engineering Culture

Get this right, and developers won't burn out or get endlessly frustrated.

1. Distinguishing between functionally complete vs. ready for production. Do you differentiate between the prototype/MVP/functionally complete phase and production readiness state of code? Do you have a checklist on what additional quality bar it means for something to be production ready?
2. Code reviews and testing. Are code reviews and automated testing (unit, integration, etc) part of the everyday development process, to the extent that not having them is a rare exception, for very well understood cases?
3. CI and CD or developers deploying to production. Do you have CI process setup that runs before committing the code? After the code is committed, do you have a CD process to push it straight to production - and if not, can developers push the code they own to this environment?
4. Healthy oncall. For teams where developers are oncall, do you measure oncall health and the impact on developers? Does fixing an unhealthy oncall have priority over any product work?
5. Internal open source. Do you follow an internal open-source model, where any developer can read and contribute to any other codebase - with appropriate code ownership in place?

All of the above are baseline practices that most tech companies where developers can move fast, with stability practice and expect. Turning it the other way around: if you are missing most of this, good luck hiring people from tech companies without them quitting in their first month - or them setting out to change the culture for something similar.

Career Progression

People who are driven want to keep growing throughout their career. Does your company have a track for senior developers growing outside of moving into management, and is professional growth supported in a variety of ways?

1. Technical managers who build trust. Are most engineering managers technical - meaning have a background of having done software development at some point in their career? Do managers do regular 1:1s in a way that builds trust (e.g. listening, giving feedback, discussing career goals)?
2. Career ladder. Do you have a career ladder, with levels, and expectations at each of the level defined, and a clear promotion process on how to get to the next level?
3. Parallel IC & manager tracks. Do you have parallel IC & management career paths that run a few levels above the entry-level engineering manager role?
4. A culture of feedback. Do you have at least two of the following three: 360 performance reviews (where directs also give feedback to managers), a culture of peers giving feedback to each other and regular feedback collected, shared, and acted on by the company via company-wide or org-wide surveys.
5. Investing in professional growth. Do you have at least two of the following three: an active mentorship program with developers also mentoring other developers, professional development stipend for books/trainings, regular tech talks where people in the company learn from each other - or from outside experts.

Managers being technical is one that I've talked a lot with people. While I understand how non-technical managers can also be empathetic and great managers: they will miss both the ability to both challenge the team, as well as to protect it from unreasonable requests. They will lack the ability to effectively advocate for sustainable engineering - both to protect the team from unreasonable request and to put practices in place for good team health. Without hands-on experience on why certain practices are important, advocating for either is very difficult. They will also struggle mentor people on their team for software engineering - which is especially important for people earlier in their career.

Parallel manager and IC tracks - or the lack of - is another predictor of the engineering culture. If the only place for the best engineers to grow professionally, and impact-wise is management, this will be a grim outlook for developers who don't want to do this or are not very good at it. It also creates a culture of managers running the show, over acting as servant leaders, who are partners with developers, especially with senior ICs.

How spot on is all of this?

You might ask: Gergely, this is a nice list, but how applicable is all of the above? It's pretty applicable, based on my professional experience, and my talking with a couple dozen software developers across different regions and industries. It also mirrors how some of the most innovative and fast-moving tech companies work, from Microsoft, Google, Facebook and Uber, all the way to smaller, but successful startups, like Monzo, N26 and many others.

Though I wrote it independently, the Tech-First Culture Test also seems to echo some of the findings of the book Accelerate: The Science of Building and Scaling High Performing Technology Organizations. Thoughts on individual and team autonomy, sustainable engineering are points that come up in this book as well.

How does your current organization score on the Developer Culture Test?

(Post image by David Rangel.)

from Hacker News https://ift.tt/3eePZdE