In the last decade I've been a CEO to a very technological company and then the security product manager of Magic Leap that acquired us in 2016, in both cases I had to supervise engineering efforts and I found out I have passion to management too. Today, as an angel investor, entrepreneur and mentor, I hope my experience can help others. Here are some thoughts regarding engineering management position and more.
The VP of R&D is responsible* to deliver a working** product***.
*Responsibility by role, and done by managing the R&D team.
** Working by doing tests that either humans or machines run and results prove objectively that all features and test cases are successful.
*** Product is defined as the standard of minimum work done and maximum throughput and impact for your customers, focusing 6 months ahead only. (Everything else is either a lie given reality’s uncertainty or a miserable attempt to die without acknowledging so, unless your startup competes in an existing product/market).
One has to remember that the role of a VPR&D is a management role first, that happens to be in the technology domain.
Your previous life as an engineer is your worst enemy. Your old thought processes are mostly irrelevant. Evolve or die.
The values of the RnD organization are:
- On-time delivery
- Short term focus
- Technological debt
- Work life balance
A value is a compass of when one has a dilemma and needs to choose how to move forward.
Some values could also be of the company’s values too. That’s perfectly alright and even aligns the sub organization with the company.
By being professionals we want to bring the highest industry standards to our daily work life. If it’s infrastructure we use or technologies we employ. Eg working with Jira and Confluence, the level of documentation expected from employees. Whether everything is peer code reviewed or fully documented as a book, the process of pushing code and working with code versioning, coding guidelines, etc. Basically, anything you choose it to be, instead of just “going with the flow” unconsciously which is unacceptable in this regard (Eg everybody uses X so I use X too in my new startup, but think Why first). In management, the way I see it everything should be minded even the most obvious things.
Cooperation is the understanding that communication is key for a successful team work. It could be that if someone emailed you, the first thing you do is to unblock them by emailing back with a "good" response, instead of waiting to the end of the day. To strive to keep emails short and precise. To keep everybody in sync about your work and status. To help others in need. To set expectations of requirements and results with everyone you work with. Keep decisions visible and transparent, so people are more aligned with your ways. Unfortunately, most organizations fail with this value too much.
On-time delivery is a key to a whole successful company. If the company can’t trust the R&D (or any other office for that matter) to deliver on time the company can’t function well. This is critical for building trust between the employees of the R&D organization and the rest of the company. Managing a tasks-list as precise as possible and keep tracking all tasks on a daily(!) basis is a must. If you're too lazy breaking down tasks, or don't educate your employees on raising red flags, for example, you're going to miss milestones.
Short Term Focus means that we aim our product to be good-enough for the next few months by collecting requirements and information that will suffice for that alone. Anything excessive would be considered a waste of time and resources. Since uncertainty is bigger in a startup aiming for more than that is a bad behaviour.
Technological debt can be a tool collapsed under Short Term Focus bullet, however it’s defined nevertheless. In its nature it’s so counter-intuitive and so important that I decided to give it its own value. To keep reminding everybody the importance of the fact that today is more important than tomorrow, because in the tough life of a startup, we might not be here tomorrow working for this company any more (run-way etc). Hence the emphasis of doing the necessary minimum only, although you might know already that in the near future it’s going to be thrown away and re-done at a higher cost later and your technological engineering instincts tell you, unwittingly, to go for the full blown implementation from the first moment. It’s such a hard management behavior to practice and yet so important. Consider it ROI of minimum resources toward highest impact on customers, for instance.
Work life balance is important in a world where we lose ourselves to pursue our careers and escapism is considered by some as positive. But as the value suggests, everything is a matter of balance. If the employees work harder and you still don’t get things on time you should look at your (bad execution) self first and not at them.
When one understands that it’s not cool to work a lot by default then she starts to plan correctly and times become even more precious and things start to tick better. The only time it’s okay to break this balance for the bad is because there’s an emergency (read: when a company might lose a strategic achievement, like wining a demo/POC/PO or losing a customer, etc), or in other words if it’s really justified, and most of the time it’s just not. If it becomes your modus operandi in your organization and you’re proud you maximized the throughput of your employees then, you’re a failing manager.
Obviously management is an art like any other profession and there are many personal touches, and we haven’t even touched how it connects to leadership. While one company define a different set of values, there is no right or wrong here, it’s tailored to the manager and the culture of the company. But throughout my experience I found out that when I think first about a higher dimension of - first starting out with values and then the actual management and execution behaviour/rules, then I get a more cohesive organization and a successful culture that I like to work in.
Eventually we need to remember that technology doesn’t matter, it’s the product that matters the most. Don’t confuse it with a technological product either. And it means that the technology itself in the product doesn’t have to excel, it should be good enough (boy, took me years to learn that) to let the company move on to its next phase successfully, most R&D managers plainly don’t get it.
You're welcome to leave comments, I'd be happy to hear about your engineering management experience and feedback.