Architecture: designing things so they don’t just emerge chaotically
Weeknotes #15: Aug 31 — Sept 4, 2020
Wow, last week’s post really generated a lot of interest! I’m so appreciative of everyone who took the time to read and respond. In case you missed it:
Between several conversations spurred on by my blog post, and reading Cyd Harrell’s new book A Civic Technologist’s Practice Guide, this was a week of identifying my own biases and blindspots, and taking steps to try to reframe things.
It’s Labour Day, but my mind hasn’t been able to shut down all weekend. Last week was mentally and emotionally draining and I haven’t really resolved on a path out yet.
I’m terribly new to the public sector, and I ask a lot of questions. Thankfully, I’ve landed on a team within Transport Canada with amazing supportive teammates and leadership. Ones that are patient and welcoming of my questions, rather than seeing them as distractions or worse, challenges to their authority.
This week I was exposed to the Project Complexity and Risk Assessment tool, Memoranda to Cabinet, and a scope of Enterprise Architecture that far exceeded my expectation.
When I get exposed to something new, I have a compulsion to go deep, so I can try to fill in gaps as quickly as possible. How does this new information align with my current worldview, or does that worldview need to shift? I enjoy this time to learn something new, but it also can be pretty stressful when I feel like I’m lacking some information I need to contribute to a discussion or initiative. I spent some of my Sunday “growing my enterprise architecture skills” on PluralSight. Do I need to do that? Probably not. But if I am going to be part of a discussion that includes talk of business architects, solution architects, security architects and transformation architects, I want to know … what .. those .. things .. mean.
In my experience from the private sector software world, technical architects designed the technical solution (at the product level), and solutions architects were technical sales people. They are focused on a particular solution, generally separate from the business / strategy side. Now I know that EA means much more than that, but several times during this past week I am sure my colleagues thought we were speaking different languages. I was bringing a bias into our conversations that prevented us from reaching an understanding.
I just need to reiterate again that I consider myself extremely fortunate to have landed on the team I’m on, where we can have some lively conversations. I’ve heard a lot about the rigid hierarchy that can exist in government: the need for meeting pre-briefings, de-briefings and taskings, and I am thankful that the people I work with are open to having real conversations without much pretense. I feel a lot of respect and trust within the group, which is how you’re going to get the best out of the people you work with. [I readily admit that in my supervisory role, I still have much more to learn/put in practice in this regard ]
I’ve been thinking a fair bit about psychological safety, especially since I saw a tweet a few weeks ago about how that’s really the key to success in an agile team. The team needs to trust each other, and be willing to be vulnerable. It can be tough to do that, especially now that everyone is working in their own private space and you don’t get as many chance encounters to interact with people casually.
Even when a challenge is tough or frustrating, it can be a lot more manageable if you know you’re not alone in your view, or the only one shouldering the burden.
That sense of not being alone washed over me time and again as I worked my way through The Civic Technologist’s Practice Guide this week. I’ve followed Cyd Harrell on twitter for quite awhile and had the opportunity to see her speak (and meet her) at CanUX last November. I found myself highlighting large sections of the book, and sharing them on Twitter. Cyd addressed so many of the subtle differences between the public and private sector that have stymied me over the past 16 months.
I wish I’d read this book before my fellowship, and advised the Code for Canada team that they should recommend this for the next cohort. Coming into the public sector as a technologist can be difficult, and reading this book helped me feel like I wasn’t alone. There is an appetite for “digital transformation” and “modernization” in the government, and it’s really more a matter of putting in the time to understand what that means to all parties, what they perceive to gain from it, and then figuring out how to get there.
Oh! That’s another thing I’ve started to learn more about in the past couple weeks. “Change Management”. I will admit that I thought the term seemed a little trivial at first, but after a wonderful discussion with a colleague, the more I think that maybe the private sector could use a little more change management of their own..
So another week that was a bit meta. Taking some time to learn how things work, and how people can work best together, to lay the groundwork for a path forward.
