This blog post has been inspired by the following article: Where the hell are all the great senioer software developers and hands-on engineering directors.

"You talk like a developer"

Let's start with a short story:

New dev comes to me as he's told I can help with a problem he has. After 5 minutes of conversation, we've got issue solved. He can't withstand & asks straight away:

"Who are you? You have managerial authority, architecture-related title & you talk like a developer."

Good question, who the hell am I?

This whole blog post is aimed to answer this question by describing the career path I've taken. But why should you care? Sooner or later, each software engineer will face similar dilemmas:

• where's my space to grow?
• do I want to write code all my life?
• what's the best way to utilize my experience & knowledge?

You may have your own opinions & preferences, but learning from your seniors / peers won't hurt & may actually help with making an optimal choice.

Blue or red pill?

I've started as a software developer a long-time ago, I've quickly move to being a senior developer & team leader even before I graduated. Soon after, I've found myself facing dreadful crossroads:

• easy path leading to siloing myself as a software developer forever (senior SD, senior senior SD, seniorer SD, the seniorest SD, methuselah SD, living fossil SD, ...), doomed to always being under the thumb of someone who doesn't even understand what I'm doing
• dark path of damnation as a content-free slave herdsman, lord of status reports, master of worksheets & conjurer of slidedecks - in a single word ... manager. What in English stands for a mix of: accountant, salesman, marketer, PR specialist & few more. Nothing related with actual engineering, building great solutions, craftsmanship, breaking technology barriers to improve lifes of future generations

1st path was very tempting - it's what I've always enjoyed most. But ... I've always wanted not just to scale myself up (get more better & more skilful in what I do), but also out (increase my impact / causative power & utilize my wits to create bigger & more meaningful things). Obviously, the latter can't be achieved alone, but by leading other towards the common goal ...

Needless to say, as both paths were fundamentally flawed, I've decided to carve my own path ;D

This is my path

Before I get into what this path is about, one more remark. This is the path I've picked for myself. It doesn't mean it's the only sensible or the best path for software engineers - it's just the one that suits me. I won't dive into possible alternatives & variations I've rejected - that could make this post end as a booklet ...

The title

According to many, the best way to describe the role / position / function is the work title. What's mine then? My actual position (on my work contract) is meaningless, so let me try to shape something on the fly ...

"Vanguard Software Delivery Captain" ;>

Err, what?!

Why "Vanguard"?

Because I'm up for a game only if environment (company, community, team, etc.) is willing to change something. Carry on the usual stuff ain't really my thing. But if there's a will to embrace the risk & improve the way things are done or raise a bar for work's product - you've got my attention.

Why "(Software) Delivery"?

Because Delivery is something much more than Development. Being skilful in the latter is highly insufficient to produce & get rollin' great products - there are other important challenges above the source code level. Regarding solution architecture (on various levels), service / release management, reliable deployment pipeline, efficient development process, scaling up work (in multi-team environment), building quality & transparency in, etc.

Why "Captain"?

• "Manager"? - has negative connotations with traditional (quasi-feudal) management models of XX century
• "Leader"? - makes more sense, but true leadership is something earned & built (in a continuous way), not a formal position / role
• "Architect"? - 1. this is the most devaluated word in XXI century Software Engineering, I don't think it's possible to get the bad smell of it; 2. I believe all who contribute to the solutions are some kind of architects (on various levels)
• "Captain"? - it sounds absolutely ridiculous :), but there's a point - this rank has been present in many contexts through the space & time, but the one I refer to is ... WH40K :)

"A Captain leads from the front."

1. He commands a company - a unit that is large enough to make a difference & small enough to keep direct, mutual, trust-based relationships with each other
2. Each of them is a proven veteran, hardened in a heat of battle - who was in a role of common Adept before & still can stand for one if needed
3. His position is based on merit, experience, respect gained in the field, not due to politics or grant

This role is about ...

... leading others to make things happen. By pro-actively consuming & radiating information, continuously inspecting both delivery process & work products, zealously promoting the culture of continuous improvement & paying attention to each relevant detail & every aspect of modern software delivery. Being omnipresent, but not as a semaphore or filter, but an icebreaker & catalyst :)

This requires a lot of past practical experience & means spending freakishly much time & effort (on daily basis) on keeping your knowledge & skill relevant & up-to-date.

The goal is to know ...

• ... what actually has to be done (in detail) to deliver the expected result (technical product / service) - knowing this, makes it much easier to comprehend the current state of endeavour, identify (or predict) problems, bottlenecks, etc.
• ... how to set efficient end-to-end delivery processes (working CI, short feedback loop, efficient troubleshooting, reliable & repeatable automated deployments, transparent configuration management, etc.)
• ... how to scale up the development (organize the way teams share source code, artifacts, align their backlogs, minimize technical dependencies, etc.) on project / program / organization level, without bogging down overall velocity
• ... how to develop & maintain solution architecture on project / program / enterprise level (efficiency, resilience, maintainability, availability, interoperability, re-usability, scalability, etc.)
• ... what's needed to help software engineering people grow, regardless of diffrent levels of knowledge and experience (coaching, teaching, tutoring, giving feedback & career advice, providing proper empowerment & space to self-develop etc.)

... all of these above not just in a single, genuine way. Each environment is different & requires an adjusted approach - fit for particular organization, people, technology stack, current situation, etc.

Stuff to forget about

1. Idea for this role isn't really about smart-assing & pretending to be a sage who has all the answers while being as approachable as Chinese Emperor; quite the contrary - instead of closing yourself in a ivory tower, you have to do gemba (work directly with others) & remain as close to the actual work as possible
2. This role is not about accumulating power & converging decisiveness either, as this would not only lead to being a bottleneck, but also dis-empower others. Usually it means:

• listen, instead of talking
• set targets (exit success criteria), instead of giving full task list
• give feedback, instead of micro-managing
• let people do small mistakes, to help them learn ownership & accountability

1. Say good-bye to writing feature code. You still work with code on daily basis (PoCing, development tooling, extricating process info, peer reviews), but it's usually code written by others, not yourself.
2. With software being so intangible, ephemeral & fragile, so-called "Powerpoint reality" seems abstract and delusioned, but in fact that's the only perspective understandable for some people (e.g. business stakeholders, top management), who'll never get technical details or engineers' lingo. Someones has to do this "context mapping" (map engineeering reality into concise, clean business message) & that seems like a perfect duty for this role.

Environment's support?

It may seem I was lucky enough to find an employer who had defined such a role that had fit my preference. The truth is ... it had not, but I didn't care. Policies, processes & organizational structures are for people, not the other way around. In my case, it was a matter of providing purely commercial arguments (make client(s) realize they need this role badly & they want to pay for it):

• gradually build awareness of the benefits of such a role (based on objective facts)
• seize the opportunity when it happens: usually it means organically growing (be being pro-active) from a lesser role (act like a role you're aiming to take)
• don't wait for the "green light" - better ask for forgiveness than for permission
• when you get into the saddle, make a difference & make it clear'n'obvious
• *ding* profit *ding*

The End-Game?

Regardless of post's title, I don't think it's the End-Game for me yet. It's a step in self-development, a step towards even more ambitious endeavours & bigger challenges. As opposed to the more traditional work models, it doesn't necessarily mean more subordinates or more decisive power. What's far more important is more value added, more disrupting innovation, more glory.

Hopefully one day much enough to earn a place in eternal hackathon at Codehalla, alongside legends like Dijkstra, Turing or Ritchie.