The Artist Engineer and the Bottom Line [Courtney Behm]

I once worked for a software company where the developers were a tight, creative team so dedicated to the success of the product that many of them had been with the company for 8, 9, even 10 years…an unusual statistic in this era of 2 years here, 2 years there. Like many companies, it hit some tough times and there was a management change at the higher levels. This new group of managers believed that software developers were interchangeable -- that one was just as good as another; that they could be moved around from product area to product area, or replaced by offshore engineers; that this kind of movement would have no real impact on productivity or morale.

It shouldn’t be too hard to figure out what happened…the core group of engineers that developed the product were broken up, a few went to other product areas, most were laid off, and all future development was moved offshore at a vastly reduced cost. Bottom line, 1. Employees, 0.

I would like to say, as a great object lesson, that the company didn’t survive as a result, but it is still very much with us. What did happen, in the words of the remaining employees, was that the heart of the company went out of it. The extraordinary culture that inspired people to work long hours, to make themselves available at all times of the day and night, to collaborate and cooperate, and, most importantly, to trust their organization, evaporated. People put in only as much work as needed to meet minimum requirements. A culture that had been voted among the best places in Silicon Valley to work became a place where people punched a figurative clock, while they waited out the recession until they could find a more hospitable home. Pretty sad, I say.

To maintain the growth and vitality of our software industry, we need committed and talented software engineers. To retain their commitment and talent, we need to be aware that they are a special breed, with a quirky way of looking at the world, and an idiosyncratic strategy for solving the problems they are given and enabling the future most of us can’t imagine. They are artists of the mind, able to make magic happen with electronics, and they have profoundly changed our expectations of what is possible. They are not, as the company I highlighted believed, interchangeable, any more than you could walk into the Sistine Chapel one day and tell Michelangelo that you were replacing him with an art student. Failure to respect this unique contribution of innovative employees might not take a company down the first time, but eventually the air will leak out of the balloon, and you will have just another formerly great company with a “For Lease” sign on the corporate headquarters. I’ve been there more than once, and I expect you have too.

But there’s a dark side to allowing talent retention to drive business decisions. It’s possible to lean over too far to protect local talent. Pandering to the tyrannical demands of a software Nureyev can paint management into a corner, and make them dependent on one or two key employees to keep the company running. An organization needs balance to survive, and sometimes fresh air and tough love are necessary to free it from the cage into which it has locked itself in a vain attempt to keep key engineers from leaving and taking all that source code expertise with them.

Artists are not the easiest people to manage, and managing artist engineers asks a lot of us Engineering leaders. We need to acknowledge and value the uniqueness of their contribution without giving up our management discretion. We need to document and share the knowledge they have given us so that we are not held hostage to their expertise. We need to respect the necessity to turn a profit without throwing the wrong people out of the boat to achieve it. We need to remember the importance of culture as a motivator, and honor it as much as the situation allows. It won’t get easier, I’m sorry to say, so over time we will be challenged again and again, caught in the exquisite tension between profit and creativity. But we are learning organisms, so perhaps we will in our turn become, at least in small part, artist leaders, more and more flexible as we enable a future that only our artist engineers can make real.

___________________
Courtney Behm holds a B.A. and an M.A. in Performing Arts and Communication, and an M.B.A. from the Harvard Graduate School of Business. In her corporate career, she has worked for wildly successful companies, and those struggling to stay afloat in the ocean of change. Through her consulting company, Viewpoint Solutions (www.ViewpointSolutions.com), she has helped a diverse client base, including Sun Microsystems, Adobe Systems, Wyeth Pharmaceuticals and the San Jose/Silicon Valley Chamber of Commerce, find creative solutions to classic business problems. An accomplished speaker, Courtney uses a combination of language, humor, insight and front-line experience to offer a fresh perspective on life in the fast lane. In 2006, she returned to the corporate world, and is currently Senior Project Manager at i365, A Seagate Company. She is writing a book on how to lead effectively in a time of constant change, and collaborating on a book on Personal Career Management.
More...

Investing in People [David Skyberg]

Here’s an old saw that I bet you recognize: “Our people are our most important asset.” Or how about this one: “Investing in our people is just good business.” Truer words…

Yet while we all chant the same hymn, do we actually perform as if these are closely held beliefs? I will challenge you to consider how you make these axioms actionable. I’ll wager that most of us measure up woefully short.

Here’s an easy tell that might give away your position: is your training budget actually used? Or do you plan big at budgeting time with the best intentions, but consistently lament at the end of the cycle, “We just didn’t have the time to send folks to training this year.” Kimberly ought to have a flag for that (if you didn’t get that reference, you really need to come to the EL SIG more often)!

What does investing in our people actually look like? I will submit that it doesn’t look all that different than any other business objective. We ought to be able to set SMART goals (Specific, Measurable, Actionable, Realistic, Time-oriented) and be held accountable for our performance against them, just like any other goal.

Now it starts to get interesting. If we are going to have real, actionable goals, how do we establish a vision to drive our goal setting? From my perspective, if you are looking internally for this vision, you may be a bit off target right from the start! If our people are the focus, then it is their vision that really needs to be paramount in the plan. But wait! What if their vision doesn’t sync up nicely with our needs? For instance, what if Janice, your ace tester, wants to become a developer? What if Johnny’s vision is to leave development altogether and become a product manager? What if Jane’s vision is to leave your enterprise app company and get into smart grid development?

The bottom line is that if you are really invested in your people, then it doesn’t matter what their career goals are. It only matters that you uphold them and honor the individual in the process. If you do this, then for the time that they are on your team, they will be better performers, and you will be creating an alluring culture.

So here’s my quick recipe for acting on the goal of truly cherishing your people, and raising them to be all that they can be.

·Routinely set aside 1 on 1 time with each direct report to focus specifically and ONLY on career planning (I target once a month). Be disciplined about this. Don’t allow this time to digress into project status meetings. Don’t let it be a feel good, “so how’s your life going” time. Drive toward the achievement of the next bullet.

·Take as a personal goal that every one of your direct reports has established a 5 year plan for which they are passionate. Commit to this goal with your manager. Be as committed to this as you are to achieving budget/revenue goals. Act on the belief that it is just as important.

·Ensure that each of your direct reports sets near term, actionable goals that advance their 5 year plan. Ensure there is commitment to these. Hold these up as being as important as any other commitment they make. Make them part of your standard review process, and hold them accountable for achievement.

·Participate in your direct reports’ growth by setting actionable goals for yourself that help them advance their 5 year plans. Commit to these and prove to your employees that you mean it when you say you are invested in their growth.

As high flying, star performer in your own right, you will be amazed at how creative you will become in helping your people achieve their dreams. You will be astounded at how good you feel about yourself as they check off their career milestones. And you will be dazzled at the positive impact this is having on your work culture and team morale. Hey, it’s just good business!

___________________________________
David Skyberg is a software team builder with over 10 years experience building and leading teams for some of the biggest names in software, such as Microsoft and RSA Security. davidskyberg@live.com
http://www.LinkedIn.com/in/davidskyberg
More...

New Tool: The Path of Least Danger [Matt Schlegel]

In the previous blog, I described the step in the problem-solving process of how a team will analyze the various ideas proposed to solve a problem. During that analysis, the team logically thinks through the pros and cons of each idea. The team will also want to consider peoples’ emotional reactions to each idea, as that will impact the overall acceptance of a proposed solution. Having done that, the team has equipped itself to formulate a plan to move forward. In order for the plan to be accepted, the costs must be reasonable and the risks must be balanced. In my experience, I have found that after bringing a team of people through the problem-solving process to this point, there is a remarkable amount of consensus around the solutions to use in order to solve the problems the team faces. Building on that consensus, the team at this point in the process decides on a plan to move forward. This plan I like to call the Path of Least Danger.

Fear is a remarkable thing. Each of us has a different reaction to fear. I will stretch myself here with my lay knowledge of how the brain processes fear. There is a part of the brain, the amygdala, that serves as the information processor that outputs the fear response to the rest of the brain. As with much of our bi-cameral brain, the amygdala has a right part and a left part. My understanding is that one side tells our brain that something is really scary and that we should avoid it if at all possible. The other side tells the brain that you should go and destroy the thing that is making you feel this way. And, just like people can be "right-brained" and "left-brained" or "right-handed" or "left-handed", some people will have a strong reaction to fight and some will have a strong reaction to flee. (Please correct me if I have misrepresented the function of the brain, this is a blog after all.)

Since we are not quite to the point in our problem-solving process where we need to fight (I will talk about that more in the implementation phase), we can tap into the thoughts of the more "run-for-your-life" types, and I put myself in this category, to help the team formulate the path to move forward. Since the team has collectively decided already to do something, they now need a plan to get them to a solution that solves their problem. And, since all the scary pitfalls and landmines have been laid out in the analysis phase, and by this I am referring to the resources that the team would need to implement each idea and the threats that would prevent an idea from being implemented, then it is a matter of finding that optimal path that minimizes both resource utilization and threats to failure. On that path the team can build the reasonable-cost, risk-balanced plan. In other words, we can use our fear response to empower the team to choose the Path of Least Danger.

Now that the team has decided on a path forward, it is time to acquire the resources you will need to take the team down the selected path. In the next blog, we will talk about the important step of advocating the plan not only to get the permission to proceed, but to get the resources, as well.

__________________________
Matt Schlegel categorizes himself as a "fear aware" type. He taps into that characteristic as he finds that it gives him the ability to create project plans, schedules, test plans and manage quality for products. He finds that he is a "natural" at worst-case analysis, and uses that natural ability to help teams avoid pitfalls, create reliable solutions, and build high-quality products.

More...

Zoom with Joomla or Drupal [Steve Mezak]

You can launch your web app faster when using a content management system (CMS) like Drupal or Joomla or other frameworks like CakePHP or CodeIgnitor – all written in PHP. These CMSs and frameworks contain built-in functionality that will accelerate you software development. But using them the wrong way, or in the wrong situation can be a disaster.

It is critical to get a web app launched as quickly as possible. No one wants to wait months (forget years) for a new web application to appear online. The promise of CMSs and Frameworks is they give you a jumpstart with pre-built functionality and an environment that makes your programmers more productive. But like most tools, they can also be misused causing more headaches than help.

These frameworks are open source and available at no cost but they have a steep learning curve. I got excited about using a CMS for a website I was creating last year. I bought a couple Drupal books and downloaded the software from the Acquia website. It installed easily and I had a working site in a day.

Customizing the site was a different matter. I was able to easily add in several contributed modules but I found it difficult to combine modules along with my custom code to create a decent looking functional application. I basically wasted a couple weeks to discover that I really needed experienced professional help.

If you are building a community website then you should consider using a CMS platform. A CMS has these features that community websites need:

• Access statistics and logging
• Advanced search functions
• Comments, forums, and polls
• Multi-level menu system
• Multi-user content create & edit
• OpenID & Facebook Connect
• RSS Feed Aggregator
• and many more . . .

CMSs and frameworks are extendable and it is common to add code to deliver your desired functionality. For example, Drupal has a list of user-contributed modules available to extend its functionality. And your programmers can create their own modules too using the Content Creation Kit or CCK.

The primary pitfall that inexperienced programmers fall into when using a CMS is adding functionality by changing the framework itself. If your programmers “hack the core” of your CMS directly they create a mess that is difficult if not impossible to fix.

Any new development team is not likely to be able to unwind the hacks. To fix any bugs they will only be hacking the core further. In this case you almost always have to start over.

First you should decide if CMS features are needed. Selecting a CMS may only add complexity if the features you need are simple or different that what the CMS delivers. A framework that enables rapid page creation and supports modern Ajax-based user interface features can be a better choice.

The look and feel of your web application is completely configurable with a CMS. Frameworks and CMSs have a way for you to deploy your design in a consistent way. In Drupal this is called Themes, in Joomla it’s called Templates.

Versions of Frameworks and CMSs change periodically. If you outsource, make sure the development team you hire has experience with the latest version, or at least the version you want to use. For example, Drupal had a major upgrade from version 5 to 6 last year. Many of the user-contributed modules did not work with the new version. It was months before most were development teams were experienced with version 6.

Experience with these modules is critical. Anyone can install a framework or CMS, but the basic functionality is not enough. Ask for examples of web apps your prospective development teams have created for other clients and the kinds of modules and custom development they employed.

Use a development team that has experience building web applications for other clients with the CMS or Framework you decide to use. You can wind up wasting your time attempting to make a sophisticated web application on your own by using one of these platforms right out of the box unless you have already gone up the learning curve. It takes professional help.

The only thing worse than wasting your own time, is wasting time and paying money to an inexperienced development team. Choose carefully and your use of a CMS can shave months off your development time line.

_______________________
Steve Mezak, CEO of Accelerance, Inc. and author of the book, Software without Borders, has dabbled with Drupal. Use his free online Global Partner Network, containing the contact information for 40+ hand-selected and pre-qualified software development partners in over a dozen countries around the world, some of which are experts in Drupal and Joomla. http://www.accelerance.com/

More...

Leading What [Jane Divinski]

When people talk about engineering leadership they often are referring to leading human beings, specifically, engineers, but I think that it’s more accurate to realize that one is actually leading decision making. Some of these decisions are made unilaterally by the “engineering leader” but many are the result of input by multiple people in the organization. Regardless of who’s involved, the leader needs to make sure that decisions ARE made and made in an appropriately timely fashion.

Years ago my then boss informally confronted me with his concern that I might be making decisions too quickly. He pointed out that additional information is usually forthcoming and wondered if I might not be better off awaiting it’s availability before moving forward with a decision. We actually had a lengthy and enjoyable discussion about this topic.

I asked him for specific examples of such instances and he promptly cited three. I then proceeded to spell out all the information I had factored into the decision. In addition, I described other data I would like to have had to factor into my analysis and explained why such information wasn’t yet available and when I could reasonably expect said info.

We then chatted about the impact (aka cost) of delaying the decision; for these three examples he ended up agreeing with me that each involved instances where a timely decision, based on the available data was better than a delayed decision. Obviously this is not always the case.

__________________________________________
Jane Divinski has enjoyed the challenges of engineering management consulting since 1994. Most of her gigs are as interim VPE but Jane's also tackled other interim roles including CTO or program manager. Her background is at www.jadski.com

More...

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...