35 Things I Learned in my First Year as a Software Architect

The Matrix Reloaded — The Architect Scene

Introduction

Having served as a software architect in a number of small startups (less than 30 engineers), I had to quickly ramp-up in order to meet the needs of the role. So I thought it would be an excellent idea to tell about the journey, in the hopes of helping others like me in a similar position.

So here are 35 things that I wish someone had taught me before I got started!

Note: This article is a bit long — if you read the headlines only, it should take only a few minutes. A deep dive should take about 10 minutes.

TL;DR

The Architect’s role can be enormously influential. To maximize impact, focus on your genuine added value to the R&D team, instead of pushing the buzzwords that are currently in fashion.

General notes/remarks

• There is no clear definition of the software architect’s role. You can go dig for information but the truth is: You are most likely to shape the role while learning, designing, coding, and reviewing.
• The architect/lead developer is responsible for a major part of the software development cycle. The following notes can help you better grasp the role, its position within the company/group, and how the role influences others.

People

Photo by Scott Blake on Unsplash

• A large portion of your time will be dedicated to recruitment, onboarding, guiding, and mentoring. The right selection of team members and proper guidance will help you shape your vision through others.
  Examples:
  Choose your employees wisely. If they share your enthusiasm for a concept, they will help you promote it among the team members, and within the organization at large. When mentoring, make sure you are consistent in your design decisions. Contradictions will slow progress and lower your team’s motivation.
• Structure your codebase so that teams can grow from inside it. The architecture you select will affect your current staff, their skill sets, and their work practices — as well as future recruitment needs.
• Mono-repo vs Multi-repo. In case you missed out on the buzz surrounding mono-repo during the past few years, it has become common to put the entire codebase of a company into a single, company-wide repository. There are a few disadvantages, but from the team’s perspective, there is a huge built-in advantage: everyone can learn and contribute immediately, without barriers.
  When repositories are divided according to expertise or knowledge domain, it becomes difficult to share code and information, and each employee’s contributions and abilities are “siloed” and remain inaccessible to other teams.
• Detach part of your codebase for future use by external groups — say, offshore teams. To accomplish this, implement a separation between your core components and operational modules.
  Example: Separate operational domains, such as analytics, reporting, admin functions, and web applications for 3rd parties.

Design

Photo by Med Badr Chemmaoui on Unsplash

• Building stuff — no matter what — requires the same methodology. If you are building an Ikea desk, constructing a highway, renovating your kitchen, or re-designing a complete code base, you’ll still need to break down complex problems into small, discrete tasks.
• A good design can be measured by many parameters, but the key for success starts with a well-documented process that encourages team members to engage, contribute, and push boundaries — from day one.
  Example: Create a simple design document that encapsulates the entire process. The main topics to be covered are:
  - General concept
  - High-level flows
  - Business needs
  - Quality metrics
  - Performance indicators
  - Out-of-scope issues

Technology

Photo by Tudor Baciu on Unsplash

• The best way to achieve consistency is to automate critical processes. Once processes are automated and begin to indicate “success” and “failure”, project management is greatly simplified.
• All best practices should be fully automated, otherwise, they may not stand up to the test of time.
• Create a value/cost calculator, and use it to share your analyses with company management — it will help them understand the decision-making process. For example, it can be used to choose between vendors, say those offering an open-source solution vs. those offering a managed solution.
• Programming languages, libraries, and frameworks are only a means to an end. You must have strong programming beliefs of your own if you want people to follow you and ignore the “flavor-of-the-month” hype. These beliefs will be a compass for you when navigating rough seas.
  Example: Always try to tackle problems based on a complete understanding of the issues at hand — rather than invoking a specific library name when discussing a problem. Remember that people tend to be emotional (and even aggressive) when speaking about their own preferred libraries.
• Tech decisions should always be made in sync with business decisions.
  Example: Launching a new product should be fully coordinated with the company’s ability to support that product.
• Do not limit your tech engineers to pure R&D work. Collaboration with other groups will benefit everyone.
  Examples: Engineers that work closely with talent acquisition personnel usually display enhanced loyalty to the team and the cooperation generally results in better quality hires. They can also help improve the performance of the customer success team.
• Lastly, be consistent in your beliefs, and don’t compromise on urgent new features that may reduce product quality.

Quality

• One Templates can be created for meeting notes, design concepts, and debugging processes.of the architect’s first tasks is to adjust your team’s quality philosophy. The philosophy should reflect your deeply-held beliefs in software design, architecture, and development. Nothing should be left to chance.
  Example: Decide what should or shouldn’t be tested. How to test, and how to measure. Manual vs automated techniques.
• Quality management is an ongoing process, involving methodology and efficiency improvements. Quality design should reflect the characteristics of your product lifecycle.
  Example: A/B testing, pre-release testing, quality control testing during production, shift-left/shift-right approaches.
• A good quality design will feature an evolving combination of automated tests, manual tests, and code quality monitoring. Always look for added value.
  Example: Manual testing should be adapted to include UX feedback. QA teams should be encouraged to provide feedback on a variety of disciplines.

Influence

• You will spend a lot of time convincing your colleagues, managers, and team members about your agenda, philosophy, and decisions, therefore:
• Learn to be a “people person” who can build a coalition of partners to support your cause.
• Your pitching skills should be as good as those of a serial entrepreneur.
• Your design concept presentation must be first-rate, in order to effectively present new concepts to a wide variety of audiences.
• Use analogies to make your presentations more convincing. Be sure to pick your analogies carefully, making sure you are not offending anyone by giving negative examples of people/organizations/occupations. I strongly recommend using construction analogies — such as roads and buildings. The similarities are everywhere.
• People tend to criticize new processes, but it becomes manageable if there is a well-documented process in which everyone understands what is expected of them.
  Example: Let’s say that you want to introduce a pair coding process to the team. Merely assigning tasks to team members is a recipe for failure. Instead, provide a well-documented process description that will reduce friction between them and give everyone a chance to speak and influence the decision.
• Delegate responsibility and lead by example. Show how things can be done, and how you are using the complete set of tools you have, and guide them to achieve better results.
• Provide guidance on delegated tasks until it is not needed anymore. It may be a bit uncomfortable at first, but with the right balance between guidance and independence, your colleagues will make you a better leader than you ever dreamed of being.

Workflow

• Creating templates will make your life much easier.
  Example: Design review here(link to upper bullets)
• Templates can be hosted on repositories, exposing the same CI/CD pipelines, code guidance, security, audit, and linting.
• Templates can be created for meeting notes, design concepts, and debugging processes.
• Templates can be used for the exploration of new features.
• Templates can be useful in preparing for job interviews.
  Example:
  - Question pools with no right/wrong answer, but that measure depth of understanding.
  - Pre-prepared technical questions, gathered from the team’s day-to-day tasks.

Culture

• Never get into an argument on Slack/WhatsApp/Instant Messaging without a proper video call.
• Maintain a sense of humility and keep your ego in check — many interpersonal challenges await.
• Open communication with all stakeholders is vital for your team and the company to thrive.
• Be open to changes, open to criticism, and open to learning.