Neil Ford on Success Skills for Architects
Neal Ford of ThoughtWorks chats with SE Radio’s Kim Carter about the skills required to be a successful software architect, how to create and maintain them, and how to transition from other roles, such as software engineering. Neal discusses that the required skills can be learned, you do not have to be born with special attributes. Those looking to make the transition should focus especially on learning “soft skills” before making the move, and exploring the idea of taking an architectural role temporarily to see if it suites you. He also discusses problem solving skills, why understanding history is so important, and how to recognize and avoid increasing complexity.
Software Engineering Radio (SER) Episode 287, IEEE.
- In your own words, what is a software architect?
- How do the required skills change from the roles of Engineering to Architecture?
- What are the top 4 skills required to be the best Software Architect anyone can be?
- How have these changed over the last few years and how do you see them changing over the next 5 & 10 years?
- What do you think about the idea that Architects are born predisposed with a special set of attributes?
- Can you discuss clever code, maybe with an anecdote, and why it’s hard to maintain?
- Eliminating complexity was discussed in the book that you were involved with: “97 Things Every Software Architect Should Know”. How do we eliminate complexity, and do you have any examples?
- Why is keeping things simple such an important attribute to try an obtain?
- Keeping things simple is often harder than it sounds, why is that?
- What do you do as an architect when you just don’t have the skills required for a particular problem?
Productivity & communications, collaborate
- What key attributes and activities have you discovered to be important in order to better communicate with stakeholders?
- Some of the quotes you’ve mentioned on your website such as:
- Those who cannot remember the past are condemned to repeat it. –George Santayana
- The past is never dead. It’s not even past. –William Faulkner
strike a chord with me.
- Why is history so important, and why should we learn it?
- How do we help our young engineers understand the importance of learning our history?
- What pearls of wisdom do you have around successfully bringing changes into an organisation or team?
- Possibly discuss Fearless Change by Mary Lynn Manns & Linda Rising
- As an architect, what do the essential sales skills look like? How do you go about selling your ideas?
- How much experience have you had in changing an organisations culture, and how have you gone about it?
- Is an architect a manger?
- If not why not? How are they different?
- What does it take to be a good mentor, what are some of the skills required?
- What is a level 5 leader? (servanthood vs dictatorship)
- Are level 5 leaders made or born?
- Refactoring, or keeping technical debt levels low, often goes unseen, and it’s only the conscientious that care enough to take the initiative to do it. How do you as an architect look for these attributes of excellence in individual team members, and train others such as PO’s & managers to understand and recognise these attributes in team members?
- In terms of empowering developers, what are some of the most effective ways you’ve found to do this?
- What are some of your techniques in creating high performing teams, that also keep levels of technical debt at a manageable level?
- For a while I’ve had this metaphor of the Architect’s role as being this person that rides the elevator of a tall building all day. Architects seem to be jack of all trades, master of none, or few. Riding the elevator to the basement where the Engineers work, up to the top floor where the C levels work, and translating one to the other. How do you see the Architect’s role?
- What skills does an Architect need to successfully negotiate between all parties within an organisation?
- What techniques do you use to transfer essential information amongst software engineers, other than adding more meetings, which are often counter-productive?
- Possibly discuss pair programming as a means for transferring knowledge
- What tips do you have for hyper-productive meetings?
Building a Tech Radar
- You’ve written on building a technology radar. Can you talk a bit about that, what the bubble is, the dangers of living inside, how to avoid it, and how to build and maintain that tech radar?
- You’ve talked about “Avoiding Yesterday’s Best Practice from Becoming Tomorrow’s Antipattern”. What is an anti-pattern and how do we do this?
- In just about all technical projects I’ve been part of, the biggest problems are just about never technology based, but rather people based. Why is this, and what tips do you have on fixing the people problems?
- How do you deal with losing your technical skills due to constantly being pushed up the ladder? I personally have to deal with quite a bit of frustration around this, and feel constantly torn between needing to go deep on technical areas and then losing focus of the bigger picture, and visa-versa. Is this an issue you face, and how do you deal with it?
- How do you attempt to retain them, or do you just not try?
- You have also discussed “how to build engineering and DevOps practices to support continuous change… and delivery” What advice do you have for us around this?
- What does failure look like as an Architect & how do you deal with it?
- If you could go back in time and change the way you progressed through your career, what would you change?
- What advice do you have for Software Engineers thinking about making the transition toward architect based roles? What do they need to be aware of before moving in that direction?