Be Brave, Learn, and Celebrate
One of the biggest challenges (I wanted to say frustrations) in the efforts of a change agent is the balance between moving forward into a fast-changing world, and relying on past experiences potentially tied to the old world. Sometimes you need to be brave and take a small leap.
- Where is the comfort point?
- When have we overstepped and forced people into a defense of the status quo?
- How can we make recommendations without the assumed risk/fear that someone will take our advice, and then regret it?
- When do we offer guidelines and support that is so benign we have added no value to the process?
- How do we lead?
I have learned some basic approaches for how we can successfully frame aspirational change. Below are a few words we should understand better, along with and a couple of inputs for writing about the work in case studies and white papers. The biggest issue, however, remains our relationship to change, which I get to in the second part of this post. Skip down if you like, I won’t be offended.
Let’s start with some language.
“Consider” – a term that means “take a look at this if you like”. Final choices, at least those not breaking code compliance, should be up to the owner. However, the designer and builder team, in whatever contractual configuration, should be making suggestions to help the owner understand what’s POSSIBLE. The word “consider” is an attempt to widen the awareness of the team and the owner.
“Recommendation” – something that we have experienced and found useful in past projects. Not a guarantee that it will work for you in this project, just insight into applicability and past performance. I suggest this experience may be one of the reasons the owner hired you.
“Mandate” or “Law” – something specific that must be achieved in the project, or, as is occurring more and more in relationship to greenhouse gas (GHG) reduction needs, broad systemic goals that must be supported in some way in each individual project. These are the aspirational goals that many of us resist because they are too big to achieve in one project. Because “we can’t fix it, here and now” we tend to do what we always do, and blame budget restrictions, or tightness of schedule or some other constraint. If we do not achieve the specific goal, or if we don’t clearly make progress along the path to the aspirational goal, we are ignoring the mandate or breaking the law.
“Context” – above all it is a hired consultant’s job to remember that a project does not stand alone. In state work, for example, it is in the context of the owner agency, and the state’s goals (see “mandate” or “law” above). And every project is within the context of its own community, financial parameters, and environmental context. Think also of the systems feeding the building. How do water and energy come to the project, if they do, and how do water and wastes leave the project, if they do. Context includes the ecological complexities of materials selection, the makeup and geographical breadth of the labor pool, and more. By consistently reminding team members of context, and using the information of the context, we can make sure to amplify the co-benefits and reduce the co-burdens…basically, paying attention to context can bring better results to all related systems, and to the project itself.
Basically, paying attention to context can bring better results to all related systems, and to the project itself.
Here are a few ideas to create broader comprehension when writing.
The Appendix – Putting resources, tools, and contextual information in an appendix is a good way to control the info and be able to update it efficiently in the future. This method, however, has the drawback of setting valuable info aside, and forcing the reader to access a different part of the document for a more complete view. One way to address this drawback is to include enticing references to the information in the document itself. Instead of just saying “see tools in appendix A” say “this relates to the transformational Living Building Challenge as well as other credentialing tools that are detailed in Appendix A”. In this way, we can begin to create familiarity with the names of some of the tools, mandates, laws, and things to consider in the process.
The Sidebar – A possibly better approach is the “sidebar”, as there is a bit of freedom in telling a story or example alongside the main content of the writing. This helps the thought process and makes the case for inputs and ideas from beyond the normal or current spectrum of influence. The resources can then be fully described in the appendix, without being lost or an afterthought. There is some freedom in a sidebar approach. In addition, it breaks up what could be a highly technical and dry guideline document, with small bites of interest.
The Big Picture Statement (and restatement) – I see that architects and engineers and project teams have been trained over the years to restrict their thought process and assessments to the siloed project at hand. They have learned to aggressively ignore, even dismiss, the context. We have a great ability in writing about projects and processes to re-state the “why”. This will help the reader and the community, over time, relearn how to understand a single decision, project, or outcome in relation to the greater context.
The classic – don’t repeat code citations. Point to the code. This way, when codes (or mandates, or certification tools) are updated, your guidance document will still be valid.
The reminder – Ditch the jargon and acronyms. Okay, so we all know this, and we all still do it. A reminder won’t kill you.
Now, the big enchilada – let’s talk about the emotional impact of goal setting.
The goal and the path – The thing I don’t have complete solution for is how to set aspirational goals for a project, and then help the team understand that any progress along the path to those goals is a success. Maybe in framing the question, we can help to break down and start to resolve this issue.
Let’s say we want to create a zero net energy building (ZNE). The only way to get the team working on this issue is to set a goal EUI (energy use index, meaning energy use per square foot, per year) and then work the problem, focusing on that goal.If we had no EUI goal, then there would be no way to discuss the design process and make decisions that could get us toward the ZNE goal. A goal EUI does not mean every other aspect of the project goal set can be dismissed out of hand. It means that all the goals, non-negotiable and aspirational, need to be worked in tandem, and the team must repeatedly discuss what can be flexed. We must also decide how far along the path to the goal we can get.
Yet the experiences I have had of late seem to indicate we all feel we must achieve the goals we set. Therefore, we set only goals that have already proven to be within reach. If we accidentally do better than those goals we will make progress, but should we base our future on accidental achievements?
No. We actually need to be setting aspirational goals, either far-reaching or just out in front of our comfort zone, so we will start asking BIG questions whose answers can be informed by the collective experience of the team. Then we will, of necessity, move forward. It is absolutely true that settling a goal is step one to improvement of any sort.
Celebrate the process and the progress, and LEARN.
So how do we do this AND protect the project, the team, the leaders, from the risks that they may feel they are taking on in reaching beyond their fully known, proven-in-the-past, capabilities? The key point to address, I think, is fear of failure, fear that not achieving the goals will bring down the wrath of…who? The owner? The public? The team? So we need to be clear and complete in our support and our iterative progress. I suggest you remind yourself of these tips below during every project, and add more tips as you discover them yourselves.
- Clearly and repeatedly cite the goals as aspirational goals, and refer to the path and the place along that path we hope to achieve.
- Clearly and repeatedly indicate which goals cannot be missed (an occupancy date? A budget level?). These non-negotiable goals establish the lowest possible result in order to have a successful project.
- Clearly and repeatedly remind people that “we’ve never done this before, so any progress we make (over code, or within budget, or…) is progress”.
- Consistently shine accolades onto the team and onto the effort in doing the unknown, in taking these difficult steps
- Celebrate the process and the progress, and LEARN. This is part of the project’s success. If something is not achieved, e.g you can do everything but the EUI goals achieved is higher (more energy use) than ideal, talk about WHY this is, and WHAT we can learn from this revelation.
- And never label a process or project you have learned from as a failure. Ever.
Never label a process or project you have learned from as a failure. Ever.
Together we can help people realize, truly, that we cannot set goals that are “normal”, that code compliant buildings are not something aspire to, and that no progress can be made without trying something new.
Be brave, and be greener,
Jodi2 Others like this post, how about you? (no login required)
Interesting about the goals. I work in an a where we have “goals” and “plan”. Plan is what we should be doing, but goal is what we want to do if we go well above and beyond. (On the flip side, we keep adjusting the goals based on actual so it tends to fall apart a little, but the idea was right…)
Thanks for the comment! That’s probably a good way to look at it, with the goal, and a plan. I think the fear of setting a goal and not achieving it is one of the biggest restrictions, especially in the public project world. If a state entity says “this residence hall will be a zero net energy (ZNE) building” and then it performs at an energy use 80% better than energy code, but not yet meeting ZNE, then there is embarrassment.
Kind of like when the corporate earnings projection say Company A will make 2 billion dollars in profits in 2020, and the they “only” make 1.7 billion, this is considered a LOSS.