Hey 👋 this is Luca! Welcome to a ✨ monthly free edition✨ of Refactoring.
Every week I write advice on how to become a better engineering leader, backed by my own experience, research and case studies.
You can learn more about Refactoring here.
To receive all the full articles and support Refactoring, consider subscribing 👇
Until the mid years of high-school, I didn't really care about football.
Then things changed, radically, when my friends convinced me to play fantasy football together.
Fantasy football — or Fantacalcio, in Italy — is a game about numbers, psychology and forecasting. I was instantly hooked, and started watching games regularly, trying to discover good players for my team.
One day, I remember watching a Milan game, where Andriy Shevchenko played.
On one occasion, he dribbled one player, run wide on the wing, and crossed into the box. No one was there to hit the ball, and the speaker said: "Great cross by Shevchenko — unfortunately there isn't another Shevchenko in the box for the header".
I laughed, and for some reason I still remember that moment today.
💥 Conflicting Responsibilities
That time, Sheva did something you often see at work: he took two conflicting responsibilities on himself. That is, responsibilities where you have to make a tradeoff, because you can't maximize both.
If you make more crosses, you will score less headers yourself, and viceversa.
As an employee of AC Milan, Shevchenko needs a way to decide how to balance these two. He wants to do so to optimize his company's outcome, his professional growth and, ultimately, his career path.
In other words, he needs guidance.
⚖️ The Great Engineering Tradeoff
Just like Shevchenko, engineers in a team face an everlasting conflict between two directions:
⚡ Speed: building things as fast as possible
🔍 Quality: building things in a way that is maintainable and long lasting
As a company, this conflict is healthy, because you want to keep balance between pushing to deliver and building technical excellence. By striking this balance, in fact, you can sustain fast, high quality work in the long run.
To achieve this, however, engineers need guidance on how to address this tradeoff. They need to understand what should be built, and how it should be built.
⛰️ The Lonely Manager
One problem you may encounter is having such tradeoffs left to the judgment of a single manager — e.g. the Product Owner of the team.
The problem lies in the fact that, in a cross-functional team, these choices require different skills based on the functions involved. A couple examples:
In a Design context, the team might choose between investing in upfront work on the design system (quality) vs delivering an ad-hoc variation for the new feature (speed)
On the Database side, we might choose to add a less-than-great column to an existing table (speed), or to revise an abstraction that is no longer working, spawning a new table altogether (quality).
It's impossible for a single person to be an expert of everything. So, in the long run, the manager's choices are bound to reflect her own personal biases, leading in turn to:
🙉 Lose of trust: people may believe their manager is not making the right choices, because she lacks the hard skills to do so.
🙊 Disengagement: people may feel a disconnect between their craft and the decisions being made, making them less and less engaged.
☯️ The Entrepreneur and the Professor
The healthy way of handling tradeoffs between two qualities, instead, is having separate people championing each of these qualities.
Mary and Tom Poppendieck, who wrote about empowering IT teams for decades, proposed an effective picture for this, that stands at the core of the highly praised Spotify model for scaling agile work.
They say employees should have dual reporting relationships, with two kinds of managers:
The Entrepreneur — who gives direction on what to do next
The Professor — who gives direction on how to do it properly
🚀 Entepreneur
The Entrepreneur works vertically on her own team, and is concerned about business goals.
She will naturally push to deliver things, which makes her the champion of ⚡ Speed. In a cross-functional product team, the Entrepreneur role is usually played by the Product Owner.
🎓 Professor
The Professor is the champion of 🔍 Quality, as she is concerned about building technical excellence. In order to do so, she has to work horizontally, promoting shared practices for her function across multiple teams.
Technical leaders of various kinds often act as Professors within a company. They are also usually involved in the work of a specific team, which is useful to stay grounded.
✂️ Splitting responsibilities
By assigning exactly one responsibility for each role, we are improving our process in multiple ways:
📚 Specialization — we are making sure each goal can be advocated by a true specialist, focused on doing her best for her own area of influence. We are also reducing the need for extraordinary people who should be able to do just everything.
⛳ Guidance — we are providing clear guidance to team members, who have now precise people to reach for advice and coaching, based on the specific need they may have.
🎢 Career Paths — as a by-product, we are laying the foundations for two different career directions: one more managerial (entrepreneur), and one more about technical contribution (professor).
That's it for this week! Do you feel your people have the right guidance for every part of their work? Do you feel responsibilities are well distributed within your team?
Let me know in the comments or via email 👇
Hey, I am Luca 👋 thank you for reading this through!
Every Friday I publish something about making software, working with people and personal growth. If you haven’t already, you can subscribe below to receive new posts in your inbox!
Thank you for sharing this!