Collins: Mihn & Klaus

My third job at Rockwell Collins was to fix the initialization (INIT) and built-in-test (BIT) that had stalled. Since I had solved two impossible problems (that others had failed on), my third job at Rockwell Collins was to write all the initialization and built-in test code (INIT/BIT), and as a 22 year old contractor, to manage 2 other 40-something year old employee engineers that hated each other (and didn't like consultants). So I just wrote all the code, gave them the credit, everyone was happy, and we completed on time. ℹ️ Info           ~ Aristotle Sabouni Created: 2003-05-10

Since I hadn't failed at the bootstrap project, and had written the cross-communication stack, obviously they weren't challenging me enough. They decided that since I had excellent technical skills, they'd put me in charge of people. Why not? I was young, inexperienced, and had the diplomacy skills of Attila the Hun, which was actually an improvement over the prior team lead. Why wouldn't two 40-something employees love being managed by a 22 year old contractor with acne telling them what to do? I guess someone thought that if I hadn't failed at code, at least I could fail at people management?

This was on the INIT/BIT (Initialization and Built-in-test), which was way behind schedule. I had to create all the software to test the machine on startup, and verify that it was working.

This was a conundrum, since if the processor wasn't working, how do you use the processor to tell if it was working? It is mostly possible, but an interesting set of problems. On top of that, since the other two members hated each other (and both spoke broken english), all the code written by one was to intentionally be as incompatible as possible for the others code.

My solution was simple (and the immature one), I threw away all their garbage code (they were taking the wrong approach anyways), and I just did all three of our jobs. They didn't have to talk to each other, I didn't have to talk to them (which wasn't easy), and they got credit for the code, while I got credit for getting them to work together. (E.g. neither of them had to work at all).

Team Leader?

My "project" was to write the software so that a computer could test itself; INIT/BIT (Initialization and Built-In test). This part of the project was way screwed up and way behind schedule; it took me one meeting to figure out why.

There were two engineers who hated, nay DESPISED each other, on the project.

• Mihn was a Vietnamese engineer with a thick accent and a stammer, so communications with him weren't always easy. He was also the previous "team lead".
• Hans was a quick-tempered German with a really thick accent that was a purist that didn't like listening to anyone. (Or didn't understand them, so just did what he wanted)

Their engineering styles were also direct opposite: Mihn being much more a self-taught seat-of-the-pants code first, design later kinda guy, and Klaus, more the buttoned up german process guy. Hans wasn't going to be bullied by some back waters tyrant, and Mihn was merciless (to play on the Flash Gordon theme) with the finger pointing and accusations.

I succeeded by being the anti-Mihn.

At my first meeting with "my team", the two started arguing about something, and their thick accents descended to the unintelligible as tempers got going. They were both trying to decide what the other was doing; and both trying to sabotage each other, and blame them for all the problems.

In the argument, I couldn't follow Hans at all; something about "gutten-fricken-sparken-zippen Mihn acht-dumkopf. YOU DID IT!".

At which point, Mihn turned purple, over the tone, since I'm sure he couldn't have understood what was said any better than I could, and screams back "wh...wh...wh... why... why.... WHY You no sp.. sp... speak... speak... fucky engrish! I c... c... can't underst-st-stand goddamn word you say!"

I lost it, as did a few others in attendance. I don't mock accents (which I enjoy) or speech impediments, but I was one of the few people that could understand Mihn at all in the company, and him criticizing another person's English skill, was just too much. He was pissed, Hans was pissed, and we were reaching critical mass. I stumbled onto how to insert the cooling rods.

I asked them both to just send me what they had and I'd look it over. I told them that since I was now responsible for the project, that both of them were off the hook, and I'd get all the blame. Plus I was a consultant, and we get paid to take blame. So worst case for them, was 6 months to a year for them sitting around, and the new guy would get the axe. They both got enough of that to like what they heard.

After that, the solution was easy. I threw it all away, and would rewrite everything myself. It was my ass on the line. After looking at what they were doing, I trusted none of it. Once they both realized they were going to get credit, and not take blame, and neither of them had to do any work, the team hummed like a charm. We got caught up, and beat our delivery (on our revised schedules).

The task

The task was actually interesting. You have to write code to test only a few instructions, and then pass or fail based on those, then use those to test the memory, and then load more of the processor test and test more of the instructions and modes, and then test all the I/O, and so on. You just work your way up. Once I threw away Mihn's and Hans's code; I explored the prior systems code.

The last generations version was 20,000 lines of some of the ugliest, self modifying code (written by hardware engineers) -- but while they didn't know code flow or software design -- they did understand how to test each subsystem. So I just re-architected what they were doing, and fleshed out new instructions/modes and features and got it down to like 1/5th the size. Reverse engineering a microprocessors subsystems is a job only a turbo-nerd could love; I was in heaven.

Hardware people think they can write code; and they can: they just can't always write good code. That doesn't bug me; I can design hardware, I'm just not that good at it either, so we're even. On many projects it doesn't matter (just get it working); but on ones you have to maintain, it matters. But there's a lesson in there, being able to program doesn't make you a programmer, or certainly not a software engineer. But over-engineering something that someone else has to maintain, probably isn't a good use of your resources. But I did it anyway).

Conclusion

At first I had put both of them on working on the documentation (because there were reams of it to do), while I looked at the code. But let's face it, their English skills were far below acceptable.

I learned something about resource management that many managers still don't get; different people have different skills. I'm still looking for what Hans and Mihns skills were, but I'm sure they had them. But the whole point that I couldn't just throw them on documentation because they were aerospace engineers was a real eye-opener for me. So in the end, I had to redo that too.

There's this whole fairy tale management theory that a good manager can manage anyone. Well, I wasn't a good manager: putting incompatible people together under a tight deadline, wasn't going to work (in the time frames allowed): once they didn't have to deal with each other, and only both dealt with me, things got better.

There is a saying by Harry S. Truman, "It is amazing what you can accomplish if you do not care who gets the credit". Or the counter to that, people act much more reasonable and try harder when they don't think they are going to get blamed. Either way, we delivered early - or at least less late than everyone else. Heck, even with one person out of three working, that seemed to make us one of the more productive teams. .

---

🔗 More

People This is the root for finding info on people

Me This section is all about me (Ari Sabouni). The initial founder/creator of the site.

1986-1988 Rockwell • Collins After I left Rockwell, I went to work for Rockwell. I learned a lot, and accomplished more.

Tags: People  Me  Collins