In recent years I have been working as a Software Architect in multiple organizations including technology companies and high-growth startups. Being both an individual contributor and a manager of an architecture team. I realised that there are three most important principles that help me to do my daily job. I always try to get all the decision contributors on board, try to understand the business and cost impact and take my time coding. There are some more principles I could find important but those three I find astonishing. They are my personal triangle of success (thanks to HBO for the name inspiration).
If you are not convinced why architects or technical leads are needed, you may want to check my other story first — Software Architects and Autonomous Teams.
Make your crew share the mission
It’s easy to get into a trap that it’s enough to convince only management in your decision or just establish a rule as an architect. Nowadays we have autonomous teams living with isolated microservices and teams have to balance conflicting priorities. It’s easy to cut the corners or take the shortest path. If you do not convince people why a certain decision is important, they simply might not find enough time to follow it. Make sure everyone understands the mission and is highly motivated. Afterward become a part of the mission yourself by hands-on contribution.
Involve contributors in making the decision
Before calling any idea a decision, present it to the people who would directly work on it. First, you get a valuable feedback and second you make sure that decision is shared and understood. At @ebaytechberlin we found that Architecture Decision Records presented as a pull request work pretty well. But before making a pull request there are other steps you should take.
Discuss technical idea on the whiteboard first
I find that nicely written down proposals are harder to change. As soon as any human invests a significant effort into something, emotional attachment comes into play. In this case, you can be biased towards the initial proposal. Better to present your ideas as a draft and discuss the ideas of others on the whiteboard first. This allows to have more discussions and adopt the proposal on the fly by moving together in the right direction. The instrument could be not necessary a whiteboard but e.g. a pull request. The idea is that initial proposal should support flexibility of changes.
Make sure you document disadvantages
We all know there is no silver bullet. Almost any technical decision is a tradeoff. Usually, logical people disagree with decisions because they don’t see tradeoffs in the same way. Make sure you explain why certain advantages overweight disadvantages for your current project. It’s a good idea to include tradeoffs, consequences, and disadvantages into Architecture Decision Record and document why they are less important than the advantages of the solution.
Present decisions to all the affected stakeholder
Once the decision is taken the job is not over. It’s only the start of the journey. By making transparent to other stakeholders why the team takes a certain technical direction you increase chances that priorities will be balanced in a right way to make the decision happen. You should also make sure that not only engineers but Product Managers and Engineering Managers understand the technical vision. Make sure your technical goals have meaningful name and values also for non-technical people. “Refactor event collector” is a nerdy name none of your product managers will understand the value in. “Remove unjustified proxy for event tracking to add handling of the new events faster” is a lengthy but already a meaningful name.
Understand the cash flow
Every successful engineering organisation needs to be financially successful in order to continue its mission. This should be one of the primary concerns of technical leads.
How much $$$ different solutions cost
Learn how much certain cloud or hardware services cost and how much an average engineering hour cost to your organisation. How much learning the technology by yourself will compare to the costs of hiring an experienced consultant. Good architecture is also one that achieves business goals at optimal costs long-term. Without putting rough numbers on your decisions it’s hard to make them right.
Participate in product requirements grooming
Product refinements are the only team meeting I try to attend constantly as an architect. As a technical visionary, you need to know extremely well how your future system needs to work. Being present when a product manager presents new features and catching all the nuances of certain product decisions I find extremely useful. But keep in mind, if you are an architect or another kind of a leader who is not part of a team, you should be rather a listener in team meetings. The main purpose of this kind of attendance is learning business requirements. Take active part only when a significant decision has to be made and it doesn’t go in the direction which you believe is optimal.
Spend some time in a customer chair
It might be a good idea to spend a week together with your operations department or together with your customer support team. I don’t say you should stop you work for a week and sit on call to receive your customer calls. But if you are not dealing directly with UX or front-end it’s easy to build false assumptions on how your product is used and operated.
Know the metrics
The other complementing way to know your product is to learn from data metrics. Who are your customers and how many you have. What are the feature people use on your platform the most. How much traffic should a certain feature handle should be a data driven decision. You may take many ideas from Product Management to learn for best practices in this area in general.
Know strategic goals
Know the strategic priorities of your business. Nobody can predict the future and you should not build what is not required. But it helps to know the direction where the ship sails. What are your competitive advantages on the market and what are your key strength that you need to keep. This will let you know where to invest your time more and what is more important for business.
Know your car from inside
The person who was a JavaScrip expert 5 years ago will not automatically be an expert today. “I have decades of experience” is not an argument in the technology field today. Things do change and you need to stay up to date. Also, the person who demonstrates the product and codebase knowledge in practice earns more trust when it comes to proposing decisions.
Keep the balance with coding
There is no ideal time how much you should spend hands-on. It highly depends on how long you are on the project, how deep you know the product and how deep you know the technology stack. The main idea is that coding is no longer a main duty of the technical lead. If you code too much you will not have time to do your most important job.
As a technical lead you can create a much higher impact to the organisation by enabling the right technical decisions and not by the code you deliver yourself
At the same time, you need to know your codebase and product deeply and by yourself. You need to code as much as needed to keep the balance between those conflicting priorities.
Find time to code
Being a technical leader you will find out that you spend too much time on meetings, working time gets fragmented, you no longer can concentrate enough and code contribution becomes a challenge.
Tip #1 Structure your work. As a rule of thumb, I don’t even try to code when I have a time window less than an hour. Even though I try to dedicate a meeting-free day to hands-on work completely while during the days with fewer meetings I review pull requests, create documents or talk to people.
Tip #2 Make a bigger contribution during “low” architecture seasons. Each project has much more design decisions at the beginning. You will be highly involved in those and will have less hands-on opportunities. Just accept this and as long as the project evolves you will get more time for bigger and significant contributions.
Select your coding tasks thoughtfully
If you are not attached to a single engineering team it might be not obvious how exactly to contribute to production code.
Tip #1 As an idea what contribute to, take the first step in the most challenging or least pleasant job. You should not take only candies. You need to make your hands dirty and lead by example. If you was pushing hard for the painful refactoring — you should be the one doing it as well.
Tip #2 You should contribute to the production code and not only work on prototypes. Just coming to the team and saying “Hi, can I code a sprint with you” will work but is not an optimal idea. For the team it might look that big brother is watching them. Instead, it’s better to find a team that actually needs a help. This could be a team with multiple members taking a vacation or just a fresh team which doesn’t know the lay of the land yet.
Stay deep
Congratulations, now you are the technical lead. You won’t be coding the whole days any longer because you have different duties. You should stay deep at least in a few disciplines. It’s being almost a 5 years since I’m not a Software Engineer by title and don’t spend my whole day coding. But I still can hint a solution to some tricky Java errors to even my most experienced colleagues. It is important not to become “Jack of all trades” who has only broad knowledge. I could hardly imaging being a good architect who proposes optimal solutions without staying deeply technical.
There are many ways how to create impact as a technical lead or architect. Don’t be afraid to take some time on learning your product, codebase and explaining your technical vision. The most important work you need to do is to have the right decisions in place and make them materializing. Effectively 99% of your work is just to prepare the technical vision by learning and contributing.
Originally published at medium.com/@ggonchar
Top comments (5)
Thank you for this post. I feel that this and your other linked article describes exactly my role. I code, I mentor, but my more important function is to guide technical decisions. That means knowing the business and the tech and doing my best to be easy to work with. It is really a different role than I thought it would be when I decided to pursue this career path years ago. I think I wanted to be the guy who knew all the right answers of software design. It turns out nearly every answer is "right" in a specific situation. Then ranges from "viable" to "dead wrong" in other situations. The trick is knowing and being able to articulate those factors in a helpful way.
I find also that in many situations the right answer is already known and is a kind of obvious. It's just about making it happen. Significant and time-consuming changes are often hard to sell and get aligned with other company priorities.
Thank you, Grygoriy - it's a good read for technical leads.
It's not easy to reach the conflicting goals, but we need to find the balance to make our organizations successful.
Wow!!! Thank you very much. There are a lot of points I can relate to.
Thanks for the good quality content:)