Be a (Part Time) Rock Star VP of Engineering [Steve Mezak]

The phone rang in the meeting with the CEO. He said, “Sorry, I can’t talk now. I am in a meeting with my new VP of Engineering and he’s a rock star.”

The title “rock star” can mean different things. To this CEO it meant he finally had someone he could rely on to get the software product developed. The CEO had fumbled badly spending over $50,000 with a local web design firm with little to show for it.

Now he had hope.

A non-technical or business-oriented CEO must hire a competent VP of Engineering to take responsibility for on-time delivery of a high quality product. But what kind of person should our CEO hire? Should the VP be hands-on and contributing to the code? Or should the VP be a people manager and stay above the details of the daily builds?

Either way, you want to hire a rock star. But what is a rock star VP of Engineering?

Rock Star as a Technical Achiever. The CEO of a startup I spoke to recently wanted to hire a VP of Engineering to jump in and start doing hands-on work with Microsoft .NET. His rock star will have his or her own MSDN subscription and personally built several ASP.NET web applications.

Rock Star as a Mature Leader. Another company already had 20 software developers (and a small outsourced QA team in South America) all lead by a young but very smart programmer. He worked directly with his team to create the software.

The CEO wanted to add an experienced VP of Engineering that could harness the existing technical leadership and get some control over the software development process. With business growing, the programming team could increase to 40 people.

His rock star will be able to impose a predictable process, command the respect of a strong technical team while hiring more programmers.

Rock Star as a Global Leader. Some companies will have no internal programmers and rely completely on their offshore software development team. One Accelerance client had their own development team in Ukraine. It was a remnant of an outsourcing arrangement gone bad, which is another story.

But things were still not going smoothly. The CEO needs a rock star leader that keep a global team productive and can hop on a plane to Kiev once in a while to do so. A technical achiever with little concern for cultural issues, or a technical leader that is a good face-to-face manager will not manage a global software development team well.

It is important to understand your situation and hire a full time VPE rock star with the kind of experience that will meet your needs.

But there is an alternative.

The Part Time Rock Star. Instead of putting all your eggs in one basket with a full time VPE, a CEO can hire a part time or interim VP of Engineering to get things started. Part of the interim VP of Engineering role is to find their own replacement.

The CEO benefits by moving the programming work forward and extra experienced help with the recruiting process for a full time VP of Engineering. Otherwise a great deal of time and money can be wasted waiting for the right person to come along, or worse, if the wrong type of VPE is hired for the situation.

On the flip side, if you are looking for a full time VP of Engineering job then decide what kind of “rock star” you are. Consider only the kind of opportunities for which you are a fit. Don’t feel bad if a prospective employer is looking for a rock star of a different stripe. Focus on what you do best and the right job will come along.

But the economy being what it is, consider offering to be a part time VPE if you can’t close a full time opportunity with an employer that looks like a good fit. Working part time is a good way to get some cash flow and for both you and the employer to get started on a trial basis.

Be a part time rock star until a full time gig comes along.

____________________________________
Steve Mezak, CEO of Accelerance, Inc. and author of the book, Software without Borders, is a global software development rock star. Use his free online World Region Outsourcing Guide containing the contact information for 40+ hand-selected and pre-qualified software development partners in over a dozen countries around the world. http://www.Accelerance.com

More...

IT Dilemmas [John Levy]

As an organization grows, it has to increase the scale of IT activities, including software development. As a result, it faces these dilemmas:

1. Software development is engineering, but IT is an expense.

If your only management metric is level of expense, rather than return on investment, then you won’t be able to differentiate between winners and losers in software development. Some organizations have the CIO reporting to the CFO, because they are completely oriented to control of expenses, and IT is a large expense. But this misses the fact that investment in software, whether for internal use or for sale as a product, should be managed the way that R&D (Engineering) is managed – as an investment in development that must ultimately produce a return.

Engineering is not purely execution. R&D/Engineering involves a degree of creativity along with a professional sense of discipline about implementation. That’s why recruiting and retaining people who can balance innovation with execution is as important in Engineering as in, say, Marketing.

2. Outsourcing and offshoring work when the activities of software development can be broken into component parts and split across multiple organizations without loss of innovation or relevance of the product.

In forward-looking organizations, IT-implemented tools provide a strategic advantage to the business. To achieve this, IT strategy and architecture must be very close to the top decision makers. In this context, the question of outsourcing becomes, “can we succeed by having people we have not hired directly execute some part of our implementation?” To the extent that the impact of software or IT on the organization’s strategic goals is not considered, the decision to outsource can lead to failure in many ways.

3. If no one in top management understands how IT works, then all the IT decisions will be made based on financial reports. As organizations get big, they become more and more finance oriented. When someone at the VP level or higher has enough technical background to understand IT implementation, then IT strategy has a much better chance of being realistic. Of course, the CIO should have a basic knowledge of technology as well, because vendors will attempt to sell things which may not be appropriate to the organization. The main problem, however, goes back to item 1 above: managing Engineering is different from simply controlling expenses.

4. Traditional Project Management doesn’t fit well with Agile software development.

When we do software development in an Agile framework, we have fixed time & budget and variable functionality. Almost no one who has been doing traditional Project Management intuitively understands how to manage a project this way. Short Agile iteration cycles confound traditional PM tools and measurements. We need the PM world to come up with a new division: Agile Project Management, with a focus on projects that are not characterized by large sets of requirements up front, and have rapid fixed cycles with variable functionality.

5. It is difficult to overcome an addiction to short-term metrics.

IT managers prefer short-term pain-reduction (ship it!) over longer-term goals (is it what the users want?) every time. This leads to the never-ending cycle of code debt (code that needs to be cleaned up and/or re-written). To overcome this phenomenon we need to understand the psychology of addiction and to get top management to support a change to proper metrics. For further discussion of this, I recommend reading Gerry Weinberg’s Quality Software Management, Volume 3: Congruent Action (New York: Dorset House, 1994).

All 5 of these items also apply to software development in Engineering departments. But the effects are most widespread in IT organizations. How is your IT organization doing?

__________________________________________
John Levy consults on managing Agile development and is a frequent expert witness in computer & software patent cases. He has 30 years’ experience as a consultant and manager at Quantum, Apple, Tandem and DEC. His book on managing development, Get Out of the Way, is due out in 2009. More info is at http://johnlevyconsulting.com/

More...

New Tool: Analysis, no Paralysis [Matt Schlegel]

In my previous blog I described how the problem-solving team generated a rich set of ideas from which to draw candidate solutions to the challenges it faces. But, how does the team go about deciding which idea is the best one? Should they fight, bicker and argue about each?

Well, sure, in a controlled way. I call this phase the Analysis Phase of the problem-solving process, and it is part of a two step process, the second step being the Proposal Phase, in which the team arrives at a consensus regarding the path they will take going forward. In this phase, the analytical folks shine.

Every idea has its good points and bad points, its pros and cons. During this Analysis Phase, I present the problem-solving team with the list of the big ideas that have been generated. I will have taken the many ideas that were generated in the Idea Brainstorm and grouped them into a number of big ideas for the team to explore. Each big idea is allotted time for discussion and for generation of the strong points and the weak points.

It is important to move quickly through the collection of the pros and cons. For instance, if you have 100 minutes and 12 big ideas, keep the pro/con analysis of each idea down to 8 minutes apiece. You will find that you are able to collect the important points in those 8 minutes. And, you can avoid getting caught up in minutiae and falling into the proverbial rat hole. Remember, some folks will excel during the Analysis Phase and want to explore the nuances of each idea. On the other hand, some folks will find this detailed analysis a bore. You will want to strike a balance to ensure the analytical folks have a chance to show off their stuff, while keeping up the pace to get through all the ideas and, at the same time, keeping the entire team engaged.

During the Idea Brainstorming phase, you asked the team to set aside their negative reactions to the ideas aired. During the Analysis Phase, you take the opportunity to revisit those negative reactions. You will want to encourage those that feel strongly about each idea to voice their thoughts and feelings. What has happened in the roughly 7 days since they first had their reaction is that the emotional level will often have subsided and the person who feels strongly will be in a better state to explain calmly to the team the reaction that they had and why they think they had it. I have found that letting some time pass is an effective way to explore the emotional side of each idea without letting emotions rule the process.

So, after spending a few minutes on each idea, would you feel like you have done a proper analysis on the idea? Of course not! What will often happen is that the team will not have all the information that they need to adequately analyze a specific idea. In that case, I ask for volunteers, generally the biggest proponent and opponent of a given idea, to collect the information the team feels it needs to analyze the idea. If the need arises, I may call a separate meeting to review any new information, so the team has the chance to develop the pros and cons for the idea to the team’s satisfaction.
Your Problem-Solving team now has a rich set of ideas with the pros and cons for each idea. The analytical folks on the team have chimed in and provided the data and assessment that the team needs to move forward. That brings us to the topic for the next blog, the Proposal Phase, which I affectionately call, “The path of least danger.”
_______________________________________
Matt Schlegel enjoys data. During a recent presentation to a client, Matt noted that he had to pare back the amount of data in the presentation, saying that there was simply too much data. The client quickly quipped, “I never thought I would hear Matt Schlegel say the words ‘too much data.’”

More...

Reviewing Up - Revenge? [Philippe Habib]

At my first job, when the VP of engineering asked me if I could come to his office for a few minutes, I felt like I was 10 years old and called to the principal’s office. Things did not improve when he asked that I shut the door. This was my first job; I was trying my best to do good work. I mentally searched for what I could have done to be in this much trouble.

Instead, he asked for my opinion of my boss. In my previous work experience , sweeping an airplane hangar, or working in a factory, my opinion of my boss was neither important or solicited. I just had to do what the boss said, and do it quickly enough and well enough to keep my job. I had no idea of how the boss was evaluated, but I was sure that what I thought of the boss never entered the equation in any way.

I don’t remember exactly what I said. Probably something lame like “She’s fine.” or some such. This really wasn’t enough to satisfy him, so he asked me more detailed questions.

• Did my manager make it clear to me what I was expected to do?
• Did she provide me with relevant and useful feedback along the way?
• When I needed help, did she provide it?
• Did she give me too much guidance and try to control my every step?
• Did she have adequate technical skills to give me the help I needed?
• Did she act in a way that made me uncomfortable or afraid to ask for help?
• In areas where another person in the department had more knowledge, was she willing to defer to that person, or did she always need to act as the expert?
• When I did something wrong, did she tell me what I did wrong and explain what I should have done instead? Was this delivered in a constructive way that helped me learn and do a better job the next time?
• Did she give me guidance about what I could be doing to get myself ready for more responsibility in the future?

Once I got over shock of having the tables turned and being asked to evaluate the boss, I answered the questions as best I could.

After we were done, I had my own question. Since she was the manager of 6 or 8 engineers and I was the newly hired, zero-experience, source control person, what did it really matter what I thought of her? I would do what she said and get my work done, whether I liked her or not.

The VP explained to me that the manager’s job went beyond making sure that I had current listings of all software and that I could build the same executable each time. Her job was to make sure that I did my job in an efficient and effective way and that I was happy doing it, so that I would not look for another job. She was also to help me grow into a more skilled role. She wanted me to succeed and be able to relay my knowledge of the company's products and processes, so that they would not be lost when I was ready to do something else.

He explained that all he could evaluate from his position was that the work was getting done, (dust on the floor, finished machines on the rack). He also cared about the stuff that would keep people happy and productive long term, so that he wouldn’t have to hire a replacement for me or have schedules jeopardized by turnover. In order to get that kind of information, he had to solicit it from the people who report to the manager.

Looking back on it after more than 20 years in the work world I now see benefits for all involved in this kind of a review. The VP knew if productivity was the result of fear and intimidation and would vanish, when his people did, at the first upturn of the job market. My manager could be alerted to good and bad habits and become a better and more effective leader. As an individual contributor I was able to influence my work environment and to learn about the bigger picture of how a department is run.

I'm sorry to say that in over 20 years of industry experience I have never worked at another company that did that kind of a review. Lacking the explicit interest from upper management, most people don't take the risk and trouble to review their manager. They just vote with their feet.

______________________
Philippe Habib consults on embedded device design and firmware. Prior to consulting he has worked for Oracle, IBM (lotus/cc:Mail), Apple, and several startups. More information can be found at www.phenomasoft.com.

More...