The Rise of the Full-Stack Architect

Pebble stack, Wikimedia Commons, Zzubnik
Pebble stack, Wikimedia Commons, Zzubnik

Full-Stack Web Architect needed with the experience with web services, back end Web platforms, databases, cloud based hosting such as Heroku and AWS, visual design, UX/UI, experience of mobile web development, all in agile environment.


An actual 2014 posting for a job based in London, UK

Ta-da – the moment has come. In post #2 of this blog, I promised to formally apologize for calling myself ‘an architect’. Only 39 weeks later, I am making good on the promise. Procrastinating much?

The hate on architects ebbs and flows, but never fully goes away. This creates a horrible problem for experienced developers who are fascinated with technology and are not overjoyed with becoming managers, yet clearly need to be in a leadership position of some kind because they are kicking them out of the developers’ kindergarten (what do you mean I am too old to hang around the playground, and why is it ‘creepy’?).

Management has been a traditional career growth path, and some still believe it is the only smart choice for former developers (kids, if you never before saw click bait, here it is):

From my chair, everything points in a different direction. Wherever I look (including my own company), hierarchies are being flattened, leading by example and by inspiration is replacing pulling the rank, and some companies are eliminating management altogether. So management is receeding as a leadership model to aspire to, but architects are being openly mocked:

So what is an experienced developer with so much to offer to younger colleagues to do? Looks like we are stranded between Scylla and Charybdis of the software leadership career paths. But it is a false dilemma. Bill was clear about this in his blog post – you should aspire to be a leader, to have a vision that inspires people and makes them follow you of their own will, not because they report to you. Somebody else can handle TPS reports, and you can focus on leading a growing group of people in making awesome products, and enjoying coming to work every morning because working in such an environment is intoxicating. Then you move the hell out of their way and let them do the work – they can do it better than you anyway.

OK, figured it all out – have a breathtaking vision, generate a growing following, solve the world hunger, and still have time to catch up on the new episodes of Silicon Valley on HBO. Got it.

Meanwhile on planet Earth…

For us lesser souls, some more attainable pointers:

  1. Be a wise sage – your experience with waves of technology allows you to notice repetition – new generations of developers re-solving problems from 5 or 10 years ago. When a puppy developer comes to you with a very cool client side MVC framework, point at the geological layers of MVC in the past technologies. Do that not to disparage the new framework, but to look at it for its own merit, not because MVC is a revolutionary new concept (you will know it is not, but chances are your junior colleague will not). Warning: don’t be an old fart for whom ‘things are not as good as they used to be’. That’s nonsense – a lot of things are many times better now, so be on the lookout for the first signs of being stuck in your own ways and nip it in the bud.
  2. Look over their heads into the future – there is always so much to do every day, and so few hours before your caffein-induced code turns into garbage. Allow developers to code like beasts, solving the ‘now’, while you look ahead, planning where you need to be in 3 months, 6 months, a year. Don’t try to go too far – we are all in a transition, and things are insane now.  Long term predictions have become somewhat useless lately, so ensure you have enough vision to prevent the team go idle, and be prepare to tweak the vision when course-correcting data becomes available.
  3. Resolve technical disputes – as fiery technical debates would indicate, there are many ways to skin any technical cat (a metaphor, I don’t condone skinning actual cats). One of your key jobs as a technical leader is to ensure the entire system works, and that can only happen if all the parts of the system speak the same language to each other. In other words, as long as everybody uses the same protocol, and that protocol does not suck too much, it is better than when parts of the system use superior but incompatible protocols.
  4. Prefer practical over pure – architects are often derided for making everything more complicated than it needs to be. Don’t do it. Look at the most popular APIs today – they may not satisfy REST police but they are clean, they work, they are stable and well documented and the deviations from the ideal actually solve some real world problems for developers.
  5. Maintain street creed – you can only lead developers if they respect you as one of their own, and that can only happen if you continue to code. Don’t put yourself on the critical path because you will spend too much time heads down, which will prevent you from doing (2), but you need to know what you are talking about. That requires that for every library or framework or protocol you want to recommend, you need to educate yourself, write some real code (sorry, more than just Hello, World) – give it a serious test drive.
  6. Don’t practice drive-by architecting – nothing irks developers more than an architect that designs a system, provides all the specifications, drops the finished docs on their poor heads and disappears, leaving them to suffer from the consequences of the poor choices. You need to see your architecture live in the running code, solving problems. Nothing makes me happier than developers gobbling up the new architecture and moving to it as fast and they can because it addresses their long standing problems. As a colleague of mine would say ‘the devil is in the pudding’ – if the system using your architecture is not faster, more scalable, more maintainable, your architecture sucks.
  7. Be a connector – just because people don’t officially report to you, it does not mean that you are free from practicing your soft skills. You need to talk to design, engineering, operations, product management – all speaking their own distinct languages. More importantly, you must be able to do it without strangling somebody with a Cat 6 cable. That privilege is reserved for developers, you need to be above it.
  8. Have cloud, DevOps and Web-scale in mind – practically all modern systems today are distributed systems running in data centers. They need to be evolved using Continuous Integration, features need to be promptly deployed using Continuous Deployment, services need to be clusterable, scalable and redundant. Architecting a system today without keeping these in mind is a recipe for a career spiral of death.

If you follow the suggestions above, you are really ‘system-developer-in-cheif’. Note that you are not a team lead even though it may sound like it – you are a ‘system lead’ serving a number of teams that already have team leads. You are a ‘how everything fits together lead’, which is too long to write, so for practical reasons, we will call you an ‘architect’. There – we closed the full circle.

What about full-stack?

In the olden days, developers have been segregated by their skills, because different tiers of a complex system were build with such a divergent technology that it was really hard to keep it all in your head. SQL experts were not very good at building backend systems with SOA and other bloatware, which was very different from writing Web sites with server-side MVC, which was very different from client side Ajax. Conversely, architects followed suit – they specialized as well.

With the dawn of the ‘JavaScript everywhere’, with NoSQL databases storing and passing around unstructured JSON, Node.js servers with JavaScript templating engines running on both sides of the fence, and MVC client libraries, a developer can theoretically write a whole system – soup to nuts. I say ‘theoretically’ because while the language context switching has been removed, the problem domains are still very different. There is actually a growing need for a breed of architects to ‘make sense of it all’ and devise and evolve a system that does not explode from the very wealth of choices that are now around us at every level.

Ad sense

Look at the ad at the top again – nothing in it surprises me, and I understand the motivation, but boy – that guy or girl is going to be one shiny unicorn, and I don’t know if there are very many prancing around with all those skills.

You know what, lets have fun: let’s see if I could get that job by a very scientific method of dissecting the ad and trying to match it with my blog posts. For this exercise we will be using a simplification that I actually possess in-depth knowledge about topics I write about (which is not a foregone conclusion, but let’s not go there):

As Magnus Pyke would yell – ‘Science!’. If this IBM thing does not work out, I should give them a call. My point was that there is a dire need for ‘making-sense-of-it-all-in-cheif’ in every large team. Again, this is too long, so we will call this job ‘full-stack architect’. If your company is large enough, there could be additional career ladder titles such as ‘Senior Technical Staff Member’, ‘Distinguished Engineer’, ‘Fellow’, but I really dig full-stack architect, so I will call myself that from now on.

Here is hoping that one day soon some future George Constanza will lie to people that he is ‘Art Vandelay, Full-Stack Architect’.

© Dejan Glozic, 2014

2 thoughts on “The Rise of the Full-Stack Architect

Add yours

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at

Up ↑

%d bloggers like this: