by John Browne, Technical Product Manager at Growth Acceleration Partners
Not long ago, I was surprised and delighted to reconnect with a co-worker from many years ago. Facebook, for all its flaws, has allowed me to find and chat with friends from years ago that I had lost contact with. In this case, Beck, who worked with me in the late 80’s at Microsoft, offered a comment about an interaction we had when we worked together. “You remember that thing you said to me?” he asked. “Frankly, I had forgotten all about it”, but once he reminded me, it all came back.
At the time, I managed the group inside Microsoft that produced all the manuals for all the language products: C, Pascal, Fortran and so on. This was in the days before online help, and so compiler products shipped in a fat box stuffed with soft-cover books. Our team wrote, edited and produced the books; before the product could go to manufacturing (to make the boxes, floppy disks — I SAID this was a long time ago — license agreement and so forth), we had to send the manuals out for printing. The whole business was tricky since the manuals had to be finished before the software, so as to be ready when everything went to Canyon Park, our manufacturing facility.
Beck was, at the time, one of my smartest technical writers, and as such, he was given the job of updating the manual for our most obscure programming product: the Macro Assembler. The manual was extremely difficult to produce and required a special production system used only by this particular workload.
The complexity of the subject matter (assembly language), the production system and the product itself meant the MASM (as we called it) manual carried a high risk of errors. Errors were always the bane of our worklife, and we had a great team of editors to review things and try to catch everything we could. Nevertheless, every product went out with a “Read Me” document that corrected those glitches we discovered too late, plus late-breaking changes in the products themselves.
Ah, the good old days.
With a new version of MASM almost ready to ship, the manual was within a couple of days of the date to send to the printer, who would then print thousands of copies of this particularly difficult book. Beck was the writer, Marge was the editor. The conversation Beck reminded me of in our Facebook chat went something like this:
Me: Hi Beck, how’s it going?
Beck: The MASM manual is ready for print. Do you want to review it before we send it to the printer?
Me: If I have to review it, why do I need you?
Beck: Hmmmm, ok, let me check it one more time.
Now in hindsight, this might seem a little harsh on my part. Obviously I needed Beck for his great domain knowledge, relationship with our development team, and writing ability. But I knew his knowledge of MASM and 8086 assembly language vastly outstripped mine, so there was little I would be able to add by reading behind his work. The point I was trying to make with Beck was: This is your baby. You own it. For better or worse, it’s your work product. So be sure before you throw the big red switch.
As I said, I had long ago filed this away in my “lost memory” file. But Beck, all those years later, remembered it well. He told me it was one of the most powerful things he had heard as an employee — realizing that I had complete faith in him to get it right. If I remember correctly, after our brief chat back in the day, he dove back into his office and went through the entire manual again, checking and double or triple checking everything before it went to print.
Trust is a powerful tool. The trust I placed in Beck made me vulnerable; if the manual was a mess, it was I who would get the blame. But the same thing that was risky for me was empowering to Beck — my absolute trust in his professionalism awakened a greater sense of responsibility and ownership.
In my different roles over the years managing teams, my standard approach was pretty simple: give people clear goals and guidelines, get them the tools they need, and get out of their way. Let them know I trust them. I’m fundamentally too lazy to micro-manage other people: I have enough trouble managing myself. Of course, you have to have metrics and make corrections when things don’t go as planned. Sadly, I’ve had to make difficult choices over the years when the rare employee couldn’t do the job we needed them to do. In those cases, I blame myself for making a bad hire in the first place.
If right now you’re thinking something long the lines of, “I can trust Maria, but Roberto is a different matter,” Ask yourself what’s missing in you, Roberto or your working relationship that causes you to doubt him. Are you expecting more from him than he’s able at the moment to deliver? Do you not know what his actual skills and strengths are? Is he in “the wrong seat on the bus?” These are questions for you, as the team leader, to answer. It’s not Roberto’s fault you don’t trust him. It’s your fault you can’t trust someone on your team. You need to help him address the issues and deficiencies that keep you from fully trusting him, or find him a different seat on the bus.
As I think back on this particular project, I’m reminded that while there were many projects before that one, and countless projects after it, that one — the MASM manual that Beck wrote — was a very good manual.
And everyone knew it.
Unlock team potential with proven leadership strategies. Contact us now.
