The Four Jedi (software architects) You Meet in Heaven

Millenium Falcon at Galaxy's Edge

*with apologies to Mitch Albom, of course. We recently got Disney+, and I finished watching The Mandalorian, and then, casting about for what else there is worthwhile, dove headlong into The Clone Wars animated series. It’s great! And somewhere deep in my subconscious, this analogy emerged.

After writing about the paths to Senior Developer, I’ve been thinking about what comes after that. Specifically about what comes after that at TELUS Digital, because that’s where I’m working. Important caveat here:
these are my musings, and not official TELUS Digital policy.
It should also be noted that the types of technical roles quickly bifurcate over and over like a career river-delta if you survey the industry: tech leads, team leads, staff engineer, fellows, principals, architects, managers, etc, so as you talk about more senior technical roles, there’s a higher-chance that you’re being very specific to your current organization. I asked on twitter about one facet of this too, as I thought about tech leads vs architects.

That I ask this question probably reveals a fair amount of how things work at TELUS Digital. But this also made me thing very specifically about the delta in those roles here, as I see it. I’ll talk about the tech lead role another time, but want to think about Software Architects, and the kinds of skills, focus and interests that make for good candidates.

Anakin Skywalker: The Solution Architect

Anakin Skywalker is confident, quick thinking – surging headlong into trouble and thinking creatively on his feet to find a solution to the problem in front of him. This is the kind of architect I’m the most comfortable speaking about because it is how I self-identified when doing this kind of work. It is a broad rather than deep role – a good solution architect can think creatively, laterally about a problem and propose a variety of potential outcomes to solve it. I’ve seen this role advertised many places as a web architect as well. If you’re a developer who loves the challenge of working in an unknown space, who prefers prototyping to refactoring or incremental improvements, this is a great fit. A solution architect has an obligation to keep current on shifting trends – be knowledgeable across a varied set of technologies, frameworks, languages, etc. More importantly than what you do know is a deep understanding of what you don’t know. A good solution architect will know to bring in other expert voices to stress-test and verify an idea. Because of this need, solution architects need to have pretty solid social skills as well to succeed, and should work more closely with developers on a day-to-day basis than others.

Of note: if you know the story of Star Wars, you’ll know that things do not end well for Anakin Skywalker, who falls to the dark side and becomes a force for evil. While this may be really stretching this metaphor, this is a useful thing for solution architects to think about too – too often we hear of Ivory Tower, or “architecture astronaut” if you don’t stay connected to the work happening.

Mace Windu: The Domain Architect

Mace Windu is a master of lightsaber combat, wise and careful of words, thinking deeply about the practice of his craft. He is a specialist, through and through. Domain Architecture is a path for deep specialization and knowledge. This is also variously called a practice lead. This is a good role to think long and deeply about a particular topic to develop unparalleled expertise in it. Spending time learning from, and talking to other experts in your domain is important in this role, to ensure that you do not end up so specialized in your particular company’s needs as to lose relevance. A key duty of this architect role is to impart knowledge to the people around you – both technical and non. More so than a solution architect, ensuring that there is a succession plan – that there is a clear apprentice to follow on is a good practice. Some examples of domains of specialization: Network Security, Testing, Telemetry, Performance, Data, etc. This role is still one of software, and so spending time writing, refining best-practice examples; pushing the state-of-the-art forwards are key outputs from a domain architect. Leading development of mission-critical implementations within your domain is also an important role for this kind of architect.

Obi-Wan Kenobi: The Integration Architect

Obi-Wan Kenobi always saw the underlying truth of a scenario as a way to find the way through it – never hurried, always already where others were going to. He understood, holistically, what was happening around him. This is a role for understanding what lays beneath: how different tools, architectures, endpoints, etc work together. It demands an incredible ability to keep hugely complicated systems in mind and be able to anticipate side-effects and unexpected outcomes from new additions. I’ve only encountered this type of architect at very large companies that have very complex, often legacy systems – a smaller scale operation is unlikely to require this kind of specialization. Interestingly, I’ve met several excellent integration architects who came into this from a business or system analyst role, as well as from a developer role. Integration architects, in my experience, make and maintain the best diagrams, are excellent teachers to others, and unparalleled in their ability to reduce complexity into more digestible chunks. If you’re a developer who likes working on edge-cases, who likes to find the weird exception to every rule, or who likes to think holistically about an entire system, this is an excellent role. It is very much a role of incremental operation of a whole system, rather than rapid prototyping or deep dives. It’s a great place to iterate on a particular system for a long time. If you want to have impact at scale through small incremental change, this is exactly that type of role.

Yoda: Principal Architect

Yoda guides the entire Jedi council with a clear vision of what a Jedi can be, should be, and helping everyone stay on the path to that vision. Including a Principal Architect may seem something of a cheat, in that I would consider this an additional tier of seniority than others – certainly at where I work now it is – but it isn’t always. Sometimes, it is the only architect. And this is largely a visionary role, to look forwards towards what might be, what can be, what must be for organizational success. It needs to be an architect who can think broadly about the range of opportunities to improve technology, who can work with other leadership to translate technological vision into business relevance. At some places, this role may well simply be the Chief Technology Officer (CTO). At somewhere large enough, there may be multiple principal architects, spread across the vast swathes of organizational complexity. A key duty of this role is to help support all the other architects as well – to provide support for their decisions, to provide rigour in decision-making, to ensure that everything roles up towards a coherent vision of good.

Do these kinds of role exist where you work? There’s probably all sorts of variants of this. For TELUS in particular, the software architect path is generally for people who want to stay primarily as individual contributors, rather than leads/managers. A path of bits, rather than heartbeats as it were. One thing I wish I had more insight is to what some key differences between something like a staff engineer and a software architect. Do places have both? My instinct is what I’m calling a solution architect may be akin to the staff engineer elsewhere, but YMMV.

Developer Levels: evaluating professional growth

This is one of those things that my instinct with developer levels is “I know an [X] developer when I see one” – but if you’re a developer reporting to me, that’s completely useless. It smacks of subjectivity, of hidden gatekeeping. It would be really hard to argue with me if my position is simply “you’re not it, yet”. And because I currently work with some of the absolute smartest, most skilled developers I’ve ever had the pleasure to work with, I’ve needed to think long and hard about this. Because while they’re all great, they’re not all at the same level of title-seniority. This is also a topic that has been written about many times. I’m focusing here on roles we have at TELUS. For a great wider/larger look at titles, please read @reiver‘s post “Software Engineer Title Ladder
At the same time, internally, we’ve been looking at building out a better career matrix in order to help guide these conversations across all disciplines. We’re still working on them – but with any luck, I’ll be able to share out at least our developer matrix (NB: in Canada, we don’t talk about engineers, but developers. If you’re elsewhere, you may substitute as per your comfort level). So with all those caveats, here’s some ideas I’m working through:

Problem Solving

  • A Junior Entry-Level Developer (I don’t particularly like that term junior – it feels vaguely pejorative – but that is another topic) is someone whom I can hand an identified, solved problem, and they are be able to implement the solution. I expect all asked-for particulars to be included, but I also expect questions to be asked, that the occasional thing might get missed, and that they would not necessarily be able to balance conflicting priorities in code without guidance.
  • An intermediate Developer is someone whom I can hand an identified problem, and they are be able to provide one or more solutions and implement it/them. They are be able to discuss the merits of each solution versus the identified problem’s parameters. I expect good testing habits, and a reasonable attempt to balance multiple concerns during implementation.
  • A Senior Developer is someone who can identify a problem that needs to be solved, include wider concerns when considering solutions and then guide implementation. They are able to help guide other developers when working through ideas, and help shape the work output that results. Senior developers can execute with a very strong understanding of the product lifecycle – so their work can have huge impact on the shape of the code base over all.

All of the above is not linear, and very open to interpretation. You’ll note I don’t talk about particular skills – in part because I’ve been looking for a through-line that would carry across different specialties, but also because my experience mostly tells me that skills and knowledge accumulate as you go. I’ve also several times encountered the inverse problem: deep specialization in one stack or skill leads to blind spots that I find troubling at more senior tiers of work. Either way, these conversations are hugely individualized and hard to generalize. But I think a useful way to put it might be: seniority is a combination of deep knowledge and broad application. Lateral thinking is important, as is deep knowledge and strong skills.

Mentorship

The other key ingredient in developer growth is on the mentorship side: Writing software is a team sport. Mentorship is multi-faceted, and can consist of a variety of things: lessons-learned, code practices, problem-solving skills, organizational-awareness, skills from other disciplines, leadership skills, etc, etc. This can be direct pairing, training opportunities, group work, special projects, etc. Mentorship is itself a program that can either reinforce existing biases or slowly shift them (that link is from 2008! sadly still feels relevant). So being incredibly intentional. both as an organization, and as a people-leader, about what is wanted out of a mentorship program is vital.
I believe that all levels can participate in this, in different ways:

  • An Entry-Level Developer will seek guidance, and share news ideas back into the community. If you’re learning, one of the best ways to learn is to do it publicly (see this very post. This is a lifelong thing). And asking questions demonstrates an important level of humility. And so junior developers looking to grow will proactively seek out opportunities to be mentored, or to surround themselves with senior developers. There’s… there’s a level of privilege associated with this idea that I’m still working through – just being comfortable asking for mentoring. The other side of this is the “new blood” idea: change is constant, and junior developers not set in their ways are amazing at surfacing new ideas, techniques and technologies otherwise dismissed by developers more used to “the way things are”.
  • An Intermediate Developer will share knowledge broadly and seek opportunities to mentor those following in their footsteps. This is the time in a career where confidence is high and more risk-taking has been earned. Be opinionated! But lean on data over opinions. And so writing, sharing internally, leading prototype builds, attending conferences. Because career mobility is very high, aligning resume development with org goals can be mutually beneficial. And in my experience, this is a time where personal ambition and organizational goals can be quite tricky to balance – investing in someone who will leave later is not the goal – but nor should it be deemed a failure. While knowledge at this tier is high, it is still being solidified, dedicated time and practice of mentoring more junior developers can help mature the intermediate developer.
  • A Senior Developer will lead patterns and practices, and stress the details with fellow developers. This may seem counter-intuitive – I’m largely saying intermediate-level should focus on board ideas, while senior developers focus on sweating the details. This is for a good reason: a senior developer will understand a level of nuance in problems that may escape a more junior developer. I often like to say that as a senior developer, the most important ability is to know what you don’t know. But you also may have wider organizational exposure, so leading initiatives in code review practices, testing patterns, performance techniques, etc will have huge impact. Lastly, if a senior developer is not actively mentoring one or more junior developers, they are not contributing enough – but the fault may not be theirs! One thing I’ve seen time and time again is that organizations get in the way of this practice – whether formalized or not – by demanding huge amounts of output from senior-level developers (arguing, perhaps, that they are paid a lot, so should write a lot), and not providing time to grow the rest of the team.

There’s obviously a huge amount that can be, that has been written, on this topic. And, because it is a complex relationship (and it might be another post?), I’m not including Software Architects (and all variants of them – principal or emeritus engineers, etc), who while generally more senior, represent a specialized career track in my opinion, as do engineering leaders (tech leads, managers etc). The question of “what happens next?” when you’re a senior developer is definitely one we struggle with a TELUS, and something I’m thinking a lot about.

One last note: willingness to be wrong is another axis I think is important, where both junior and senior developers are more willing to admit to being wrong than intermediates – and I think this curve is a good sign of growth.

Role Fit

This question comes up a lot in context of the above – what comes next when you’re a senior developer? But this actually a really important conversation to have at all levels. I’m a big believer in the Pioneer / Settler / Town Planner model of types of work (note: that particular phrasing gives me distinct qualms, due to the genocidal history of pioneers & settlers in North America. Bear with me, please), that I believe Simon Wardley coined (at least, his writing was my introduction to it).
People are not all the same, and are not excited by the same types of work. This may seem really obvious, but I have only twice, in 25 years of doing this, come in to a company that didn’t essentially consider all developers to be the same person in some basic way. Maybe distinguish between front- and back-end, or developer and QA roles. Very little is done, in my experience, to help developer self-interrogate as to which kind of work they like to do, and sell all kinds of work as being equally exciting and important (see: unconscious bias).

  • An Entry-Level Developer should be given opportunities to explore various roles: both in style-of-work models, but also in specializations. Early-specialization is as problematic as early-optimization.
  • An Intermediate Developer will develop a sense of their preferred model of work: indeed, this might be the key outcome of this portion of one’s career. Note that having a preferred mode doesn’t exclude others – but it can help inform all sorts of personal career decisions.
  • A Senior Developer will have an understanding of their preferred model of work. Senior developers have experience, knowledge and a level of self-awareness that informs this. Everyone understanding this can help prevent square-peg-round-hole syndrome.

Note: Preferred working models can definitely change, either via personal interest or organizational mandate. But if as a developer, you find yourself struggling to fit in on a new team, reflect on this particular axis of work-modelling. Same for leaders, who’re not seeing the results they were expecting of a newly joined team-member.

Experience/time-in-role

I innately reject time-based markers of seniority for engineers, but nor do I want to completely discount them. But time-spent is not spent equally. An organization firing on all cylinders will grow senior developers much faster than one that is in disarray. I’ve also seen developers who’ve got 15-20 years experience who simply have not kept up with changing practices.

So… how do you tell what “level” a developer is? it’s not here yet, but I think but I think there’s a series of variables above that can help define that, but also an individual could easily advance very differently in each category, making these titles feel increasingly inelegant and arbitrary. Mapping these to defined organizational role-titles remains important though, because that how I can talk to my current team, and it directly affects compensation for them.

Reflecting on my own experience, senior developer is still, in the arc of possibility, not even the midpoint of a developer’s potential career progression. And that next transition point remains deeply interesting to me to think about.