I generally like to keep this blog focused on technical things, but with 2020 careening towards the end of the track, I want to get a little bit retrospective. Earlier this year I was laid off from my job, in large part because of the economic situation surrounding the COVID-19 pandemic. I was able to find a new position, but I learned quite a lot of lessons along the way. Today I’m going to talk a little bit about that, and the realities of being a software architect.
The first time I was offered a position as an Architect I stopped and asked a couple friends of mine who had the title, “What does it take to be a good one?”. It’s been a couple of years since then, and I can’t remember exactly who said what, but I do remember the deep sense of respect I had for the position. I knew what a good architect could do for a team and for a project, and I didn’t want to take that title for myself if I didn’t think I could do it justice. I thought it was a lot like being a developer, just more experienced and more respected and better-compensated. It turns out it’s a very different role in a lot of ways and if I had known that I might have done things a bit differently.
I had a position where I was doing good architect work. I was designing good systems. I was writing good code. People came to me with design and algorithm questions, the tricky kinds of technical problems that other people couldn’t answer, and I did my best to always come through. My name was attached to all sorts of big development projects and wishlist items stretching out past Q4 of the year after next. I thought I had job security.
Then there was a crunch. The company suddenly had to do a round of layoffs, and after a tough conversation and a couple of apologies and promises of being references, out the door I went. It stung at first. I was confused. I felt like it was a failure, and I had disappointed the people who depended on me. But, with some down time and opportunity to really think about what happened and why, I have come to understand it. I’m no longer sour about being laid off. I no longer think I was let go because of a failure on my part. I don’t think there was any way I could have saved it. Instead I have come to appreciate and respect the difficult decisions that had to be made. The only failure was that I should have expected it and prepared myself better. Now I know, and I won’t suffer that same failure again.
Some roles on a team are very tactical. These are the people doing the day-to-day work: keeping the servers running, handling customer complaints, developing the features this sprint which are going into production at the beginning of next sprint, making the machine keep rolling along from one day to the next. These are the people who are directly in the hot path between customer requirements and delivered software. In short, tactical people make sure you don’t lose the customers you currently have. Other roles are strategic. These are the people who give the company a future: big plans, long-term roadmaps, Research and Development. Strategic people are the ones who help lead the company from what we have now, to what we want to have in the future. Strategic people help to bring in new customers and drive future growth. Architects, pretty frequently, fall into the second category. Architects are strategic.
In good times you want strategic people on your team to be giving you a good future and making sure that you meet and even exceed your projections. You want to attract new customers with better product offerings, and you need to make sure your enterprise infrastructure can support all that new traffic when it arrives. But every once in a while times aren’t good. Sometimes you’re in the middle of a pandemic-fueled economic downturn which has exploded all your projections. The company is losing clients. The company is hemorrhaging money. In those situations you don’t have the luxury of worrying about the future. You need to focus on just keeping the lights on. Tactical people are the ones who help stem the bleeding. Strategic people start feeling more and more like a luxury that the company can’t seem to afford right now. Especially the ones associated with big line items on your balance sheet. Architects, for the most part, are big line items, at least compared to some of the other resources on the team.
(Note: I don’t mean to assert or imply anything specific about the financial situation of my former employer. The fact is, I was an Architect, not an Accountant, and I honestly don’t know what the balance sheets or revenue predictions looked like during the heart of the pandemic or at any other time. All I do know for certain is that we were having an economic downturn and I was let go from a position I thought I held securely in the middle of that. The rest is just speculation but it doesn’t change the thesis of this post.)
A lesson I often keep in mind is this: You don’t get paid according to how hard you work. If that was how the world works, miners and trash guys would be living the good life and I know more than a few lazy middle-managers and developers who would be sitting in cardboard boxes begging for change. Instead, very frequently, you get paid according to how hard you are to replace. 10 years of on-the-job experience isn’t something that just any person can pick up in an afternoon at the library. The pool of available candidates shrinks as you begin looking to fill roles which require more knowledge, more experience, and more expertise in the specific technologies you depend on. I’ve experienced this on both sides of the interviewing table. As an interviewer, I have seen that high-level positions like architects and team leads are extremely hard to fill. I have interviewed many dozens of candidates for these kinds of positions, and among the special few who made it through the technical screen to talk to the hiring manager, an even smaller number were able to receive an offer. As a candidate, I have been in interviews where I had all the experience and qualification that the team wanted a candidate to have, and still I turned out not to be right for the job. It happens. The needs of the organization can be pretty specific at times. Architects can be difficult to replace.
This is why I have a lot of respect for the people who were able to let me go. With as much value as an architect can bring, how hard they can be to replace, and how much of the long-term roadmap they impact, deciding to let one go has to require some serious courage and determination for a manager. When it comes down to a question of needing to lose people, and also needing to keep your tactical people so they can help retain your customers, it makes good sense to start chopping strategic people. And, if you’re cutting, it might make better sense to lose a couple of the big line items off the top than to lose many small line items from the bottom. It must be easy for a cowardly manager to ignore that kind of decision, kick the can down the road and hope the business problems fix themselves before anybody has to get let go. It takes a lot more courage to get in front of the train and tackle things head-on. If I had better understood the strategic nature of architecture, I would have seen this coming and better prepared myself for it. Now I know, and I will be prepared for next time. (Hopefully, of course, there won’t need to be a next time.)
As an architect, developer, team lead, and all the other roles I have played over the years, I feel like I can be a pretty valuable guy to have around. I have seen the kinds of positive impacts that my work has had on projects and organizations. I have seen the ways I have been able to help teams grow and improve. But, I also know that no matter how well-liked I am, or how much success and value I bring, there is no such thing as perfect job security. There are times when it may be desireable or even necessary for a company to let me go. I can’t just work harder and get better and produce more to avoid it, no matter how much I wish it might be the case. Sometimes you have to go. When the time comes, if you’re properly prepared, you can use it as a springboard into new and better opportunities.
Start by asking yourself: Am I redundant with other resources on the team? Am I too expensive for the team to afford? Am I delivering enough value to justify my cost? Is the team too top-heavy with technical leaders and managers? If revenue suddenly drops by 10%, or 25% or worse, am I likely to stay or likely to go? It’s a necessary self-assessment that every developer should take, especially as you start climbing the ladder of experience and seniority. You need to decide if it’s worth the extra money, when offered a promotion to architect, knowing that you may transition from a tactical role to a more strategic one. Some people will say “no” to that question. I know that I said “yes” to it, but the only way to give an answer at all is to understand the issues at stake.
If you know what to look out for, the tough conversations won’t be a total surprise when they happen. Know that, in a crunch, the highly-paid strategic people are the first to be shown the door, the under-paid tactical people will be the ones who turn the lights out and lock up when they leave. Everybody else will be somewhere in the middle. If you can figure out where your place in line is, you’ll be able to be proactive instead of reactive in what happens next.
This is something developers should know and understand before making the jump into architecture, or jumping from a technical role to management, or any of the other many possible transitions that may happen in your career. It seems like it’s just more respect, more seniority, more responsibility and more money, but it is a fundamentally different thing that brings new risks and realities. Prepare yourself for them.