I, as a developer…

Or: How does teamwork actually look like?

Maybe you have seen this video on “The Power of Teamwork“. I always enjoy watching that video because it conveys the energy of working as a team and the positive effect it has on our results as well as on ourselves. Maybe you have also wondered how to create good teamwork in your own organization? On one of the LeSS conferences that I attended I stumbled over a talk by Ari Tikka about how to “Simplify Organizations by Creating and Protecting Teamwork“. I highly recommend that you check out his video, too.

What Ari and many others agree on is: Teamwork is not about giving yourself up for the greater good of the team, but rather about identifying what you contribute to the team, to the goal and to the vision.

One of the most influential books for me about this topic is Richard Hackmans “Leading Teams: Setting the Stage for Great Performance”. Somewhere close to the end of the book (according to my kindle at 79%) Hackman talks about “Making Magic”, based on the terminology it seems well aligned with the “The Power of Teamwork” video. Hackman says: “It would be wonderful if we could create magic at will, if we could somehow engineer it, but we cannot.” He continues to quote from Mark Salzman’s novel “The Soloist”:

“You cannot make great music happen, you can only prepare yourself for it to happen. To a degree, your preparation determines what will happen, but once it starts happening you have to surrender yourself to it.”

But if we cannot create or engineer it, how does it work? What do I, as a developer, have to do to achieve great teamwork?

There is part of an answer to that question, what do I have to do, hidden in the quote: I can prepare myself!

But there are many ways to prepare yourself, many aspects – too many for a “short” blog post about making teamwork magical. I don’t want to tell you that you should be seeking feedback or that you should value different perspectives in a discussion or offer your help rather than waiting for people to ask for help. All of that is true, but I want to talk about two aspects that in my opinion can be done by anyone and be practiced regularly – or even daily – and therefore are well suited to “prepare yourself”.

I want to start with an omni-present topic that we all enjoy: Complexity!

Or rather with the complexity bias, a logical fallacy where we prefer complex solutions over simple ones. You can find a link to an article on the complexity bias below. My favorite quote from that article is: “Chaos tends to disguise itself as complexity.“. And sometimes complex solutions certainly feel like chaos. But apart from being aware of this cognitive bias that we all share, what can I do?

A first step is to actually consider simplicity.

Maybe you are aware of Occam’s razor, a principle that suggests that when faced with competing hypotheses that make the same predictions, the one with the fewest assumptions should be selected. So, the first step is to create alternatives that are simple. Do not get tangled up in existing complexity or solutions. Ask simple questions and advocate for simplicity. This is a decision you can make and it will take effort and courage. But it will be worth it.

The next step is to consider your language.

The complexity bias article contains a section on language and jargon. It says about jargon: “Jargon…can be useful for people as a shortcut to communicating complex concepts. But it’s intrinsically limited: it only works when all parties involved know the code.”. This also means that complex language can be harmful. So you should prefer simple language, especially in situations where you do not know who might read it – or listen to it – afterwards. And this will also take effort and courage. I will add an example, taken from a physics paper in 1996 – also used in the linked article – and you can try to figure out what Alan Sokal actually wanted to say:

“Secondly, the postmodern sciences deconstruct and transcend the Cartesian metaphysical distinctions between humankind and Nature, observer and observed, Subject and Object. Already quantum mechanics, earlier in this century, shattered the ingenious Newtonian faith in an objective, pre-linguistic world of material objects “out there”; no longer could we ask, as Heisenberg put it, whether “particles exist in space and time objectively.”

Now let’s talk about the second topic of this blog post: Teamwork.

I don’t want to get into a definition of the term, but it is by nature team-based work. This means that we work together and communicate with each other. And therefore, the practices of our teams should make those two things as easy as possible: Communicating with each other and working with each other. I added a link to an article that is less of a definition, but an example of teamwork (see Curiosity Reading Material #2). The first part might even be an example on how to fail with the complex solution. It is the story on how a small team helped rebuild the healthcare.gov website. And by achieving this they did something that hundreds (maybe even thousands) of developers and sub-contractors could not do. My favorite quote from the article is this one:

“The thing about needs is, you don’t mix the solution with the need, so you actually say, this is a need we need to solve. And you use the creativity and the energy of the team to figure out what the best way to address that might be…”

But what does that mean for you, as a developer?

Well, it means that you need to use and practice methods that will make communication and collaboration easier in your team and across teams. And one of these practices is Test Driven Development (TDD) – ideally in pair or mob programming sessions. But you can find more inspiration in the book “The Clean Coder” and Dave Farley, the author of “Continuous Delivery” and “Modern Software Engineering”, has a helpful YouTube channel where he e.g. explains common anti-patterns when starting/doing TDD. It is interesting that many of them come from the simple fact that developers are not writing the test first. That is also why an easy first step is to start exactly there: Write the test BEFORE you write your code.

And if you are looking for more things to try, you could also have a look into the “Practices for Scaling Lean & Agile Development” book, especially into the chapters 9 & 10: “Legacy Code” and “Continuous Integration”.

That’s it. I hope there is some useful info here for you.

Have fun!

Curiosity Reading Material

1. ARTICLE: Complexity Bias: fs.blog/complexity-bias/
2. ARTICLE: The Secret Startup that Saved the Worst Website in America
3. VIDEO: Dave Farley on “When Test Driven Development Goes Wrong“
4. BOOK: Hackman, J. Richard. Leading Teams: Setting the Stage for Great Performances. Harvard Business School Press, 2006.
5. BOOK: Martin, Robert C. The Clean Coder: A Code of Conduct for Professional Programmers. Prentice Hall Press, 2011.
6. BOOK: Larman, Craig, und Bas Vodde. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley Professional, 2010.