Knowledge Work Practice Plan

Last edited 1st November 2020

how we learn Evergreen Note

Knowledge Work and Practice

  • idea of “game day” where everyone knows what their teammates are doing, everyone’s deep working at the same time, lots of collab.


Building large, scalable, and user friendly software systems is a highly skilled task. In order to do this well, it takes many hours of practice and study. To do it well and fast takes even more experience and discipline, adding to the amount of time that must be allocated to perfecting one's craft. Unlike other skilled professionals, however, developers are not expected to practice and hone their craft as part of their daytime work hours. They are expected to ship features in the day and do the craft-honing (in the form of side projects) in their free time. I think that this approach is fundamentally broken. Compare this to another highly skilled profession, athletics. No one in the Lakers organization is going to question LeBron James for spending his time in the gym during work hours, likewise, the organization is not going to trade Anthony Davis because he's been missing shots in practice. In fact, a pillar of large and successful sports programs is to establish processes, build infrastructure, and hire coaches with the sole focus of improving the quality of training its athletes receive.

Among highly skilled workers such as professional athletes, musicians, fighter pilots, emergency response teams, the amount of time spent training drastically outweighs the amount of time spent executing the actual tasks for which they get paid. The processes of these professions are almost entirely focused on the skills required for the desired outcome, with many organizations embracing process as a mantra. From a software engineer's perspective, it may be difficult to know what skills they should hone to improve their game: spending time taking shots, breaking down game footage, and practicing ball handling will certainly make you a better basketball player, but what skills will make you a better developer?

Critique: Developers should have the requisite skills before they are hired

The goal of a skills driven process is not necessarily to teach programmers how to program, but rather it is to give time and opportunity to team members to hone and improve the skills necessary for the current goals of the project. In an interview about coaching some of the greatest players to ever play the game, legendary coach José Mourinho:

It's very important for a coach to understand, you are not going to teach them how to play football. [...] You are going to teach them how to play football in that team".

For example, if we've identified a problem with the UX of our product, it would be a waste to invest precious work day time in developers practicing algorithm implementation. Instead, we coach them to play football on our particular team by investing work time in pairing them with designers to understand why we have UX problems, how we can improve them, and giving them the opportunity to apply these principles in work that may or may not end up in production, but whose principles will help address the current issues facing the product.

A skills oriented process focused around the most pressing issues facing your software provides a platform for developers to have the ah-ha moments of insight that can radically improve a product. Even the most highly skilled engineers cannot find innovative solutions to problems if they do not have the requisite time to understand the context, or, as Richard Hamming of Bell Labs put it in his book, The Art of Doing Science and Engineering, "Truly creative solutions require an emotional investment in the problem's context". In adopting a skills focused process, the entire development lifecycle becomes saturated in context. Developers spend time learning, practicing, and delivering features all within a certain context, and this contextual knowledge becomes a force multiplier across the team, and across disciplines. Let's apply this to the UX example from above. Say a sprint is broken down into three weeks: study, practice, execute, the first week (study) is spent understanding the problem. Questions are asked: Why is the UX bad? How does this affect existing customers? How might this affect our ability to sign new customers? What does good UX look like here? What principles of good UX have we violated? Developers can spend this time collaborating with designers to understand some of the pitfalls of UX, as well as collaborating with each other to share what they've observed and what they've learned. The next week (practice), developers take what they've learned from the previous week and put it into practice. This could mean building tools to check for common UX missteps, creating libraries to make creating good user experiences easier, or building a prototype of how the current product might behave differently. Collaboration is key here as well. Team members cannot work in isolation as the goal is to quickly validate ideas that can be carried on to the next week. The final week (delivery) is where JIRA tickets get cut and assigned, and features get shipped. It is the culmination of the team's learning, practice, and most importantly, collaboration. At the end of this hypothetical sprint, developers have deepened their understanding of the problem space, and we've avoided the problem where one or two developers are the only ones with enough context to truly fix future issues.

Critique: We don't have time for anything but shipping features

Critique: We hire developers to develop, not to learn

Teams hire LeBron James and Ronaldo to win championships. Part of achieving that goal is putting in the necessary work: lifting weights, practicing technique, watching game film, etc. Skill development is every bit as critical to shipping features as it is to winning the Champions League.

But as much as Hinkie and his disciples want to talk about a process, many people out there still live in an outcomes-based world