Developer productivity surveys.

While writing Managing technical quality in a codebase, I wanted to find a good reference on running developer productivity surveys, but could only find one related article, How to survey your software developers about their tools. That’s a totally fine article, but it’s advice is much more focused on running an internal survey in general rather than running a developer productivity survey, so I decided to jot down some notes.

What is a developer productivity survey?

A survey you send out to folks writing software, plus adjacent roles, within your company. You’ll ask questions about which tools are and are not supporting their needs.

How should you do the survey?

Start simple. Use a Google Form or Surveymonkey or something like that. Don’t prematurely optimize.

When should a company do a dev prod survey?

I’ve found them most useful after a large hiring push, because new hires are the most attuned to your workflow and tooling problems. Asking the same folks the same questions is less helpful.

You also need someone who’s going to actually use the results for something.

What’s the best-case outcome?

You pick the right projects to improve the experience of being a developer at your company. Your organization gets faster and does more important work. You’re promoted and actually like the sort of work at that level, I guess?

What’s the worst-case outcome?

People ignore the survey and don’t fill it out. People feel like you’re disrespecting their time. People raise real issues and you ignore them, losing trust with the organization.

How often should you run them?

You should never send surveys out more frequently than you’re able to make significant improvements on the previously raised issues. Generally, quarterly is the maximum, but it really depends on your company size. Some companies are large enough that they can survey a small segment of the company every week rather than the entire organization every quarter. That’s a pretty nifty way to get weekly data, but you’re going to need thousands of folks to make it work well.

What are some good questions?

It really depends on what you’re trying to answer, but some ideas:

  • How would you rate our X process from 1 to 10? Where X is every common workflow at the company: test, code review, build, deploy, release, feature flagging, running experiments, reverting, incident management, on-call, debugging, and so on.
  • What tools that you’ve previously used do you find yourself missing?
  • Where do you feel like you lose time every week?
  • Are there tools or areas of our code that you avoid when possible?
  • Are these tasks or activities they feel unreasonably hard to accomplish?
  • What feels hard that you know would be easy if you were doing it yourself as a hobby project?
  • If you could wave a wand and fix anything about developing software at our company, what would you change?
  • Is there anything you’d like to say that didn’t fit elsewhere?

To find the right questions, figure out what you want to learn, and reason backwards from that.

Do you have a template we can use?

No, I do not.

Any more advice on picking questions?

Test run the questions with a few different folks who you want to reply to the survey. You’ll find a bunch of gaps in questions you should have asked along with questions that don’t make as much sense as you thought they did.

Also, try to focus on qualitative questions more than quantitative.

Should we set a goal on our survey results?

It’s easy to fall in love with the quantitative aspects of surveys, but generally speaking I’ve not found the scores to be particularly useful. Internal surveys are often filled out by so few folks that changes are not statistically significant. Folks often get bored of filling out surveys so numbers can reflect who participates more than general sentiment. Folks become accustomed to how something works over time, no longer perceiving the friction they’re existing within.

For all those reasons, I recommend against setting a direct goal on survey results. Something we experimented with at Stripe was setting a goal on how long a given item remains in your top three complaint (on the theory that going from “top three” to “not top three” correlates with quality improvement), but suffered from being too complex to explain to work well as a metric.

These results are more useful as a map than a ruler.

Can I please stop sending out these surveys?

Yes, absolutely. Using on-demand surveys to answer a particular question after a particular change can be more helpful than generic, periodic surveys. Don’t feel pressured to keep sending surveys every three months if they’re not serving a useful purpose. Internal surveys are almost guaranteeable invalid and inaccurate in the details, so don’t get caught up pursuing a facsimile of science.

Is this worth doing?

Well, I think so. I’ve never regretted doing these surveys once or twice at a given company, although I think the desire to run them frequently tends to get folks in trouble, particularly at companies with an abundance of email to work through. If you’re not sure it’s a good idea, give it a try.

Managing technical quality in a codebase.

If there's one thing that engineers, engineering managers, and technology executives are likely to agree on, it's that there's a crisis of technical quality. One diagnosis and cure is easy to identify: our engineers aren't prioritizing quality, and we need to hire better engineers or retrain the ones we have. Of course, you should feel free to replace "engineers" with "Product Managers" or "executives" if that feels more comfortable. It's a compelling narrative with a clear villain, and it conveniently shifts blame away from engineering leadership. Still, like most narratives that move accountability towards the folks with the least power, it's both unhelpful and wrong.

When you accept the premise that low technical quality results from poor decision-making, you start looking for bad judgment, and someone at the company must be the culprit. Is it the previous CTO? Is it that Staff Engineer looking at you with a nervous smile? Is it everyone? What if it's none of those folks, and stranger yet isn't even your fault either?

In most cases, low technical quality isn't a crisis; it's the expected, normal state. Engineers generally make reasonable quality decisions when they make them, and successful companies raise their quality bar over time as they scale, pivot, or shift up-market towards enterprise users. At a well-run and successful company, most of your previous technical decisions won't meet your current quality threshold. Rather than a failure, closing the gap between your current and target technical quality is a routine, essential part of effective engineering leadership.

The problem

As an engineering leadership team, your goal is to maintain an appropriate technical quality level while devoting as much energy as possible towards the core business. You must balance quality across multiple timeframes, and those timeframes generally have conflicting needs. For example, you’ll do very different work getting that critical partnership out the door for next week’s deadline versus the work you’ll do to build a platform that supports launching ten times faster next quarter.

Just as your company’s technical quality bar will shift over time, your approach to managing technical quality will evolve in tandem:

  1. fix the hot spots that are causing immediate problems
  2. adopt best practices that are known to improve quality
  3. prioritize leverage points that preserve quality as your software changes
  4. align technical vectors in how your organization changes software
  5. measure technical quality to guide deeper investment
  6. spin up a technical quality team to create systems and tools for quality
  7. run a quality program to measure, track and create accountability

As we dig into this toolkit of approaches, remember to pick the cheapest, most straightforward tool likely to work. Technical quality is a long-term game. There’s no such thing as winning, only learning and earning the chance to keep playing.

Ascending the staircase

There's a particular joy in drilling into the challenge at hand until you find a generalized problem worth solving. However, an equally important instinct is solving the current situation quickly and moving on to the next pressing issue.

As you think about the right quality improvements to make for your team and organization, it's generally most effective to start with the lightest weight solutions and only progressing towards massive solutions as earlier efforts collapse under the pressure of scale. If you can't get teams to adopt proper code linting, your attempts to roll out a comprehensive quality program are doomed. Although the latter can be more effective at scale, they're much, much harder to execute.

So, do the quick stuff first!

Even if it doesn't work, you'll learn more and more quickly from failing to roll out the easy stuff than failing to roll out the hard stuff. Then you'll get to an improved second iteration sooner. Over time you will move towards comprehensive approaches, but there's no need to rush. Don't abandon the ease, joy, and innocence of early organizations for the perils of enterprise-scale coordination without proper need.

It's convenient to present these phases are a linear staircase to be ascended, but that's rarely how real organizations use them. You're more likely to fix a quality hot spot, roll out a best practice, start running an architecture review, abolish that architecture review, and go back to hot-spotting for a bit. Premature processes add more friction than value and are quick to expose themselves as ineffective. If something isn't working, try for a bit to make it work, and then celebrate its demise.

Hot spots

When confronted by a quality problem, the first instinct is often to identify a process failure that necessarily requires a process solution. If a deployment causes an outage, it's because the author didn't correctly follow the code test process, so now we're going to require tests with every commit – that'll teach those lazy developers!

There's the old joke about Sarbannes-Oxley: it doesn't reduce risk; it just makes it clear who to blame when things go wrong. Unfortunately, that joke applies without humor to how many organizations roll out processes. Accountability has its role, but it's much more important to understand the problem at hand and try to fix it directly than to create process-driven accountability.

Process rollout requires humans to change how they work, which you shouldn't undertake lightly. Rather than reaching for process improvement, start by donning the performance engineer's mindset. Measure the problem at hand, identify where the bulk of the issue occurs, and focus on precisely that area.

The previous example of an untested deploy might benefit from giving direct feedback to the deploying engineer about changing their testing habits. Alternatively, maybe you're better served by acknowledging that your software design is error-prone and adopting the "define errors out of existence" approach described in A Philosophy of Software Design.

If you have a development velocity problem, it might be optimizing test runtimes, moving your Docker compile step onto a RAM disk, or using the techniques described in Software Design X-Rays to find the specific files to improve.

Systems thinking is the most transformative thinking technique I've encountered in my career. Still, at times it can be a siren beckoning you towards fixing a current system you may be better discarding. Sure, you can roll out a new training program to teach your team how to write better tests, but alternatively, maybe you can just delete the one test file where 98% of test failures happen. That's the unreasonable effectiveness of prioritizing hot spots, and why it should be the first technique you use to improve technical quality.

At some point, you're likely to find that your organization is creating quality problems faster than you're able to fix hot spots, and that's when it's time to move on to adopting best practices.

Best practices

I once worked at a company that didn't have a team planning process. Over time the head of engineering was increasingly frustrated with the inability to project target dates and mandated that we use Scrum. After the mandate, a manager wrote the Scrum process on a wiki. There was an announcement that we were using Scrum. Managers told their teams to use Scrum. Mission accomplished!

Of course, no one started to use Scrum. Everyone kept doing what they'd done before. It's awkward to acknowledge mistakes, so the head of engineering declared adoption a major win, and no one had the heart to say differently.

This sad tale mirrors how many companies try to roll out best practices, and it's one of the reasons why best practices have such a bad reputation. In theory, organizations would benefit from adopting best practices before fixing quality hot spots, but I recommend practices after hot spotting. Adopting best practices requires a level of organizational and leadership maturity that takes some time to develop.

When you're rolling out a new practice, remember that a good process is evolved rather than mandated. Study how other companies adopt similar practices, document your intended approach, experiment with the practice with a few engaged teams, sand down the rough edges, improve the documentation based on the challenges, and only then roll it out further. A rushed process is a failed process.

Equally important is the idea of limiting concurrent process rollouts. If you try to get teams to adopt multiple new practices simultaneously, you're fighting for their attention with yourself. It also makes it harder to attribute impact later if you're considering reverting or modifying one of the new practices. It's a bit draconian, but I've come to believe that you ought to limit yourself to a single best practice rollout at any given time. Channel all your energy towards making one practice a success rather than splitting resources across a handful.

Adopting a single new practice at a time also forces you to think carefully about which to prioritize. Selecting your next process sounds easy, but it's often unclear which best practices are genuinely best practice and which are just familiar or famous. Genuine best practice has to be supported by research, and the best source of research on this topic is Accelerate.

While all of Accelerate's recommendations are data-driven and quite good, the handful that I've found most helpful to adopt early are version control, trunk-based development, CI/CD, and production observability (including developers on-call for the systems they write), and working in small, atomic changes. There are many other practices I'd love to advocate for, who hasn't spent a career era advocating for better internal documentation, but I don't trust my intuition like I once did.

The transition from fixing hot spots to adopting best practices comes when you're overwhelmed by too many hot spots to cool. The next transition, from best practices to leverage points, comes when you find yourself wanting to adopt a new best practice before your in-progress best practice is working. Rather than increasing your best practice adoption-in-progress limit, move on to the next tool.

Leverage points

In the Hotspotting section, we talked about using the performance engineer's mindset to identify the right problems to fix. Optimization works well for the issues you already have, but it's intentionally inapplicable to the future: the worst sin of performance engineering is applying effort to unproven problems.

However, as you look at how software changes over time, there are a small handful of places where extra investment preserves quality over time, both by preventing gross quality failures and reducing the cost of future quality investments.

I call those quality leverage points, and the three most impactful points are interfaces, stateful systems, and data models.

Interfaces are contracts between systems. Effective interfaces decouple clients from the encapsulated implementation. Durable interfaces expose all the underlying essential complexity and none of the underlying accidental complexity. Delightful interfaces are Eagerly discerning, discerningly eager.

State is the hardest part of any system to change, and that resistance to change makes stateful systems another critical leverage point. State's inertia comes from its scale. From its tendency to accrete complexity on behalf of availability, reliability, and compliance properties. From having the sort of correctness described with probabilities rather than theorems. (Or in the case of distributed state, both probabilities and theorems.)

Data models are the intersection of the interfaces and state, constraining your stateful system's capabilities down to what your application considers legal. A good data model is rigid: it only exposes what it genuinely supports and prevents invalid states' expression. A good data model is tolerant of evolution over time. Effective data models are not even slightly clever.

As you identify these leverage points in your work, take the extra time to approach them deliberately. If it's an interface, integrate half a dozen clients against the mocked implementation. If it's a data model, represent half a dozen real scenarios. If it's stateful, exercise the failure modes, check the consistency behaviors, and establish performance benchmarks resembling your production scenario.

Take everything you've learned, and pull it into a technical specification document that you socialize across your team. Gather industry feedback from peers. Even after you begin implementation, listen to reality's voice and remain open to changes.

One of the hidden powers of investing in leverage points is that you don't need total organizational alignment to do it. To write a technical vision or roll out a best practice, you need that sort of buy-in, which is why I recommend starting with leverage points. However, if you've exhausted the accessible impact from leverage points, it may be time to move on to driving broader organizational alignment.

Technical vectors

Effective organizations marshall the majority of their efforts towards a shared vision. If you plot every project, every technical decision really, as a vector on a grid, the more those vectors point in the same direction, the more you’ll accomplish over time. Conversely, some of the most impressive engineers I’ve worked with created vectors with an extraordinary magnitude but a misaligned direction, and ultimately harmed their organization as they attempted to lead it.

One sure-fire solution to align technical direction is to route all related decisions to the same person with Architect somewhere in their title. This works well, but is challenging to scale, and the quality of an architect’s decisions degrade the further they get from doing real work on real code in the real process. On the other extreme, you can allow every team to make independent decisions. But an organization that allows any tool is an organization with uniformly unsupported tooling.

Your fundamental tools for aligning technical vectors are:

  • Give direct feedback. When folks run into misalignment, the first answer is often process change, but instead start with simply giving direct feedback to the individuals who you believe are misaligned. As much as they’re missing your context, you’re missing theirs, and a kind, clear conversation can often prevent years of unnecessary process.
  • Articulate your visions and strategies in a clear, helpful document. (This is a rich topic that I’ll be covering separately. TODO: Add a link to writing technical strategies section once it’s written.)
  • Encapsulate your approach in your workflows and tooling. Documentation of a clear vision is helpful, but some folks simply won’t study your document. Deliberate tools create workflows that nurture habits far better than training and documentation. For example, provisioning a new service might require going to a website that requires you to add a link to a technical spec for that service. Another approach might be blocking deploys to production if the service doesn’t have an on-call setup established, with someone currently on-call, and that individual must also have their push notifications enabled.
  • Train new team members during their onboarding. Changing folks’ habits after they’ve formed is quite challenging, which is frustrating if you’re attempting to get folks to adopt new practices. However, if you get folks pointed in the right direction when they join, then that habit-momentum will work in favor of remaining aligned.
  • Use Conway’s Law. Conway’s Law argues that organizations build software that reflects their structure. If your organization is poorly structured, this will lead to tightly coupled or tangled software. However, it’s also a force for quality if your organization’s design is an effective one.
  • Curate technology change using architecture reviews, investment strategies, and a structured process for adopting new tools. Most misalignment comes from missing context, and these are the organizational leverage points to inject context into decision-making. Many organizations start here, but it’s the last box of tools that I recommend opening. How can you provide consistent architecture reviews without an articulated vision? Why tell folks your strategy after they’ve designed something rather than in their onboarding process?

Regardless of the approaches you use to align your technical vectors, this is work that tends to happen over months and years. There’s no world where you write the vision document and the org immediately aligns behind its brilliance. Much more likely is that it gathers dust until you invest in building support.

Most companies can combine the above techniques from hot-spot fixing to vector-alignment into a successful approach for managing technical quality, and hopefully that’s the case for you. However, many find that they’re not enough and that you move towards heavier approaches. In that case, the first step is, as always, measurement.

Measure technical quality

The desire to measure in software engineering has generally outpaced our state of measurement. Accelerate identifies metrics to measure velocity which are powerful for locating process and tooling problems, but these metrics start after the code’s been merged. How do you measure your codebase’s quality such that you can identify gaps, propose a plan of action, and evaluate the impact of your efforts to improve?

There are some process measurements that correlate with effective changes. For example, you could measure the number of files changed in each pull request on the understanding that smaller pull requests are generally higher quality. You could also measure a codebase’s lines of code per file, on the assumption that very large files are generally hard to extend. These could both be quite helpful, and I’d even recommend measuring them, but I think they are at best proxy measurements for code quality.

My experience is that it is possible to usefully measure codebase quality, and it comes down to developing an extremely precise definition of quality. The more detailed you can get your definition of quality, the more useful it becomes to measure a codebase, and the more instructive it becomes to folks hoping to improve the quality of the area they’re working on. This approach is described in some detail in Building Evolutionary Architectures and Reclaim unreasonable software.

Some representative components to consider including in your quality definition:

  • What percentage of the code is statically typed?
  • How many files have associated tests?
  • What is test coverage within your codebase?
  • How narrow are the public interfaces across modules?
  • What percentage of files use the preferred HTTP library?
  • Do endpoints respond to requests within 500ms after a cold start?
  • How many functions have dangerous read-after-write behavior? Or perform unnecessary reads against the primary database instance?
  • How many endpoints perform all state mutation within a single transaction?
  • How many functions acquire low-granularity locks?
  • How many hot files exist which are changed in more than half of pull requests?

You’re welcome to disagree that some of these properties ought to exist in your codebase’s definition of quality: your definition should be specific to your codebase and your needs. The important thing is developing a precise, measurable definition. There will be disagreement in the development of that definition, and you will necessarily change the definition over time.

After you’ve developed the definition, this is an area where instrumentation can be genuinely challenging, and instrumentation is a requirement for useful metrics. Instrumentation complexity is the biggest friction for adopting these techniques in practice, but if you can push through, you unlock something pretty phenomenal: a real, dynamic quality score that you can track over time and use to create a clarity of alignment in your approach that conceptual alignment cannot.

With quality defined and instrumented, your next step is deciding between investing in a quality team or a quality program. A dedicated team is easy to coordinate and predictable in its bandwidth and is generally the easier place to start.

Technical quality team

A technical quality team is a software engineering team dedicated to creating quality in your codebase. You might call this team Developer Productivity, Developer Tools, or Product Infrastructure. In any case, the team’s goal is to create and preserve quality across your company’s software.

This is not what’s sometimes called a quality assurance team. Although both teams make investments into tests, the technical quality team has a broader remit from workflow to build to test to interface design.

When you’re bootstrapping such a team, start with a fixed team size of three to six folks. Having a small team forces you to relentlessly prioritize their roadmap on impact, and ensures you’ll maintain focus on the achievable. Over time this team will accumulate systems to maintain that require scaling investment, Jenkins clusters are a common example of this, and you’ll want to size the team as a function of the broader engineering organization. Rules of thumb are tricky here, but maybe one engineer working on developer tooling for every fifteen product engineers, and this is in addition to your infrastructure engineering investment.

It’s rare for these teams to have a product manager, generally one-or-more Staff-plus engineers and the engineering manager partner to fill that role. Sometimes they employ a Technical Program Manager, but typically that is after they cross into operating a Quality program as described in the next section.

When spinning up and operating one of these teams, some fundamentals of success are:

  1. Trust metrics over intuition. You should have a way to measure every project. Quality is a complex system, the sort of place where your intuition can easily deceive you. Similarly, as you become more senior at your company, your experience will no longer reflect most other folks’ experiences. You already know about the rough edges and get priority help if you find a new one, but most other folks don’t. Metrics keep you honest.
  2. Keep your intuition fresh. Code and process change over time and your intuition is going stale every week you’re away from building product features. Most folks find that team embedding and team rotations are the best way to keep your instincts relevant. Others monitor chat for problems, as well as a healthy schedule of 1:1 discussions with product developers. The best folks do both of those and keep their metrics dashboards handy.
  3. Listen to, and learn from, your users. There is a popular idea of “taste level,” which implies that some folks simply know what good looks like. There is a huge variance in folks who design effective quality investments, but rather than an innate skill, it usually comes from deeply understanding what your users are trying to accomplish and prioritizing that over your implementation constraints.

    Adoption and usability of your tools is much more important than raw power. A powerful tool that’s difficult to use will get a few power users, but most folks will pass it by. Slow down to get these details right. Hide all the accidental complexity. Watch an engineer try to use your tool for their first time without helping them with it. Improve the gaps. Do that ten more times! If you’re not doing user research on your tools, then you are doomed as a quality investment team.

  4. Do fewer things, but do them better. When you’re building for the entire engineering organization, anything you do well will accelerate the overall organization. Anything you do poorly, including something almost great with too many rough edges, will drag everyone down. Although it’s almost always true that doing the few most important things will contribute more than many mediocre projects, this is even more true in cases where you’re trying to roll out tools and workflows to your entire organization (the organizational process-in-progress limits still apply here!).

  5. Don’t horde impact. There’s a fundamental tension between centralized quality teams and the teams that they support. It’s often the case that there’s a globally optimal approach preferred by the centralized team which grates heavily on a subset of teams that work on atypical domains or workloads. One representative example is a company writing its backend servers in JavaScript and not allowing their machine learning engineers to use the Python ecosystem because they don’t want to support two ecosystems. Another case is a company standardized on using REST/HTTP2/JSON for all APIs where a particular team wants to use gRPC instead.

    There’s no perfect answer here, but it’s important to establish a thoughtful approach that balances the benefits of exploration against the benefits of standardization.

A successfully technical quality team using the above approaches will be unquestionably more productive than if the same number of engineers was directly doing product engineering work. Indeed, discounted developer productivity (in the spirit of discounted cash flow) is the theoretically correct way to measure such a team’s impact. Only theoretically, because such calculations are mostly an evaluation of your self-confidence.

Even if you’re quite successful, you’ll always have a backlog of high-impact work that you want to take on but don’t have the bandwidth to complete. Organizations don’t make purely rational team resourcing decisions, and you may find that you lack the bandwidth to complete important projects and likewise can’t get approval to hire additional folks onto your team.

It’s generally a good sign that your team has more available high-impact work than you can take on, because it means you’re selective on what you do. This means you shouldn’t necessarily try to grow your technical quality team if you have a backlog. However, if you find that there is critical quality work that you can’t get to, then it may be time to explore starting a quality program.

Quality program

A quality program isn’t computer code at all, but rather an initiative led by a dedicated team to maintain technical quality across an organization. A quality program takes on the broad remit of achieving the organization’s target level of software quality. These are relatively uncommon, but something similar that you’ve probably encountered is an incident program responsible for a company’s incident retrospectives and remediations.

Given this is written for an audience of senior technical leaders, let’s assume you have the technical perspective covered. Your next step is to find a Technical Program Manager who can co-lead the program and operate its mechanics. You can make considerable progress on the informational aspects of an organizational program without a Technical Program Manager; it’s a trap. You’ll be crushed by the coordination overhead of solo-driving a program in a large organization.

Operating organizational programs is a broad topic about which much has been written, but the core approach is:

  1. Identify a program sponsor. You can’t change an organization’s behavior without an empowered sponsor. Organizations behave the way they do because it’s the optimal solution to their current constraints, and you can’t shift those constraints without the advocacy of someone powerful.
  2. Generate sustainable, reproducible metrics. It’s common for folks running a program to spend four-plus hours a week maintaining their dataset by hand. This doesn’t work. Your data will have holes in it, you won’t be able to integrate your data with automation in later steps, and you’ll run out of energy to do the work to effect real change; refreshing a metrics dashboard has no inherent value.
  3. Identify program goals for every impacted team and a clear path for them to accomplish those goals. Your program has to identify specific goals for each impacted team, for example, reducing test flakiness in their tests or closing incident remediations more quickly. However, it’s essential that you provide the map to success! So many programs make a demand of teams without providing direction on how to accomplish those goals. The program owner is the subject matter expert, don’t offload your strategy to every team to independently reinvent.
  4. Build the tools and documentation to support teams towards their goals. Once you’ve identified a clear path for teams to accomplish towards your program goals, figure out how you can help them make those changes! This might be providing “golden examples” of what things ought to look like, or even better, an example pull request refactoring a challenging section of code into the new pattern. It might be providing a test script to verify the migration worked correctly. It might be auto-generated the conversion commit to test, verify, and merge without having to write it themselves. Do as much as you possibly can to avoid every team having to deeply understand the problem space you’re attempting to make progress in.
  5. Create a goal dashboard and share it widely. Once you have your program goals communicated to each team, you have to provide dashboards that help them understand their current state, their goal, and give reinforcing feedback on their (hopeful) progress along the way. The best dashboard is going to be both a scorecard for each team’s work and also provide breadcrumbs for each team on where to focus their next efforts.

    There are three distinct zoom-levels that your dashboard should support. The fully zoomed-out level helps you evaluate your program’s impact. The fully zoomed-in level helps an individual team understand their remaining work. A third level between the two helps organizational leaders hold their teams accountable (and to support your program sponsor in making concrete, specific asks to hold those leaders accountable).

  6. Send programmatic nudges for folks behind on their goals. Folks are busy. They won’t always prioritize your program’s goals. Alternatively, they might do an amazing job of making your requested improvements but backtrack later with deprecated practices. Use nudges to direct the attention of teams towards the next work they should take towards your program’s goals. Remember, attention is a scarce resource! If you waste folks times with a nudge email or ping, they won’t pay attention to the next one.
  7. Periodically review program status with your sponsor. Programs are trying to make progress on an organizational priority that doesn’t naturally align with the teams’ goals. Many teams struggle to break from their local prioritization to accomplish global priorities. This is where it’s essential to review your overall progress with your sponsor and point them towards the teams that prioritize program work. Effectively leveraging your sponsor to bridge misaligned prioritization will be essential to your success.

In a lot of ways, a program is just an endless migration, and the techniques that apply to migrations work for programs as well.

If you get all of those steps right, you’re running a genuinely great program. This might feel like a lot of work, and wow, it is: a lot of programs go wrong. The three leading causes of failed programs are:

  1. running it purely from a process perspective and becoming detached from how the reality of what you’re trying to accomplish,
  2. running it purely from a technical perspective and thinking that you can skip the essential steps of advocating for your goal and listening to the folks you’re trying to motivate,
  3. trying to cover both perspectives as a single person–don’t go it alone!

A bad program is a lot like an inefficient non-profit: the goal is right, but few funds reach the intended goal. No matter how you decide to measure technical quality, the most important thing to always remember when running your quality program is that the program isn’t the goal. The goal is creating technical quality. Organizational programs are massive and build so much momentum that inertia propels them forward long after they’ve stopped working. Keep your program lean enough to cancel, and remain self-critical enough to cancel it ceases driving quality creation.

Start small and add slowly

When you realize your actual technical quality has fallen considerably behind your target technical quality, the natural first reaction is to panic and start rolling out a vast array of techniques and solutions. Dumping all your ingredients into the pot, inevitably, doesn’t work well, and worse, you don’t even know which parts to keep.

If you find yourself struggling with technical quality–and we all do, frequently–then start with something small, and iterate on it until it works. Then add another technique, iterate on that too. Slowly build towards something that genuinely works, even if it means weathering accusations of not moving fast enough. When it comes to complex systems and interdependencies, moving quickly is just optics, it’s moving slowly that gets the job done.

Neural Networks Create a Disturbing Record of Natural History in AI-Generated Illustrations by Sofia Crespo

All images © Sofia Crespo, shared with permission

Sofia Crespo describes her work as the “natural history book that never was.” The Berlin-based artist uses artificial neural networks to generate illustrations that at first glance, resemble Louis Renard’s 18th Century renderings or the exotic specimens of Albertus Seba’s compendium. Upon closer inspection, though, the colorful renderings reveal unsettling combinations: two fish are conjoined with a shared fin, flower petals appear feather-like, and a study of butterflies features insects with missing wings and bizarrely formed bodies.

Titled Artificial Natural History, the ongoing project merges the desire to categorize organisms with “the very renaissance project of humanism,” Crespo says, forming a distorted series of creatures with imagined features that require a new set of biological classifications. “The specimens of the artificial natural history both celebrate and play with the seemingly endless diversity of the natural world, one that we still have very limited comprehension and awareness of,” she writes.

Crespo manufactured a similar project, Neural Zoo, that combines disparate elements of nature into composite organisms. “Our visual cortex recognizes the textures, but the brain is simultaneously aware that those elements don’t belong to any arrangement of reality that it has access to,” she says. More generally, Crespo explains her motivation behind merging artificial neural networks and natural history:

Computer vision and machine learning could offer a bridge between us and a speculative “natures” that can only be accessed through high levels of parallel computation. Starting from the level of our known reality, we could ultimately be digitizing cognitive processes and utilizing them to feed new inputs into the biological world, which feeds back into a cycle. Routines in artificial neural networks become a tool for creation, one that allows for new experiences of the familiar. Can art be reduced to the remapping of data absorbed through sensory processes?

Head to Crespo’s site to explore more of her AI-produced studies, and follow her latest pieces on Instagram.

 

We love because we care

Here is a collection of posts from artist Amy Meissner — one of my favorite follows on Instagram —  advertising a mending and clothes repair workshop she helped run in Anchorage, Alaska, before the pandemic. They all have the same caption: “Mend a thing.”

Here’s something she said about the workshops that has stuck with me:

Once you’ve mended something, if you didn’t have sentimental value attached to it before, then you certainly do once you’ve taken the time to care for it.

CARE FOR SOMETHING” is the last lesson in my friend Rob Walker’s wonderful book, The Art of Noticing.

He explained in his newsletter:

[O]ne of my favorite responses to a willfully open-ended prompt I give my students — I order them to “practice paying attention” — came from a student who thought he did it wrong. He had made a planter, he explained, for a cactus. He’d done this, he said, on the theory that “by nurturing or caring for something, you pay more attention to it.” And of course he was right! (See also this recent Times Magazine essay making a similar point: “How Taking Care of Houseplants Taught Me to Take Care of Myself.”)

I will try to connect Amy and Rob’s thoughts with a snippet from Keep Going:

“Attention is the most basic form of love,” wrote John Tarrant. When you pay attention to your life, it not only provides you with the material for your art, it also helps you fall in love with your life.

So, while we often think of love as leading to care, care can also lead us to love.

I feel this most deeply with my kids. I’m closest to them when I’m giving them my full, undistracted attention and care. I feel the least love for them when I’m trying to get something else done, or I’m wishing I was elsewhere. (There must be a connection here to John Cage’s formula: If we ignore noise, it disturbs us. When we listen to noise, we find it fascinating.)

In her book, The Gardener and the Carpenter, Alison Gopnik advocates for the abandoning of the word “parenting” as a verb, and encourages readers to think of being a parent as a relationship that runs on love, instead of a job that runs on work. “Love doesn’t have goals or benchmarks of blueprints,” she writes, “but it does have a purpose.” The purpose of loving children is to care for them as a gardener would tend to plants, creating the conditions under which they will thrive.

This caring, she says, changes us, and deepens our love. “We don’t care for children because we love them,” she writes, “we love them because we care for them.”

This sentence has profound implications for parents and caregivers of all kinds. (Including children caring for aging parents.) I’m not even sure if the sentence is true, but I want it to be, and if it isn’t true, it is a useful fiction, because it encourages us to do the verb, first — not to wait on the deep feeling before we care, but to care first, and if the feeling comes it comes, but if it doesn’t, at least we’ve cared.

Gary Snyder once said he didn’t think talking about “doom scenarios” were very effective when it comes to changing people’s behavior.  “The first step, I think… is to make us love the world rather than to make us fear for the end of the world. Make us love the world… and then begin to take better care of it.” I’m thinking of this now, and wondering if the first step is to perform an act of care — to mend, to repair, to darn, to sew, to patch, to heal — and then the love will come.

Or maybe it’s not directional at all, but an endless cycle:

The Definitive Guide to Dawn Patrol

There’s never a wrong time to head out the door. But if you’re serious about scoring the best conditions, enjoying a peaceful sunrise, or just fitting more adventure into life’s busy schedule, you’re going to need to master the art of dawn patrol (or at least give it a try). Besides, tackling a trail run or backcountry ski before breakfast sets a great tone for the day. Not a morning person? That’s OK. These top athletes have tricks to get even the sleepiest out of bed for an outing you won’t regret.

Plan Ahead

Nobody gets up at 5 a.m. on a whim. You’ve got to make a plan. Set an alarm, have an idea of where you’re headed, and organize your essentials before bed. “I prepare the night before, setting out my clothes, charging my headlamp, grinding my coffee, so I’m not looking around too much in the morning,” says Joe Grant, an ultrarunner from Durango, Colorado. His most essential item? The Wind Hood GridTech Gloves. “I use them to keep the chill off on early-morning runs, and I can easily stow them in the pockets of my shorts if it gets too warm,” he says. “They’re an ideal dawn-patrol piece.”

Have a Morning Routine

Turn on music, stretch, drink coffee—whatever you need to get going. Give yourself enough time so it doesn’t feel rushed. “I used to give myself 30 minutes to get out the door, but that felt like a whirlwind,” says Mary McIntyre, a ski mountaineer and photographer from Salt Lake City, Utah. “Now I take 45 minutes for coffee and a little breakfast, check the avalanche report, and I’m out the door.”

Know Before You Go

If you’re heading into avalanche territory, triple-check your safety kit before you head out and make sure you’re familiar with all of it. “At the beginning of every season, I’ll do some practice with my avalanche safety gear, with friends or by myself,” says McIntyre. “I’ll practice pulling everything out of my pack and see how quickly I can assemble my shovel and probe.” She uses the Black Diamond Guide BT Avalanche Beacon, which is very user-friendly for how advanced it is, and the Transfer 3 Shovel and Quickdraw Tour Probe 320—“they’re sturdy and strong and can handle a big, deep snowpack.”

Set a Date with a Friend 

If you have an agreement to meet someone early in the morning, you’re likely to stick to it. “Backcountry skiing, you need a partner anyway, but having a friend also helps with accountability,” McIntyre says. “Don’t be late. When I was getting into dawn patrolling, a friend told me, ‘Waiting for a friend for ten minutes at 5 a.m. feels like waiting an hour later in the day.’”

Make It Fun

You want to make the outing feel like an adventure, not an obligation; otherwise you’ll be more tempted to hit snooze. “Make whatever you’re going out to do feel approachable and fun, so it’s compelling enough to get out of bed,” Grant says. “Maybe that means running a new trail or running your favorite loop in reverse.”

Watch Your Step

Grant’s go-to headlamp is the Sprint 225, Black Diamond’s smallest and lightest rechargeable light, which is plenty bright for even the darkest mornings. And to get a grip on slippery trails midwinter, he uses Black Diamond’s Distance Spike Traction Device. “I make sure those things are right next to my shoes, by the door, so I don’t forget them,” he says. 

Keep Your Expectations Light

The predawn hours may not be the time for personal records or uncharted routes. Come up with a mellow plan and be willing to adapt if you’re not feeling it. “The fact that you’re getting up is already a win. Don’t put too many other pressures on it,” Grant says. “If the workout isn’t your best, you still made those steps.” A lightweight ski, like the Helio Carbon 115, makes each step a bit more effortless. “You’re often trying to squeeze in one run before work, so you might be hustling,” says  McIntyre. “When you have less weight on your feet, going uphill faster becomes easier.”

It’s All About the Post-Mission Breakfast

If you need to, eat something small to energize you before you head out—a piece of toast, a banana—or pack a bar for the skin track or trail. But keep it light, because the best part of dawn patrol is treating yourself to a breakfast burrito and coffee on your way in to work afterward. “I love stopping at a good bakery for a pastry when I’m done with dawn patrol,” McIntyre says. 


Black Diamond’s heritage goes back to 1957, when we started selling hand forged climbing gear from the trunk of a car in Yosemite Valley. Six decades later, we are still committed to designing and engineering the most innovative mountain equipment in the world.

I Missed Bars. So I Built One in My Own Backyard.

One day in May, feeling bored and bummed out by the pandemic, I launched into a home-improvement project that I hoped might ease my unease: building a bar.

Bars are good places for bad times—or at least they used to be, before they were canceled along with everything else. My last public drink was consumed on March 6: a Bud Light at the Hogs and Heifers Saloon in Las Vegas, possibly the least socially distanced place on earth, where the all-female staff wear Daisy Duke shorts and dance on the bar top. I was in town for the Mint 400, the desert off-road race immortalized by Hunter S. Thompson in Fear and Loathing in Las Vegas, and Hogs and Heifers was hosting an event for teams and sponsors. Across the counter, a bartender held a bottle of vodka in one hand and a megaphone in the other, which she aimed where I sat on a stool a few feet away, blaring: “You going to do a shot, or what?”

I miss bars. Less the rowdy ones, where it feels like a fight is going to break out at any moment, than the quiet local establishments where you can talk to the person next to you. Such places have long been woven into the writing life. In the nineties, when I was in grad school at the University of Montana, no one in the writing program would take you seriously until you’d made at least one trip—and better yet, many—to the now closed Milltown Union Bar, which was located a few miles east of Missoula and was the legendary haunt of the school’s late poet laureate, Richard Hugo. The wood-paneled watering hole was known for its blue-collar clientele and quirky decor, like the goat and sheep heads mounted on the wall and encased in clear plastic. “You need never leave,” Hugo wrote about the joint in one of his most famous poems. “Money or a story brings you booze.”

When I’m not writing, I like to build things. Construction is therapeutic in many ways: the hard labor, the feel of wood and metal, the cuts and calluses, the heft and roar of power tools. In Santa Fe, where I’ve lived for more than 20 years, I’ve renovated three old houses—“dumpitos,” a realtor friend called them—in a historic neighborhood. The most recent, in 2015, was a 900-square-foot adobe cottage that I dubbed the CrackShack, because I’d purchased it from a notorious local drug dealer who inherited the place along with his five siblings and couldn’t quite handle maintaining it. 

My latest project emerged from piles of scavenged lumber that had been left around the property—an unfinished two-bedroom adobe on three acres in the Santa Fe foothills—by the previous owner, an artist and anarchist who was also something of a hoarder. But one person’s junk is another person’s building-supply store, and soon I was sawing and hammering away, becoming the latest participant in a long tradition of bros creating backyard dream spots. I figured I’d be done by five. 

At one point, my girlfriend and the property’s co-owner, Madeleine, who goes by the nickname Maddawg, walked up and assessed the progress with folded arms. I’d hoped she would approve of my rustic addition to our home. I was in luck.

“Wow,” she said. “I’m impressed. When do we start drinking?”

“Soon!” I said, optimistically.

Cholla Bar (Photo: Madeleine Carey)

A week later, I’d constructed a ten-by-six-foot L-shaped structure, bracketed by three posts crowned with old wood corbels—decorative supports—that I found in the junk pile. I finished the counter using four one-by-eight fir planks that I sanded and sealed with two coats of marine-grade spar varnish and then buffed to a glossy shine. When I started, the wood looked gray and sad, but after it absorbed the polyurethane, the color deepened into a rich caramel, bringing the structure to life.

I splurged on a dremel ($60) to make a sign, the only money I spent except for the purchase of a few six-inch lag screws to secure the posts. The dremel, a rotary power tool used for grinding and engraving, was awkward to handle, like drawing with a dentist’s drill, and it took me a few practice attempts on some scrap before I wrote, in my best looping cursive: Cholla Bar. I hung the sign from two hooks twisted into a crosspiece above the bar counter.

Cholla (pronounced “choy-yah”) are shrubby cacti common to New Mexico. Undisturbed, they can reach eight feet tall. Until I moved to the foothills, where they grow in abundance, I’d never really taken notice of them. But they soon became some of my favorite flora. In early summer, bright-purple flowers burst joyfully from the ends of their tentacles. When chollas die, they leave behind twisted honeycomb-like skeletons that are nearly as haunting and beautiful as the living plant.

Another bonus about construction projects: they’re a great workout. Gyms around Santa Fe were closed, and the idea of doing burpees in my living room made my eyes cross. So I kicked it old-school: working shirtless and alone in the searing New Mexico sun, dredged in a fine coat of sweat and sawdust, my shoulders turning a startling crimson. I imagined that I looked like Brad Pitt in Fight Club, until I saw the pictures Maddawg took on her phone. Alas, my Brad bod was more like a dad bod.

No matter; I wasn’t doing it for the ’gram. I was doing it because I hoped a cool al fresco space might lure friends to hang out. I had barely seen another human for months, and those were mostly fellow face-masked shoppers on furtive grocery missions. Every excursion from my home was a new kind of masquerade ball, where the guests were afraid to get too close, or even make eye contact, as if an errant glance might blast you with COVID-19. The tension and anxiety were palpable. I thought we could really use one big, collective drink, maybe a toast to human connection, in real life.

It worked! I strung up decorative lights, some friends showed up, and we sat around in a carefully spaced circle drinking blueberry-basil margaritas. (Don’t @ me; they are good, and they will flatten you.) One pal brought two whole chickens from his home smoker, and we shredded the tender meat, added coleslaw, and piled everything between slider buns. Someone else made guacamole that we shoveled into our faces with tortilla chips. We swapped stories of the old days, when people gathered in large groups, without a single piece of PPE, to listen to concerts, watch sports, or frolic on a beach.

Was our gathering safe? There are always risks, of course, but in this situation they seemed pretty low. Was it necessary? An emphatic yes. After my friends went home, I lingered in a lounge chair, staring at the Milky Way, which arced brightly above the Cholla Bar, and pondered the Big Questions: What if Trump gets reelected? Was the pandemic a kind of cosmic reckoning for years of profligate and uncharitable behavior? How much had I had to drink?

By the end of June, many bars around the country reopened—and then promptly closed again, in the wake of surging infections. In Florida, you could go to a bar, but you couldn’t buy a drink. In Texas, angry citizens descended on the state capitol, brandishing ill-advised signage: “Bar Lives Matter.” Was drinking a right or a privilege? It wasn’t clear. What was clear is that bars were dangerous grounds for COVID-19 transmission.

“Bars,” remarked Anthony Fauci, the embattled infectious-disease expert, during an interview on CNN. “Really not good.”

As July crackled away, the understanding that our grim new reality wasn’t going to change anytime soon took on renewed weight. An older woman in my neighborhood was verbally assaulted for not wearing her mask correctly while walking her dog, and she felt threatened enough to call the police. Entire industries—retail, restaurant, and travel among them—were imploding. Parents were frayed, strung out, and staring at the prospect of home-based school indefinitely. Kids were going stir-crazy. And still it appeared that things would get worse before they got better. In mid-July, Robert Redfield, the director of the Centers for Disease Control and Prevention, said that the impending fall and winter could be “one of the most difficult times that we have experienced in American public health.” Zoiks. I was going to need cases of tequila.

A week or so later, I sat outside in a chair by the Cholla Bar on a cool morning, reviewing my handiwork and trying hard not to doomscroll on my phone. A vicious heat wave had finally broken with the arrival of an afternoon monsoon pattern. I sipped coffee, enjoying the birdsong and blue sky, and admiring a silver-lace vine that had coiled around a nearby bentwood fence and frosted over with tiny white flowers. “Nature, man,” I Lebowskied.

That morning brought the first whiff of changing seasons. I knew I’d need to put a roof over the bar by fall, to protect it from the rough weather ahead. Where we live, at 7,500 feet, conditions can get intense. I found some paper and sketched out a crude design—shed style, a simple two-by-four frame, with a top layer of corrugated tin. If I started now, I was sure I could be done by five.

I Feel You, Julie Nolke

The third time-traveling installment.

The other two have been posted here before, but in case you missed them, here they are, and in reverse chronological order:

Looking forward to/vaguely dreading what I assume will be the final installment, sometime in December.

— JS

Why Endurance Athletes Feel Less Pain

While researching a book on endurance a few years ago, I interviewed a German scientist named Wolfgang Freund who had recently completed a study on the pain tolerance of ultra-endurance runners. Subjects in the study had to hold their hands in ice water for as long as possible. The non-athlete control group lasted an average of 96 seconds before giving up; every single one of the runners, in contrast, made it to the three-minute safety cut-off, at which point they rated the pain as a mere 6 out of 10 on average.

The results were consistent with previous research showing that athletes can tolerate more pain than non-athletes. But not all sports impose the same demands, Freund pointed out: “Maradona, at least, had the illusion that a brilliant soccer player didn’t need to suffer.” As a runner myself, I liked the implication that endurance athletes are uniquely tough, so I happily included that quote in my book. But is it really true?

As it happens, researchers at Norway’s University of Tromsø tackled exactly that question, along with several other interesting ones, in a recent study in Frontiers in Psychology. They compared 17 national-level soccer players with 15 elite endurance athletes (cross-country skiers and runners, also “competing at the highest national level in Norway”) and 39 non-athlete controls in three pain tests. They also administered a series of psychological questionnaires to explore what traits are associated with greater pain tolerance.

The first pain test was the same one used in Freund’s study: dunking the hand in barely-above-freezing water for as long as possible (again with a three-minute cut-off, though the subjects weren’t told about it in advance). On average, the endurance athletes lasted 179.67 seconds (meaning virtually all of them made it to three minutes, with the exception of one person who stopped five seconds early). The control group averaged 116.78 seconds, and the brilliant soccer players just 113.90 seconds.

This was exactly what the researchers expected. After all, embracing open-ended discomfort is exactly what endurance athletes do every day in training, so it makes sense that they have a high pain tolerance. But pain threshold—the point at which a sensation goes from unpleasant to painful—might be different. Soccer players, like other team sport athletes, experience briefer spikes of pain associated with “short bouts of supramaximal intensity and receiving blows from opponents or the ball,” the researchers point out. As a result, they hypothesized that the experience of this more intense pain would give soccer players a higher pain threshold than endurance athletes.

To test pain threshold, they applied a heated aluminum thermode to the inner forearm of the subjects, starting at 90 degrees Fahrenheit and slowly increasing to a maximum of 126 degrees. The subjects had to press a button when the sensation changed from warmth to pain, and this process was repeated five times. This time, contrary to their hypothesis, the soccer players and endurance athletes were essentially the same, at 117.7 and 118.2 degrees, and both were significantly higher than the non-athletes at 115.8 degrees. (Those numbers are from the first test; when the test was repeated a second time, the numbers were slightly higher but the pattern was the same.)

The third test looked at yet another aspect of pain response, pain sensitivity. While pain is fundamentally a subjective experience, pain sensitivity tries to quantify how intensely you feel a given stimulus. It’s obviously related to both threshold and tolerance, but it’s not identical: one person might feel pain very intensely but nonetheless be willing to tolerate it for longer than someone else who feels it less intensely. To measure sensitivity, the temperature of the heated thermode was ramped up to 117.5 degrees for 30 seconds, and participants had to rate their pain on a scale of 0 to 100. The researchers expected no difference between the soccer players and the endurance athletes. Instead, the average pain scores for the first test were 45.5 out of 100 for the endurance athletes, 51.9 for the soccer players, and 59.4 for the non-athletes. In the second test, the scores were 37.9, 45.4, and 53.7. The differences aren’t statistically significant, but there’s a pretty suggestive trend.

There are two big questions here. One is why the three groups have different perceptions of pain; the other is whether the athletes were born with these differences, or whether they acquired them as a result of their training. The most widely held view is that the big differences are psychological, as opposed to some sort of physiological dulling of pain sensors. In this study, the researchers assessed the subjects’ “Big Five” psychological traits (openness, conscientiousness, extraversion, agreeableness, and neuroticism), and gave separate questionnaires to assess grit and fear of pain.

The results are a little convoluted, given that there are seven psychological traits, three groups, and three pain perception outcomes. Both grit and conscientiousness had a bit of predictive power on some outcomes, which isn’t surprising since some critics argue that grit is basically just a fancy repackaging of the older concept of conscientiousness. The one psychological characteristic that predicted all three outcomes was fear of pain, which makes sense. But there were no statistically significant differences between the three groups in their average fear of pain scores, though the endurance group seemed to have slightly better (i.e. less fearful) scores. That means it can’t be the main reason the three groups scored differently on the pain tests.

As for the second question on nature versus nurture, this study can’t answer it. There have been some hints in previous studies that pain tolerance is a trainable trait, and that endurance training is one way of enhancing it. On the other hand, I’d be surprised if there isn’t some element of athletes being “chosen by their sport” in part based on pre-existing psychological attributes like willingness to suffer. The new study adds fear of pain to the list of relevant psychological attributes, alongside others from previous research like tendency to catastrophize (bad) and ability to ignore negative feelings (good).

It seems to me that we’re unlikely to find one neat mental trick that distinguishes pain gluttons from pain avoiders. Instead, successful athletes likely have an array of different mental tactics for dealing with different types of discomfort in different contexts. Teasing out the best strategies is a great topic for future research. But to be honest, it’s all a digression from the main point I wanted to emphasize from this paper—which is that Wolfgang Freund was right.


For more Sweat Science, join me on Twitter and Facebook, sign up for the email newsletter, and check out my book Endure: Mind, Body, and the Curiously Elastic Limits of Human Performance.

Finding the right company to reach Staff Engineer.

Note: this is an article for staffeng.com, written for an audience of folks on cusp of reaching a Staff Engineer role.

There are only a few magic spells to attain a Staff-plus role: negotiate for the title while switching roles or find a supportive environment to “bake in place” while building your internal credibility with an empowered sponsor who’ll advocate for you. The most important reagent in both spells is picking the right company to perform them at.

The good news if you’re applying to a new company is that while you might invest weeks of energy into determining if you can get a Staff role there, you won’t need to invest years. On the other hand, if you’re looking for a company to join and grow within, you’re embarking on a years-long journey into an unknown organization. This is a daunting decision to make, and picking the right company for you will have a considerable impact on whether you attain a Staff-plus role.

Disproportionately values you

If career velocity is your aim, then join a company that, for whatever reason, disproportionately values what you’re good at. For example, Fastly valued Keavy’s API design experience, and Stripe valued Dmitry’s work on compilers. If there’s a gap matching your particular shape that’s limiting their success, your impact on the company will be uniquely high.

Well run organizations value you for what you’re good at. Less well run companies value you for your identity, for example a culture that views aggression as leadership would indeed promote and center the most aggressive folks, but to their culture’s and team’s detriment. Sometimes you’ll find a company that nets you values you appropriately because it values your incidentals without valuing your contributions that you consider to be valuable; that seems like it’ll work out, but generally speaking it’s a recipe for frustration.

Meritocrats and Proceduralists

When you’re trying to identify your company to make the Staff transition, there are a number of company values to consider in your decision. One that’s particularly important is understanding if the company’s leadership fundamentally subscribes to an exception-heavy “meritocratic” view of the world or a consistency-heavy “proceduralist” view. Few companies exist exclusively at one end of this continuum, but most slant heavily in one direction.

Of course, folks won’t describe themselves in these terms. The first style would have called themselves a meritocracy a few years ago. Now that the term has fallen out of favor they’d avoid it, but their core beliefs remain intact. This style is particularly common in Silicon Valley, is heavily exception driven, and consolidates its efforts feting a small cadre of treasured individuals. Generally, in these companies, you’re going to be very successful if you pattern match with whatever they believe high potential looks like. You’re like in for a rough ride if you don’t.

Another style of company you’ll find out there, believes that consistency drives fairness. They’re the sort that work the policy rather than the exceptions: they design the clock, set it in motion, watch it tick, and make occasional repairs. These companies tend to be more structure-driven and less intuition-driven, which can create wider access to opportunity for more folks, but they can also be rigid bureaucracy whose look on smugly while their machinery grinds an individual down.

Inevitably, both meritocrats and proceduralists view their world-view as a moral position, and depending on who you are and who the company’s leadership is, you’ll have a radically different experience.

Some ways to explore during your interview process to help distinguish these mindsets:

  • Companies with rigid compensation bands and who actually stick to them tend to be run by Proceduralists. Those that willing eskew their bands are Meritocrats.
  • Companies that create one-off roles for individuals to get them onboard tend to be run by Meritocrats. Those that hire to their planned roles are Proceduralists.
  • Companies with ad-hoc or unstructured interview processes looking to get your “feel”, particularly for senior roles, tend to be run by Meritocrats. More structure means Proceduralists.
  • Companies that perform ad-hoc conjurations of new, rubric-less interviews tend to be run by Meritocrats. Those that evaluate you rigidly, even if it doesn’t let you shine, tend to be Proceduralists.

Neither meritocratic nor proceduralistic companies have inherently better odds of propelling you into a Staff-plus role, rather it’ll depend on your identity, and the identities of folks in a company’s leadership roles. Depending on how those pieces align, you can estimate the level of support and friction you’ll encounter pursuing a Staff-plus rol.

Archetypes

Most companies only hire one or two of the Staff archetypes, even though they all use the same titles to describe the role they’re hiring for. If you’re trying to figure out a given company’s preferences, it’s most effective to reach out to some of their existing Staff-plus engineers and get a sense of the work they do. Most companies don’t deliberately think about the sort of Staff engineers they support, so asking directly rarely works as well as it should.

Sufficiently large companies end up with at least some folks operating in each of the archetypes, but it takes a long time until that’s the case, usually after their engineering organization has scaled to thousands of engineers.

Growth

If you’ve exclusively worked at fast growing, successful startups then it might not cross your mind that there can be a lack of room for additional folks operating in Staff-plus engineering roles, but it’s surprisingly common for slower growing companies to simply not have the work or the budget for more folks in leadership roles. This is also a common constraint for companies that haven’t reached product-market fit–there’s limited leadership slots when a company needs to remain highly aligned while changing frequently–with potential exceptions for those that happen to be selling a developer-centric or technical infrastructure product of some sort.

If you join a fast-growing company, new Staff opportunities will organically open up. In slower growing companies, you may need to wait for someone to vacate their current role before another becomes available. That’s not to say that you should necessarily join a fast-growing company if you don’t want to–they’re often stressful and run on perpetually out-of-date processes–just another factor to consider.

Sponsorship

Getting a Staff-plus offer at a new company requires someone inside that company who believes in you and is willing to push through a fair amount of organizational friction to get you the title. Getting promoted to Staff-plus requires a manager and management chain who believe in you, and their willingness to push through even more friction to get you the title. Without an empowered leader within a company who’s willing to invest their organizational capital on you, you can’t get a leadership role.

When looking for a company to pursue a Staff-plus role at, a big part of the equation is identifying a company where you’ll have an effective sponsor. Interviewing outside of your current company is often effective at finding you a sponsor: your would-be hiring manager tends to have well-aligned incentives to extend you a Staff offer. Equally important, your time investment is high but still relatively low compared to working at a company for two years to realize you’re never going to reach your goal.

The easiest sponsors to find are folks who you’ve worked with before. The flying wedge pattern of one senior leader joining a company and then bringing on their previous coworkers is a well-known and justifiably-despised pattern that relies on this built-in referrer-as-sponsor, but it doesn’t have to be toxic if done sparingly.

This is also where having an external presence and network can greatly aid your search. Folks who’ve seen your presentations, read your blog posts, or nodded in agreement at your tweets are more likely to become your proactive sponsor in the interview process and later during promotion discussions.

Durability

Particularly if you’re earlier in your career and pursuing a promotion into a Staff role, it’s important to consider the company’s durability: will the company even exist five years from now when you’re hoping your work will culminate in a Staff-plus promotion?

Somewhat more subtly, you also have to consider the longevity of your would-be Staff sponsor. There are some wonderful engineering leaders creating pockets of equitable access to Staff-plus roles, but all too often these turn into a Values Oasis that can’t sustain itself once the sponsoring leader departs the company or changes roles.

Derisk durability by ensuring you join companies with business models that actually work, and work for leaders who are values-aligned with their organization’s senior-most leadership (that way, even if they leave, you’re still aligned with potential sponsors).

Pace

Throughout a forty year career, there are times when you’re rested and looking for a challenging, enveloping role. There are going to be other times when you’re drained and worn out. You will harm yourself by accepting a role that demands more pace from you than you’re able to presently sustain. When taking on a technical leadership role it’s particularly important to make sure that the company’s pace expectations align with what you’re able to provide, because you’ll be evaluated in part on being a role model for the company’s pace.

And everything else, too

Job searches for leadership roles are much slower than the typical software search, taking months rather than weeks, and it’s trying to rush it rarely works out. As you evaluate a company about where it’s an effective place to reach a Staff-plus role, you also have to evaluate it for everything else that you’d evaluate in a typical process.

Dig into your whisper network for toxic issues and individuals. Make sure the mission is something you can stay supportive of and engaged with for years. Search for the folks you’ll be able to learn from during your work. If you find that these Staff criteria are pulling you towards a company that you otherwise have concerns about, the good money is that you’ll regret that decision.

Todd Rundgren & Rivers Cuomo Made A Ska Song Together

Todd-Rundgren-Down-With-The-ShipThe veteran studio-pop wizard Todd Rundgren has a lot of wacky ideas. Historically speaking, he has usually been able to pull those ideas off. I don't know about this one, though. Rundgren is getting ready to release a new album called Space Force. One track features Weezer frontman Rivers Cuomo, and it's a damn ska … More »

Lift Your Skinny Fists Like Antennas To Heaven Turns 20

Godspeed-You-Black-Emperor-Lift-Your-Skinny-Fists-Like-Antennas-To-HeavenThere comes a point in a young man's life when he simply cannot watch any more experimental black-and-white short films from Canada. One night in August of 2000, the mysterious Montreal band Godspeed You! Black Emperor came to play at New York's Knitting Factory, a club that was already much too small for this band. More »

Family follow-up Rivals brings you more lovely musical detection

A screenshot of the investigation board in Rivals, including a poster for a launch party for a music label called Bad Mole and an invite to a school prom, with music by a band called Pony Parade

Only a month ago I wrote about Family, a free investigation game about plotting the movements of musicians across a (fictionalised) ’80s London music scene. By placing the right people in the right bands at the right times, you’re drip fed more clues so you can then place more names, and so on.

Well, turns out that was just warming us up. Meet Rivals, broadly the same thing but longer, tougher, and about tracing 20 years in the careers of two school friends who formed a high school band and then almost immediately broke it up to do their own separate bands.

(more…)

Deciding to switch companies.

Note: this is an article for staffeng.com, written for an audience of folks on cusp of reaching a Staff Engineer role.

My father was a professor of economics. After he completed his PhD in his late twenties, he started teaching at one university, got tenure at that university, and walked out forty-some years later into retirement. Working in technology, that sounds like a fairytale.

There are very few software companies with a forty-year track record, and even fewer folks whose forty-year career consisted of one employer. There used to be a meme that many engineers spent either one or four years at each company to maximize their equity grants and then bounced on to the next. If that ever happened, it certainly isn’t common behavior for folks who aspire towards or reach Staff-plus roles.

Instead, generally those folks stay, and are rewarded for staying, at a given company as long as the circumstances support their success. If those circumstances change, they tend to either leave shortly thereafter or spend a while burning out and then leave after exhausting their emotional reservoir.

It takes years to build the visibility and social credibility to get promoted from a Senior Engineer role to a Staff-plus role, which makes it very difficult to walk away if you feel like you’re just one hump away from the promotion. Leaving, it can feel like, means starting over from scratch.

Then again, as described by Duretti Hirpa and Keavy McMinn, it’s common for folks to attain their first Staff-plus title by joining a new company. Even with all your internal credibility, sometimes leaving is the most effective path forward.

What’s the right decision for you?


Before going further, I want to recognize two very different job-switching experiences: one of privileged flexibility and another of rigid constraints. Your residency might depend on a work-sponsored visa. You might be supporting an extended family. You might be constrained to a geographical area with few employers. This advice focuses on the former circumstances, which are more common circumstances for someone who’s deep enough into a technology career to pursue a Staff role. You should absolutely discount it to the extent this doesn’t reflect your circumstances.

Why leaving works

The company that knows your strengths the best is your current company, and they are the company most likely to give you a Staff-plus role. However, actually awarding the role depends on so many circumstantial concerns, that this isn’t how it works out in practice.

If your current team is very senior, it may be hard to justify your impact at the Staff engineer level because it’s being attributed to your peers. Your manager might have a limited budget that doesn’t have room for another Staff engineer. You might lack an internal sponsor. There simply might not be the need for an additional Staff engineer at your company. Any of these can mean that while you ought to be promoted, your current company won’t.

Conversely, when you interview for new roles, you can simply keep interviewing until you find a company that’s able to grant the title. The interview process often brings an automatic sponsor with it – the hiring manager – whose incentives will never be more aligned with yours than in the interview process.

The technical interviews are an inconsistent and unreliable predictor of success, which is bad for the industry and bad for companies, but works in your favor if you’re set on attaining a Staff-plus role and are willing to conduct a broad search. Interviewing creates the opportunity to play “bias arbitrage,” finding a company that values your particular brand of bullshit disproportionately. That might be a company that values folks with conference speaking visibility, your experience designing APIs, or your PhD thesis on compilers.

Similarly, sometimes you’ll get into a rut at a company where your reputation is preventing forward progress. Perhaps you’ve tagged “difficult” after flagging inclusion issues. Maybe you embarrassed an influential Director at lunch and they’re blocking your promotion. A new company lets you leave that baggage behind.


Yeah, of course, it’s always an open question whether you can really leave anything behind you in the tech industry. It can feel a bit cliquey at times. If you’ve worked in tech hubs, at larger companies, and for more than ten years, then you almost certainly have mutual connections with the folks interviewing you.

If you have a bad run at a company, maybe your manager was a bully or maybe you were going through a challenging period in your own life, it can feel like a cloud poisoning your future prospects. That said, much like the interview process in general, references and backchannel reference checks are deeply random. If you need any further evidence of that, look to the serial harassers who continue to get hired job after job at prominent companies.

Things to try before leaving

If you’re planning to leave due to lack of interest, excitement, support or opportunity, it’s worthwhile to at least explore the internal waters first. This lets you carry your internal network with you while still getting many of the advantages of switching companies. Depending on your company’s size and growth rate this might not be an option for you, but there are some folks who switch roles every two-to-three years within the same parent company, and find that an effective way to remain engaged and learning.

On the other hand, if you’re considering leaving due to burnout or exhaustion, it’s sometimes possible to negotiate a paid or unpaid sabbatical where you can take a few months recharging yourself, often in conjunction with switching internal roles. This is more common at larger companies. (In case you were wondering, no your coworkers taking parental leave is not “on sabbatical” or “on vacation.”)

Leaving without a job

Speaking of burnout, if you’re particularly burned out, it’s worth considering leaving your job without another job lined up. There’s a fairly simple checklist to determine if this is a good option for you:

  • Does your visa support this?
  • Are you financially secure for at least a year without working?
  • Do you work in a high-density job market, remotely, or are you flexible on where your next job is?
  • Do you interview well?
  • Could you articulate a coherent narrative to someone asking you why you left without a job lined up?
  • Are there folks at your previous company who can provide positive references?

If all of those are true, then I don’t know anyone who regrets taking a sabbatical. However, bear in mind that it’s only the folks who took six-month-plus sabbaticals who felt reborn by the experience. Folks taking shorter stints have appreciated them but often come back only partially restored.

Taking the plunge

If you’re almost at the Staff promotion in your current company, there is absolutely another company out there who will give you the Staff title. Whether or not you’ll enjoy working there or be supported after getting there, that’s a lot harder to predetermine. If your internal reputation is damaged or if you’ve been repeatedly on the cusp of promotion but victim to a moving criteria line, then you should seriously consider switching roles if the title is important to you – at some point you have to hear what your current company is telling you.

Conversely, if you’re happy in your current role outside of the title, consider if you can be more intentional about pursuing your promotion rather than leaving. Many folks hit a rut in their promotion path to Staff-plus, and using techniques like the promotion packet can help you get unstuck. If you’ve used all the approaches, taken your self-development seriously, and still can’t get there – it’s probably time to change.

That said, it’s easy to overthink these things. Few folks tell their decade-past story of staying at or leaving some job.

Mmm, noodles

Buttery pasta, peppery vermicelli, masala sevai—noodles come in many shapes and sizes. They can provide comfort, nostalgia and a sense of belonging. This collection of personal essays, guides, recipes and deep dives serves as a little bit of a 'food hug' with everything that has gone on in 2020.
KQED explores noodles.

Individual essays:

David Attenborough: A Life on Our Planet

Now streaming on Netflix, David Attenborough: A Life on Our Planet, a documentary about the 94-year-old broadcaster, naturalist, and international treasure.

In this unique feature documentary, titled David Attenborough: A Life On Our Planet, the celebrated naturalist reflects upon both the defining moments of his lifetime and the devastating changes he has seen. Coming to Netflix October 4 2020, the film addresses some of the biggest challenges facing life on our planet, providing a snapshot of global nature loss in a single lifetime. With it comes a powerful message of hope for future generations as Attenborough reveals the solutions to help save our planet from disaster.

In the trailer (embedded above), Attenborough says “I had the most extraordinary life. It’s only now that I appreciate how extraordinary.” In saying that, he’s speaking not only as a living legend whose long career in television and science has brought him nearly universal acclaim, but also as someone who can look back and see how recognizably and thoroughly the Earth has changed during his lifetime. The depletion of animal populations, the changing climate, the shifting habitats — he’s witnessed firsthand how much humans have fucked up the planet. We should listen to his testimony and suggestions for fixing what he calls “our greatest mistake”. I hope it’s not too late.

Tags: David Attenborough   David Attenborough: A Life on Our Planet   Earth   movies   Netflix   science   TV   video

Kid A Turns 20

Kid ASitting across his desk from Thom Yorke last fall onstage at the Ed Sullivan Theater, Stephen Colbert posed a question to the Radiohead frontman. "For decades you've been writing music that is uneasy and anxious with regards to society, our government, technology, the general direction of the world," the Late Show host said. "How does … More »

Peanuts, remixed

It’s the 70th birthday to Charles Schulz’s Peanuts, one of the greatest works of American art. (The very first strip ran on Oct. 2, 1950.) In celebration, I thought I’d post a batch of my remixed Peanuts strips I make in my diary, which are made from cut-up Page-A-Day calendars I buy every year. Be forewarned: They’re pretty weird. 

Links to four zines worth of them: 

See also: “Cutting and pasting the comics

David Lynch Gives a Lesson in Sound Design

David Lynch is relieving his lockdown boredom by posting videos. He gives weather reports (nothing new for him), baffles fans with what he’s working on, and declares a daily magic number. If only I could get a couple of hundred YouTube views from pulling numbers out of a jar.

In addition to documenting these quaint activities, Lynch’s team is also posting a series of short films under the David Lynch Theater series. I don’t think many, if any, of these are new, but most are new to me.

So far, my favorite is the deceptively simple one-shot video, The Spider and the Bee. The mini-movie consists of a close-up shot of an unfortunate bee caught in a web as a spider enacts its fate. There’s no semblance of Hollywood production here, and it’s a solid guess we’re looking at an undusted window sill in Lynch’s house. It’s Lynch, not Attenborough, after all.

The scene lasts for eight minutes, a challenging length for a real-time display of a struggling insect. But I found the video transfixing, my attention aided by the remarkable sound design. Evocative use of sound is a Lynch trademark, dating back to the hisses, hums, and whirrs found in the Eraserhead score. Sound is dramatically and innovatively used to accent images and nestle implications through Lynch’s entire oeuvre, right to the recent Twin Peaks series. If you pay attention to final credits, you’ll notice Lynch is always partly or solely responsible for the sound design on his projects. And The Spider and the Bee is an experiment in sound design.

With only natural sound (or no sound at all), the video’s nothing special, a ‘circle of life’ home movie shot on a lazy day. Add the sound — the bee’s hapless buzzing, the spider’s cartoonish clicking, the swoops as the spider slides — and the story becomes compelling. The viewer is brought into this, too, as the camera thunders as it quickly changes angles. I jumped out of my seat the first time that happened.

Sound is an effective contextualizer, and inventive sound design, even when subtle, can transform a visual storyline into something heightened and unreal. It’s a fun trick played on our brains.

Bonus points: check out the documentary Making Waves: The Art of Cinematic Sound.

The post David Lynch Gives a Lesson in Sound Design appeared first on 8Sided Blog.

On Call Shouldn’t Suck: A Guide For Managers

There are few engineering topics that provoke as much heated commentary as oncall. Everybody has a strong opinion. So let me say straight up that there are few if any absolutes when it comes to doing this well; context is everything. What’s appropriate for a startup may not suit a larger team. Rules are made to be broken.

That said, I do have some feelings on the matter. Especially when it comes to the compact between engineering and management. Which is simply this:

It is engineering’s responsibility to be on call and own their code. It is management’s responsibility to make sure that on call does not suck. This is a handshake, it goes both ways, and if you do not hold up your end they should quit and leave you.

As for engineers who write code for 24×7 highly available services, it is a core part of their job is to support those services in production. (There are plenty of software jobs that do not involve building highly available services, for those who are offended by this.) Tossing it off to ops after tests pass is nothing but a thinly veiled form of engineering classism, and you can’t build high-performing systems by breaking up your feedback loops this way.

Someone needs to be responsible for your services in the off-hours. This cannot be an afterthought; it should play a prominent role in your hiring, team structure, and compensation decisions from the very start. These are decisions that define who you are and what you value as a team.

Some advice on how to organize your on call efforts, in no particular order.

  • It is easier to keep yourself from falling into an operational pit of doom than it is to claw your way out of one. Make good operational hygiene a priority from the start. Value good, clean, high-level abstractions that allow you to delegate large swaths of your infrastructure and operational burden to third parties who can do it better than you — serverless, AWS, *aaS, etc. Don’t fall into the trap of disrespecting operations engineering labor, it’s the only thing that can save you.
     
  • Invest in good release and deploy tooling. Make this part of your engineering roadmap, not something you find in the couch cushions. Get code into production within minutes after merging, and watch how many of your nightmares melt away or never happen.
     
  • Invest in good instrumentation and observability. Impress upon your engineers that their job is not done when tests pass; it is not done until they have watched users using their code in production. Promote an ownership mentality over the full software life cycle. This is how dev.to did it.
     
  • Construct your feedback loops thoughtfully. Try to alert the person who made the broken change directly. Never send an alert to someone who isn’t fully equipped and empowered to fix it.
     
  • When an engineer is on call, they are not responsible for normal project work — period. That time is sacred and devoted to fixing things, building tooling, and creating guard-rails to protect people from themselves. If nothing is on fire, the engineer can take the opportunity to fix whatever has been annoying them. Allow for plenty of agency and following one’s curiosity, wherever it may lead, and it will be a special treat.
     
  • Closely track how often your team gets alerted. Take ANY out-of-hours-alert seriously, and prioritize the work to fix it. Night time pages are heart attacks, not diabetes.
     
  • Consider joining the on call rotation yourself! If nothing else, generously pinch hit and be an eager and enthusiastic backup on the regular.
     
  • Reliability work and technical debt are not secondary to product work. Budget them into your roadmap, right alongside your features and fixes. Don’t plan so tightly that you have no flex for the unexpected. Don’t be afraid to push back on product and don’t neglect to sell it to your own bosses. People’s lives are in your hands; this is what you get paid to do.
     
  • Consider making after-hours on call fully-elective. Why not? What is keeping you from it? Fix those things. This is how Intercom did it.
     
  • Depending on your stage and available resources, consider compensating for it. This doesn’t have to be cash, it could be a Friday off the week after every on call rotation. The more established and funded a company you are, the more likely you should do this in order to surface the right incentives up the org chart.
     
  • Once you’ve dug yourself out of firefighting mode, invest in SLOs (Service Level Objectives). SLOs and observability are the mature way to get out of reactive mode and plan your engineering work based on tradeoffs and user impact.
     

I believe it is thoroughly possible to construct an on call rotation that is 100% opt-in, a badge of pride and accomplishment, something that brings meaning and mastery to people’s engineering roles and ties them emotionally to their users. I believe that being on call is something that you can genuinely look forward to.

But every single company is a unique complex sociotechnical snowflake. Flipping the script on whether on call is a burden or a blessing will require a unique solution, crafted to meet your specific needs and drawing on your specific history. It will require tinkering. It will take maintenance.

Above all: ✨RAISE YOUR STANDARDS✨ for what you expect from yourselves. Your greatest enemy is how easily you accept the status quo, and then make up excuses for why it is necessarily this way. You can do better. I know you can.

There is lots and lots of prior art out there when it comes to making on call work for you, and you should research it deeply. Watch some talks, read some pieces, talk to some people. But then you’ll have to strike out on your own and try something. Cargo-culting someone else’s solution is always the wrong answer.

Any asshole can write some code; owning and tending complex systems for the long run is the hard part. How you choose to shoulder this burden will be a deep reflection of your values and who you are as a team.

And if your on call experience is mandatory and severely life-impacting, and if you don’t take this dead seriously and fix it ASAP? I hope your team will leave you, and go find a place that truly values their time and sleep.

 

Anti-Social Recording Artists

I’m thinking about what Darren Hemmings had to say in a recent Motive Unknown newsletter. It’s not a secret that I’m no fan of social media (esp. Zuckbook). You might not know that I’m presently doing a lot of research into how a label or artist can effectively promote music without social media. I’m convinced it’s possible, but not without a fair amount of legwork and reconsidering music marketing traditions. So it was with great interest to see Darren, who runs a marketing consultancy representing the likes of Run The Jewels and Moby, state the following:

… there may be quite a fundamental shift starting here – albeit in very, very early form. It strikes me that some artists are increasingly tiring of existing on other people’s platforms where their relationship to fans is always compromised. Instead, platforms like Bandcamp and community hubs like Discord allow them to sell directly and build a home for those fans that is not subject to algorithmic control over who see their message. They are tiring of social media and tiring of other platforms controlling who they can reach. […] Where I think this could get interesting is when we see the first artists really break through with little support or presence across both DSPs and social media in general. I think many would see that as an impossible notion right now, but to my mind that is something that may happen sooner than we all realise.

I agree. And I would love for some of these breakout ‘first artists’ to be emerging rather than established (I mean, if Bruce Springsteen decided to do a Bandcamp-only release, it would obviously do well).

I also think the anti-platform sentiment that’s loudly brewing isn’t only about lack of direct fan access. There are also political concerns, especially among a younger crop of tuned-in artists. In Spotify’s case, there are problems with the platform’s unsupportive moves against musicians. And issues with Facebook (which, remember, owns Instagram) are so plentiful that the platform’s contributions to things like, uh, genocide are now old news. 

It isn’t easy to find optimism right now, but I’m optimistic about this. Artists and labels are starting to take control. They’re learning that the tools exist, for the first time in history, to reach new levels of independence (and interdependence). You know that thing I like to say: It’s the punk rock dream come true … if you want it.

The post Anti-Social Recording Artists appeared first on 8Sided Blog.

Being visible.

Bert Fan’s best advice for those trying to reach a Staff-plus role was,

often reaching Staff is a combination of luck, timing, and work.

Timing is a particular sort of luck, so in some ways you can simplify this even further down to just luck and work.

If you’re fortunate, then you won’t have to pursue a deliberate path to a Staff-plus role.. You’re already working on your company’s top priorities, have a well-positioned manager who cares about supporting your career, and are working from your company’s headquarters office. If you’re starting with none of those things, getting promoted is going to be quite a challenge, but don’t count yourself out: it’s easy to underestimate your own role in getting lucky.

One of the most effective ways to get luckier is to be more visible within your organization. There are of course very quick, very negative ways to increase your visibility, so I’ll refine the statement a bit. Your goal is to be known for good things while minimizing the organizational bandwidth you consume to do so.

Why visibility matters

Katie Sylor-Miller describes visibility as a key piece of getting promoted to Staff,

Something I haven’t talked about enough is communication and transparency. A big part of being promoted to Staff is making sure that your work is visible, that people know your name and you have a good reputation.

Staff-plus roles are leadership roles, and by recognizing you with such a role the company is bringing you into its leadership team. The existing members of that team want to be comfortable that they’re expanding their ranks with folks they believe in, and they can’t believe in you if they don’t know you.

If you’re operating without much visibility within your company, this may likely come across as cliquey or gatekeeping behavior. Conversely, if you are well-known internally, this may feel like the necessary cost for maintaining a consistent set of expectations and criteria for folks taking on leadership roles – how could you maintain consistency if you are unfamiliar with their work?


It’s interesting to briefly reflect on how inclusive organizations mitigate the negative gatekeeping aspects of validating folks are appropriate additions to your leadership team. The answer is that they design mechanisms to ensure the full swath of potential leaders get exposure to the folks who will evaluate them for leadership roles. Conversely, less inclusive organizations inadvertently center access on folks who most aggressively self-advertise.

Internal visibility

The single best way to create internal visibility is to work on the things that matter to your company and company leadership. This path is also the most aligned with how a well-managed company will evaluate your contribution.

Sometimes that isn’t enough though, and some other strategies are:

  • Write more long-lived documents, like architecture docs or technical specifications.
  • Lead (and to a less extent, participate in) company forums like architecture reviews, company all hands, and learning circles.
  • Be a cheerleader for your team’s and peers’ work on Slack.
  • You can also cheerlead via email instead of Slack.
  • Share weekly notes of your work to your team and stakeholders, in a way that other folks can get access to your notes if they’re interested.
  • Contribute to your company’s blog.
  • Attend, or potentially even host, office hours for your team or org.

Find the right mix of activities that leverage your strengths, aren’t already overburdened with volume, and feel authentic to you. If you’ve never done much communication of your work, it may feel awkward to self-promote your work. You never want to wholly lose that sense of awkwardness–restraint helps–but you will have to get comfortable with some of it.

External visibility

It’s helpful to complement your internal visibility work with external visibility work. There are a huge number of successful Staff-plus engineers with no external presence, but many find external visibility contributes to their career.

Compared to an exclusively internal focus, one advantage of building an external presence is that there’s a lot more room to create a niche and name for yourself. Internal efforts often end up competing for attention with your peers in a way that external efforts simply don’t.

In terms of how to create this sort of visibility for yourself and your work, it could be writing a blog post like Silvia Botros, giving a conference talk like Keavy McMinn or Dan Na, going on a podcast like Michelle Bu, turning a problem into a website and book like Katie Sylor-Miller’s ohshitgit, or creating a mailing list like Pat Kua’s Level Up.

Should you focus on visibility?

You can always have more visibility within your organization, but at some point increasing your visibility is likely reducing the opportunities for others to create visibility for themselves. Internal visibility is not strictly zero-sum, but it’s constrained by the attention of the folks you want to see your work.

My advice would be to use the promotion packet exercise to identify if lack of visibility is likely to hold you back in the promotion process. If so, work to clear that threshold, but not much further. Visibility is a transient currency, learning and developing yourself is a permanent one; focus on the later once you’ve done the minimum to clear the former’s cliff.

TechWriters community.

In part "stuck away from friends due to pandemic" inspired, I've been wishing there was a tech writing community for semi-serious writers. As an experiment, I'm trying to spin up a Discord server to create such a community.

Read a bit more about the project at techwriters.dev.

My hope is this will become a healthy, positive place to talk about creating tech and tech-adjacent, particularly for folks who do it semi-seriously: frequently bloggers, book authors, public speakers and so on. Creating this sort of community is hard work, and not something I've done before, so I imagine it'll be a bit of a learning curve, and excited to add a few more administrators if there are folks with that experience who'd be interested in participating.

Alright, a few frequently asked questions.

Should I join?

Sure, if you're interested you should join. I'm not really sure what "semi-serious writer" or "semi-serious" content creator means, so if you think you'd enjoy being part of a creative community then you should definitely join.

Why Discord rather than Slack?

To be honest, I've never used Discord before, but a few folks mentioned it as preferable to Slack and figured it would be good to give it a try.

Why not join an existing community instead?

I reached out to a handful of folks and none had found a particularly good fit in an existing Slack or Discord, so decided to try spinning one up. It's totally possible there's already a great existing community that'll emerge from the woodwork and it'll make more sense to fold this effort into that preexisting one.

Can I be an admin?

Maybe! If you're empathetic, kind and engaged then send a note to techwriters-dev@googlegroups.com and we'll see what we can do.

2020 - you're having a laugh

2020 has not been the best year in which to see live comedy. The anarchic atmosphere, audience feedback and off the cuff retorts are difficult to reproduce in an online stream. Some comedians have realised this and decided not to attempt it, instead working out new ways to create interactive comedy online. Sean Morley currently runs a crowd sourced 'Meme Machine' on Wednesdays and a fully democratised attempt to make the pope a bear in Crusader Kings II on Saturdays. Foxdog Studios have tried live interactive bolt sorting, and now perform live coding in 'Make a website in an hour' on Thursdays and tidying up a room in 'Sorting out the Banished Realm'. Jain Edwards is doing computer puzzles while drinking tombola wine.

There is also a supergroup including all of the above and Jack Evans which came together to deliver a new interactive platform for comedy which puts three random audience members into a kind of choose your own adventure situation within a virtual comedy arena. It is hard to explain.

You can watch all of King Morl (make the pope a bear) on Youtube. Apparently some people have actually done that, currently over 30 hours. To be fair, I am one of them, but I watched it on Twitch.

This is all pretty mellow/slow comedy, a bit like having friends around for a chilled out chat and a board game, or something. It has certainly been a very welcome escape from the global pandemic for me.

If you have any positive new comedy that you can share, that would be lovely!

Damian Schenkelman - Principal Engineer at Auth0

August, 2020 blog, twitter, linkedin

Tell us a little about your current role: where do you work, your title and generally the sort of work do you and your team do.

I'm a Principal Engineer at Auth0, an Identity as a Service platform. I work in the Systems Architecture group, which today has three Principal Engineers. We work with different teams on strategic initiatives and also shape Auth0's technical strategy, architecture decisions, and guidelines.

At the time of writing, I am working with a group of Identity and Access Management (IAM) teams as a tech lead of a large new product feature, as well as driving reliability and scaling related initiatives with other teams.

What does a “normal” Staff-plus engineer do at your company? Does your role look that way or does it differ?

Within Engineering, we are organized in domains (today Identity & Access Management, Developer Experience, Service Management, and Platform). Auth0's Staff Engineers are people that can technically lead teams within a domain. A Staff Engineer would typically be part of a single team in a domain, while also being able to actively contribute to initiatives across the scope of a domain.

Principal is the next level in our ladder. Principal Engineers can either be in a specific team (depth) or work with multiple teams and their scope spans the entire organization (breadth). Today I am operating in "breadth mode". This means both working on specific initiatives and also the definition of technical strategy, technology choices for our Platform, and leading the Design and Architecture workgroup (a.k.a. DNA).

DNA has 6 members (3 permanent Principal, and 3 Staff/Senior II that rotate every 6 months). The workgroup defines decisions and guidelines to help drive Auth0's technology in a specific direction (e.g. avoid language proliferation so we can build libs once and people can switch teams easily) and also collaborate with teams in technical reviews of large initiatives.

The biggest way in which my role differs, because I have been at the company for 6+ years, 3+ of those as a Director of Engineering, is that I have the "broadest scope". I work with both Product and Platform teams on initiatives and also work often with other parts of the company: joining conversations with high profile prospects, working with our legal team on contract language, or collaborating with Marketing.

How do you spend your time day-to-day?

This varies a lot :). A typical week involves a lot of meetings, so I am trying a new thing: grouping meetings on Mondays, Wednesdays, and Fridays. Thursdays are completely blocked, and Tuesdays are only for urgent matters. Because we are remote all meetings are over Zoom.

On meeting days I have recurrent:

  • 1:1s: to catch up with my manager (VP of Engineering), or a team manager or tech lead. Those conversations are great to stay up to date with them and know their challenges. I feel being too detached from that would impact my ability to get things done effectively.
  • team meetings: Engineering leadership, Design & Architecture workgroup.

Non-recurrent meetings also take place. Some example topics might be:

  • specific initiatives I am tech leading
  • helping a group of teams figure out how to get something started
  • doing a sync design review

On Thursdays (and as much of I can on Tuesdays) I spend my time thinking about:

  • current initiatives and how they are going
  • what we could/should be doing in the future (next quarter, next year)
  • writing docs, guidelines, blog posts
  • (not often) doing POCs and/or writing small tools

Where do you feel most impactful as a Staff-plus Engineer? A specific story would be grand.

The biggest impact comes from being able to help achieve "people scale", positively influencing the work of as many people as possible internally. The book Scaling Up Excellence provides an easy to understand analogy: scaling is a ground war, not a one-off airstrike. It requires a lot of time, and patience but to get to your goals you need to align the whole company in terms of goals and how to get to them.

As a Principal Engineer, I try to find opportunities/gaps that I believe will set a direction for as many people as possible in the long term. There's a lot more value to align the ~200 people we have in our Product Delivery organization around a certain topic than to code a solution for a problem myself. The former has more impact, it scales better.

Can you think of anything you’ve done as a Staff-plus engineer that you weren’t able to or wouldn’t have done before reaching that title?

Before becoming a Principal I was a Director of Engineering at Auth0. The most interesting thing is that as a Principal Engineer people get a lot less defensive when I provide feedback and they seem a lot more open in 1:1s. I think it might be related to the fact that as a Principal Engineer you are not "representing a part of the organization".

In that regard, being an individual contributor feels a lot better.

Do you spend time advocating for technology, practice, process or architectural change? What’s something you’ve advocated for? Can you share a story of influencing your organization?

A common problem for fast-growing companies is that there's usually some "lack of clarity". In our case, there was a lot of confusion about what was coming in the future and that made us slow and inefficient in making technological decisions. Teams were uncertain if they should be using a particular technology because they didn’t know if that technology would be supported in the future, they were uncertain if they should be building a particular product in a certain way because they didn’t know if that approach was aligned with our long-term technical strategy, etc. Naturally, this caused a lot of inefficiencies.

We believed we needed a long-term direction that explained how to approach the technical implementation of problems today and how to bridge the gap between our initial situation and the future vision. More precisely, we needed a documented technical strategy that would detail what we should and shouldn’t be doing to be successful in the long run.

After talking to a great number of people I learned that all of them have been exposed to inconsistent information, and rumors, which made them afraid of making decisions, e.g.: "I heard the company is going for X in the future" or "I heard this particular technology Y is not going to be supported by our platform teams". A lot of confusion was caused by a particular rumor that we were going to support a certain customer need and its technical implications. People kept hearing about it, but concrete plans were never announced. I wrote down these issues, connecting all the dots and aiming to translate that information into knowledge. I realized we needed both short and long term ways of solving the problem.

Short term: We had to fill the gap of uncertainty relating to some more urgent and short-term matters. Teams needed to make technical decisions and couldn't wait for a full-fledged technical vision and roadmap. We also realized that once we had that long term vision and decisions, there would naturally be the need to review decisions for specific exceptions. I put together the "design and architecture" (DNA) group, which also wrote guidelines and recommendations, including "approved" technology choices, to guide teams towards independent decisions that don't require review, and also established an RFC review process.

Long term: I came up with a set of topics that I believed the company needed to make decisions about. I tailored my presentations to suit two different audiences -- executive and technical. For the executive audience, I developed a succinct presentation, applying non-technical analogies and explanations, and providing actionable solutions. The technical presentation was much more detailed and included many technical terms. I used nemawashi (an informal process of quietly laying the foundation for some proposed change or project, by talking to the people concerned, gathering support and feedback, and so forth) and shared with my VP of Engineering, other execs, my peers, and other senior leaders through to get buy-in before formally making a decision. More specifically, I approached people asking them for their thoughts and opinions securing the buy-in, so that by the time we met to discuss our decisions, it wouldn't be the first time they were seeing the ideas. We finally met, discussed tradeoffs, and arrived at a set of decisions. All decisions were documented in a decision log and we committed specific owners -- in writing -- to carry them forward.

How do you keep in touch with how things really work as you spend less time on hands-on development?

There are two aspects of this, keeping up with technology in general and keeping up with what goes on at Auth0 and the current "state of affairs" in Engineering teams.

These are the things I do to keep in touch with things related to Auth0:

  • Internally: keep an ear to the ground both through Slack and having 1:1s with some tech leads and Engineering Managers. This helps me understand what challenges they are having first hand, and also find patterns or arrive at global solutions instead of local ones.
  • Externally: talk with customers/prospects to see how they use the product, read tweets and news, etc.d mentioning Auth0 and the identity space.

I don't feel I am "keeping in touch" as much as I'd like technology-wise, but I do try to :). So many new important new things are happening in our industry every month that it is hard to keep up. Accepting the fact that meetings and not being hands-on means that I will likely be less in touch than I'd like with things is important. Once I accepted that I could start prioritizing what was valuable.

I read books, carve out time to do some POCs or read blogs/papers about specific topics, and ask to lead specific initiatives to stay up to date with how we are developing even if I don't code that often.

How have you sponsored other engineers? Is sponsoring other engineers an important aspect of your role?

Yes, a lot! I am a member of our Engineering Leadership team. We meet twice a week to discuss topics around the organization. This, together with keeping an ear to the ground, and being part of meetings about mid-term plans helps me know about (and sometimes propose) opportunities that might be available ahead.

Whenever that happens I typically propose the names of people that I believe would benefit from that opportunity, explain why I think they would be good at it, and, if helpful, offer to mentor them in case there are any perceived skill gaps.

You first got the title Principal Engineer at Auth0. Were you hired as a Principal Engineer? If not, what was the process of getting promoted to Principal?

My story here is a particular one. I started at Auth0 in May 2014 as the fifth engineer, ~tenth employee. There were no titles, no ladder, nothing like that. Around 2015, I started mentoring and doing 1:1s with a couple of new hires. Towards the end of 2015, I was working on my initiatives, and also leading others, helping with hiring, etc. Late 2015 Matias Woloski, Auth0's CTO and co-founder, was looking for someone to lead Engineering teams and he asked me if I would be a Director of Engineering.

I've been privileged enough to be able to approach my career in a way that maximizes learning and opportunities for hard problem-solving. That's the main principle that helps me make decisions. When he offered me, a 25 year old living in Argentina, the opportunity to lead the Engineering organization for a "Silicon Valley", remote-first company that was growing exponentially I naturally said "yes". I had never thought "I want to manage", it just happened because I wanted to learn and solve hard problems.

Things worked out great. I learned a lot about building teams, organizations, leading people, etc. Because I was one of the first engineers, had built a lot of the systems and I enjoyed technical conversations I also did a lot of technical leadership in that role, both with Product and Platform/Infrastructure teams. Towards early 2019 as a Director of Platform, I started thinking that I was not learning as fast as before and that I wanted a broader scope than just working on our platform. After many conversations with Christian McCarrick, Auth0's VP of Engineering at the time, I realized that the challenge I wanted to take up next would be being one of Auth0's (a 🦄 by now) technical leaders. I transitioned to Principal Engineer in August 2019.

What two or three factors were most important in you reaching Principal? How have the companies you joined, your location, or your education impacted your path?

A quote I love from Seneca is "Luck is what happens when preparation meets opportunity.". Getting to Principal required getting some things right, but also a lot of luck. I want to call out some of the key factors that got me to Principal and also show how luck played a part in them.

First job

In Argentina it's common to start working while you are in University. When I finished high school I found a job at a fantastic company called Southworks. The two key things about that place were that:

  • the company worked on projects with cutting edge technologies, which gave me lots of opportunities to hone my learning skills
  • the company worked mainly as a Microsoft US vendor remotely, which meant that not only technical skills were valued, but also we got to practice communication, expectation management, and other interpersonal skills often.

The reason I could work in software right out of high school was that when I was 11 I started telling my mom I wanted to "build video games" and my parents found and paid for a high school that taught programming.

How luck played a part: I was about to take a job at another company when a friend of mine from high school told me her brother worked at Southworks and they were looking to hire junior people. He did a good job selling the company to me and I decided to put the other opportunity on hold to see if I could get into Southworks.

Auth0

I was one of the first engineers at Auth0 and over the years I worked on many parts of its product and infrastructure, which makes it easy for me to help people and provide valuable input on various topics. Being a Director of Engineering also helped me understand many things about our business that help me be a more effective contributor.

How luck played a part: the success of any startup requires a lot of luck at many different points in time. If Auth0 had not grown as it did, I wouldn't have had the opportunities to learn what I did and be where I am. This is particularly important because I live in Argentina where the Software industry is much smaller than it is in the US and most companies don't have dual tracks.

Team sports

I played basketball as a kid and during my teens and I realized early on it felt a lot better to win by scoring any amount of points than to lose scoring lots of points. That shaped how I worked in two ways:

  • it led me to help team members often to see how we could succeed as a team
  • it led me to learn and do things that would be required to "cover gaps", which helped me build leadership and interpersonal skills that are very useful as I grew in my career

There is a popular idea that becoming a Staff Engineer requires completing a “Staff Project.” Did you have a Staff Project, and if so what was it?

I did not. Because of how I grew at Auth0 I kind of "skipped that part". As a Director at a startup, I got the opportunity to technically lead a lot of big, critical initiatives, but there was no specific/explicit "staff/principal project".

I think implicitly the closest thing to a "Staff Project" was the work I led in 2017 & 2018 to increase the reliability and scalability of Auth0, leading some projects to offer higher SLAs for a subset of our key customers.

What piece of advice do you have for someone who has just started as a Staff Engineer?

Staff means different things at different places, so the first piece of advice I would give is to talk to as many people as possible to define expectations where they are.

The next thing I would tell people is to be patient. They probably got to where they are because they are fairly technical and got results, but as you grow in the ladder the outcome of your work takes time to develop. You might be working on more things at once, and the impact of them has a longer time horizon. You are also now influencing more people in different roles, and sometimes it takes them longer to "see" the things that you might see clearly. Being patient, progressively influencing people, and teaching others pays off long term.

Finally: get used to writing things down and repeating them to others. Writing down thoughts, plans, reasoning, and standards is the way you will scale yourself. When you document something you make it easy for anyone to access it and read in the future, it is easier to reference. It is a lot better than "just talking about it": it scales better and it also reduces the chances of things being misunderstood. Repetition is also necessary as just publishing written documents is not useful, so you have to share your ideas with people. Hosting AMAs, brown bags, and other sessions to explain what your thoughts are very valuable.

Did you ever consider engineering management, and if so how did you decide to pursue the staff engineer path?

I wasn't planning for it, but when the opportunity came to be Director I took it. However, my thinking is that there's a pendulum where you can go back and forth between the two paths. How easy it will be will depend on the company and how specialized the skills as a Staff/Principal are, but I think it is possible.

Nowadays I am very interested in continuing to develop my technical skills and leadership skills, as that's what I think will bring the most valuable learnings and challenges.

What are some resources (books, blogs, people, etc) you’ve learned from? Who are your role models in the field?

I try to follow people on Twitter who I think are doing interesting things and from who I can learn. There are so many people doing interesting things and so much to learn! Some of the names that come to mind:

  • Aphyr's work with Jepsen and general content about distributed systems is great.
  • Tanya Reilly has some very good content like RFC process @ Squarespace and Being Glue.
  • David Fowler shares a lot of content about the .NET Framework and ASP.NET internals which I find interesting. There's also this video of him sharing how he became the ASP.NET Architect.
  • At Auth0 I work with Jon Allie who is a fantastic engineer and person. He strives for simplicity, can explain things very clearly, and is extremely humble considering how much he knows.

I haven't found a lot of books or similar content specific to senior "individual contributors" (might be interesting to write one 🤔). I recently read Fundamentals of Software Architecture that does a fairly good job at describing that role while also understanding the nuances and gray areas of it.

Some books about management are useful to get organizational awareness and help with mentoring, 1:1s, hiring which are things one typically helps with as a staff-plus engineer. In High Output Management Andrew Grove refers defines the "know-how manager" as "people who may not supervise anyone directly but who even without strict organizational authority affect and influence the work of others", which sounds an awful lot like staff-plus engineers. I strongly recommend Managing Humans as it shares stories that are easy and fun to read, and also helps generate empathy with managers, which is important as a staff-plus engineer. The 7 habits of highly effective people is also a book that has a lot of good lessons for staff-plus engineers.

Accelerate is another great book that helps tie company success to engineering practices and outcomes in a way that is useful to influence stakeholders, especially at an executive level.

🤩 More