Role of a Staff Engineer
I see this question asked many times — What do Staff Engineers do or should do?
Today, I thought of writing about my experience being a Staff Engineer having worked with small, medium and large teams. Most of the things in this blog are taken from the book Fundamentals of Software Architecture by Mark Richards and Neal Ford.
Expectations from an Architect
A staff engineer is an architect responsible for architecture decisions of the business domain he works in that ties back to the overall business domain of organisation. This involves lot of things as mentioned below
Making architecture decisions
The most important rule about architecture is Everything is a trade-off. Whether to choose REST or GraphQL, an RDMS database or a NoSQL database, doing synchronous communication between services or asynchronous — there is no correct answer but the fact that It Depends.
An architecture depends on many factors such as deployment environment, business drivers, budgets, developer skill set to name a few. It is crucial for architects to analyse the trade-offs behind every decision. It’s like challenging your own thoughts and be your own critic. We as an architect like it or not, until we analyse the trade-offs, our decisions will be short lived.
On the other hand, we should avoid getting trapped in the Analysis Paralysis and not make any decision. Rather take a data driven approach, record your architecture decision and move on.
Architecture versus Design
An architect typically is responsible for analysing the requirements and selecting technology and patterns to solve the problem at hand. The artefact produced by an architect is usually high level system design and then handed over to development team to create low level design artefacts like class diagram, ER diagram,API Contracts, UI screens and ultimately develop code.
If the architect just hands over the HLD and leave the rest to the development team, it will be difficult to ensure that architecture decisions are carried over into LLD and ultimately code. There is a need for architect to be part of low level designs either as a reviewer or collaborator.
Business Domain expertise
Architecture decisions are made to solve a business problem using technology and business domains evolve with time. The hard part is being able to foresee the changes that can be made to a business domain for example, by extending a particular service to other similar problems. I have worked in teams where the business domain was very complex and I did not have complete understanding of domain, as a result my decisions were short lived and often challenged by changes in business requirements. As architects, we want to build systems that can be extended not re-written as business evolves.
Technical Depth versus Breadth
Every architect started as a developer to get technical depth of technologies and languages that they need to do their job efficiently. As an architect, however you need to have breadth over depth. This is essential so you can look from different perspectives while solving a problem. A problem can be solved in many ways using different technologies and patterns. If you restrict yourself to a particular technology, you will not know that there are other ways to solve the problem which may be better than the only way you know of. So it is important we spend time daily on self learnings — reading blogs, books on system design.
To code or not
I strongly believe that every architect should be hands on with coding. But there is a need of balance between coding and architecture work. Maintaining a balance is really hard between the two. As an architect, we cannot become bottleneck for a project. For instance, if there is a need to write abstract framework for services, then if you decide to do it yourself you are risking the whole team’s velocity if you don’t do it on time. A better approach will be to delegate it to developers and be part of design meetings and code reviews. For maintaining a coding habit, we have a few options — optimise an existing code for performance or pick a tech debt (nobody is waiting for it to be completed in a sprint).
Another option is to do Proof of Concepts yourself. This has multi-fold benefits — you will yourself find answers to most of the questions you have from the technology you are trying to adopt, you will be able to address queries of other developers in team, you will visualise the coding standards you would want to put during implementation phase.
Coding would also help you to identify the pain points that developers are facing in day to day life.
Finally, I would like to end this blog with these rules I learnt about architecture :
Everything in software architecture is a trade-off !
Why is more important than how !
