Urban Technology at University of Michigan week 245
Surveying the State of the Urban Technology field with Siqi Zhu
We're on our fourth calendar year of operations with students and the 6th year total, and in just a couple weeks we will graduate the first-ever cohort of Bachelor of Science in Urban Technology students. Thinking about students "converting" into alumni means we're also having discussions about careers and first jobs, which means this is a good time to share insights from a recent visit by Siqi Zhu of the legendary design firm Sasaki. Reflections from his recent visit to the U-M studio below, as well as a few morsels from our work on career advising for UT students.
💬 Hello! This is the newsletter of the Urban Technology program at University of Michigan, in which we explore the ways that data, connectivity, computation, and automation can be harnessed to nurture and improve urban life. If you’re new here, try this short video of current students describing urban technology in their own words or this 90 second explainer video.
🌾 State of the Field with Siqi Zhu
Somehow Siqi Zhu finds time to be leader of the urban technology practice at Sasaki and faculty member at Harvard's Master of Design Engineering program (which, btw, is kinda Harvard's version of UT, but at the grad level). Formerly of Sidewalks Labs and the AEC startup Envelope, Siqi has been in the field of urban technology as long as anyone. He recently visited us at U-M and brought his calm and thoughtful style of inquiry to our studio, where he shared his work with the UT students.
Right off the bat Siqi described the field of urban technology as "liminal" with people coming from lots of different backgrounds. In part this is a reflection of the emergent quality of the field. There are only two degree programs with "urban technology" in the name: us and Cornell Tech. "Some level of eclecticism is beneficial," Siqi shared, because of the interdisciplinary nature of the work. At the highest level, what he does at Sasaki is to "figure out a desired future state and marshal resources that are financial and technological" and the people to make it happen. No single discipline can lay claim to that aspiration, so it has to be interdisciplinary.
You can also see the interdisciplinary needs when looking at Sasaki's urban technology work, which breaks down into the following categories (actual titles rephrased by me):
1. Urban data analysis
2. New approaches to [community] engagement
3. Design of new products and urban experiences
4. Project delivery tools
While the example projects were super impressive, as Siqi walked through examples of each category of work, what fascinated me most were the business models driving each project and how the profiles of revenue and costs are different for each type of work. Some projects were booked as consulting, some as products. It's not easy to do both inside of one firm, yet this is a pattern that I see in most AEC firms of Sasaki's scale. Therefore, I find this to be indicative of the moment we are in, where firms are seeking to leverage their unique expertise to access higher revenue business models. Meanwhile, other businesses (often called startups) are taking a more disruptive approach and seeking to apply the means and methods of technology to solve the same problems or deliver similar outcomes as AEC firms.
If the list above are the different foci of work that Siqi showed, here are the *types* of projects that he mentioned: workflows, prototypes, and products. I built out the table below by riffing on Siqi's trifecta:
The projects that were best described as workflows were meant to supercharge Sasaki's client services teams. These could hardly be sold to somebody else as a product because they are too intertwined with the internal processes of the firm. Generalizing is hard and would probably require collaboration with peer firms who are also competitors, because they are the most plausible customers.
Prototypes were developed under the guise of a client project but were conceptualized as mini products that could be given to users. My favorite example shown by Siqi was a community engagement tool from Boston that asks people about their experience of urban heat. Instead of a awkward survey, the tool helps each user create a customized comic book of their hot day in the life. Such a tool *could* be turned into a product, but it hasn't been yet, and doing so would require a higher level of commitment on behalf of the organization to provide customer support and maintain the code base. There's a tension between serving the client who provided the motivation for the prototype and validating the prototype as something that could be selfishly expanded into a product.
The final group of work were bona fide products. The best example there is something called Dashi, which is a tool that Sasaki sells to its customers to enable them to manage the long-term delivery of urban planning projects. Developing such a thing internally requires software engineering, customer success, and customer support to the extent that it's almost a business within a business.
While you can imagine a progression such as first writing some code for a workflow, that then turns into a prototype on the next project, and eventually becomes a product later on, it is important to resist this kind of linear assumption. As Siqi described, "some things don't need to be anything other than workflow." There's plenty of value to be squeezed out of well-applied automation. This is the equivalent of designing better tools for yourself or making a custom jig in the wood shop. Siqi reminded the students that built environment work is highly bespoke, so you simply can't turn everything that Sasaki does into a product. The firm doesn't have the engineering and product design resources to do that, first of all, but it also wouldn't be appropriate to even try. Their work is intensely place-based. Projects are one-offs. No two campus plans are the same—and that's a good thing because it translates to quality of place.
While I am often given to being pessimistic about the sluggish process of digitalization in the built environment, I feel that it's more important to have a descriptive language for what's happening. The question for urban technology students is whether they want to be "innovators" who join a team like Siqi's and help an existing firm with AEC expertise develop more and better workflows, or do they want to become a "disruptor" who seeks to build new products that obviate the need for AEC services in the first place? As we graduate our first batch of students, this is the thing I'll be paying closest attention to during the early years of their careers.
🧑🏫 Behind the Scenes: Careers Primer
Advising students about careers in urban technology has been a fun thing to figure out. The range of jobs that our students are interested in is quite diverse and spans both built environment firms and tech companies. Job descriptions, hiring timelines, pay expectations, and lots of cultural factors can be quite different between those two types of companies. Add to this the fact that students are also interested in working for government, and it is a truly broad set of potential career pathways that urban technology students are collectively considering.
Before the fundamentals of advice on interviewing and resumes, what I feel compelled to give the students is a way of understanding the economy that they are entering. To that end, we created something called the Careers Primer which is an internal set of documents aimed at helping students figure out what they're interested in, finding the right opportunities, landing a job, and being a good coworker. Recently we worked with the graphic designer John Custer, who gave the documents a refresh and made them look seriously awesome, so I'm sharing a couple snapshots just to make you jealous.
These weeks: The endless process of space planning; graduation stuff; final reviews; why is there so much muchness? 🏃