Do you practice the habits of highly successful software architects? Can you deliver a solution while acting as a technical mentor, empowering others, improving the process, and developing a focused, high-performance team along the way? In Software Architect Bootcamp
7 Habits of Highly Successful Software Architects
According to Malveau and Mowbray, the seven successful habits are:
- Keep it simple.
- Let others defend the architecture.
- Act don’t argue.
- Keep an eye on the prize.
- Be willing to change, but never too much at once.
- Learn where to stop.
- Know how to follow.
Keep It Simple
Avoid complicated explanation. Keep it high level and grounded in principle. Malveau and Mowbray write:
When communicating various architectural concepts or software mechanisms to team members, resist the temptation to provide a complete and detailed explanation of how things work or a detailed comparison against all the alternatives in front of a group. Instead, the software architect should say enough to communicate the idea at a level that is high enough to be generalizable but just low enough to be understood in principles, so that the individual team members can do their own homework or meet separately with the architect to address their specific concerns.
Let Others Defend the Architecture.
If you’re the only one defending the architecture, there’s a problem. Malveau and Mowbray write:
It is always preferrable to have someone respond to a technical concern rather than have the software architect appear to be the sole source of knowledge. it reinforces teamwork, provides the architect with insights from people who agree as well as disagree, and is a key aspect in mentoring others, among other benefits.
Act Don’t Argue
Rather than argue, focus on results. Keep it objective and keep things moving forward. Lead by example. Malveau and Mowbray write:
Arguing technical points in a meeting wastes, time, hurts feelings, and seldom if ever fully resolved any technical issues. When such an argument starts, the software architect must act – by assigning people to get or verify the relevant information, setting up a meeting specifically for resolving the debated topic, or, if time requires an immediate course of action, laying down the law by explaining why the time constraints force an end to the matter.
Keep an Eye on the Prize
Have the overall vision in mind. Malveau and Mowbray write:
Software architects must always be aware of the end goal. It is easy to be distracted by tasks and smaller technical issues, and frequently other team members will succumb to oneform of tunnel vision or the other. However, it is vital that the architect always be focused on the overall vision of the system and relate every task or technology to how it contributes to the end goal.
Be Willing to Change, But Never Too Much at Once
Be flexible in your approach, but make incremental changes. Malveau and Mowbray write:
After the initial bootstrapping of a software development effort, the architect should be wary of implementing too many process improvements all at once because there is a risk of compromising the effective parts of the process.
Learn Where to Stop
Don’t micromanage the design. Malveau and Mowbray write the following:
Software architects must resist the temptation to go into too many details and to micromanaging design decisions. For example, it would typically be enough to specify that caching is required in client applications and that the caching code should be resused throughout the application. However, detailing the specific caching algoritm used or writing the caching pseudocode is probably overkill. Learning to trust other team members to provide design and implementation details and letting them ask for help is essential.
Know How to Follow
Avoid public confrontation. Malveau and Mowbray write:
No matter who is in charge, software architects should avoid publicly confronting others on major design issues. This can be accomplished by knowing ahead of time what is going to be discussed and the reasons for the various decisions. This is a key aspect to developing a focused, high-performance team.
Key Take Aways
Being in the software building business, I can easily relate to this. I think there’s a couple of themes that underly the habits:
- Balance connection-focus with task-focus. Building software is a team sport. It often means building rapport and getting others to buy into ideas over time. While knowing your stuff is a good thing, you should use it to lift others up and produce a great results. Winning technical battles at the expense of the human relations war, will cause unecessary friction and reduce your results and drain your energy.
- Focus on value delivered over the shiny object. If you’re passionate about the technology, it’s easy to fall into the trap of focusing on the technology or the shiny objects. At the end of the day, your credibility and perception will be about the solution you deliver and the team impact.
- Be a mentor and a coach. It’s true that knowledge is power. The trick is to grow yourself, by growing others. What you share comes back to you tenfold.
My Related Posts
