An Open Response
I attended the SDForum Engineering Leadership SIG talk What Defines an Early Stage A+ VP of Engineering? held on Thursday, October 16 at SAP. Matt Pérez, COO of nearsoft.com, spoke his mind on the subject in the context of his own experience. I see a lot of presentations. Matt’s style and presence puts him at the front of the class.
At the end of his talk, Matt opened the floor for audience questions. He also opened the floor for the audience to answer (or simply opine on) the question. One guy asked–I paraphrase here–the question, “I am a CEO; How do you VPs of Engineering want to be managed.”
The audience and the CEO bounced the conversation back and forth for quite a while. It ended with more facts about the CEO’s situation than with answers or solutions. Here’s what I recall. The CEO:
- leads startup company
- has a six month product development plan
- has technical degree
- has not seriously programmed since college
- cannot assess if VP Engineering is performing satisfactorily
Audience members commented on the six month development plan. I want to add here two more comments that emerged as I’ve thought about the question over the past week: communication skills and models. I will first chime in on the development plan.
Development Plan
In the context of a startup company building a software-based product, a six month calendar for milestone delivery is too long a time window. My opinion. Why? A development plan is not simply the milestone dates extracted from the marketing plan.
Marketing plans, business plans and development plans are all very different animals yet they both describe the same business but from different perspectives.
In the diagram above, milestones are only one part of the development plan. The development plan may extend for six month or longer. Of course it can. Budget planning requires that. However, I’m an advocate of agile methodologies. Pick your favorite flavor. I choose Scrum.
In doing so, milestones fall into one of two buckets: now and later. The now bucket is the set of milestones to be delivered in what scrum calls a sprint. A sprint is simple a two or three period. It can be a little as one week or as long a four weeks. Every day, developers choose a set of tasks and commit themselves to finishing those tasks.
This is all very binary. Either developers finish the daily tasks they take on or they don’t. Either the development team delivers the milestones for the now bucket or they don’t.
Communication Skills
From the comments, the CEO had a lot of experience in marketing and sales but little experience in development. Consider that the communication skills that help a salesperson succeed in meeting revenue goals are very different than the communication skills that help a developer succeed in meeting milestone commitments.
On the surface, a sales approach might seem appropriate to secure commitment on a set of near and long term milestones. It is not. In selling, there is a trade of values. You, the sales rep, offer a product and through conversation, influence the buyer to commit money in exchange for the product. All platitudes of seller and buyer partnerships aside, the roles of seller and buyer are well defined and they are not on the same team. That’s okay. That’s simply the nature of that game.
Contrast that with the nature of milestone scheduling. Everyone is on the same team. But consider the impact of selling a schedule. Consider the techniques used in sales: tie downs, uninvited debts, reciprocal concessions, and so on. These are not speech elements which help developers solve problems. Speech techniques that work for a sales rep to “uncover hidden money” does not work for a developer to “uncover the cause of thread lock”.
Every time you sell a schedule to a development team unfamiliar with the mechanisms of selling, you diminish the trust and respect the team has for you. In turn, you diminish your ability to lead.
Topic of communication fills volumes. I will offer here but two alternatives. They are not the only options.
One option, put the VP of Engineering on equal footing with respect to the communication style. Have her trained in brutal negotiation tatics. The upside is that you will end up with a schedule that the team more consistently delivers on time. The downside is that the team will solidify their trust and respect in the VP Engineering and increasingly see you as the enemy.
A second option, take responsibility for the success of the development team, including the VP of Engineering. The upside is that you increase your ability to lead. The downside is that it requires more of your time. A lot more. And it is more difficult that the first option. The key is to improve the quality of communication with your team. (A deep and controversial topic which I leave to you as an exercise to investigate.)
One last work on communication skills. When a development team uses their development process as a fortress wall to protect themselves, it is a symptom of a chronic lack of trust and respect. I have personal experience where the team lead used user stories to bury the marketing team in an endless morass of rework. Agile methodologies are designed to facilitate flexibility. Beware of anyone using an agile methodology to justify insubordination. It is cancer.
Development Model
Lastly, you are either the CEO or your not. As CEO–especially a CEO of a startup–you have a responsibility to know how your business operates. If you cannot determine whether your development organization is performing well or not, you have a responsibility to find out.
I suggest you take your VP of Engineering to task. Immediately. Have him create a model of the processes and methodology the development team uses. You don’t have to understand the minutia of every line of code, the configuration of every tool, the… you get my point. But if you don’t have a working model of how they do their work, there is no common language in which to communicate. (That damned communicate word keeps popping up.)
The model doesn’t have to be literally accurate. The Bohr Model is very useful for chemists and physicists when they discuss the atom. But they understand that the Bohr Model of the atom is not the atom. It’s a model. And there are times when the Bohr Model is insufficient for the conversation; a new model must be used.
So it is with business operations and processes. Establish a working model and insist that the management team understand the model. It will improve the quality of your staff’s communication and in turn the efficacy of company teams.