I don’t think there is anyone who would disagree that getting someone to review your work is a pretty good idea. A second pair of eyes is always useful, as is someone to bounce ideas off, or someone to bring specific expertise that you may not yet have, or someone who can shape your work to better suit your target audience. All of these good reasons are likely to result in time and money saved for a project, as well as an opportunity to reflect on your work and grow professionally.
However, even though it is clearly good practice, it is rarely done in any meaningful way. I can probably count on one hand the number of times I have been involved in an effective peer review.
I don’t think this is because we are bad practitioners. Typically we don’t have, time; either the project needs things done quickly and can’t wait for the reviews, or the people who would peer review are too busy themselves. In the end, many reviews are left to be done in a governance meeting - exactly the place where a review should not take place!
So there are many, many good reasons why we don’t do peer reviews, but they aren’t as good as the reasons why we should do them. So, how can you get the benefits of peer reviews without significant impact on project timelines and colleague workloads? Here are some ideas and thoughts.
Break it down
For the sake of simplicity, let’s assume that you are developing a document. You don’t need everyone to review all of your document. Help reviewers make the best use of their time by directing them to the specific areas of the document where you need their feedback, along with areas where they may find useful information when giving feedback. Also, let your colleagues know which parts are relevant to their skills.
Be very clear about what you want
Be clear about exactly what you want from the review. For example, if you are the sort of person who leaves typos in their document to be fixed at the end, then let your reviewers know this. If you need someone to provide alternative solutions, rather than critique the proposed solution, then say so. Or maybe you need someone to fact check or confirm assumptions. Whatever it is, if you clearly state what you want you are far more likely to get it.
It doesn’t need to be perfect
As a group, architects are particularly guilty of doing too much. Maybe because we are seen as “The Experts” we don’t want to be seen to be wrong, or maybe we are just fussy perfectionists. This is a useful personality trait in our profession, but it is not necessarily useful for a review. Fight the urge for perfection, and ask for just enough for the review. You will give everyone more time to provide you with feedback, while reducing the amount of content to review, and you will potentially save yourself unnecessary rework.
Find the time and Give the time
It is essential to plan ahead and be sure to give yourself time, and most importantly give time to your reviewers. A lot of this comes down to personal time management skills. Not wanting to generalise again, but architects sometimes find time and effort estimation a challenge. Work closely with project managers to find the time, sell them the benefits of reviews, and try to be realistic about the time it takes.
You can also look to work a bit smarter. For example, if you break your work down into reviewable sections, then you can get one section reviewed while working on the next. Also, make sure you give provide a realistic time and date that you would like to receive your reviewers’ feedback by.
Collaboration and tools
Architects still spend a lot of time working in isolation and tool support is limited and can be expensive. But collaboration isn’t just about tools, it is a way of working that can be helped with tools. If you are collaborating with your peers from the start, then there will be far less need for reviews. Spend more time talking and sharing ideas with colleagues whether over a coffee, in front of a whiteboard or in the corridor.
But it you do want to use tools, start simple. Pick up a tool like Slack or Teams and move conversations out of email and onto channels. It may take a while for the change to take hold, but you will feel and see the benefits when it does.
Governance is not review
Governance is about approval rather than review, and often there are a lot of things to approve. But all too often these meetings are used for reviews - it isn’t what they are for and you never get a good outcome. Using governance for review will waste people’s time and lead to long and arduous meetings that consume valuable time needed to approve other activities.
David Molesworth has just written on effective governance where he takes the time to elaborate on what governance meetings should be focusing on.
That last point is more to do with how an architecture practice is run and may be out of the control of individual architects. However, if you do the things discussed above then your journey through governance will become easier and faster, you solutions will be approved in the governance meetings, you’ll have less rework, and the delivery managers will be happy.