Having looked at the ten Superuser qualities or attributes, and ten Superuser superpowers, it’s time to put these skills into action. What are the specific roles Superusers play on teams, in firms, and in the industry? Firm after firm, Superuser roles fall into predictable categories: they are either generalists or specialists, often falling somewhere along a continuum between the two. Design technology specialists either serve as internal consultants, where they are considered overhead, or integrated into project teams, and billable, or some combination of the two. This chapter looks at each in an effort to determine which approach is more prevalent, and which more effective, resulting in increased value for firms. We’ll look at Superuser roles as they compare with more traditional titles within AE organizations, and contrast the differences between generalist vs. specialist design technologists, the generalist/specialist hybrid role, and how teams and firms benefit from this grey space; whether Superusers provide the most value when billable (where e.g. computational design should be billed on a project) vs. overhead; when integrated on teams vs. sitting “in the corner;” and, hands-on vs. primarily strategic, providing leadership or a management role. The chapter concludes by looking at the role of the Superuser in practice: a Superuser team case study.
Superusers as generalists
Does the fact that KieranTimberlake is a research-based practice with an interest in creating knowledge influence their decision of whom to hire? “Everyone here is a designer, researcher, and creator of knowledge through continuous learning,” says Matthew Krissel, Partner at KieranTimberlake. “We are all as committed to sharing ideas as we are to creating them. Research, asking questions, and restless curiosity are part of our culture.” One has to go back into the recent past to explain why it’s important for future specialists to start-off as generalists. Krissel says:
It is important to acknowledge the confluence of other changes that coincided in the mid 2000s. Software and hardware are obvious but more important is the cultural change of sharing coupled with new business models and platforms for design. This evolution, with access to cheap memory and speed was an accelerant for a design environment with significantly fewer barriers to computation, networking knowledge, and exploration in architecture firms.
For me, working on both sides of this offered clarity to the incredible opportunity here. It is also important to remember that this speed and access caused many to not learn some key foundational elements about designing parameters, principles and the mindset around these emerging workflows which are critical skills that too often have been lost.
Something for today’s design technologists is lost by not first learning analog prior to immersion in the digital. Krissel continues:
Learning to build a perspective by hand is incredibly valuable to working in the computer. This is the same in photography and the continued value in experimenting with film. The foundations of composition, how the human eye works, understanding dynamic range are confronted in analog workflows but software and hardware has unintentionally subverted much of this meaning. This often results in a laissez-faire approach where one will just fix it all in post-production. The need to be aware, conscious, and clear on early decisions impacting modeling, simulation, and visualization downstream are heightened when it is labor intensive to change variables. So, it required great intentionality and purpose in the analog-only era. Being in command of the fundamentals and involved in the design of the early parameters are critical skills for computationally driven practices that seek to do meaningful work.
To be clear, Krissel is not advocating for going back to that earlier, analog time. Krissel emphasizes:
But there is no doubt that parts of working manually are a great precursor and learning tool for working digitally. I would rather we enhance our education to evolve and bring those valuable principles and methodologies forward into a digital workflow. The tactility one feels with a fountain pen, or the joy a well-written piece of code brings us is not the goal. A design practice can and should be about much more than process and diagrams. Even more than the creation of space and the organization of mass and volumes, it is about experiences, connectivity, relationships, movement, time, and the social construct of what the built environment can do.
As a firm, KieranTimberlake has taken the position that everyone must have familiarity with the tools that drive the work. “That does change the dynamic and while not everyone may be authoring content, everyone is expected to be reflective on the work, operating three dimensionally, exploring ideas outside of design reviews, and question it,” says Krissel. “This improves the capacity of the whole team and is the foundation of a highly functional collective intelligence model.” KieranTimberlake doesn’t use the title Design technologist. “Labels that separate people by skill compartmentalize them, you’re in or you’re out,” says Krissel. “We prefer specialist which suggests a time-based difference. Someone who is expected to go deeper but it does not mean others are not still accountable to be engaged.” So, while their design technologists are referred to as specialists, Krissel emphasizes their generalist natures. “We are a firm of polymaths with people interested in lots of things,” adds Krissel. “Some go deeper on fewer things and some go wider on many things, but it never creates a territory for one or another.”
Figure 3.1
Model building party in Scott Crawford’s personal shop before completion of the LMN shop. (2018) Credit: LMN Architects.
Scott Crawford, Principal at LMN Architects says:
Superusers are actually this generation’s version of the generalist architect. Antoni Gaudi had a unique process of incorporating simulations, study models, and mockups. I believe this range of tools helped enriched his process and give him a grander view of what he saw as possible, leading to his unique projects that so many are in awe of. This generation’s Superusers are approaching practice in a similar way. Designers now have the potential to iteratively study a design through parametric modeling while getting feedback about the performance differences through the use of simulations, and develop highly customized design that can then be constructed through the use of digital fabrication. I believe there is a shift to a more generalist perspective when you can see the design space through the different lenses of each of these tools. The design process is no longer about finding the best of three options, but instead studying the behavior of a combination of decisions, and thereby learning about how decisions affect the performance of the entire system. Because of this, young designers have the ability to quickly establish a depth of experience that previous generations would’ve taken much longer to develop.
Superusers as specialists
Given how quickly design practice is evolving, is design technologist an unnecessary label and/or distinction? According to WeWork’s Brian Ringley:
Theoretically my position has always been that the design technologists, or whatever it’s popular to call them in a given era, is that it’s important to have a small crack team of designers who are able to slowly research and implement new processes in a practice.
There are various models for doing that, and one of the things we were always talking about back on the Design Technology team at Woods Bagot was, “Yeah, right now I’m training users in how to use custom Grasshopper and Revit tools, but ideally that’s not my career.” Ideally that eventually gets absorbed into the culture of the studio or into the culture of the industry and I move on to the next promising thing, so that we’re establishing a reinforcing feedback loop of R&D in architecture.
So where do firms draw the distinction between an architect that knows Grasshopper, Rhino and Revit, and a specialist? “While every architect can work in modeling software, the specialist is charged to move across the office and connect knowledge and expertise,” says Krissel. He continues:
When they are not taking on a discrete design problem, they are teaching, guiding, and editing the workflows and habits while introducing new and alternative ways to work. The specialist also has time that is insulated from project demands so they can go deeper and take good ideas that are often crushed under project pressures and develop them further to everyone’s benefit.
NBBJ advertises the specialist’s role as a design computation specialty. NBBJ Design Computation Leader Dan Anthony explains:
We identify when we need to be doing a better job and when there’s a role that needs to be filled. Now it has become specialized … There is still going to be a lot of project design that’s expected, but by labeling it a specialist, that makes it part of the active HR exploration. We want to make sure candidates have the skills, having done work that has demonstrated their visual programming skills, some algorithmic design, maybe an interest in fabrication. We look for that in their work.
As discussed in Chapter 1, a distinguishing characteristic of specialists is how devoted they are to coding. According to Anthony:
There are just human differences. There are certain individuals who want to go all the way in, and understand every nuance of the code. Their passion is in the expression of it. They have very little interest in the other parts of it. They don’t want to do spreadsheets, or even talk to other people. They really want to dig deep into what they are doing. To bring this topic all the way around, now I work in a workplace practice that designs workplaces, including workplaces for these people. You see very clearly the human needs that they have. They just want darkness, privacy, and a space that does not disturb them.
CannonDesign CTO Hilda Espinal offers a word of caution:
Be careful to do everything in your power not to be pigeonholed as a person that only does “techie things,” because I’ve been there too. It was important to me to advance my career, equally, in both areas and ensure I balanced the two. This is all going to depend on the culture of the office or firm you’re at, and their leadership. While you may get to focus on this intersection in some cases, situations, revolving around life/work balance, may make this experience problematic and having to choose one vs. the other. Unfortunately, you may be pressed by management, particularly middle management to answer “well, pick one role. Which one are you going to do? Because you can’t do both. I need you to make my project a priority. I need you to be 100% billable” and so on. Not everyone has caught up with the vision of how crucial these hybrid roles are. As an industry, we still have work to do.
Figure 3.2
Audience gradient. (2018) Credit: DLR Group.
Generalist/specialist hybrid role
Today’s practice calls for a range of hybrid roles that fall somewhere along a continuum from generalist to specialist. In 2016 DLR Group began an effort to inform its design teams and help bring parametric design methodology and computational design tools into their practice. For some, buy-in comes instantly. Why is that? What are some of the mindsets, skillsets, and attitudes of people for whom buy-in is instant vs. may take more time to on-board? DLR Group’s Ryan Cameron explains:
What I have is a series of different users. I ended up discovering something I didn’t know existed. I just thought users would be in – or they wouldn’t. But that was not the case at all. I have people I call: eyes-on, hands-off. I have eyes-on, hands-on. And I have minds-on, everything else is off. There are some people who want to know about it but don’t necessarily want to see it, or touch it themselves. I have people who just want to know that there are certain people in the company who can use it. Then there are people who not only want to see it or watch it but also want to perform the same actions that I am doing.
As explained earlier, KieranTimberlake has people who are vertical thinkers and go deep, and they also have a lot of generalists who move laterally across projects. Krissel elaborates:
While polymaths touch a lot of things and see possibilities, they sometimes don’t go beyond the surface. Deep thinkers expose new layers of an idea but may miss adjacent possibilities. We design our teams with a mix of attributes, experiences, skills, and perspectives and expect that people are open minded, recognize their blind spots and like working in a complimentary way.
This leads to the concept of the Superuser team.
Computational Design Group Leader at Thornton Tomasetti, Hiram Rodriguez, is a polymath who works with all groups at TT, ranging from concept design to construction documents, from rationalizing a building to creating a workflow for a new tool. Rodriguez says:
For the most part, I am part of the team early on the design stage of the building helping with the rationalization and creating a cohesive workflow. I am also part of monthly talks within different practices. It is key to understand what the current process is in order to create the best workflow. In addition, outreach is a key aspect of my job. We need to make sure we can reach all staff and not only a particular sector. TT is a global office and we have to make sure we are reaching everyone.
In addition to his design talent, LMN Architect’s Scott Crawford is an example of a designer who has a considerable number of tools in his arsenal. Does he believe every team and every architect should have these skills? “Absolutely!” says Crawford. He continues:
To me it’s an extension of the architect as generalist. I grew up during a time that technology was becoming very accessible with a lot of online resources and I greatly benefitted from exposure to these new tools. That’s not to say though that I didn’t also get exposed to more traditional tools as well. I learned to draft and construct perspectives when I was in middle school. While I may no longer use some of those skills from my past, they’ve still contributed to my understanding of how and why things work the way they do. An essential skill within design is the ability to see things from a diversity of perspectives. Experience is one contributor to that diversity and a faculty with a variety of tools is another. Historically, our digital tools were fairly constraining in their functionality, but tools are now getting to the point where there is more opportunity for customization which allows for a designer to essentially design new ways of developing design solutions.
Figure 3.3
A lot of firms benefit from the grey space. (2018) Credit: Deutsch Insights.
Benefitting from the grey space
Shane Burger admits that many people are concerned about their career path and professional development:
Some of them sit in this position where they can’t decide, do I still want to be a project architect eventually? Or do I want to be a specialist? So they sit a little bit in that in-between zone. I had that exact issue in the process of my leaving Grimshaw’s office. I was basically put in a position where neither one were being presented to me as a viable option. But Grimshaw benefitted from me sitting in the grey space in between. But in terms of my professional development, I didn’t want that anymore.
A lot of firms benefit from that grey space. They can sit and do basic project drawings, but I can also shove them onto a complicated façade and do some SOAR analysis on it. Because there has been no real conversation around that within the practice, it leads it into an unknown space. Then that person is like, I don’t know if this is the right place where I want to be. So maybe – I’m in my mid-twenties – I’m going to hop on over to this other firm that’s going to give me this specialist’s role. And I’ll keep hopping around. They either can’t decide which of the two they want to be, or they’re going to practices that can’t decide which of the two they’re going to be. The easiest of those paths is to go the project architect route because that’s a known career path. Everybody knows what steps you’re supposed to go through to eventually become a project architect. Maybe you get named a senior associate. Maybe you become a principal at some point. However, if you’re on the specialist side of it, that’s really difficult. Because in a lot of practices, including ours, we don’t have a clear answer for what you do with specialists in terms of career opportunities and promotion. Can a specialist become a principal has been a huge question? I get asked that sort of thing all the time from my peers when I go to conferences because I’m a principal now. How did you get to be a principal? How does that even work? I have to explain to them, here’s the problem. If you want to be a specialist, you then have to decide do you want to remain a subject matter specialist, or do you want to become a manager of specialists? If you go the manager route, that’s also a more well-known route. Still more difficult, because a manager of specialists is not as known a career path within an architecture firm as perhaps in other professions. But if you want to stay a specialist, and you really know your topic, and you want to keep doing that by becoming more and more advanced with it, can you ever become a principal like that? I’ve not seen a firm that is capable of doing that yet, for someone who doesn’t go in to a direction of management.
A collection of specialists does not a team make
We’re told in school that once in practice our autonomy won’t be valued. We’re told to get used to working in teams – because projects have gotten too complex and problems too intractable to work on one’s own. Then, once we’re in the workforce, we discover that we are indeed valued for our ability to work independently: that there’s a time for collaboration, and there are times when we’re asked to just get it done. Collaboration vs. DIY. Which is it? Team leaders want both.
As already discussed, Superusers have the qualities that enable them to work on projects that are team-based and team-focused as well as having the ability, when required, to go deep. There has to be some overlaps between the different roles, explains Burger:
[b]ecause that enables a better conversation. If you have a collection of specialists who were so specialized that they can’t engage with each other, that’s not a team at all. I have run into this in the past. Years ago I had a collection of specialists, not actually a team. I spent a long time changing how that works. What has worked best to ensure that they are operating like a team is to be focusing on the end outcomes. Not so much on the technology and the steps that will get us there.
Figure 3.4
Team of Superusers (top) vs. Team of Specialists (bottom). (2018) Credit: Deutsch Insights.
Superuser team case study
Shane Burger provides an example of how Superusers can operate as a team, on a Woods Bagot project in their Jira project environment called Project Collaboration, that asks: What is the next generation of what we do for design reviews?
We started to use this in Jira, epics to describe what are the main things we are doing. Project Collaboration hits a whole lot of things, both internal and external collaboration and communication systems. e.g. our study of Slack within the process is part of that. One of our epics refers to a desire to better engage with model-based design reviews. I basically say this is what we’re going to focus on for the next two months. Say, four of us will focus on model-based design reviews, and the other two of you will work on something else. That right there, yes it’s telling you that we’re already talking about software, or talking about models, but we’re not necessarily saying what software platform we’re talking about. We’re not saying which part of the phase we’re thinking of, whether conceptual design all the way through construction documents. We haven’t actually answered the question of internal vs. external. What this is going to mean is I can bring in a group of people that have a diverse array of skills. I can bring in someone who is quite strong in terms of Revit and can have a conversation about what kind of information needs to be in our Revit model to make its way into a tool. They may have experience with BIM 360 Glue. They may have experience with Revizto – a collection of different things. I have another person who comes in and has a lot of experience in tools like Aconex construction management software, but also knows a lot about contractual arrangements associated with collaboration and the protocols for larger-scaled projects. So he’s going to be talking mostly process. Then I have another person coming in who had been doing some work with me in the past in VR and is very interested in the kind of interpersonal conversations that happen amongst designers in an augmented environment. How does it work socially?
Then I come in as the person who has been leading this design communication platform development tool where we’re building in a design review functionality to it. I’m interested, from a leadership perspective, about how we report upstream the outcomes of reviews. We’re all coming from slightly different directions based on our experience and our interests. But we’re all trying to meet in the middle to solve the problem that is the same kind of space. It ends up meaning we have a wider conversation around the same thing but from each of our own perspectives. Through that we end up learning the other’s perspectives.
For me it’s important that I am trying to take advantage of the diversity of backgrounds, skills and interests that might surround a particular thought-space. In this case, around design reviews: What is the next generation of what we do for design reviews?
The role of the Superuser in practice
What proportion should the Superuser be billable vs. overhead?1 Hands-on vs. strategic? Integrated on project teams vs. providing internal consulting? Going wide vs. deep?
Architect and designer Cory Brugger has a Master’s in Engineering from the Product-Architecture Lab at Stevens Institute of Technology, USA. Brugger left Morphosis in 2017 joining HKS as their new CTO. At Morphosis, how much of what Brugger achieved from a design technologist standpoint was project-based? He explains:
The majority of my work came out of projects, but it was always tied to a long-term vision of where the firm was heading. Every initiative and all our R&D was purposeful and viewed as a strategic investment in the future vision of the company. At HKS we’ve got a variety of internal initiatives and external collaborations aimed at supporting the long-term health of the business. What Heath set up with LINE is very project based. There are two ways that they work. They either help and support other projects throughout the offices, which would be more of a consulting role. They might send one or two people to push through ideas on a design or to implement a new strategy for a project’s delivery. Alternatively, they work as a standalone studio and take a project from concept through delivery. We also have a few research groups who are focused on true R&D. They are almost entirely separate from projects which allows them to focus on expanding our industry and market sector expertise.
It is inevitable that one’s role evolves and changes as you grow in your career and your value broadens in relationship to a firm’s needs. Most recently my role on projects was limited to strategic planning, project set out and review/auditing our models and documentation. Most of my time was sitting in meetings, making sure our teams and project consultants were aligned to a project’s goals. Meeting with our clients, contractors, or sub-contractors to go over model uses, and to help support design and delivery processes. Not very much hands-on implementation. That is one of the things I worked on in moving to HKS. We’ve agreed that 50% of my time should be focused on project or initiative work. We recognize that the actual amount of time will vary depending on the work and initiatives that we have prioritized, but it is still a goal for me to remain integrated into our innovation work.
Typically, the higher one rises within an organization, or in the profession, the less hands-on one is, and the more strategic their focus becomes. As Brugger rose within his previous organization, did he miss the hands-on work? “Yes. I’m not ready to let go,” he admits. “Leadership at HKS knew this and it was part of our conversation.” Brugger relates it back to medicine:
You want someone who is involved in day-to-day practice to be administering your care. It is important to have somebody who understands the most current tools, processes, and thinking available in practice today – not what was relevant ten years ago. Staying hands-on is important to understand how one’s decisions will impact practice and a project’s outcome. And by hands-on, I am referring to everything from drafting details to writing code. For example, I’ve probably written a hundred lines of code in the past six months vs. writing that amount every day. I haven’t been doing a lot of platform or plug-in development since I took on a leadership role at Morphosis, so the focus was more on pseudo-code and specifying what we need the tools to do. I still think that this is where I will be in my new role, I don’t need to write code every day. It’s really hard for me. That’s not my expertise. I haven’t wrapped my head around it often enough to be fluent. There are a lot of people coming up who can do it better than me.
Figure 3.5
Career-wise, your goal is to spend as much time as possible in Quadrant II. (2018) Credit: Deutsch Insights.
Billable vs. overhead
Each of the Superusers I spoke with for this book works at slightly different percentages when it comes to billable time. “For me, the best balance that we achieve was typically when I had a member of the computation team running about 50/50,” says Shane Burger. “So, 50% of their time on direct project work that was billable. And 50% of their time on non-project work development.” Burger explains the idea behind this break-down:
You work on projects, with really difficult problems or amazing opportunities and challenges. Learn from something that was developed there. Then potentially, if you’ve seen two or three projects run into something similar, use your other 50% of your time to back-up and further develop a more generalized methodology, and potentially a tool. As part of that then, you then go into the next project already having a framework for a tool put together. Or you teach others how to use this tool. You end up having an opportunity where, yes, I’m focusing on one problem on one project, to start thinking multi-project, to then start thinking across the whole enterprise. To then think about how can I start to apply this to a larger set of problems? Are there some generalizations that can be brought about from this to think beyond the context of my individual project?
As a Design Computation Leader, NBBJ’s Dan Anthony’s proportions of work that is strategic vs. hands-on is smaller:
About 25% of my time at this point is strategic. The key to that is not only is that time spent envisioning, but a big part of being a computational specialist is imagining and planning – we’re managers – but also have the ability to execute. For instance, we’re not going to tell someone what the new process is, we’re going to start to build it, and prototype it, writing out portions of our workflow or toolsets that are missing to get that to work properly.
With such a large portion of a leader’s time spent on hands-on activities, is there a danger of getting lost in the weeds? Anthony admits:
We always get lost in the weeds. Almost certainly. Maybe it’s the joy of the job that there is an opportunity to do that. If I was 100% strategic, it would seem like I wasn’t helping to accomplish anything. Occasionally, it feels really good to dive in to a problem, especially a design problem, and provide solutions at a rapid pace.
Anthony finds himself embedded these days in project work. “Which can sometimes be less technical, but it’s also where you can sometimes discover new opportunities to apply technology for technique,” he explains.
When design technology specialist Jordan Billingsley works on a project specific problem, his time is billable to that project, whereas tool, workflow, and firm-wide office resource development is considered overhead. He says:
I have seen arguments, not at our firm, where they have suggested that a computational designer should be billed on a project, so if a client requests a façade, the most common example, that has some sort of computational design element, that we bill them for computational design work. If anybody’s going to become project billable, it’ll be the computational designer role.
KieranTimberlake doesn’t have “managing partners.” That work is distributed across their seven partners to ensure they all still spend most of their time in design. “As a partner, my design agency extends to buildings and the built environment as well as platforms for thinking and making. I create knowledge networks, and help design new workflows, software, and hardware,” explains Matthew Krissel. This means he typically runs a 70/30 split with his time:
Roughly 15% of my time is towards Digital Design guidance, editing, testing tools, and mentoring and another 15% of my time is in managing the practice, business development, lecturing. The remainder is spent on multiple design projects and I dial this up and down based on a variety of situations and demands.
While we have an idealized mix or framework it is essential to understand it is highly influenced by situational opportunities and demands so it is critical that what you design can be adjusted on the fly. All specialists at KT must be involved with design work directly on a range of projects. Also, it is important to cut across all projects to ensure they have their finger on the pulse and totality of what’s happening here to ensure the stewarding of resources and building skills for immediate needs as well as looking out to future opportunities. They must balance proactive work, the firm goals and digital design strategies while helping to elevate everyone’s digital IQ.
Krissel’s 60/40 split is made up of 60% on projects, embedded in teams; 20% on office-wide resources, training, knowledge sharing; 20% strategy, building discourse, proactive exploration. For Krissel, the choice between being a specialist and generalist is simple:
Be a specialist and be pervasive throughout the practice. Cultivate a restless curiosity and don’t disappear in a corner with your headphones on. Establish your agency and constantly demonstrate your value across typologies and scales, traverse the expected and the unexpected areas of design and engage the strategic and detail parts of the work.
If you compartmentalize yourself, you undermine the most fundamental opportunities of technology and people to expand our design potential in everything we do. Get a seat at the table and help guide architecture in areas beyond just modeling practices, process, and workflows. Proactively engage in the design of new business models, project delivery opportunities, contractual relationships, and the very products we make.
Note
1 See Robert Yori’s Design Technology: Billable or Overhead? Two Perspectives, DesignIntelligence, October 19, 2015. www.di.net/articles/design-technology-billable-or-overhead-two-perspectives/.