Author: Michael Donahue

WfH in AED – fun while it lasted?

TEN months ago, I did a web panel with four AED leaders from various-sized firms about their approach to Covid and the work-from-home ramifications. The video can still be found here.

The takeaways from that call – and from what we’ve heard in the months since – is that firms expect the WfH / Flex split to continue on, post-covid. The primary reasons given are:

  1. Talent Attraction/Retention. Quite often, especially in major markets, finding high-end, experienced staff can be a challenge. The ability to offer WfH can both attract potential recruits, and to keep existing staff happy.
  2. Productivity. Productivity – at least that which can be measured – didn’t seem to suffer much. I think the jury is still out in terms of individual’s productivity levels, but especially from a production standpoint, it was same-as if not better.
  3. Office Space. The only thing firms spend more on more than IT are staff and space. With WfH, there’s a current of “can we shrink our floorplan” and “if we do a every-other rotation, can we use hotel stations at half the existing number?”.

A very small number of our clients have defined plans in terms of who comes back, when, and in what manner. We have achieved a technical equilibrium, for the most part, for home users. It really is now about people and process.

THAT’S where everything falls apart. In the panel conversation, I’m pretty clear that I don’t think WfH works in a collaborative environment. For Architects and Designers (and yes, you too Engineers), that is essentially the work product. The requirement for effective collaboration to produce excellent work isn’t uncommon in professional services, but the A/E/D space relies on it *much* more heavily than say, insurance, legal, or other service types.

I’ve found over the years that AED firms aren’t much on “soft costs” – natural, given their constant adherence to project budgets. But that collaboration requirement goes beyond an undefinable metric. A firm’s ability to execute collaboration well can be a make-or-break component.

There’s a reason why studios are clustered physically in offices. There’s a reason why clients pay for first-class tickets to get everyone into a charrette. There’s a reason why the predominant seating layout is a U-shape with an A0 or A1 sized flat-top cabinet in the middle. Because we know, at some instinctive level, that close teams create better work. That the “magic spark” of great design can not only sprout from a single talented designer, but from a team all standing around a set of plans.

But with understanding that, and missing that, it may not be the biggest obstacle to a long-term WfH flex.

THE biggest deciding factor may be the unwillingness of leadership and project managers to take on the headache of managing remote teams.

Let’s be honest – it is just harder. I’ve been doing it for a long time and I’m still Very Bad at it (though last year, I was Terrible, so improvement!). Harder to communicate. Harder to review. Harder to engage. Harder to gauge productivity.

Architects and Engineers are extremely conservative in terms of approaching change in the industry – see “years to adopt CAD” and “years to adopt Revit”. This is the classic case of we know what works vs. what we’re still unsure of. Don’t underestimate that rip curl of thought in the company.

BUT Mike, you protest, what about tech? What about A/R V/R X/R drones and 3d printers and all the other twenty-first century tech? Why can’t we recreate the office virtually?

Two reasons. First – the tech isn’t there yet, and honestly, not even close. There’s few offerings now – The Wild is one of the few that look promising- but as much as a leader it can be, we’re still below achieving 50% of that in-person experience.

Second – and this is a hard truth – I apologize in advance – but leadership in A/E/D *loves* shiny things. Where that comes from – and I suspect it may be in part due to the Keeping Up with the Joneses effect – contrasts a bit with their normal conservatism. If I had a dollar for every dusty laser cutter, 3D printer, VR station, VR goggles, I’d have… a lot of dollars. Which is not to say the tech can’t be effectual. It’s just that the shiny-shiny aspect of a tool isn’t always matched by the necessary level of effort, support and training to *make* it effectual.

BOTTOM line – We will ease back into normal work conditions in much the same way we eased out of them. All it takes is a few key firms making the decision to bring everyone back, and the rest will follow suit. Hotel stations are a horrible idea that sounds great but never works in practice. Managers (and staff) don’t want the continual exhaustion of Teams meetings. And if the decrease in collaboration capability hasn’t shown itself yet, it certainly will in time.

Once leadership feels they won’t lose staff due to the Great Come-Back, they’ll accelerate. Then pressure (of various sorts) will be placed on those not coming into the office, even if “technically” allowed. Or people will be offered a choice to accept a remote/flex position, but at a significant pay cut.

And I’m not criticizing this in any way. It is what the industry is. But 10 months from today, the 50/50 worker will be the exception, not the norm.

Tell me why I’m wrong. I probably am. 🙂

Filed under: Uncategorized

Security in the AED industry

I’ve been doing IT for a long time – a healthy chunk of that within the AED industry. There’s a bunch of variances that set apart the AED world, both within IT and without.

One of my favorites is how open most firms are. They’re open internally – “we want all staff to be able to see all projects” and they’re open externally – “sure, yes, let’s share what worked or didn’t work with them”.

A deeply cynical person might say that these are due to the desire to easily shift labor resources around, and to maintain the “keeping-up-with-the-Joneses” culture that’s fairly prevalent.

But as cynical as I am (I make Diogenes look like an optimist), I don’t buy those reasons. Leadership I’ve dealt with do want to make project information widely available, for all sorts of reasons. They do want staff seeing different approaches, different methodologies. Hell, many firms spend thousands every year sending people to Knowledge Management conferences, which, to be honest, I *am* deeply cynical about.

They do enjoy sharing information with other firms. The associations I’ve been part of – AECIT, LFRT, etc., have been a great resource due in large part to the willingness of firms to be open about things other industries would jealously guard.

I am going to make some general statements here. They’re all worthy of commentary in and of themselves, but here, they’re just laying the context for the security vs ease of access conversation.

  1. Most firms follow a traditional career ladder system, where leadership is comprised of older (50+) staff.
  2. Those who were born prior to the Internet, in general, have a harder time adjusting to new/different technology.
  3. C-suite individuals, whether in AED or other verticals, have a bottom-line approach and don’t like to be mired down or impeded when trying to do their job.
  4. AED firms tend to govern by consensus rather than mandate. (Engineering firms are a *bit* more ok with mandates than Architects/Designers, but not by much.)

Just putting those out there. There is no judgement attached, but if you disagree with me, please let me know – I’m always keen to hear other takes.

For the first 10-15 years I spent in AED IT, nobody really cared about security. Let’s be honest. Do we have the basics covered? Yup? Ok. Moving on. Any security discussions were had post-event, never before. And if they did, they were brought up by IT, not leadership. The problem was, that proactive conversation was always had a cost component (we need better A/V-Backups-Firewalls-etc). And explaining how big a risk there is between using Defender ATP vs. Webroot is *really* hard to explain, let alone explaining that doubling your expense is worth it.

So firms would be lax on anti-virus, and then there’d be a virus, and then the anti-virus would be an important expense. And then there’d be a virus from email, so anti-spam/email anti-virus became a big deal. But in general, when IT expenses result in *soft cost* savings rather than *bottom line* savings, it is hard to get AED leadership on board. Which I don’t think is purely unique to AED, but when you’re dealing with people who *always* think about the bottom line, project budgets, profitability, resource planning – the concept of soft costs is even a bit more ethereal.

But that has changed in the last five years, just a bit, and *really* has changed in the last two years.

Obviously, the anonymity Bitcoin provides is part of it, but really the explosion came with the massive increase of Office 365 migrations. When email is hosted with Microsoft, it is very easy to just attempt to log in as a user. *Everyone* gets their webmail by going to outlook.office.com.

So if your work email is floating around out there – be it one scraped off the company website, or one used on a different site that was breached – the attackers now have 2 of the three items necessary to get into your mailbox. 1) “where” it is on the internet. 2) your username. The last third comes down to your password. As you might expect, this is not as hard as you might expect. The need for dozens of accounts for various websites means people keep passwords simple, keep passwords for a long time, and use the same passwords on a bunch of different sites.

This is why MFA (multi-factor authentication) is an *absolute* must have. No discussion. No “but this, but that”. No. Shoosh. But across our industry, IT continues to run into roadblocks concerning MFA and security in general.

There is a one-to-one correlation between security and ease of access. A great example of this is MFA. Before it was, go to website, punch in username/password, hit go. Now it is go to website, punch in userinfo/password, get an MFA prompt, get your phone out, get a code, punch the code into the site, and go. There’s a dozen variations on that, but it can be a hassle.

This goes into all aspects of internal security as well. Restrictive permissions on a project? “Why can’t I go there?” Requiring passwords on file links sent via email? “Why can’t they just click it?” As security increases, access decreases. To increase ease of access, you lower security.

The true trick, the true slight of hand for IT, is to attempt to increase security to a decent level with the minimum of headache for end users. Because there isn’t a lot of buy-in, especially at the leadership level. Yes, you can implement MFA, but not for the C-suite. Well – they’re the ones who need it most. I can cite a dozen instances over the last two years where firms have lost money due to impersonation via email.

So if you are in leadership, please take these suggestions onboard.

  1. Set the example. It is hard enough to enforce security measures of any stripe if others know you’ve decided to ignore it.
  2. Understand that email impersonation fraud is the #1 risk right now. If hackers encrypt your files, you can go get backups (or pay them off). There is *no* backup of your bank account.
  3. Many of the frauds that occur happen because there is no secondary verification. Almost all of the frauds are “this is urgent, I need this asap!” requests. Train your staff that when any email is received with a nonstandard request regarding money in any way, especially if it is urgent, to have them *call* the originator. It takes ten seconds. If it is a legitimate request, it shouldn’t bother the requestor. Another step? Yes. Important? Very.

For the AED IT folks:

  1. Don’t give up when security is concerned. Your obligation is to the best interests of the firm, and if that means sounding like a broken record, so be it.
  2. Try to right-size your security stance with what your firm does. Firms with DoD contracts, for instance, will require a unique posture.
  3. Don’t stop with MFA. There are many items you can take to increase your O365 security, not the least of which are Conditional Access rules and some other fairly straightforward policies which don’t necessarily impact end users directly.

 

In summary – I think everyone gets it. We work in a culture that strongly values openness and sharing of information. But we need to figure out together how to accomplish that while still protecting the firms we work for. If that means another 10 seconds out of your day, or a small fractional increase of the IT spend, so be it.

Filed under: Uncategorized

The Incredible Disappearing CAD/BIM Manager

I’ve danced around this topic a bit before, but let me strike at the heart this time.  One of the benefits of only having customers who are Architectural firms means we get to see some of the trends that happen in the industry, sometimes even a bit earlier than those working directly in it.

One such trend is the minimalization (is that a word?) of the role of CAD Manager, or BIM Manager, or Design Technology Manager, whichever your firm calls it.  In the early days of CAD (when papyrus was used), the CAD Manager bordered on semi-deity.   Computers were scary enough – CAD on computers (yes, redundancy, I know) was even scarier.  Licensing. LISP. Confusing commands, whole other languages!  Users (and leadership) had no problem signing off on the idea that a CAD Manager could be 100% non-billable, and that was still perfectly OK.

Fast forward 10-15 years, and that “unassailable” guy or girl?  Not so much.  The mystique started to roll away.  Many of the functions that CAD Managers had created in LISP became integrated into the product.  Then Revit hit, and the window was cracked open slightly for BIM Managers.  The reality today, however, is that *most* firms use Revit simply as AutoCAD on steroids.  Plans, elevations, and some modelling.  “True” BIM, or BIM as part of IPD, is still some way away.  So whatever awe that BIM Managers were first held in disappeared shortly after leadership realized, hey, we’ve moved X percent to Revit, and we’re doing just fine.

So a devaluation of the position based on the perceived ease of using both AutoCAD and Revit has contributed, but there are other factors.  Someone I respect opined that the reason Leadership doesn’t value the role is that the decision-makers are all right-brained, design-oriented individuals; and that the actual CAD/BIM production process can be very left-brain. And because of that, they have a hard time valuing the role.

Another opinion is that the proliferation of technology in general has devalued technology support roles overall;  that a much higher comfort level with technology – at all levels, including leadership – leads to more questions of “why”, rather than blind acceptance.

Personally, I think all of those contribute, but right now, the economy plays a large role.  A number of AEC firms are slowly emerging from this economy with a much greater desire to be aware of, and to control, finances.  Unlike when we’re all fat and happy, there is a huge focus on the absolute bottom line – what are my dollars in, and what are my dollars out.   In scenarios like those, “soft costs” tend to play a very minor role in comparison to their big, hard cost brother.

And that, in a nutshell, is why the CAD/BIM/DT Manager is slowly fading away.  It isn’t malevolence, it’s just a case of “I have this person who costs me X dollars and they generate Y dollars”.  If Y-X is positive, you’re OK.  When it isn’t, look out.  Because that is a black and white, very easy to see calculation of how you are contributing to the firm’s bottom line.  And it isn’t reasonable to yell at Leadership for thinking this way; too many people in the negative, and no more company.

Many of you have participated in group/individual personality labeling, for more effective communication.  You’re an INTJ, they’re ENFP, or you’re a muffin and they’re an orange, however your particular program divided up people.  At the end of the day, however, most have the same goal: how do you effectively communicate to an ENFP/Muffin?   Current CAD/BIM/DT Managers should be looking at their *organizations* as a personality type that likes cold, hard facts dished up in an analytical, unbiased manner.

So what does that mean?  Metrics.  Stats.  Black and white numbers, without the BS.  You can say to Leadership “I play an essential role”, or “CAD standards are hugely important to productivity” and you’ll get a nod and a “uh-huh”.  You need to be saying “My role saved this firm $250,000 worth of billable man-hours last year”.

This is *not* easy.  Much of what you do *is* soft.  You help.  You create.  For all intents and purposes, every hour you spend non-billable is a complete money sink.  That’s the hard view.  As difficult as it may be, you should start trying to create actual metrics – statistics – for your role.  Especially those that pertain to supporting billable hours or overall productivity.  An easy one is Save-to-Central times.  Let’s say, because of your optimization efforts, each project STC averages 5 minutes faster, and each staffer saves 4 times a day.  And you have 100 Architects.  And they average bill at $150/hour.  Congrats, that’s a million dollars worth of labor saved over a year.  Or how much time is saved from reusing families you’ve created.  Or how much time is saved by team members who move from one project to another not having to learn a new file structure.  Those metrics are out there.  You need to start finding them, and start assigning numbers that aren’t crazy or unrealistic.  They need to pass the B.S. test.

Thusly armed, go forth on a marketing mission.  You can have the best stats in the world, but they won’t help you one bit if no one knows about them.  Don’t wait for the day when they come with bankers boxes.  Either team up, if your firm is small, or find someone in Leadership who believes in your role, and have them help you craft a simple presentation.  Make your case heard, at the very minimum, of once a year.  If you belong to a group, make sure the group leader is doing this at an executive level.

Because believe me, the case needs to be made.  I believe in your role – very strongly – but I’m bucking the trend.

Filed under: home

Work From Home: Fun While It Lasted

Filed under: Uncategorized

Technology Debt in IT Operations

There’s a new buzzword making the rounds in appdev circles called “Technical Debt” – basically, the concept that as a project grows/changes, that there is effort required to manage all the implications of the change, and the longer you ignore that work, the more costly it is to correct down the road.

I’m not above plagiarizing (my Facebook page is basically a subReddit) – and I think there’s a corollary to be found when it comes to traditional IT Operations.

Flying Buttress is a consultancy. People don’t reach out to us when they think things are going great internally, that they have everything covered. We get contacted for three basic reasons:

1) Things are a mess, and they need help.

2) They have a ton of work to do, and not enough internal resources.

3) They want an outside ear and outside eyes to give a different perspective or to provide advice.

Personally, my favorite situations are the encounters of the first kind. If you work in IT, you know the satisfaction that comes when you’re able to see the results of your efforts in a tangible way. The mess-cleaning situations are like any other cleanup operation; there isn’t a lot of complexity – plan well, spend well, and put in a lot of elbow grease.

But over 20 years, when I’ve seen bad IT situations, it is usually because firms have accumulated too much technology debt. One of the main concepts of proper IT management is that it requires a constant annual spend. Major fluctuations, either upward or downward, can have severe long-term effects (i.e., dropping a huge amount of money to replace all the computers which means they all end-of-life at the same time rather than in a controlled, staggered manner).

In Architecture firms, my *very* loose rule of thumb is that the IT spend for a firm in standard, non-aggressive IT mode is about 6% of NSR (Net Service Revenue). As revenue goes up, projects come in, bodies get hired, spend goes up; and conversely, bodies lost means IT spend down. But if you start grossly cutting that into the 2-3-4% range, you start accumulating technology debt.

It is not an uncommon situation. Things get bad over time, so leadership goes out and says “hey, we’re in trouble, let’s spend a bunch of money and fix all this”. Consultants brought in, new hardware purchased, and yes, things get better. And soon – sooner than you might think – that need for a consistent annual maintenance spend is forgotten. There’s a “coasting” effect of that injection of equipment that doesn’t always speak to the multitude of components that comprise IT operations.

If you’re Leadership, and reading this – I’m not making this argument to get you to spend money. I’m making this to save you money. Because in IT, that technology debt doesn’t just have a hard-dollar connotation. You will lose far more money over time in outages, lost data, speed issues, and general productivity than you will that 5-6% of NSR. I’ve seen it.

Here’s the dumb car analogy. I’m the mechanic. I’m telling you you need to spend about $100 a year taking care of the various parts on your car. This amount varies based on how nice of a car you have. You tell me, well, I just spent $300 two years ago getting the brakes done. That’s great, but you still need your fan belt changed, wiper fluid, and your left taillight is out. You can pay me $100 a year now to make sure those are taken care of, or we can wait until you’re broken down on the freeway.

I am willing to have philosophical discussions about the relevance and importance of technology to Architecture, but I’m also able to just view it in cold black and white numbers. And technology debt – especially debt that can come due at the worst possible time – is just not good for business.

Filed under: home

Metrics, metrics and more metrics

IT always feels a bit behind the corporate 8-ball when it comes to justifying costs. There’s two main factors for this – the first is that for almost all firms, IT represents the biggest pure overhead money suck (behind labor), with usually zero net income to show for it. Second, IT workers tend to make more money that other support group functionaries, from entry level to skilled labor.

So for 99% of firms, when the c-levels look at the balance sheets, the IT spend is just seen as a painful cost of doing business, with it appearing a bit like the Pentagon’s Black Ops budget – money going in without a good understanding of *what it all means*.

None of that is going to change anytime soon. But with Architects and Engineers – who live and die by exact hour calculations, meticulous details, and precise metrics regarding WIP and profitability – it’s an uncomfortable state. And the default reaction is to try and get IT metrics through a ticketing system.

There’s a bit of built-in conflict here; never, ever do the execs want to force users to open a ticket to get help – but at the same time, they want to see exactly how busy IT is – how responsive it is, how many tickets we did this year compared to last, and more importantly, do we really need that tech in Buffalo?

While this makes perfect sense on the surface, for Architects and Engineers, this is a trap. And here’s why.

1) It is not the statistic you should be caring about. It is very possible that your team does 1000 tickets a year, and the staff hates IT. You can do 900 tickets a year, and the staff loves IT. What is it you really want? Do you want IT to be perceived as responsive, supportive, with excellent customer service? If so, the number of tickets opened/closed will tell you absolutely nothing in that regard. What will? Customer surveys, annually/biannual/quarterly. Identify what the users think you’re doing right/doing wrong, and adjust accordingly.

2) Your IT staff will focus less on customer service, and more on ticket creation/closing. Once IT realizes that the metric leadership cares about is tickets, *that* becomes their focus. User wants a mouse? Ticket. Forgot the wifi password? Ticket. Is it ridiculous to imagine that if a tech knows they’re “short” that month on tickets, that they create some? We all know how police work with their ticket quotas. Is that really what you want IT focused on?

3) It’s a slippery slope. The next logical progression to this becomes the “you need to open a ticket” comment. The phrase users hate hearing. Once ticketing becomes the be-all, end-all, however, the mandatory ticket comment isn’t far behind, either by de facto or de jure.

And that’s not for design firms. Architects and Engineers are high-touch professions. You’re used to getting the same level of service you provide to your clients in turn. That means that the IT guy is sitting out on the floor with everyone else and not in a call center in India, which would be a hell of a lot cheaper. When you’re on a deadline and can’t save a file, you don’t want to talk to “Rick in Bangalore”, you want to talk to a guy you know, and you sure don’t want to have to open a ticket to talk to him.

Tickets have their place. In very large firms, when you have a team or staff who never leave their cubicle, whose only task is to churn through ticket after ticket remotely supporting users, it can help. But that just doesn’t exist in firms under several thousand staff. And it certainly isn’t conducive to providing the highest levels of customer service.

It’s easy to understand the desire to try and tie down some aspects of the ethereal IT spending pit. But it needs to happen in reverse. What do you truly want from your IT organization? And is that goal measured by how leadership and staff feel about IT, or about whether Sally opens 8 vs. 10 tickets in a day?

Filed under: home

Interview with a BIMmie – Gautam Shenoy, Steinberg Architects

This week’s interview is with Gautam Shenoy, BIM Director with Steinberg Architects.

Filed under: home