From Designer to Software Engineer to Solutions Architect: my journey

I want to start this post with the regular disclaimer: this is my journey, and everything about it, is intrinsically bound to my nature as a person. A different person, under the same circumstances, may experience something totally different and get different results.

To explain how I got here, I have to go all the way back to when I was studying to be a draftswoman, and was supposedly going to continue my education as a (buildings) architect. Somewhere down the road I fell in love with CAD, with computers and graphic design, and even got a job at a printshop after a Photoshop, Quark and Freehand crash course.

In 2003 I moved to Spain. Immigrating is difficult, especially when you have to support yourself entirely. But when I did I was lucky to have over 5 years of experience as a graphic designer, and it was easy for me to get a job working for a small agency as soon as I moved here. We published a magazine focusing on real estate and after a few months I was promoted to Creative Director to be in charge of the magazine and the corporate image of a few clients. I had a couple of designers in my team, and it was fun.

Plot twist

One year later, it was evident all business was moving online. Youtube was about to be born, Facebook was in diapers, and everyone wanted to have online presence. I convinced the manager we should have a website, and we should try to build an online version of the magazine as a portal.

"We need a web developer for that" -he said. "I will be the web developer". I answered.

I started spending all my spare time learning Action Script. I was amazed at those full screen Flash websites, featuring gorgeous animations and graphics. I wanted to learn to do that. For the portal, I learned HTML, CSS, Javascript, PHP and mySQL. I was amongst the first avid consumers of online tutorials and web development books.

I experimented with Joomla, Wordpress, and finally Drupal.

And then the 2007 crisis hit us hard

We could keep the boat afloat selling websites, exclusively. I would be in charge of designing the websites, managing the databases, the hosting, setting DNS records, configuring htaccess, installing the CMS and plugins, developing frontend, and doing the maintenance. I was a true "webmaster" of the time. I loved it!

But in 2011, we hit rock bottom. Most of our clients were developers and real estate agents, that bursted together with the real estate bubble. They had to close business, and so did we. I started freelancing.

Being a freelance web developer, is a 24/7 job

If you're not working as a consultant for a much larger company and you have your own clients like I did, it's tough work. You're the sales person, the architect, the PM, the designer, the developer, the quality engineer, the tier 1 to 4 support person, the systems person, and the back office cashing the checks...you're it all. There are no evenings, no weekends...

Being a mom and a freelancer, was the most challenging thing I ever did. I breastfed my kid while patching 10 Drupal sites for heartbleed. I ran to school while holding a call with a client.

Getting a job in enterprise

So in 2014 I sent my CV to a consultant company (the same one I work for right now), with little hope. I had no CS degree, and all I had read around was I stood no chance to land a job in that league.

But I did land the job as a Frontend Developer for Adobe Experience Manager projects. I had to move to Barcelona, with my family. It was an immense bet. And you can say fortunately, it went well. Although it was not only fortune: there was always a lot of hard work involved.

It was not only fortune. There was always a lot of hard work and persistence involved.

The enterprise context has particularities, also. Working on enterprise you also learn a lot about politics, policies and processes. ;)

Getting acquainted with Adobe Experience Manager

Up until that day, Adobe was for me the company behind Photoshop, period. (Aaaand the company that had bought Macromedia and decommissioned my favorite ever vectors editor, Freehand ... :/ ) I had no idea they had also bought Day Software and had a CMS.

I was very comfortable with content management systems, and it did not take me too long to wrap my head around how it worked. Some frontend developers want to stick to frontend code only, and it's respectable. But I was coming from a different kind of dynamics (see the freelancer part!) and I was happy to traverse the whole stack.

My first role was as a Frontend Tech Lead for a very large platform being built from scratch. One year later, I was moved to a banking platform where I stayed for 6 months. Then I was assigned to a new account we had just gotten, as a tier 3 support and solutions engineer for a massive legacy platform. I was again in the role of Frontend Tech Lead, and I know a lot of people dislike working with legacy software, but I can promise you the amount of knowledge I was getting every single day working with it, was priceless.

The amount of knowledge I was getting every single day working with legacy code was priceless; the problems I had to solve were unique.

In my opinion, no other experience is better to understand coupling, dependencies, and acquire an overall overview of a system.

Plot twist, again

Apart from support, we were integrating new features, and at some point we decided we did not want the risk to build anymore on top of it, we wanted to go for cutting edge technologies. So a little bit more than a year later I got my first architect gig, working in the conceptualization and definitions of the 2.0 version for the same platform.

I fell in love with designing systems. It is a lot like building with legos. And I could apply principles learned while studying to be a buildings architect. After all, you want the same for your buildings than you want for your systems, for them to meet quality standards, to be resilient, secure and durable, amongst other things.

My first pre-sales experience was intense

In August 2017 I also attended my first RfP workshop. A global leading brand issued a RfP (request for proposal) for a very large enterprise project and I helped in putting together the whole DevOps strategy, and then travelled onsite, together with the Account Manager, a UX Engineer, and two C-levels, to defend our proposal.

I had to present the whole DevOps offer.

We won.

Conferences and public speaking and how they help me in being a better architect

Being an architect is a lot about communicating. You have to communicate your ideas and definitions or decisions to a team, other project leads and the clients. Translating those very technical concepts into simpler words and concepts any audience can understand demands highly developed communication skills. You need to be able to articulate and convey with simplicity, what sometimes are very abstract ideas.

Speaking at conferences and other technical events, has definitely helped me grow more comfortable into that presenter role. But I have to admit it is never the same talking to a crowd of peers or other developers, than to a customer.

The key is, no matter who you are addressing, you need to build rapport. And the most optimal way to build rapport is to identify with the more human side by providing structure to your narrative in a way that it becomes a story your audience can relate to.

Always, always put some work in your communication skills. Especially if you want to become an architect in the future.

Collaborating with sales teams

Typically, Solutions Architects have more of a backend/systems background. 4 years ago, it was already obvious to me that as the volume of frontend work was growing, the integrations were more complex, and there was a lot more to put together nicely. The role of a frontend expert during discovery phases was not only necessary, it was essential. I started paving the way to get there.

I joined a sales squad operating in northern Europe, in parallel to being a hybrid Tech Lead/Architect at the project I was assigned to (the one we won!).

As part of that team, I review code bases of potential clients/leads, join meetings to understand their problems and requirements, write architecture vision papers from infrastructure to tech stack, estimate and define timelines, estimate staffing needs, etc. Before COVID, I was traveling places to present those analysis or gather more information, or to build a connection with the clients, or to educate them on a certain subject.

Sometimes I would fly for the day only to Amsterdam or Copenhagen, sit in a meeting, and come back in the evening right on time to have dinner with my family. It was exciting, but also intense, and if you want that, you have to be prepared. On the way there, I was putting together slides and documentation for that meeting. On the flight back, I was reviewing PR's from my own project.(Thank you Norwegian and all the airlines that have wi-fi onboard!).

Leaving the tech lead role behind

At some point last year, we started working on a brand new concept that required a lot of high level definitions and I was officially anchored to the Solutions Architect pathway. In the context of the project I work at, I already had the architect role officially for 2 years, as part of our Holocracy organization.

Every company has their own role definitions and people energizing them are expected to deliver in different ways. At my current company, architects are definitely very hands-on. Our culture promotes and celebrates the intersection of architect and lead developer.

However, the domains where architects and tech leads work, although intersecting, are on opposite sides of the high-level design imaginary line. For those that are not familiar with the differences, this diagram may shed some light.

What does an architect do?

Architects are in charge of high level definitions of a system. They are the connecting point between the business vision and requirements, and the technical know-how. Even if they can, architects will not care about the nitty gritty details of the implementation.

Architects are the connecting point between the business vision and requirements, and the technical know-how

That is probably the part that is more difficult to detach yourself from, when you transition from being a tech lead. When you review a pull request, your input is not really so necessary in terms of "You could've used this method here, instead of this other one". Your concern is the big picture.

In fact, you will find yourself less and less in contact with other developers, and working more on your own or with other architects, requirement engineers, system engineers, and quality assurance leads. That is probably the hardest part of the transition.

Also if you come from a frontend technical lead position, you will be less in the spotlight. Work at a high-level is less tangible and visible, but equally important.

The day to day

As an architect, most of my (project) day is spent on client calls, team meetings to align the rest of the team on decisions made, partner calls, working on diagrams and documentation, and executing proof of concepts. I am more concerned about API design and integrations, data storage, security, performance, CD/CI pipelines, releases and rollouts. I care about my client's system being legally and standards compliant.

I am no longer part of the development sprint, and I don't deliver tasks in the scope of it. Do I miss it? I have to admit that I miss it less and less every time: for once, I really like what I do now. And I also enjoy tremendously the ability of delegating and seeing other people grow in the same direction I did.

My sales support day is spent supporting proposals and discovery, attending meetings with leads, writing architecture visions, reviewing concepts by other architects, and preparing educational material pre and post sales. So everything I used to do before COVID, minus the traveling.

The skills required to become a solutions architect

Let's map what I do, to the skills I find the most useful. The soft skills required to do a great architect job are:

• Communication skills (ability to articulate but also to listen)
• Presentation skills (put together great diagrams, and concise slide decks)
• Diplomacy (you're at the front line with the client. It's all about business and especially in enterprise, you have to use a lot of patience and good manners)
• Manoeuvring (because of working together with the client, you have to have the capacity to manoeuvre and respond fast)
• Analytical skills (your job is all about solving abstract problems, designing or fixing systems that many not even exist yet)
• Leadership skills (you have to lead your team and your client's team. You have to bring everyone onboard with what's best and the decisions made -which is a complex topic, sometimes, may not be the absolute best, but the most convenient in terms of parameters like time and budget-)
• Ability to estimate and staff a project
• Ability to prioritize

The technical knowledge is also different than the one you needed to have as a tech lead. Apart from mastering a programming language, right now in 2021 I recommend you specialize in

• cloud providers and their offerings
• concepts like horizontal and vertical scaling
• concepts like replication and sharding
• serverless computing
• databases
• API patterns and contracts
• CD/CI and how to build your pipelines effectively
• automation
• containerization
• orchestration
• architecture trends (like micro-services)
• design patterns
• UML and different types of diagrams (flow, mindmaps)
• security and protocols (networks)

If you have a frontend focus, you can check this mindmap of useful skills I put together a bit ago

https://twitter.com/AnfibiaCreativa/status/1331565865196777472/photo/1

Additionally, stay up to date! These are some of the architects I follow to keep myself informed on architectural trends. This list is relevant for me, you may need to find your own good sources ;)

Luca Mezzalira
Manfred Steyer
Martin Fowler
Dan Wahlin
Gabriel Walt

Do I feel like my coding skills are suffering?

Not for now, for sure. I spend a lot of time coding, and being a GDE and other community activities I do, help with that. I see myself coding for a very long time, and my new focus only adds value.

Finally

Another very important skill is the one of receiving feedback and acting upon it. If you want to become a great architect, find people that have been doing the job for a long time (this is valid for any profession, of course) and ask them for feedback and mentorship. Ask them to assign you tasks in areas where they see you're the weakest, so you have the chance to gain experience.

And...enjoy the ride!

PS: Thanks to Mario, Ina, Conrad, Tomasz, Andreas and Georg, who have been those mentors for me, from infrastructure, to architecture to soft-skills.