What to expect when you become a Software Architect

Are you currently working as a software engineer hoping to advance your technical career? Are you thinking about applying for a software architect position? A career in software architecture can be very exciting, challenging and rewarding but you may wonder; what is it really like? How is it different from what you do today? (presumably you are currently working as a software engineer) Hopefully this post will give you some insight.

Ok, let's start with some context, the role or job title of software (or technical) architect can mean different things to different people, it really depends on the type of company you work for. For small to medium sized companies with agile teams it can be more of a role than a job title and for some larger companies it can be a job title which spans across several teams, there are no hard and fast rules here. In some cases, the role will come with tech lead, business analysis or project management responsibilities. It can also vary quite a bit when it comes to writing code, some software architects write code every day, for others its a few hours a week and others don't write any at all, it's just like the most common answer that a software architect gives to any question; "it depends".

It's very likely that some of the points below will not apply to your situation but I can only write about my own experiences, if you experience something different then please post a comment below. For me, I worked my way from software engineer to senior software engineer to senior software engineer with architecture responsibilities to a full time technical architect position (mid 2012), and yes I still write code, not as much as I'd like to but enough to keep me happy. Sometimes I have team lead responsibilities but generally the business analysis and project management is taken care of by someone else.

Right, with that out of the way, let's get to the important stuff...

You will have to talk to people

Of course you will have to talk to people, but as a software engineer you can generally sit at your desk for most of the day with your headphones on; writing code and communicating with your colleagues (who probably sit right next to you) via IM and email. Machines are so much less confrontational aren't they?

As an architect you will have to get comfortable with talking to people on a more regular basis, not just team members but people on all rungs of the corporate ladder. This includes everyone from the college grad who just walked in the door to the CEO, this is sometimes called the architect elevator.

You need to imagine the world through other people's eyes, to understand things from their perspective and then discuss complex ideas with them using language and abstractions which they understand, in other words, don't ramble off a stream of jargon and acronyms and expect everyone to get it!

It really isn't as bad as it sounds although it does take a little getting used to, especially if you are on the more introverted end of the scale.

You will spend (much) more time in meetings

Oh yes, get used to a calendar with lots of conflicting appointments, regularly trying to decide which meeting is more important or deciding who will be less annoyed by you not showing up for their gig, fun and games indeed!

You will write less code

Mostly as a consequence of the points above, you will not have as much time to write code as you used to. However, it is really important to stay fresh so try to set some time aside for coding, even if it is just proof-of-concept or throw-away code. I sometimes create a calendar appointment for myself to set aside some dev time, sometimes it works, sometimes it doesn't...

You will read more code

While you will write less code you will most certainly have read a lot more of other people's code. Whether you are analysing the functionality of an existing system or reviewing developer code commits you will need to get comfortable with reading through lots of code and understanding what it does (obviously). Following on from this, you must be able to give constructive feedback to developers when their code isn't up to standard.

You will have to research a lot more

If you think that you read a lot about technology now then you can triple it, at least! With the ever increasing pace of technological advancement you will have to read a lot more; technical articles, blog posts, social media, industry news etc, you will need to read a minimum of two to three pieces a day (maybe including weekends!) just to keep on top of the basics. Podcasts are another great way to absorb information while on the move but finding the time to read that (virtual) pile of e-books you bought over that last year is difficult, you might get to those during your holidays ;)

You will have to write business cases

As you are researching, you must try to identify up-and-coming technologies and trends which can improve your company's competitive advantage. If the CTO likes your ideas and if you can describe how to apply them in a cost effective manner then you will probably have to write a business case to convince the "powers that be" that your ideas will add business value and a return on investment.

You will have to write more documentation

Documenting a software architecture isn't just about pretty colourful pictures or beautiful whiteboard masterpieces. You will have to write design specifications, decision registers and documentation for frameworks and component libraries etc. While formal documents are often required (i.e. customer facing documents), in my experience a wiki is far more beneficial for internal documentation, in terms of writing speed, collaboration and the ability to cross reference various artefacts. As you get more experience you can start to structure your documentaton into a Architecture Description with views and viewpoints.

You will have to present more

When you have written a design proposal or business case and it has been approved you will probably have to present your design to a wider audience. Presenting to large groups of people is always difficult at the start, I have worked with developers who have turned pale when presenting to more than their immediate team so you might need to ease yourself into this one. Taking a presentation skills course is a good way to build confidence. One important thing to remember is that you are a professional and you probably have a broader range of knowledge than most of the people in the room.

You probably won't be an expert in all subject areas

Since you won't be spending so much of your time knee-deep in code you will generally find that you don't have the deepest knowledge in all subject areas. It's not your job to have the most expertise in everything, your job is to see the bigger picture, to understand enough to allow you to make decisions, to spot when things are going wrong and to steer everyone else towards your vision (and the CTO's vision) of the future state architecture. Your knowledge will become T-shaped.

This is also where talking to people comes into play, you need to find the true subject matter experts, befriend them, get them on your side an ensure that they trust you.

A very important point regarding subject matter experts, do not take the credit for their ideas and contributions, always, I repeat, always give credit where credit is due.

You will have to trust developers

When you have put your heart and soul into a piece of design work, something you are really proud of (and hopefully you developed a proof-of-concept yourself), it can be difficult to hand it over for others to implement. If you have written code for many years you will probably have a very clear vision of how the code should be written, down to minute details. As a software architect you will not have the bandwidth to focus on every minute detail so you must trust developers to do the right thing. Obviously you will pull them up on bigger items but you have to give developers some breathing room to make the smaller design decisions, otherwise they won't be on your team for very long!

You will have to take the blame if it all goes wrong

There is nowhere to hide, if there is a design issue with the software you will have to take it on the chin, role up your sleeves and get it fixed, pronto! Having your documentation in order really helps here, when you constantly have multiple projects running concurrently it is difficult to remember why you made every single decision.

Getting into a habit of consistently adding a few short notes to a wiki can really pay off, it can help you to retrace your steps and get to the root cause of the issue so that you can dig your way back out again. The Attribute Driven Design process really helps with this.

You will actually gain lot of respect from your colleagues if you take ownership of you decisions and readily admit when you are wrong.

You will probably have to interview people

This will vary depending on your company's structure but since you have a broad range of experience and work with so many people you will probably get roped into the recruitment process. This can actually be quite fun, I usually try to make my candidates laugh at least once during an interview.

Final thoughts

Becoming a software architect doesn't happen over night, it takes a lot of hard work but that isn't so bad if you really enjoy working with software. Whatever you decide to do, have fun!