Craftleadership: Craft Your Leadership as Developers Craft Code

Learning software craftership made me reconsider how I wrote code. Being an experienced software team manager, I try to reevaluate my management practices in the same way: what could Test Driven Management or Pair-management be? Here I propose different insights on how software craftership tools and mindset are transposable to the management domain.

An ideal manager for software crafters

I often hear developers saying that managers were pushing them away from agile and quality practices, however without calling into question their necessity. This is why the question of how an ideal manager would look for them was something that I had in mind for a long time. So I asked a dozen software crafters, rigorously doing so (See Evolution of managers role in a software craft perspective, in French). They told me that the first things they were looking for, unsurprisingly, were managers who could first teach them about the software business (mentors), and then promote and defend these practices in the organization (advocators). 

What surprised me was that for some of them it was not enough, and sometimes not even necessary: autonomy was the only thing they asked for. But what blew my mind was when a developer told me that the best managers she had were those who managed a crafter crafted in the same way. They had the same quality practices and postures in their management methods.

Applying practices from software craftership in management

I am not saying that you can copy practices from one domain to another. But I am saying that, as soon as you have the same motivations, then some practices transpose well from software craftership to management. 

That being said, it is not theoretical. I have the same feeling when I try to name a team as when I try to name a method, and I know that the first name I come up with won’t be the best one. But maybe the most caricatural example concerns changing organization: when I tried to change a 30-person team in a big bang way, the same thing happened as when you want to replace a legacy system in a big bang migration: it rolled back. The organization resisted so much that they kicked me out. I am now against big bang organizational changes!

There are other common practices in software development that apply to management. First, organize your budgeting process as a CI/CD pipeline. Make budget definition something that is easily repeatable, and that fits in your organization. CI/CD allows you to get rid of fastidious tasks by putting them in a pipeline. Budgeting is one of the most fastidious things I have found I have to do as a manager.

Second, master your tools. If MS Excel is the tool used by the managers in your organization, be an Excel master. 

Third, try to be reactive in your decisions, as in reactive programming. Be asynchronous when making decisions; as much as possible, try to reduce the “commit” phase, that is, the meetings where everyone must be present to say they agree. In my case, I think that it is necessary to maintain these meetings where everybody agrees on different things. Yet, in these meetings, I never address an issue that I haven’t had the time to discuss thoroughly with everyone beforehand- this could be through a simple asynchronous email loop where everyone had a chance to give his or her opinion.

Pair management

In addition to the practices proposed above, there are two software craftership practices that I found really useful as a manager. The first one is code reviews. As code is not able to go into production without having been read by two people at least, I try to review all my management decisions with someone else: a colleague, or a boss for example, and eventually what I found works the best is to have people from my own team review them.

But we pushed this reviewing practice even further within my company Arolla: we are pair managing. We are two VPs with the same responsibilities. It’s not that we cut the team in two; we manage a team twice as big, but together. And we make sure that everything one says is assumed by the others. In practice, there are two main cases: either my action is coherent with the vision we defined together (eg. “raising expertise through groups of practice”) and I act; or it is in conflict with different goals (eg. “short term revenues” vs “long term training”), and I ask.

I have found that reviewing code in development and sharing or delegating responsibilities in management is the same thing at the end of the day. When I review a code, it becomes mine. This is how I see the link between code reviews and delegation practices in management 3.0. Reciprocaly, the different levels of delegation that Management 3.0 proposes could be a way to understand the different dynamics underlying code reviews: what do you accept to delegate to your code reviewer?

Test-driven management

The second software practice I find really useful is Test-Driven Development. I use it on an everyday basis as a manager, and translate it to “Test-Driven Management”. “TDM” is a way to assure the quality of my management; the same way I assure the quality of my code with Test-Driven Development. And it has the same three principles: test first, use baby steps, resulting in an emerging design.

The first principle of TDM is thus to express your goal before your action (test first). For instance, I formulate my goals as a hypothesis that the action I propose will hopefully help to validate it. It could be as simple as rephrasing “Let’s do an epic-map,” to “Let’s do an epic-map- this should hopefully allow us to define smaller releases”. Assume that intuitions are intuitions! 

This is also the reason I ask managers I coach to refrain from using performative speech, following the same principle that just because it’s in the specifications does not mean it will be in the software. For instance, instead of just asking a team to deliver on time, work with them on their priorities, and be sure they don’t just agree because you are the chief, and want to please you.

But more practically, “test first” is when you have to do something: simply drafting the email you would have sent after the task is done, but doing so before starting the task. This way, you won’t get lost and you’ll have a light in the dark, knowing precisely when you have finished: as soon as the email is sendable. This is why it is important that you write the real email that you will send, and not just a goal on paper. It has to “compile”, like a unit test, so it’s easy to know if you have reached your goal: can you click on “send” or not? And as soon as you can send it, send it and immediately write the new “future email” before going any further.

The second principle of TDM is, like in TDD, to assume that you won’t reach your goal in one single step (“baby steps”). When you have a complex problem, don’t try to communicate it globally; tackle it example by example. For instance, when we had discrimination issues, we didn’t try to solve them as a whole; we started with tackling sexist jokes, to see how the system reacts.

And the last principle of TDM, like in TDD, is to allow the design of your organization to emerge little by little. This is the most difficult thing, as it is impossible to change names of a team as easily as you can change the name of a method when its responsibilities evolve. Thus, what I find most useful is to work with the people before trying to change their organization; and after that, give the people the option to change the processes that they follow. To illustrate this, I often talk about how UI/UX “design systems” emerge in an organization developing user-facing applications. The responsibility is first distributed in different feature teams who have their front-end developers building their web components independently. Rapidly, the responsibility is then shared, through a guilde, for instance. Finally, after one or two years, a specific team maintains it, with a specific pipeline and its own “demo project”.

Craftsleadership and learning organizations

Taking a small detour, I found that when talking to people working in holacracy organizations, it seems that their concept of “tensions” really looks like my unit tests in Test Driven Management. Without going into too much detail, a tension is a concrete fact that team members report, that refrained them from assuming their responsibility. It’s a fact, and it’s always related to a goal it goes against. The way I put it is the “tension resolution” process in holacracy is a way to refactor the organization, little by little, with really small, concrete and unitary issues that we want to resolve, in the same way we refactor a software in TDD with our small concrete unit test.

Indeed, being able to change responsibilities across teams, without having this renaming issue, and having a way to change processes every month in a standardized way, are practices that some types of organizations have already formalized, and they are called learning organizations. 

I am not saying that you must deploy holacracy to have quality management, but I think that it is much simpler in learning organizations than in more rigid ones, or organizations built on personal motivations and power. And to give this type of management a name, I chose to call it craftsleadership.

Using this term, if I reformulate what I said before, being a craftsleader is having similar aptitudes as software crafters, such as: test driven management, pairing, continuous budgeting, tool mastery, and reactive decision-making.

But we also know that software craftership revolves around attitudes. Being a craftsleader should be about having the same attitudes as a software crafter; mainly, showing respect, respect to yourself, to your team members, but also to the future managers who will manage them, and also to the team’s former managers and their legacy. It’s also about being frugal, searching for resiliency and scalability. It’s about giving value to teaching, learning and coaching, with humility.

Going back to aptitudes, there is one which is well-known to software crafters and that I have not talked about: the aptitude to give feedback. We practice it, as a developer, when we review code, but also in our discussions with the business (for example, by talking about specific examples with BDD).

Feedback is central, and you need feedback as a craftleader too. To do so, first of all, don’t forget to differentiate output and outcome. More power might be an output for you, but it is not an outcome for your organization. After, don’t try to observe your team as you observe IT systems. Teams are much more reflexive and self organizing. People in teams can monitor themselves to a certain extent. 

Perhaps this could lead to a sort of a craftsleadership manifesto, with these two first principles: “Craftsleaders prefer conversations over monitoring” and “Craftsleaders prefer self monitoring over external control”. If you have any idea how to enrich this, I would be happy to talk about it!

Coding your organization

Remember, all this came from my feelings as a developer and as a manager. Hence, I tried an experiment to even go further: I tried to code the organization itself. The goal was to see if precise coding practice mapped, through code, to precise management practices. So, I decided to model a simple organization in Java, and to refactor it using classical code refactorings, such as “inline”, “moving method to parameter”, “extract method”, “rename”... And it worked: inlining methods was like “go and see” as in gemba; moving method to parameter was really like giving a responsibility to someone else, and the urge to rename roles when responsibilities changed arose quite rapidly. A small excerpt is available in this craft leadership kata. 

Yet, the first time I presented this to a group of practitioners, one of them, Laurent Bossavit, told me that someone had already written some papers on it: Leon J. Osterweil, and in 1987! The papers I am talking about are Software processes are software too from ICSE, 1987, where the author explored the importance of process as a vehicle for improving both the quality of software products, and the way in which we develop and evolve them; and Software processes are software too, REVISITED from ICSE, 1997, whose goal was to clarify some misconceptions about the first one, and map out future research directions.

So I read his papers, and I found that one of his most precious pieces of advice was that you should leave the methods blank where humans are involved. Osterweil concludes that software is not only code, but it has processes, and human processes. But, precisely that we should not try to code what should remain human, in order not to transform people into robots.

Learnings

I learned that it's a long journey! I have been developing software for more than twenty years, managing development teams for more than fifteen years, and coaching managers for a couple of years now. Sometimes it was difficult to match how my managers wanted me to behave as a manager, to what my team members were looking for. But I think I have arrived at something now. It is not an intellectual comparison between two domains with off-the-ground correspondances, but a way to trust our feelings when we feel similar things while acting in two different domains. I hope that other managers will also find helpful tips here, or be reassured on their slightly offbeat practices. And maybe some developers would like to advise their managers too!