Training Badge
Submitted by TomW on
in

Forums

I try to believe in the idea of specifying results and letting people use their own methods. One of the issues I wrestle with is that of office standards and whether they get into describing methods instead of results.

I work for a 50-person architecture firm, and we try to standardize some things on the end-product so it all looks like we work for the same company, things like drawing organization, drafting standards, level of detail... you know, basic QC stuff. For that, there's usually not much argument.

The other thing we try to standardize is organization of projects within the company, things like electronic project file organization, CAD layer usage, etc. The goal here was interchangeability, so that in case of a crunch (or a vacation or a termination), other staff members can fill in and be able to find their way around. Since we do a lot of similar (repetitive) work, we can also use it to copy data recursively from one project to another more easily.

We wrote the standard for "worst case" projects, assuming that smaller/simpler projects would fit within it. To simplify it, we have a browser-based creation system that creates all the empty folders for the project.

I've gotten some resistance from one staff member who says that the second standard set is micromanaging, and as long as she meets her deadlines and is on budget (the results she wants), her filing and organization don't matter. Her electronic filing methods are... creative, and really difficult to navigate (it was one of her staff that brought it to me because they could not figure out where something was when she was out one day)

I made the argument that a desired result is the ability for other staff members to work in her project along side her without tutorials on how she likes to do things (which also requires her to re-organize the folders created by the script and create several new ones). With the average project having nearly 4 gigabytes of data and at least 3 permanent team members and 1 to 2 part timers floating on and off, it's important that everyone be able to find what they need. (And in case anyone wonders, yes the filing standards evolve to keep up with technology and changing needs, usually with an annual update/revision published).

Am I specifying methods too much? Or is compliance with a filing standard something that could be considered "a desired result"?

Another side of me worries about the individual. If we let her get away with something minor, will she keep testing the waters to see what else she can get away with? (yes, my issues with her go beyond the filing, but her argument about methods vs results did make me question that one issue)

jhack's picture

Tom, this is a great question. Programmers are similar, believe me!

I focus on their career. If you want to move onto new projects, and if you want to broader responsibility, other people will have to maintain previous work product and will have to work alongside you. And, you need to set a good example for the junior folks.

So, when you ...., here's what happens...[career slows, stuck working on old projects, ....]

If there is not a compelling reason like the above, then you are micromanaging. But if it affects the ability of others to inherit her work or to collaborate, then it's not. It's good practice.

John

RichRuh's picture
Licensee BadgeTraining Badge

Whoa. Hold on a second. This isn't about micro-managing, this isn't about employee preference and this isn't about any issues Tom might have with his direct.

Behavior: Staff member used creative filing methods.
Results: "it was one of her staff that brought it to me because they could not figure out where something was when she was out one day"

This is about [b]results[/b]. Your staff member might feel that they got results, but the [b]team[/b] did not.

And that is where you should focus your Feedback.

WillDuke's picture
Training Badge

I agree with Rich. This is clearly affecting other people, hence it's not micromanaging, it's managing. That's your job right?

Sounds like a C personality, so design your feedback accordingly.

As for will they test the limits - absolutely. It's human nature.

TomW's picture
Training Badge

[quote="RichRuh"]This is about [b]results[/b]. Your staff member might feel that they got results, but the [b]team[/b] did not.[/quote]

Ah, that's the point I was looking for! Thanks!

TomW's picture
Training Badge

[quote="WillDuke"]Sounds like a C personality, so design your feedback accordingly.[/quote]

Actually, she's a mega-D. It's why we collide so much ;-)

WillDuke's picture
Training Badge

I wondered about that after I wrote it. I wondered if they were a D,C. But if you have already identified her personality type, you are probably already adjusting your feedback accordingly. I guess if she's "mega" then you have to "mega" adjust.

I'm always working on my own feedback skills. I'd love to hear how you decide to work with her. (If you have time.)

TomW's picture
Training Badge

[quote="WillDuke"]I wondered about that after I wrote it. I wondered if they were a D,C. But if you have already identified her personality type, you are probably already adjusting your feedback accordingly. I guess if she's "mega" then you have to "mega" adjust.

I'm always working on my own feedback skills. I'd love to hear how you decide to work with her. (If you have time.)[/quote]

We're approaching the systemic feedback stage, so it could get interesting. This is the third time I've had to correct her on standards issues (one was a graphic standard, which makes if a quality control issue and way more serious)

Mark's picture
Admin Role Badge

Yep. Rich is right. She feels micromanaged...that's reasonable. And, it's reasonable for you to ask her to file things to allow others to get to things. I generally would think twice about mandating filing standards, but in your case it's reasonable.

Give her feedback and expect her to change. If there are problems again, more feedback.

Mark

thaGUma's picture

I would reinforce this. Data on building projects is so diverse it needs to be captured systematically. In my previous incarnation, we used a CiSFB system for an architectural practice. Seems unweildy at first but it saved our bacon several times.

Favourite phrase "What happens if you are run over by a bus tomorrow?".

Also your life becomes much easier in monitoring progress as you can dip into specific files to check.

From my experience Architects love to reinvent the wheel, it is part of their construct as they solve problems with lateral thinking as an integral part of the design process. Give them a structure or system and they will evaluate and try to improve on it.

Chris