Software Architecture Summit

Responsibility

Somebody once told me the following and it's particularly relevant for software architects.

Share the successes with your team, take on the failures yourself.

From a software architect's perspective, you can't necessarily blame the development team for failure. If your architecture didn't meet the non-functional requirements, that's your fault. If the system didn't meet the functional requirements, that's also your fault (probably jointly with the other senior members of the team). If the quality of the system wasn't of a high enough standard, that's your fault too.

If you have junior people on the team and your project fails, the senior people should take that failure on themselves. You can't simply push it onto the development team because it's the senior members of the team that have most the influence to make things happen, not them. Software architects are senior members of the team and the responsibility for the success or failure of a project is in there hands.



Re: Responsibility

So true. Architects should be sure to remain fully-engaged, hands-on members of the team and the ones that everyone turns to for leadership and guidance. I wrote about this recently in The Architect Is Accountable, which included some discussion about the additional responsibility to actively support the Business and IT strategy.

Brian
http://blog.softwarearchitecture.com

Re: Responsibility

Apart from taking responsibility for failures because it is you who should have spotted them, taking responsibility in this way can also encourage other members of the team to take more responsibility for their own work. This teaches them that everyone makes mistakes and that it isn't a great disaster to make a mistake, because we learn from mistakes. It can instill the idea that is is better to make problems known and take responsbility for them than to sweep them under the carpet and hope that nobody notices.

Add a comment Send a TrackBack