What I learned from Developers…

Innovating in a corporate world leads to a collaboration with product development world. To ensure that the product is unique, and useful, both worlds need to work together on the concept in order to successfully go through the stages of development.

This journey can look something like this:

Interesting things happen when you place an Engineer within a Development team, and give them a role of a Product Manager. Tough lessons that developers taught me included a newly acquired level of humility, and the sudden realization and self-awareness that I actually don’t know anything.

I could write a survival guide that should be called “Developers vs. the rest of the world.” Instead I would like to share my journey, spread out through several posts.

My first contact with product developers was eye-opening. I quickly realized that HOW I communicate requests to the development group is critical to the successful build of the product.

A well-managed development team can build digital models, structures, and features where there are no constraints such as gravity to obey. The abstract mindset of a great developer can create solutions to a problem like I have never seen before.

I quickly realized that I have stepped into a different world. A unique space, with a different language… oh wait, it is a different language! Did you know that there are approximately 500 different programming languages? Two years ago I could name 3, now I can name at least 20, and LOLCODE programming language takes the cake for me. The KTHXBYE became “a thing” in my office. (So did ID10t, and PEBKAC, mostly directed at me.)

There are several topics that I would like to address. Lets start with these three.

Language is the barrier to entry

In order to be accepted into the dev mafia, you have to speak their language. Programming languages aside, there are other “languages” that the developers use to communicate.

Language #1: ‘Confuse the hell out of the engineers so they stop requesting new features’

The use of this language worked on me for a while until I learned to listen to not the words, but to the person. This might sound strange, but the moment I started listening, instead of requesting, the developers stopped trying to confuse me (most of the time).

Language #2: ‘Throw as many irrelevant development statements, acronyms, and dev talk, so they stops requesting new features’.

This one was more difficult to decipher. My head was still spinning, but I could pick out the bits and pieces of the relevant information to not be thrown off so easily. What helped me was learning to be curious and supportive, and the developers appreciated that I tried to understand the bigger issue(s) they were facing.

Language #3: ‘I actually want to explain this you. I will use the whiteboard, and then you can ask for new features’.

This was a good sign. I was now connected to the dev group, even though the acceptance of my being was still under review. The criteria used for acceptance is known only to the developers. Do not try to understand this.

Language #4: ‘I don’t care if you understand or not, I just want to tell you about it”.

This was a very good sign, I WAS IN! I must have done something right, and I was determined at this point to find out what it was. Then I realized something, I started to talk with the developers using their own jargon. Patience, understanding, and the jargon were the keys!

Last language #5: ‘You really do try to understand us, therefore I will tell you how I can make those features come true”.

Now I was on a roll. Don’t get me wrong — during the conversations, my head would spin, words were spoken that I did not understand, world cease to exist as I know it, and I HAD to look at the code. Changes were made that I just accepted and most definitely every time I learn something new (which was and still is the most exciting part).

Take Away: The only way to learn the “language” of developers is to understand development. Familiarize yourself with the different development phases and cycles, the coding techniques and the necessary requirements to build anything. Most of all learn how to listen. Really listen.

NOTE: Also, very important, if you don’t know how to code, learn. Simple as that. This was my mistake.

Assumed Difficulty vs. Actual Difficulty

In my career I have worked with engineers, geophysicists, and geologists as well as technologists. I believed that I did not belong to the non-technical, the “it just works” group. But, when it comes to the development world, unfortunately I did.

It became most evident when describing a requirement of a product to the development team. It turns out that the minor features end up taking a huge chunk of time to build. The assumed difficulty in most cases is incorrect and it leads to frustration on both sides. I ask to be taught and I humbly soaked up every bit of information, and I tried to answer not only the What, but the Why.

Take Away: If you are not a developer, do not assume and forecast any timelines, budgets and effort required, until you talk to one. Now that you have learned to listen, listen some more.

What they require

The holy grail document required by developers is called technical specifications.

Developers really require this one document. Well, they require more than that, but if you get this one right, then you took the most important step in becoming part of their mafia.

I have heard the following statement hundreds of times: “I need a technical spec otherwise you will get what you don’t want.” Or better yet, “I am not doing it.” Guess what happened? I got what I did not want.

The concept of asking the question “why” is well known to me. I ask “why” ALL THE TIME. It might not always be direct; I ask “how is this accomplished?”, “what will you do with it”, “who will use it”, “how they will use it”, “what about this or that”, “show me”, “teach me”, “let me do it”… etc. It all leads to the why at the end. Believe me I have annoyed many people with all my questions.

I thought I had a clear understanding of why I actually ask “why”. I soon learned that the “why” in development has such a profound impact on not only the overall understanding of what is being built, but how it will be built. It is a difference between having a feature that is complicated, not scalable, one-purpose driven and overall shitty and a feature that is simple, expandable, seamless and, dare I say, useful.

So, back to the technical spec. I could write design documents that provide a broad understanding of product, which meant that I could answer only some of the Why. On the other hand, a technical specifications document describes the minute details of the concept and design, data models, and interactions between datasets.

This is a long, iterative, extensive process. It is a game of asking “why” back and forth between the system architect, lead developer, and the requestor. This process requires a clear understanding of use cases vs. business cases, security considerations, auditing of the system, risk analysis, infrastructure changes, third-party requirements, integration issues, tolerances, and environmental conditions, life of the product, control assignments, and many, many more elements.

I haven’t even started on the mock-ups, design, user experience, language, functional specifications, and many more items that need to be addressed.

A technical spec document is not a small task, it is a great endeavor into the world of the unknown to make it known. It is a discussion that turns into a plan with countless revisions. It is also a fight between what is needed and what is wanted, a tidal wave that engulfs time and space. It is during this time that humility is absolutely necessary in order to come to an agreement.

Take Away: Repeat after me: if you want the developers to build your idea, then for god’s sake, work with them to develop proper technical specifications requirements. Do this with clarity and commitment, and your product will be what you want and need. Remember: always listen.

In the next post I will answer the question: Are they human?, and I will address some common misconceptions about development.
BTW: Did you know that there is a feature called “No”?