Let’s face it. As an engineer we can create freaking awesome stuff – but do we have the business chops to back up our creations? During this post I want to explore 3 critical business skills that I believe every engineer should master.
Data Driven Critical Reasoning
Generally speaking, as an engineer, we are naturally talented in the field of critical reasoning. However to succeed as an Engineer at Zynga you need to ensure that your critical reasoning is backed by the right motivations.
Let’s take one of my favorite examples. Whether or not a team hooked into SVN as their SCM tool should switch to GIT. This is an easy analysis for me. GIT is cooler, easier to branch/merge with, has a strong community, etc… Why on earth would I not switch over to it? Well – the answer is that your reasoning is not backed by the right data. Each of the points raised are valid – however it does not take into account the cost consideration of switching. As presented this analysis is what I like to call a “religious battle” which is tailored more towards the engineers preferences rather than solid data backing up the decision.
What is the solid data then? Let’s dig deeper into the points mentioned (and I will use fake data here). Let’s assume that it currently takes an engineer on your project 1 hour to merge their development branch into the main release branch during releases. Let’s assume you make a major release once a week and you have 8 engineers in your group. In essence the basic time cost is 8 man hours each week or 412 man hours a year. Now let’s look at the flip side. Using GIT it takes your engineer 30 mins, or 4 man hours a week and 206 man hours a year. However in order to move over to GIT there are some upfront costs that need to be accounted for. Let’s assume it takes a team of 2 engineers a full week to setup the servers, establish user accounts, migrate the repo, change build jobs, etc… (80 man hours). In addition each engineer will need to take time to learn new GIT skills, setup their accounts, migrate their personal dev environments over and so forth. Let’s assume 4 hours per engineer to perform those tasks. (32 man hours). When you look at this you think – well on a yearly basis the cost is 412 man hours on SVN vs 206 + 112 man hours on GIT. GIT is still the better choice. The key however is to realize that due to the upfront costs of 112 man hours to switch to GIT that it could take close the 9 months for you to truly realize the saved time of moving over to GIT.
These numbers are fake – but not unrealistic. The key is that you use the right data to analysis your decisions in order to work as efficiently and productive as possible. Avoid the decisions that are based on “personal preferences”.
Engineers are naturally not good salesmen. That’s why we are engineers. However the reality is that the industry wants more from us in a shorter amount of time. How do you control delivering the correct items without having to work all night, every night. Negotiation and Communication.
This is by no means to say that you need to weasel your way out of work. Rather your communication skills come into play to help you understand what the importance of the tasks you are working on. Your negotiation skills come into play to ensure that you are able to focus on the 2-3 most important items and not over-commit yourself to a slew of lower priority tasks.
There are so many good, polite ways to focus on the important tasks. The most effective I have ever found has been to be honest about how long certain pieces of a project can take. Let’s assume a project is broken down into 5 pieces and together will take a full 2 weeks. The product owners however wants it done in a week. By communicating honestly about it taking 2 weeks the project owners can make rational decisions about lower priority pieces to trim out. Here’s the caveat though: Once the deadline has been negotiated you as an engineer need to ensure that it will be delivered.
How then do you account for changes mid project? Well those skills come with time – but the best advice is to communicate often and honestly about the changed circumstance. Let the project owner evaluate the changed circumstances and make delivery decisions appropriately. Generally either the project scope has to be trimmed or the deadline has to be moved. Be honest and communicate often.
Passion and Drive
This is the business skill that is often not hard for many engineers to acquire. However those that don’t often have a difficult career. You can be a software engineer in almost any field. If you don’t engineer for an industry that you are passionate about – you may find that you are just not that interested in designing the required solutions.
For this skill however I want to take a different approach. In this context I want to talk about the importance of having passion and drive even through the grunt times. I call it the ability to do what is needed versus only what is desired. In this job market software engineers are so high in demand that often we get a bit of ego trailing behind us. I hear people whispering things like, “I don’t need to write comments or documentation for my code, that’s what a technical writer does” or “I don’t need to write test cases for my code, that’s what an SDET does”.
I find this approach very dangerous. The most successful engineers I have ever known have always had a passion and a drive for full success of their product. This leads them to oversee success of these sometimes seemingly unimportant details. In many cases I see these engineers starting the work of these details in order to lay the proper ground work. They then start involving others and build upon what they started, leveraging other’s expertise in different fields. This collaborative approach leads to richer documentation and a more solid testing suite that ensures better adoption and stability of their product.
Be passionate about the project you are working. Drive towards the full completion of your project. Help others gain the same passion and drive that you have and together the collaborative result will be far stronger than something you could have created on your own.
It’s not common for engineers to worry and focus on improving their business skills. You don’t need to be a salesman or be a data analyst. However these 3 core business skills will help any engineer succeed in a bright and fulfilling career while at Zynga – or anywhere else in the industry.