Triangle of Success for Software Architects and Technical Leads
Triangle of Success for Software Architects and Technical Leads
Software architects and technical leads are often at the top of the team heirarchy, but learn how to make sure everyone is on the same page here.
Join the DZone community and get the full member experience.Join For Free
Whatever new awaits you, begin it here. In an entirely reimagined Jira.
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 realized that there are three 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. 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 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 Ideas 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 you to have more discussions and adopt the proposal on the fly by moving together in the right direction. The instrument could be not necessarily 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 outweigh the 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 Stakeholders
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 organization needs to be financially successful in order to continue its mission. This should be one of the primary concerns of technical leads.
How Much Money Different Solutions Cost
Learn how much certain cloud or hardware services cost and how much an average engineering hour costs to your organization. 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 a listener in team meetings. The main purpose of this kind of attendance is learning business requirements. Take an 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 your 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 do you have? What are the features people use on your platform the most? How much traffic a certain feature should 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 strengths 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
Keep Balance with Coding
There is no ideal time for 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.
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.
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.
As an idea to what contributes 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 were pushing hard for the painful refactoring — you should be the one doing it as well.
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 it's 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.
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 been almost 5 years since I'm was a Software Engineer by title and I 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 a "jack of all trades" who has only broad knowledge. I could hardly imagine being a good architect who proposes optimal solutions without staying deeply technical.
Published at DZone with permission of Grygoriy Gonchar , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.