As you probably know, I'm an Academy Engineer at OutSystems. So I'm responsible for creating OutSystems product documentation and free online training. My ultimate goal is to

Put myself out of work by working closely with the development teams and helping create products that require no training or documentation.

So after reading The Hard Thing About Hard Things, which I very much recommend, I took some time and wrote down the qualities of a good Academy Engineer.

I also believe these are the qualities you should search for in Developer Advocates, and Technical Writers.

On Excellency

Good Academy Engineers know the market, the product, and their audience. A good Academy Engineer is the CEO of the product learning curve, the training content, and the documentation.

On Proactivity

Good Academy Engineers take full responsibility and measure themselves in terms of the success of the product. They take responsibility for driving the development teams into making an easy to use product that requires no training and no documentation.

Good Academy Engineers define their job and their success. Bad Academy Engineers constantly want to be told what to do.

Bad Academy Engineers have lots of excuses:

  • I've lots of stuff to document;
  • My manager doesn't agree with me;
  • The development teams ignores me;
  • Google has ten times more resources than I do;
  • I don't get enough direction.

Our CEO doesn’t make these kinds of excuses and neither should the CEO of the product learning curve.

On 80/20

Good Academy Engineers think about the user stories that are most relevant to the users. Bad Academy Engineers think about covering every feature and being absolutely technical, even if no one will ever read what they wrote.

Good Academy Engineers know when to stand on the shoulders of giants, and take inspiration from others. Bad Academy Engineers take pride in making everything from scratch.

Good Academy Engineers prioritize their work and raise a flag when they know they can't complete a project on time. Bad Academy Engineers, don't raise awareness for derailing projects, and work overtime to hide this from the team.

On Small Crisis and Being on Top of Things

Good Academy Engineers plan ahead and anticipate when to engage in a project. Bad Academy Engineers put out fires all day.

Good Academy Engineers don't get all their time sucked by dealing with the endless interruptions that need their constant attention. Bad Academy Engineers feel great by either facing all or ditching all tasks requiring their attention.

On Communication

Good Academy Engineers communicate clearly in whatever medium is available to them (verbal, technical docs, email, etc).

Good Academy Engineers decompose problems. Bad Academy Engineers combine all problems into one.

Good Academy Engineers assume their audience is really smart. Bad Academy Engineers assume their audience is dumb because they don't understand the subtle nuances of their particular technology. Good Academy Engineers err on the side of clarity. Bad Academy Engineers never even explain the obvious.

Good Academy Engineers take written positions on important issues (difficult to learn feature, lack of training, missing documentation) and follow-up on them. Bad Academy Engineers only voice their opinions verbally and don't follow-up on the decisions. Bad Academy Engineers lament that the "powers that be" won't let changes happen.

On Helping, Coaching, and Developing Others

Good Academy Engineers create collateral, FAQs, presentations, brown-bags that can be leveraged by the rest of the company. Bad Academy Engineers complain that they spend all day doing work that others could do.

Good Academy Engineers take pride in making others autonomous. Bad Academy Engineers rejoice when their the only ones capable of executing a task.

On Asking Why

Good Academy Engineers take nothing as granted and challenge even their own decisions. Bad Academy Engineers don't challenge:

  • The development teams;
  • Product management;
  • Support. And they don't backtrack after taking a wrong decision.

You should also check Good Product Manager/Bad Product Manager by Ben Horowitz. This was what really made me write this down.

And if you're curious about the OutSystems culture, definitely check the Small Book of the Few Big Rules.