Heroes And Teachers in Software Engineering

Photo credit: John Schnobrich on Unsplash

WHEN we start off on our software engineering career journey, the thing we concentrate on first — and probably almost exclusively, for several years — is our work as individual contributors. In the very beginning, that’s ‘how can I get up to speed?’, later morphing into, ‘what value can I bring to this?’.

We quickly get much better at working collaboratively but this individual streak doesn’t really go away. As you get more senior, what you’re personally tasked with grows in breadth, depth and complexity — and you chase after it too. Who wants to be stuck doing the same old thing when there are new, bigger challenges to go after? And isn’t your career progression contingent on your individual achievements somehow?

It’s only towards the higher levels of hands-on engineering seniority that something else starts to happen. At first it’s probably little pieces like onboarding new starters such as graduates, and this morphs into longer-term mentoring, until one day you’re the most senior engineer on the team or even in the company, and instead of your individual helper relationships, people in general now look to you to lead and provide them with the benefit of your experience.

But provided you’ve remained in the hands-on role, still coding, rather than going down a managerial team lead route, you do still fundamentally have an individual contributor role — at least, it’s available to you if you want it.

This presents a challenge, and an opportunity.

—

An Aside: Peter A. Kropotkin, Senior Consultant Revolutionary (Band D)

This guy would have the best LinkedIn profile

In my opinion, job titles are mostly a way of placating engineers who want at least the illusion of career progression, and — although it would be an ‘interesting’ transition — teams could in theory be just as effective if everyone suddenly had the title ‘Software Engineer’ in a flat role structure. The people with the most experience would still get paid more, still provide their influence, and still have the highest expectations placed upon them, but a high performing team doesn’t necessarily need the most senior titled person to be a point of contact or a single source of authority. Problems could be brought to the self-organising team and figured out together.

When it’s next time to re-evaluate your ceremonies like Kanban or that probably illegal animal sacrifice thing you do, why don’t you give anarchism a go? Just kidding. Am I?

Either way, that’s generally not where we find ourselves today, and as you get more senior, your job title does change and that change does have meaning. Often, your role or job description becomes less prescriptive and you’re given more autonomy, not least because at this point you may well be more knowledgeable about the overall state of what you’re entrusted with than your managers are.

—

So, as you get more senior, more and more people like product managers come to you-with-the-title personally to get questions answered or problems handled. Usually they bring some complicated issue directly to you. And why not? You’re probably the most qualified to deal with it.

When those big, complicated problems arrive at your door, you really have a choice. Do you try and solve it yourself? Or do you do something else?

—

It’s really tempting to forge ahead and take the big challenge on, solo — not least because the individual contributor background of our earlier careers normalises exactly that. And then there’s the draw of the task itself. Maybe it’s got novel elements that interest you (you stay doing this job because you feel there’s still interesting mileage in it, right?) or maybe it’s just that you clearly know what you’re doing when it comes to this area, and therefore of course you would do it, it just makes sense.

Meanwhile, what’s everyone else on your team going to do? Well, you think to yourself, they can get on with the simpler challenges that are more in line with their experience. Perhaps by taking the new, complex work on, you’re even insulating them from unwanted distractions or really taxing decision making, saving them from this burden — how benevolent of you. Plus anyway, it would have been really painful to explain all this stuff. You can probably imagine your juniors pulling a face and saying that they don’t know what to do with this and can they please just be left to get on with the stuff they understand?

And there is merit to this school of thought. Team leads in particular spend a lot of their time and energy insulating their team from the gale force winds of the business around them and the many directions and conflicting priorities that the randomly-appearing tentacles of ‘business as usual’ would try and tear them away in. You too have a similar responsibility.

But there is a problem here. Your juniors need to grow, and to grow they need to be fed: not just being presented with abstract challenges, but learning by doing, not by observing or being told. If you make what I just described into a habit, you slowly starve them of that. In the worst case, teams suffer a polarisation of tasks into easy work for bored juniors and difficult problems for a senior elite.

—

In my little world at least, we have come to refer to the solo embrace and resolution of a problem as the ‘hero’ behaviour.

Theseus, a hero who fought a large pig and then, later, one and a half bulls

We should be a bit careful about semantics here. Culturally, we tend to default to thinking of heroism as something to aspire to. In the 19th century, there was even something called The Great Man Theory, asserting that history is defined primarily by leading individuals. It’s something we have seen sometimes popularised in our own industry, especially with the notion that there are ‘10X’ or ‘rock star’ programmers (bleugh), to say nothing of the most celebrated software figures.

Of course, not long after that theory was published, some guy called Karl Marx asserted that it was collective class struggle, not individuals, that really moved the dial; that meaningful change only comes from the masses. And whilst I guess you might not have read his book, Clean Code: The Communist Manifesto, you’ve perhaps heard of ‘bus number’; the number of people it would take, were they to be run down and killed by a real or hypothetical public transport system, to endanger a project through loss of their knowledge or expertise. What are the bus numbers of all the things you or your fellow heroes work on? How often is it ‘one’? Do you really want your work to not outlive your part in it?

—

Another Aside: The Force Multiplier

The military have a term, ‘force multiplier’. This is the idea that introducing some factor, be it new technology or a new strategy or even a state like raised morale, can give you a capability equivalent to, say, doubling your number of soldiers.

For example, if you suddenly got satellite reconnaissance capability, you and your team would have a much better idea of what you might be up against trying to conquer a certain location. If it was less than expected, you might only send a fraction of your previously planned forces there, leaving you with a lot more options elsewhere. If it was more, you might reconsider and therefore not get bogged down or beaten in a fight you didn’t anticipate being so arduous. This is how wars are won.

—

There is another way, and we’ve taken to calling this — although I don’t necessarily love the term — the ‘teacher’ behaviour. Teaching means many different things but the order of the day here is empowerment.

You have the expertise to solve the typical problem you’re given, whether you have the whole, exact solution in mind yet or not. That ability is likely a product of various things; chiefly, your overall problem solving experience, and your familiarity with the project or problem. The rest of your team perhaps doesn’t have this.

So, why don’t you use your knowledge to construct a framework with which to support your team? Try to dismiss that vision of a gallows, and imagine yourself trying to create an environment in which they can be presented with a version of the challenge at hand, enabling them to tackle it in a supported way.

By ‘supported’ I mean that you will provide the minimal required direction, which might initially be deliberately less than is demanded of you, especially if you suspect your juniors’ ability actually exceeds their confidence. In this environment, we are not here to instruct, solve or take over the implementation unless absolutely necessary, and we’re also trying not to belittle or patronise anyone.

Instead, we might be sharing our experience of what good looks like, providing a bit of insight into how we would make decisions, confirming and validating people’s good ideas, gently questioning the less good ones. It’s light touch but when our team is stuck or struggling, we can propel things along by Socratic questioning at first, moving on to more directive guidance as required, but only as much as that moment requires. It’s also OK to oversee (temporary) failure, in a loosely controlled way, as it’s great for learning.

In this way, the team will learn by doing, and hopefully, absorb a little of your experience as a seasoned professional engineer in each interaction. It also offers them a great perspective on what your role is or what seniority in general really means, something that is all too often opaque. If you’d like to serve as a role model, it’s much more powerful to present yourself via your living behaviours than your completed accomplishments.

If you make a habit of this, you become a force multiplier of your own. Instead of you doing the work of maybe a couple of junior engineers, all of the junior engineers’ skills are enhanced and the whole team’s ability levels up. Not only that, but what you do will likely spread, becoming culture; don’t be at all surprised to happen upon one of your ‘students’ doing a better version of your whole teaching schtick when they’re next onboarding someone on to the project.

—

This stuff is challenging. An essential ingredient is fully understanding people’s ability; their existing technical competence/familiarity, the way in which they best receive information, and what pace is appropriate. You won’t have this at first, by any means, and you will bounce around between patronising (“uhh yeah we know this”) and completely bewildering people (“uhh we have no idea what you’re on about”). Just be open with everyone about this from the beginning.

It will be slower than you cracking on with it, and you’ll feel this acutely, with many a suppressed “I could just…” moment. Remember that you’re building a team capability, not just delivering the feature. You may never see the explicit dividend; it’s the invisible outcome of how much better the team is able to perform with their enhanced experience. Unless someone is going to really step up and put together a personalised, boring and probably deeply creepy version of It’s A Wonderful Life for you at your next retrospective, you’ll never be able to compare what it would have been like in the absence of your input. But I strongly believe you will have made a big difference. If you’re lucky, you might get to hear about it from time to time.

“You see George, without you, they’d still think RxJava was good”

Reading this, you might also fear that it’ll be boring for you personally, taking you away from the things that inspire and motivate you. We live a charmed life where our job is mostly fun, and you’re here to code, right? You know that you get a reward from delivering engineering, and what’s suggested is not exactly that — given the above, it might even seem kind of punitive, as it took you longer to do a thing, and required more energy and ceremony on your part.

I once asked a team lead why they became a team lead, and they told me — inaccurate paraphrasing ahoy— that they’d got bored of solving the same technical challenges, so wanted to help other people solve theirs. I don’t totally connect with this myself, as I’m not personally bored of the technical work. Nonetheless I think there is something really valuable in this answer.

I’m here doing engineering because, at the heart of it, I really enjoy applied problem solving, and it doesn’t matter all that much what that problem is exactly. I’ve always believed that to some extent, but when I was more junior, I thought it just meant being relatively agnostic as to what language or platform or project I was coding away on. These days I also think it holds true for situations where it might not be me personally implementing anything, as long as I’m still involved and pouring some value into it. In other words, leading you through solving the problem is not, from my perspective, a lesser sibling of me figuring it all out myself.

For some of us, there is also a vague unspoken prospect that this idea of empowering everyone else could actually pose a threat. Hopefully you don’t run into many people in modern working environments with any kind of strong gatekeeper attitude around their skills and information. However, redundancy is hardly alien in this industry. Are you inadvertently putting yourself at risk if you build a really high performing team around you? All I can tell you is that in my experience, no. Despite what we often think, our value is not so heavily derived from our product or codebase knowledge — it matters that you know your stuff, but people move jobs, and so this is always transient to some extent. Modern software employability is based on behaviours and values, and if you’ve got what it takes to build that kind of team, you’ll never go far wrong.

I’ve worked in lots of different contexts, not always with big teams and not always with people to mentor. Reward for me as a software engineer has come in lots of forms: solving a difficult technical challenge, building something clever or elegant, making a difference for a customer, and more recently, being able to make a difference to other engineers’ abilities, confidence and careers. Positive feedback on this has been one of the best and most enduring things to happen me in my whole career. Rather than finding myself frustrated at my growing distance from the keyboard, it really surprised me how rewarding taking a back seat could be.

—

Should you do this for everything, delegating everything that comes to you? Am I saying there’s no place for the ‘hero’ model? Alas, no, it’s not that simple.

You really need to try and figure out this balance of what you would be doing by taking on the work: denying people experience versus protecting them from an unhelpful distraction, and you will have to do this on a case-by-case basis. Some questions you might like to ask yourself:

• Is tackling this problem — either in itself or the strategies I would use to solve it — going to be additive to anyone’s development as an engineer? Some problems we face are, let’s be honest, grubby little tangents that are better just quietly got rid of, whereas others are ripe to serve as vehicles for another iterative step forward towards someone’s growing responsibility or competence
• Can I reasonably bridge the divide between complexity of the problem and their perhaps limited experience, without this being a horrible experience for everyone? If what it needs is going to be so heavily directive that it’s basically one long show-and-tell, then it might be a questionable endeavour. However this is not fatal to the teaching model — you may just need to break the problem into component parts, some of which you forge ahead and deal with, sharing the remainder.
• Is there an opportunity cost? By dragging others away from some activity where they’re already receiving a lot of value, or where they’ll lose continuity if it goes on in their absence, perhaps it’s better to leave them where they are.
• Is me delivering this ASAP actually going to make everyone’s lives significantly easier and unlock much better opportunities for learning?

It’s very tempting to provide easy answers into these questions in order to dismiss collaborative opportunity and justify solo work under the hero model. It’s your responsibility to be honest and reflective about this, and try to genuinely reason what the best option for team health really is in each case. You don’t have to figure this out alone either — talk to people about the opportunities available to them and what they would like.

A little ongoing thought experiment I like to run now is: what if I’d handed my notice in and I had a month or two before I left the company? Assuming I didn’t despise the place and everyone in it, my focus would probably switch to a seamless handover by way of extracting all the stuff that exists primarily in my brain, either documenting it somewhere or, much better, imparting it to others. And then: what if I behaved like that all the time without the leaving part? Perhaps give it a go for a while.

—

I don’t have any of this perfected. I have had success with it, especially in areas like improving dev/test collaboration (that’s an article in itself), and in helping develop particular software engineers. However I still regularly get it wrong and make poor decisions, missing opportunities and exhibiting the very same ‘hero’ behaviours I encourage you to avoid. Our work lives are complicated and we have a lot of competing demands to contend with. When I do try it, it doesn’t always go brilliantly, and sometimes it’s ambiguous as to whether it added value or not.

Neither you nor I will get this right all of the time — but that’s OK. The approach outlined here doesn’t require absolute success. Anything you can do to direct your role privileges and your experience towards empowerment is worth a try. It won’t be trivial or seamless, especially at first, but it might yield some surprisingly powerful improvements to your team culture, and be rewarding for you personally.

Good luck!