tag:blogger.com,1999:blog-12101471940783376032023-11-16T01:51:56.546-06:00Software Executive RamblingsCompletely random stream of thoughts about the software business, from the perspective of an executive.Neal Reizerhttp://www.blogger.com/profile/05525404065315976171noreply@blogger.comBlogger49125tag:blogger.com,1999:blog-1210147194078337603.post-29493018402997879292015-04-17T14:53:00.000-05:002015-04-17T14:53:57.724-05:00So you want to be a VP?<div class="OutlineElement Ltr SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: white; clear: both; cursor: text; direction: ltr; font-family: 'Segoe UI', Tahoma, Verdana, sans-serif; font-size: 8px; margin: 0px; overflow: visible; padding: 0px; position: relative;">
<div class="Paragraph SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: transparent; color: windowtext; font-size: 6pt; padding: 0px; vertical-align: baseline; word-wrap: break-word;" xml:lang="EN-US">
<span class="TextRun SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: transparent; color: windowtext; font-family: Calibri, sans-serif; font-size: 11pt; line-height: 18px; margin: 0px; padding: 0px;" xml:lang="EN-US">I am periodically asked about becoming a VP. That is the wrong question. An appropriate </span><span class="TextRun SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: transparent; color: windowtext; font-family: Calibri, sans-serif; font-size: 11pt; line-height: 18px; margin: 0px; padding: 0px;" xml:lang="EN-US">question is, "How do I increase my organizational, customer, or industry influence?" Recognize that o</span><span class="TextRun SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: transparent; color: windowtext; font-family: Calibri, sans-serif; font-size: 11pt; line-height: 18px; margin: 0px; padding: 0px;" xml:lang="EN-US">ur interests are not what drive other departments. </span><span class="TextRun SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: transparent; color: windowtext; font-family: Calibri, sans-serif; font-size: 11pt; line-height: 18px; margin: 0px; padding: 0px;" xml:lang="EN-US">They want to execute and grow a business. </span><span class="TextRun SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: transparent; color: windowtext; font-family: Calibri, sans-serif; font-size: 11pt; line-height: 18px; margin: 0px; padding: 0px;" xml:lang="EN-US">For them, technology is a means to an end. </span><span class="TextRun SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: transparent; color: windowtext; font-family: Calibri, sans-serif; font-size: 11pt; line-height: 18px; margin: 0px; padding: 0px;" xml:lang="EN-US">To influence them, seek to understand their world. </span><span class="EOP SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: transparent; color: windowtext; font-family: Calibri, sans-serif; font-size: 11pt; line-height: 18px; margin: 0px; padding: 0px;"> </span></div>
</div>
<div class="OutlineElement Ltr SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: white; clear: both; cursor: text; direction: ltr; font-family: 'Segoe UI', Tahoma, Verdana, sans-serif; font-size: 8px; margin: 0px; overflow: visible; padding: 0px; position: relative;">
<div class="Paragraph SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: transparent; color: windowtext; font-size: 6pt; padding: 0px; vertical-align: baseline; word-wrap: break-word;" xml:lang="EN-US">
<br /></div>
</div>
<div class="OutlineElement Ltr SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: white; clear: both; cursor: text; direction: ltr; font-family: 'Segoe UI', Tahoma, Verdana, sans-serif; font-size: 8px; margin: 0px; overflow: visible; padding: 0px; position: relative;">
<div class="Paragraph SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: transparent; color: windowtext; font-size: 6pt; padding: 0px; vertical-align: baseline; word-wrap: break-word;" xml:lang="EN-US">
<span class="TextRun SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; color: windowtext; font-family: Calibri, sans-serif; font-size: 11pt; line-height: 18px; margin: 0px; padding: 0px;" xml:lang="EN-US">I recommend three groups with whom you develop relationships.</span><span class="EOP SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; font-family: Calibri, sans-serif; font-size: 11pt; line-height: 18px; margin: 0px; padding: 0px;"> </span></div>
</div>
<div class="OutlineElement Ltr SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: white; clear: both; cursor: text; direction: ltr; font-family: 'Segoe UI', Tahoma, Verdana, sans-serif; font-size: 8px; margin: 0px; overflow: visible; padding: 0px; position: relative;">
<div class="Paragraph SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: transparent; color: windowtext; font-size: 6pt; padding: 0px; vertical-align: baseline; word-wrap: break-word;" xml:lang="EN-US">
<br /></div>
</div>
<div class="OutlineElement Ltr SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: white; clear: both; cursor: text; direction: ltr; font-family: 'Segoe UI', Tahoma, Verdana, sans-serif; font-size: 8px; margin: 0px; overflow: visible; padding: 0px; position: relative;">
<div class="Paragraph SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: transparent; color: windowtext; font-size: 6pt; padding: 0px; vertical-align: baseline; word-wrap: break-word;" xml:lang="EN-US">
</div>
<h4>
<span style="background-color: transparent; color: windowtext; font-family: Calibri, sans-serif; font-size: 11pt; line-height: 18px;">Customers</span></h4>
<span class="TextRun SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: transparent; color: windowtext; font-family: Calibri, sans-serif; font-size: 11pt; line-height: 18px; margin: 0px; padding: 0px;" xml:lang="EN-US"><span class="NormalTextRun SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: inherit; margin: 0px; padding: 0px;">Find ways to visit customers, attend customer events, or join calls with customers. Set aside time to learn about your industry (in my case, healthcare). The more you understand </span><span class="NormalTextRun SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: inherit; margin: 0px; padding: 0px;">your</span><span class="NormalTextRun SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: inherit; margin: 0px; padding: 0px;"> customer's business and industry, the better partner you become. It will improve your product decisions, as you will have context for how your customers use your product and the problems they are trying to solve.</span></span><br />
<div class="Paragraph SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: transparent; color: windowtext; font-size: 6pt; padding: 0px; vertical-align: baseline; word-wrap: break-word;" xml:lang="EN-US">
<span class="TextRun SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: transparent; color: windowtext; font-family: Calibri, sans-serif; font-size: 11pt; line-height: 18px; margin: 0px; padding: 0px;" xml:lang="EN-US"><span class="NormalTextRun SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: inherit; margin: 0px; padding: 0px;"><br /></span></span></div>
</div>
<div class="OutlineElement Ltr SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: white; clear: both; cursor: text; direction: ltr; font-family: 'Segoe UI', Tahoma, Verdana, sans-serif; font-size: 8px; margin: 0px; overflow: visible; padding: 0px; position: relative;">
<h4 style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: transparent; color: windowtext; font-size: 6pt; padding: 0px; vertical-align: baseline; word-wrap: break-word;">
<span class="TextRun SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: transparent; color: windowtext; font-family: Calibri, sans-serif; font-size: 11pt; line-height: 18px; margin: 0px; padding: 0px;" xml:lang="EN-US">Business partners</span></h4>
<div class="Paragraph SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: transparent; color: windowtext; font-size: 6pt; padding: 0px; vertical-align: baseline; word-wrap: break-word;" xml:lang="EN-US">
<span class="TextRun SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: transparent; color: windowtext; font-family: Calibri, sans-serif; font-size: 11pt; line-height: 18px; margin: 0px; padding: 0px;" xml:lang="EN-US">Your business partners include departments like sales, support, services, and marketing. Take time to learn how they do what they do. For example, learn how a salesperson gets quota credit (you do know what quota credit is, right?) or when and how your services team recognizes revenue (you do know what revenue is, right?) Once you learn these concepts, you will have a better appreciation for why June 30 is significantly more than one business day away from July 1.</span></div>
<div class="Paragraph SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: transparent; color: windowtext; font-size: 6pt; padding: 0px; vertical-align: baseline; word-wrap: break-word;" xml:lang="EN-US">
<span class="EOP SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: transparent; color: windowtext; font-family: Calibri, sans-serif; font-size: 11pt; line-height: 18px; margin: 0px; padding: 0px;"> </span></div>
<h4>
<span class="TextRun SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: transparent; color: windowtext; font-family: Calibri, sans-serif; font-size: 11pt; line-height: 18px; margin: 0px; padding: 0px;" xml:lang="EN-US">Finance and accounting</span></h4>
<span class="TextRun SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: transparent; color: windowtext; font-family: Calibri, sans-serif; font-size: 11pt; line-height: 18px; margin: 0px; padding: 0px;" xml:lang="EN-US">Learn how the money works in your organization. There are critical concepts like capitalization, R&D Tax Credits, and so on that impact your company financial statements. These in turn impact your ability to hire or to buy software. Financial management is as much a software development executive function as is shaping engineering practices and technology choices.</span><span class="EOP SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: transparent; color: windowtext; font-family: Calibri, sans-serif; font-size: 11pt; line-height: 18px; margin: 0px; padding: 0px;"> </span></div>
<div class="OutlineElement Ltr SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: white; clear: both; cursor: text; direction: ltr; font-family: 'Segoe UI', Tahoma, Verdana, sans-serif; font-size: 8px; margin: 0px; overflow: visible; padding: 0px; position: relative;">
<div class="Paragraph SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: transparent; color: windowtext; font-size: 6pt; padding: 0px; vertical-align: baseline; word-wrap: break-word;" xml:lang="EN-US">
<br /></div>
</div>
<div class="OutlineElement Ltr SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: white; clear: both; cursor: text; direction: ltr; font-family: 'Segoe UI', Tahoma, Verdana, sans-serif; font-size: 8px; margin: 0px; overflow: visible; padding: 0px; position: relative;">
<div class="Paragraph SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: transparent; color: windowtext; font-size: 6pt; padding: 0px; vertical-align: baseline; word-wrap: break-word;" xml:lang="EN-US">
<span class="TextRun SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; color: windowtext; font-family: Calibri, sans-serif; font-size: 11pt; line-height: 18px; margin: 0px; padding: 0px;" xml:lang="EN-US">I have never met a customer or business partner that refused to teach me. They greatly appreciate your interest. In turn, you will be surprised at how much you teach them about product development. Spend your time here, and the question of "How do I become a VP" will take care of itself.</span><span class="EOP SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; font-family: Calibri, sans-serif; font-size: 11pt; line-height: 18px; margin: 0px; padding: 0px;"> </span></div>
</div>
<div class="OutlineElement Ltr SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: white; clear: both; cursor: text; direction: ltr; font-family: 'Segoe UI', Tahoma, Verdana, sans-serif; font-size: 8px; margin: 0px; overflow: visible; padding: 0px; position: relative;">
<div class="Paragraph SCX252432280" style="-webkit-tap-highlight-color: transparent; -webkit-user-drag: none; -webkit-user-select: text; background-color: transparent; color: windowtext; font-size: 6pt; padding: 0px; vertical-align: baseline; word-wrap: break-word;" xml:lang="EN-US">
<br /></div>
</div>
Neal Reizerhttp://www.blogger.com/profile/05525404065315976171noreply@blogger.com0tag:blogger.com,1999:blog-1210147194078337603.post-82554416592704431892015-02-21T13:22:00.001-06:002015-02-21T13:22:41.541-06:00Customer involvement to reduce time to satisfaction<span style="font-family: Verdana, sans-serif;">In my previous post, I discussed time to customer satisfaction. Much has been written elsewhere about customer involvement as part of a user experience program. Prototypes, wireframes, and other techniques are well documented. As such, I'll avoid these topics. There are, however, two items that don't receive the same level of attention (or at least I haven't seen them frequently). They are the focus of this post.</span><br />
<span style="font-family: Verdana, sans-serif;"><br /></span>
<h4>
<span style="font-family: Verdana, sans-serif;">Early involvement via sprint demos</span></h4>
<span style="font-family: Verdana, sans-serif;">Agile advocates that stakeholders (or proxies in the form of product owners) be part of the team. This is an admirable goal, but I've yet to see it occur in practice. This may be due to my experience in product development companies, where the "customer" is a market, not specific people. While I've not had the opportunity to embed customers in my teams, there are ways to integrate them in your process.</span><br />
<span style="font-family: Verdana, sans-serif;"><br /></span>
<span style="font-family: Verdana, sans-serif;">Make each product owner responsible for cultivating a cadre of users. These users are people heavily involved in the operational workflows for which the product is intended to be used. Beginning with the first storyboards, this collection of users participates in sprint demonstrations. They are made aware of the user stories delivered and the user stories being considered for the next iteration. As the product is demonstrated, they can immediately confirm or correct workflow and visual designs. I've even witnessed users helping each other understand how to use the product, thereby eliminating feature requests entirely.</span><br />
<span style="font-family: Verdana, sans-serif;"><br /></span>
<span style="font-family: Verdana, sans-serif;">This group also is a sounding board for questions or ideas that come up during the development process. It is not unusual for product owners to have multiple user contacts through an iteration.</span><br />
<span style="font-family: Verdana, sans-serif;"><br /></span>
<h4>
<span style="font-family: Verdana, sans-serif;">Advisory boards</span></h4>
<span style="font-family: Verdana, sans-serif;">While iteration demonstrations are tactical, advisory boards are strategic. Look for people with industry breadth and understanding of operations within their organizations. Advisory boards are critical to ensuring appropriate major product features and workflows. Instead of focusing on iteration deliverables, this group guides you to determine priorities of competing major features, high level workflows across features, and your standing relative to competitors (within ethical and legal constraints). </span><br />
<span style="font-family: Verdana, sans-serif;"><br /></span>
<span style="font-family: Verdana, sans-serif;">You will want 8-12 people representing multiple dimensions of your product. For example, a product for physicians would have an advisory board comprised of multiple specialties, geographies, and EHR usage. I encourage you to have non-customers represented, as well. They are highly likely to provide you completely new ways of thinking about problems, since they don't "know" your product or its workflows.</span><br />
<span style="font-family: Verdana, sans-serif;"><br /></span>
<span style="font-family: Verdana, sans-serif;">Most importantly, you want this group to tell you where your strategic mistakes are - before the market does.</span><br />
<span style="font-family: Verdana, sans-serif;"><br /></span>
<span style="font-family: Verdana, sans-serif;"><br /></span>
<span style="font-family: Verdana, sans-serif;">These two groups can tremendously impact your ability to deliver a highly acceptable product to the market. They help refine workflows and visual designs, thereby decreasing the time to customer satisfaction. Equally important, the people involved throughout take a high degree of ownership. They become product advocates, since it is their product design.</span>Neal Reizerhttp://www.blogger.com/profile/05525404065315976171noreply@blogger.com0tag:blogger.com,1999:blog-1210147194078337603.post-7458015353181979012014-09-21T10:08:00.001-05:002014-09-21T10:08:57.877-05:00Customer satisfaction & technical debt<span style="font-family: Verdana, sans-serif;">Time to market is a key concept for product delivery. Reducing time to market can preempt competition, show responsiveness to customer requests, and generate revenue sooner. It is the basis for commitments to sales, to customers, and to the market.</span><br />
<div>
<span style="font-family: Verdana, sans-serif;"><br /></span></div>
<div>
<span style="font-family: Verdana, sans-serif;">Without ignoring time to market, I propose you plan, design, and deliver software with an additional concept in mind: </span><span style="font-family: Verdana, sans-serif;">Time to customer satisfaction. </span><br />
<div>
<span style="font-family: Verdana, sans-serif;"><br /></span></div>
<div>
<span style="font-family: Verdana, sans-serif;">Bringing a product to market and having satisfied customers are not the same thing. Time to market is straightforward. It is when the product is released to sales and to customers. Time to customer satisfaction is difficult to measure. It is a subjective combination of a customer's willingness to purchase, deploy, and use the software.</span></div>
<div>
<span style="font-family: Verdana, sans-serif;"><br /></span></div>
<div>
<span style="font-family: Verdana, sans-serif;">With an ideal product delivery process, the gap between time to market and time to satisfied customers is zero. Alas, we don't live in ideal worlds. Periodically, the gap is significant. When this occurs, the development team incurs a subtle of technical debt.</span></div>
<div>
<br /></div>
<div>
<span style="font-family: Verdana, sans-serif;">Let me step back for a moment. Generally, plans expect version "X" to go to market with little or no additional work. Reported defects are handled by a maintenance or customer support team. Requested enhancements are considered for a future release. All is good. </span></div>
<div>
<span style="font-family: Verdana, sans-serif;"><br /></span></div>
<div>
<span style="font-family: Verdana, sans-serif;">But, what happens when the feature itself is rejected?</span></div>
<div>
<span style="font-family: Verdana, sans-serif;"><br /></span></div>
<div>
<span style="font-family: Verdana, sans-serif;">Regardless of the reason for the rejection, you are forced to repair fundamental flaws immediately. </span><span style="font-family: Verdana, sans-serif;">These require depth that only your</span><span style="font-family: Verdana, sans-serif;"> development team has.</span></div>
<div>
<span style="font-family: Verdana, sans-serif;"><br /></span></div>
<div>
<span style="font-family: Verdana, sans-serif;">The challenge is that your development team is executing plans and commitments for version "X+1." Those have been communicated to sales and customers. P</span><span style="font-family: Verdana, sans-serif;">roduct delivery c</span><span style="font-family: Verdana, sans-serif;">ommitments</span><span style="font-family: Verdana, sans-serif;"> </span><span style="font-family: Verdana, sans-serif;">are commitments</span><span style="font-family: Verdana, sans-serif;"> for revenue.</span></div>
<div>
<span style="font-family: Verdana, sans-serif;"><br /></span></div>
<div>
<span style="font-family: Verdana, sans-serif;">Oops.</span></div>
<div>
<span style="font-family: Verdana, sans-serif;"><br /></span></div>
<div>
<span style="font-family: Verdana, sans-serif;">You have a few options:</span></div>
<div>
<ul>
<li><span style="font-family: Verdana, sans-serif;">Replan and change commitments.</span></li>
<li><span style="font-family: Verdana, sans-serif;">Overwork your team to repair version "X" and maintain delivery of version "X+1" simultaneously.</span></li>
<li><span style="font-family: Verdana, sans-serif;">Cut corners on version "X+1" as much as possible without impacting revenue and customer satisfaction.</span></li>
</ul>
</div>
<div>
<span style="font-family: Verdana, sans-serif;">The right option depends on your business. For example, a small start-up needing cash is going to go for the latter two choices. Whether or not the choices are sound business decisions is irrelevant. What matters is that they feed on themselves to increase the likelihood of a future delay in version "X+1" time to customer satisfaction.</span></div>
<div>
<span style="font-family: Verdana, sans-serif;"><br /></span></div>
<div>
<span style="font-family: Verdana, sans-serif;">You might say at this point, "Adjust the plan and change the commitments." That is the engineer talking, not the business person. Changing commitments can not be taken lightly. The consequences range from lost credibility to severe financial harm (lost contracts, stock price, etc.). </span></div>
<div>
<span style="font-family: Verdana, sans-serif;"><br /></span></div>
<div>
<span style="font-family: Verdana, sans-serif;">Your goal as a development leader is to reduce the risk of a gap in time to customer satisfaction. Now that I've introduced the concept, I'll stop here. </span><span style="font-family: Verdana, sans-serif;">My next post will focus on things you control (or, at least influence) to decrease time to customer satisfaction.</span></div>
</div>
Neal Reizerhttp://www.blogger.com/profile/05525404065315976171noreply@blogger.com0tag:blogger.com,1999:blog-1210147194078337603.post-68174242212438117232014-08-29T09:03:00.001-05:002014-08-29T09:03:22.359-05:00When opportunity knocks<div style="font-family: 'Segoe UI'; font-size: 12pt; margin: 0in;">
Last
week, I resigned my position to pursue a new opportunity. I will dearly miss my current team, product,
and customers. But, you know what is
said about opportunity knocking. </div>
<div style="font-family: 'Segoe UI'; font-size: 12pt; margin: 0in;">
<br /></div>
<div style="font-family: 'Segoe UI'; font-size: 12pt; margin: 0in;">
Turns
out that a combination of family and professional factors lined up. It was truly "too good to pass
up." In the course of the many
goodbyes, one individual wrote that it takes a lot of the right kind of work to
find these things. He then asked if I
had any recommendations. </div>
<div style="font-family: 'Segoe UI'; font-size: 12pt; margin: 0in;">
<br /></div>
<div style="font-family: 'Segoe UI'; font-size: 12pt; margin: 0in;">
My
reply was, "No."</div>
<div style="font-family: 'Segoe UI'; font-size: 12pt; margin: 0in;">
<br /></div>
<div style="font-family: 'Segoe UI'; font-size: 12pt; margin: 0in;">
Followed
promptly by my recommendation.</div>
<div style="font-family: 'Segoe UI'; font-size: 12pt; margin: 0in;">
<br /></div>
<div style="font-family: 'Segoe UI'; font-size: 12pt; margin: 0in;">
Know
what matters to you. You are the only
one that can figure that out. Maybe it's
money, maybe it's family, maybe it is title and prestige. Then go a little deeper. For example, what does money represent to
you? Security? Freedom?
Is money the only way to achieve these goals?</div>
<div style="font-family: 'Segoe UI'; font-size: 12pt; margin: 0in;">
<br /></div>
<div style="font-family: 'Segoe UI'; font-size: 12pt; margin: 0in;">
The
things that matter most to you are a filter for opportunities that come your
way. Technology comes and goes (unless
mastery of a particular technology matter most to you). Commutes can be altered. And yes, cities can be left for new ones.</div>
<div style="font-family: 'Segoe UI'; font-size: 12pt; margin: 0in;">
<br /></div>
<div style="font-family: 'Segoe UI'; font-size: 12pt; margin: 0in;">
In
the end, know yourself, use that to measure things that come your way, and seek
out people that share your goals (since they will likely be connected to others
that also share your goals).</div>
<div style="font-family: 'Segoe UI'; font-size: 12pt; margin: 0in;">
<br /></div>
<br />
<div style="font-family: 'Segoe UI'; font-size: 12pt; margin: 0in;">
Maybe
it is less about finding opportunities and more about recognizing them when
they appear.</div>
Neal Reizerhttp://www.blogger.com/profile/05525404065315976171noreply@blogger.com1tag:blogger.com,1999:blog-1210147194078337603.post-46406351021501602942014-07-30T14:41:00.000-05:002014-07-30T14:41:33.166-05:00Teach, don't solve<span style="font-family: Verdana, sans-serif;">New or inexperienced managers tend to fall into the trap of solving problems for their team. This frequently occurs when an engineer asks for validation of a technical solution. Given normal delivery pressure, you want to quickly get the problem corrected or solution implemented. The perceived easy path typically goes something like one of the following two ways:</span><br />
<br />
<ol>
<li><span style="font-family: Verdana, sans-serif;">It's good. Make this tweak and go for it. Let me know when you are done.</span></li>
<li><span style="font-family: Verdana, sans-serif;">You really missed it. Here is how you need to do this. (You then return to your office where you solve the problem and the engineer watches you)</span></li>
</ol>
<br />
<span style="font-family: Verdana, sans-serif;">Either may be efficient in the short term, but neither is a teaching moment. Watching someone else do something is a poor substitute for engaging the person in the learning experience. To increase learning, engage your engineer in the solution process. </span><br />
<span style="font-family: Verdana, sans-serif;"><br /></span>
<span style="font-family: Verdana, sans-serif;">Regardless of whether the solution is right or wrong (as if it is ever that black and white), ask the following questions:</span><br />
<br />
<ul>
<li><span style="font-family: Verdana, sans-serif;">What are the aspects of the problem that lead you to this solution? What are the downsides to this solution?</span></li>
<li><span style="font-family: Verdana, sans-serif;">What alternatives did you consider? What is your rationale for rejecting those?</span></li>
<li><span style="font-family: Verdana, sans-serif;">How will this solution impact…? Insert what is appropriate, such as implementation, maintenance, upgrading to a future version, workflow.</span></li>
<li><span style="font-family: Verdana, sans-serif;">Now that we've discussed this a bit, what parts of the solution will you change? Why?</span></li>
</ul>
<br />
<span style="font-family: Verdana, sans-serif;">Your goal as a manager is to promote independence and critical thinking skills. Solving the problem on behalf of the engineer builds neither.</span>Neal Reizerhttp://www.blogger.com/profile/05525404065315976171noreply@blogger.com1tag:blogger.com,1999:blog-1210147194078337603.post-53066067409427514362014-06-24T13:58:00.003-05:002014-06-24T13:58:47.742-05:00Learning<div style="border-width: 100%; direction: ltr;">
<div style="direction: ltr; margin-left: 0in; margin-top: 0in; width: 5.993in;">
<div style="direction: ltr; margin-left: 0in; margin-top: 0in; width: 5.993in;">
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<span style="color: #444444;">In my last post, I introduced <a href="http://nealreizer.blogspot.com/2014/06/bad-idea-filtering.html">Challaboration</a> as a core team value. A second
core value is learning. Within this are two elements: being
adaptable and courage.</span></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<span style="color: #444444;">Requirements,
technology, business environments all change.
A person (and by extension, a team) will have limited success solving
new problems only using past solutions.
If you are unwilling to adapt and don't have the courage to find help from others, you will not expand your set of
tools to solve problems.</span></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; margin: 0in;">
<span style="color: #444444; font-size: large;">Adaptable</span></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<span style="color: #444444;">When you explore new
approaches and tools, you learn. For
example, around 2011, my company made a reasoned decision to shift some of its
product stack from .NET to Java. Quite a
bit of our team (who we hired as .NET
developers) were faced with a choice: continue as .NET experts or become
novice Java/HTML/JavaScript programmers.
Every developer made the transition.</span></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<span style="color: #444444;">It would have been
easy to leave. After all .NET is the
dominate programming platform in Nashville. Because they chose to adapt, they
expanded their toolkit (learning a new language and front end technology). It was a tough road. In the beginning, we
wrote a lot of C# code masquerading as Java.
Over time, the team grew into first-class Java developers.</span></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<span style="color: #444444;">By adapting, the
developers learned a valuable lesson:
Their excellence is based on their critical thinking and design skills,
not language competency. More
importantly, they </span></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<span style="color: #444444;">not to define
themselves by the technologies they know.</span></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; margin: 0in;">
<span style="color: #444444; font-size: large;">Courage</span></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<span style="color: #444444;">Our team is a mix of
veteran and junior developers. We have
experienced healthcare providers and seasoned QA who have never provided direct
patient care. You would think the knowledge
flows from the "older" to "younger" generation. That is far from the case. Junior developers show veterans how some of
the new technology stack functions. In
turn, veterans share hard-fought learnings from years of production software.</span></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<span style="color: #444444;">What our team has in
common is not knowledge or skill level.
It is their courage to say, "I need help" or "I don't
know." This simple acknowledgement
creates the possibility for learning. </span></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<span style="color: #444444;">The dynamics of
healthcare IT demand constant learning. A willingness to adapt and the courage
to ask for help creates an environment where everyone learns from each
other. As a team, we adapt to changing
demands and have the courage to rely on each other to learn how to solve
problems. In other words, we win and lose as a team. </span></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
</div>
</div>
</div>
Neal Reizerhttp://www.blogger.com/profile/05525404065315976171noreply@blogger.com0tag:blogger.com,1999:blog-1210147194078337603.post-57570232433372946422014-06-16T19:14:00.000-05:002014-06-16T19:14:08.813-05:00Bad idea filtering<div style="border-width: 100%; direction: ltr;">
<div style="direction: ltr; margin-left: 0in; margin-top: 0in; width: 5.993in;">
<div style="direction: ltr; margin-left: 0in; margin-top: 0in; width: 5.993in;">
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
Some teams seem to
consistently end up with better decisions.</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
While not
downplaying individual contributions, I believe the way the team brings
ideas to life (or kills them) matters most. It isn't about starting with
more good ideas. It's about creating
a culture where good ideas are refined and bad ones are eliminated
quickly. In other words, they have a
better Bad Idea Filter, and the means to make mediocre ideas good (or great).</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
I've found two factors to influence idea quality: challenge and collaborate. They are blended; so much that my team
coined the phrase <i>Challaboration</i>.</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<span style="font-size: 11pt;">We challenge
practically everything.</span><span style="font-size: 11pt;"> </span><span style="font-size: 11pt;">If you propose
an idea, you will defend it against technical, business, workflow, and visual
design critiques.</span><span style="font-size: 11pt;"> </span><span style="font-size: 11pt;"> </span><span style="font-size: 11pt;">One person is unable to consider a variety of
consequences, barriers, and alternative solutions.</span><span style="font-size: 11pt;"> </span><span style="font-size: 11pt;">A team of people with varied experiences can. </span><span style="font-size: 11pt;">If the idea cannot be defended, then it doesn't survive - even if it is mine.</span></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
With multiple
solution paths explored, the resulting decision is more resilient. It draws from improvements to address
previously unforeseen aspects of the problem, while minimizing weaknesses (or
at least making them known).</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
If challenging is
behavior, then collaboration is motivation. Team members receive and provide
critiques to the idea, not the person.
This isn't about scoring points; the desire must be to reach the best
decision the team can make. When I
challenge a design, I do so to make it excellent. I want the other person and
the team to be successful. Thus, I
challenge.</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
The motivation for
the critique matters. If the motivation
is to increase quality results, better ideas emerge.
If the motivation is to show personal intelligence or to score points,
bad decisions slip through. Worse yet,
idea generation itself shuts down. </div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
Your team gains confidence as they struggle with criticisms and pursue alternatives. When external groups and customers provide input, frequently it has been considered in depth. Your team is prepared to acknowledge inputs
and explain how they were considered, enhanced, or rejected. In turn, your team's confidence provides
confidence to the customer.</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
Challaboration is a
core value of our team. Each person has
a responsibility to assist in crafting a better solution. They also have an obligation to identify weak
ideas and prevent them from harming the team, product, and customers. These are key, since our team doesn't start
with more good ideas than most teams. It
just has a pretty darn good Bad Idea Filter. </div>
</div>
</div>
</div>
Neal Reizerhttp://www.blogger.com/profile/05525404065315976171noreply@blogger.com0tag:blogger.com,1999:blog-1210147194078337603.post-44218834490712586802014-05-05T16:40:00.004-05:002014-05-05T16:40:58.972-05:00Solve the problem class, not the instance<span style="font-family: Verdana, sans-serif;">Failure reports are specific occurrences of end users experiencing unexpected results. These typically occur when the system is not designed to handle unexpected user input. There are really two underlying defects causing the failure. The first is the workflow and visual design allowing the unexpected input to be entered. The second is the unexpected result - the failure itself.</span><br />
<span style="font-family: Verdana, sans-serif;"><br /></span>
<span style="font-family: Verdana, sans-serif;">When correcting either defect, it is typical to update the system to handle the unexpected user input. This is where most people stop. Since systems are built using patterns and models, a defect in one part of the system has likely been introduced elsewhere. Generally, solutions to reported failures miss opportunities to identify and resolve the underlying class of defects. </span><br />
<span style="font-family: Verdana, sans-serif;"><br /></span>
<span style="font-family: Verdana, sans-serif;">When faced with a failure report from the field (or internal QA), go deeper. While more an art than a science, there are several questions to ask that may reveal additional latent defects:</span><br />
<br />
<ul>
<li><span style="font-family: Verdana, sans-serif;">Where else is this programming model used? (E.g., the pattern is used in all our repositories)</span></li>
<li><span style="font-family: Verdana, sans-serif;">How can the specific user input be generalized? (E.g., a screen blows up because one piece of information was made inactive by the system administrator, but other types of information can also be made elsewhere)</span></li>
<li><span style="font-family: Verdana, sans-serif;">Where else can these type data be entered? (E.g., Dates prior to today can be entered in many places)</span></li>
</ul>
<br />
<span style="font-family: Verdana, sans-serif;">Cultivate this perspective by starting with these questions and extending them to your environment. Encourage people on your team to generalize every failure reported. The goal is to get past the specific instance of the failure and to consider the class to which the failure belongs. You may elect to only repair this instance due to time or money. At least you will be doing so consciously. Alternatively, you may find that you identify and avoid serious field failures.</span><br />
<span style="font-family: Verdana, sans-serif;"><br /></span>
<span style="font-family: Verdana, sans-serif;">You may elect to only repair this instance due to time or money. At least you will do so consciously. Alternatively, you may find that you identify and avoid serious field failures.</span>Neal Reizerhttp://www.blogger.com/profile/05525404065315976171noreply@blogger.com0tag:blogger.com,1999:blog-1210147194078337603.post-7944783492381026762014-04-10T18:40:00.000-05:002014-04-10T18:40:20.682-05:00Fallacy of a shippable product<br />
<div>
<span style="font-family: Verdana, sans-serif;">The agile literature generally advocates a potentially shippable product at the end of each sprint. I find this assertion problematic. It is disconnected from the larger discipline of product development and somewhat naïve.</span></div>
<div>
<span style="font-family: Verdana, sans-serif;"><br /></span></div>
<div>
<span style="font-family: Verdana, sans-serif;">The fallacy lies in the fatal (and unstated) assumption that the product is programming, testing, and documentation. It isn't. While these are the basis for the end user experience, they do not represent the totality of the experience.</span></div>
<div>
<span style="font-family: Verdana, sans-serif;"><br /></span></div>
<div>
<span style="font-family: Verdana, sans-serif;">For example, the customer may need help and call support. Or, the customer may need help implementing the software and require training and services. You may not even have a customer, and therefore require someone to market and sell the software. All the coding, testing, and documentation in the world isn't going to solve these challenges.</span></div>
<div>
<span style="font-family: Verdana, sans-serif;"><br /></span></div>
<div>
<span style="font-family: Verdana, sans-serif;">Here are some of the other groups needed to make a product shippable.</span></div>
<div>
<span style="font-family: Verdana, sans-serif;"><br /></span></div>
<div>
<ul>
<li><span style="font-family: Verdana, sans-serif;">Sales requires knowledge of the problems the software solves in order to position it to the buyer. They need assistance learning how to demonstrate it effectively. They will also need to determine the price of the software.</span></li>
</ul>
</div>
<div>
<ul>
<li><span style="font-family: Verdana, sans-serif;">Marketing must understand the features, what they do, the problems they solve, and the benefits they provide to the customer. They may need testimonials or other endorsements. They also typically develop collateral, press releases, and other material that can be "left behind" by sales or used at trade shows.</span></li>
</ul>
</div>
<div>
<ul>
<li><span style="font-family: Verdana, sans-serif;">Support must be trained on the use and troubleshooting of new features. They may also need to learn new issue escalation paths to development for issues that exceed their skills or knowledge.</span></li>
</ul>
</div>
<div>
<ul>
<li><span style="font-family: Verdana, sans-serif;">Services will need to learn how to install, upgrade, and configure the software. They may also be the group that trains users, as well as consults on best practices for using the software efficiently. They will need to develop end user training and consulting guides.</span></li>
</ul>
</div>
<div>
<ul>
<li><span style="font-family: Verdana, sans-serif;">Legal will need to draft contracts that can be used when the software is purchased or licensed.</span></li>
</ul>
</div>
<div>
<span style="font-family: Verdana, sans-serif;"><br /></span></div>
<div>
<span style="font-family: Verdana, sans-serif;">This is a significant list of deliverables required to ship a product to an end user. Are you really going to have your organization do this in conjunction with the end of every sprint? The cost associated with these type activities is best spent once, when the release is stabilizing towards the end of the remaining sprints.</span></div>
<div>
<span style="font-family: Verdana, sans-serif;"><br /></span></div>
<div>
<span style="font-family: Verdana, sans-serif;">Continue to strive for fully coded, tested, and documented software at the end of each sprint. But let's mature our view of product development and recognize it is much more than just the ones and zeros.</span></div>
<div>
<br /></div>
Neal Reizerhttp://www.blogger.com/profile/05525404065315976171noreply@blogger.com0tag:blogger.com,1999:blog-1210147194078337603.post-6758602154580267712014-04-02T22:08:00.002-05:002014-04-02T22:08:48.188-05:00Letting your team find their own path<span style="font-family: Verdana, sans-serif;">I recently spent a week on the road. As luck would have it, several key meetings were scheduled in the office for the same week. I selected different members of my team to represent me at each. They did a fantastic job representing themselves and our team. They helped good decisions be made for our company and for our customers.</span><br />
<span style="font-family: Verdana;"></span><br />
<span style="font-family: Verdana, sans-serif;">I'm proud of them, and in full disclosure, I also take pride in my role helping them be successful. But that is not the point of this post. What I'd like to share are the lessons from a conversation prior to one of the meetings. For ease of reading, let me refer to the person with whom I talked as Chuck.</span><br />
<span style="font-family: Verdana, sans-serif;"> </span><br />
<span style="font-family: Verdana, sans-serif;">In preparation, Chuck and I talked about the intent of the meeting, who should attend from our team, how we thought the session would go, and our goals for the outcomes. As we talked, I caught myself doing more dictating than coaching. I was (not so) subtly guiding Chuck down a path of how I would have approached the meeting based on my role, my understanding of the background and attendees, and my knowledge of the situation.</span><br />
<span style="font-family: Verdana;"></span><br />
<span style="font-family: Verdana, sans-serif;">Chuck stopped the conversations and said, "I need to do this my way. I can't be you." And Chuck was absolutely right. We took a step back and looked at things from his perspective. From there, Chuck led the approach with me in the better role of coach. I challenged his assumptions when necessary and added context when needed. In the end, we agreed that he would do much better as a confident Chuck than a pretend Neal.</span><br />
<span style="font-family: Verdana;"></span><br />
<span style="font-family: Verdana, sans-serif;">Chuck went to the meeting and knocked it out of the park. When asked how Chuck did, a peer executive texted me, "Very good. [He] was strong." I could end the story here, but there are two lessons I'd like to share.</span><br />
<span style="font-family: Verdana;"></span><br />
<span style="font-family: Verdana, sans-serif;">First, without trust, Chuck wouldn't have advocated for himself. I've written elsewhere about the need to build this culture. This is a terrific example of why this matters. If Chuck hadn't believed he could challenge anyone on the team - including me - he would have performed less effectively at the meeting. Given the stakes, the results would have harmed the team and the business.</span><br />
<span style="font-family: Verdana;"></span><br />
<span style="font-family: Verdana, sans-serif;">Second, it reminded me to let my leaders find their own way. I try hard to not over manage, and yet it is easy to do so. Only through constant self-awareness can I pull back and give my team the space to find their own solutions and style. Each leader on my team has a unique way of approaching problems. For them to grow, they need my guidance and trust. And they need the confidence that comes from knowing that if they choose a path different than one I might have chosen, I will support them.</span><br />
<br />
<span style="font-family: Verdana, sans-serif;">In the end, what matters is that we achieve good results. To get good results, fall back to the basics of trust among the team and freedom to explore different paths to success.</span>Neal Reizerhttp://www.blogger.com/profile/05525404065315976171noreply@blogger.com0tag:blogger.com,1999:blog-1210147194078337603.post-6186419645055004482014-03-21T08:53:00.000-05:002014-03-21T08:53:00.514-05:00Creating product evangelists<div style="font-family: "Segoe UI"; font-size: 11pt; margin: 0in;">
<span style="color: #666666;">I've been
spending time recently with sales, education, and other teams talking about new
products.<span style="mso-spacerun: yes;"> </span>A challenge these teams face
is their distance from the original product design decisions (and the
discussions surrounding them).<span style="mso-spacerun: yes;"> </span>This can
put them at a disadvantage with customers.<span style="mso-spacerun: yes;">
</span>Without a deeper appreciation for the design intent, they may struggle
to adapt beyond feature/function.<span style="mso-spacerun: yes;"> </span>This
can lead to missed opportunities or an overreliance on product development. </span></div>
<div style="font-family: "Segoe UI"; font-size: 11pt; margin: 0in;">
<span style="color: #666666;"> </span></div>
<div style="font-family: "Segoe UI"; font-size: 11pt; margin: 0in;">
<span style="color: #666666;">Here a two tips
for creating product evangelists from within your teams of colleagues.</span></div>
<div style="font-family: "Segoe UI"; font-size: 11pt; margin: 0in;">
<span style="color: #666666;"> </span></div>
<div style="font-family: "Segoe UI"; font-size: 11pt; margin: 0in;">
<span style="color: #666666;">Invite other
teams to product design sessions</span></div>
<div style="font-family: "Segoe UI"; font-size: 11pt; margin: 0in;">
<span style="color: #666666;">Members of other
teams bring valuable perspectives.<span style="mso-spacerun: yes;"> </span>This
alone is a great contribution.<span style="mso-spacerun: yes;"> </span>Equally
important is the insight they receive to the assumptions, alternatives, and
choices made during the design process.<span style="mso-spacerun: yes;">
</span>These insights provide knowledge and confidence during future customer
interactions.<span style="mso-spacerun: yes;"> </span>For example, when a
customer makes a recommendation for an alternative, they might reply,
"Great comment.<span style="mso-spacerun: yes;"> </span>We considered that
during design and here were our thoughts…"</span></div>
<div style="font-family: "Segoe UI"; font-size: 11pt; margin: 0in;">
<span style="color: #666666;"></span><br />
<span style="color: #666666;">Teach more than
features</span></div>
<div style="font-family: "Segoe UI"; font-size: 11pt; margin: 0in;">
<span style="color: #666666;">When you interact
with a colleague, take a few moments to go beyond a simple "how-to"
explanation of a feature.<span style="mso-spacerun: yes;"> </span>After you
explain it, review why the feature exists.<span style="mso-spacerun: yes;">
</span>What user problem is being solved?<span style="mso-spacerun: yes;">
</span>How does it make them more efficient? Effective?<span style="mso-spacerun: yes;"> </span>What alternatives were considered and
rejected? Why were they rejected?</span><br />
<span style="color: #666666;"> </span></div>
<div style="font-family: "Segoe UI"; font-size: 11pt; margin: 0in;">
<span style="color: #666666;">Recognize that
product development has the deepest understanding of the intention for the
product.<span style="mso-spacerun: yes;"> </span>We literally are with it from
conception to delivery.<span style="mso-spacerun: yes;"> </span>We must use
every interaction with others to infuse them with the knowledge, hopes, and
aspirations we have for the product.<span style="mso-spacerun: yes;">
</span>That, in turn, makes the other teams significantly more effective.</span></div>
Neal Reizerhttp://www.blogger.com/profile/05525404065315976171noreply@blogger.com0tag:blogger.com,1999:blog-1210147194078337603.post-48468326538461558132013-09-09T19:24:00.000-05:002013-09-09T19:24:03.811-05:00Development Partner Due Diligence<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif;">Recently, over tea, I was asked about offshore partners. During the course of the conversation, I shared my thoughts about selecting a partner. While not an exhaustive list, nor in a particular order, here are some thoughts I believe represent significant consideration.</span><br />
<span style="font-family: Arial;"></span><br />
<h3>
Demonstrated technical competence</h3>
<span style="font-family: Arial;">In what technologies does the partner claim expertise</span><span style="font-family: Arial;">? Regardless of whether you have a technical stack in mind or are deferring to the partner, you want confidence the partner has skill and competence. </span><br />
<span style="font-family: Arial;"></span><br />
<span style="font-family: Arial;">The strongest evidence is successful completion of projects using the proposed technologies. Your partner ought to provide examples of other projects, including how the technologies were used, the extent to which they were used, and the results. You want to know the projects were roughly comparable in terms of complexity (scope and team size). If not, then you want a clear picture of how the partner can scale their experience to meet the demands of your needs.</span><br />
<span style="font-family: Arial;"></span><br />
<span style="font-family: Arial;">Second, ask for corporate credentials or relationships that indicate expertise with the given technologies. For example, if the partner claims extensive .NET experience, ask them to elaborate on their relationship with Microsoft. I'm not talking about getting a certification for buying a bunch of Microsoft stuff. I'm talking about actually engaging the Microsoft developer tools and technology program teams. Have they participated in any Microsoft ISV programs? Have they been in a <a href="http://blogs.msdn.com/b/mwcc/archive/2005/01/04/346485.aspx">TAP</a>? While not perfect, this can give you a sense that they have invested additional effort in mastering one or more technologies.</span><br />
<br />
<span style="font-family: Arial;">As a concrete example, a partner I work with has the largest absolute (and as a percentage of staff) number of HL7 certified developers on staff of any company I know on the planet. This is a strong signal of their deep organizational </span><span style="font-family: Arial;">commitment to healthcare interoperability.</span><br />
<span style="font-family: Arial;"></span><br />
<h3>
Reference customers</h3>
<span style="font-family: Arial;">Your partner should have a set of customers willing to talk to you. I like to ask for 5-6 customers. Some in related fields and some not. Then I pick some (or all) and call them. Here are some of the questions I typically explore:</span><br />
<ul>
<li>How does the partner handle the contracting process? What about changes? I want to know if the contractor views this as a transaction or a relationship.</li>
<li>Are the people on the team the same as the people that were introduced during the sales process? I want to know if I can trust the partner, or is this going to be bait-and-switch.</li>
<li>How is the quality of the deliverables (not just the software)? How are quality problems addressed? I want to know if the partner takes pride in what they produce.</li>
<li>How is the interaction with the partner's leadership team? How would you describe their character? Organizations take on the characteristics of their leaders.</li>
<li>If you have visited their location, describe the physical environment (including hardware and equipment they have) and work conditions. Is it a sweat shop or do the employees appear well cared for? This impacts turnover, and consequently, the overall productivity of the team.</li>
<li>Have you awarded the partner additional business since you begin the relationship with them? Yes or no, why? You can finesse the other answers, but where you put your money says a lot.</li>
<li>If possible, describe briefly your project. Ask the reference if they would recommend the partner based on your description. Arguably, it might be little to go on, but you would be surprised. You may describe a highly technical research project and find that the partner is better suited at a well defined line of business application.</li>
</ul>
<h3>
The team</h3>
Ask for resumes or biographies of the key team leaders that will be assigned to your project. Don't accept "representative" overviews. Get the details of the specific people that will be assigned. And be sure to interview them to verify their credentials and background. You should treat these key leaders no differently than if you were going to hire them onto your team directly - because that is what you are doing.<br />
<br />
In addition to the team itself, ask about their training program. Elements you should look for include:<br />
<ul>
<li>New hire orientation programs</li>
<li>Domain specific training (e.g, Healthcare, Banking, etc.)</li>
<li>Function specific ladders with associated expected skills (e.g., Junior Developer through to Developer Team Lead)</li>
<li>If appropriate, language and communication skills training</li>
</ul>
The best partners I've seen (and therefore, do business with) are able to tell me, "When you hire a Senior Java developer, you are assured they have these skills, each at this level, and will receive the following training in the coming year."<br />
<br />
Again, this is not an exhaustive list. But it should get you thinking about more than just cost rates. Leave some of your questions or other items as comments. I'd love to hear what you think.Neal Reizerhttp://www.blogger.com/profile/05525404065315976171noreply@blogger.com1tag:blogger.com,1999:blog-1210147194078337603.post-46354766318652852722013-06-09T19:10:00.001-05:002013-06-09T19:10:19.220-05:00Big rewrites: Summing things up<span style="font-family: Helvetica Neue, Arial, Helvetica, sans-serif;">My last several posts dealt with <a href="http://nealreizer.blogspot.com/2013/02/migrating-technology.html">migrating technologies</a>, <a href="http://nealreizer.blogspot.com/2013/04/system-migration-and-people-part-1.html">people</a>, and <a href="http://nealreizer.blogspot.com/2013/05/system-migration-and-people-part-2.html">skills </a>considerations. Certainly, a few posts can't do justice to something as complex as a system technology refresh. On the other hand, there are a few principles that can be helpful guides as you navigate the the complexity.</span><div>
<span style="font-family: Helvetica Neue, Arial, Helvetica, sans-serif;"><br /></span></div>
<div>
<ul>
<li><span style="font-family: 'Helvetica Neue', Arial, Helvetica, sans-serif;">Iterate<br /></span><span style="font-family: Helvetica Neue, Arial, Helvetica, sans-serif;">If possible, break the rewrite into smaller chunks. Determine the smallest amount of business value you can deliver and start there. This allows you to stay focused on </span><span style="font-family: 'Helvetica Neue', Arial, Helvetica, sans-serif;">software delivery </span><span style="font-family: 'Helvetica Neue', Arial, Helvetica, sans-serif;">fundamentals</span><span style="font-family: 'Helvetica Neue', Arial, Helvetica, sans-serif;"> and to use the new technology in the real world. Release management, branching and merging, and patching are just a few of the processes I've seen atrophy after years of rewriting software without a delivery.</span></li>
<li><span style="font-family: 'Helvetica Neue', Arial, Helvetica, sans-serif;">People<br /></span><span style="font-family: Helvetica Neue, Arial, Helvetica, sans-serif;">A blended team of existing folks and new hires is desired, but comes with issues that require supportive, yet firm, management. The technology transition is going to happen - that is where you must remain firm. It is not reasonable to expect your existing team to learn a new technology stack in the context of significant business implications. </span><span style="font-family: 'Helvetica Neue', Arial, Helvetica, sans-serif;">You will have acquire skills and that will cause friction. These new folks have to be integrated into a new, combined team.</span></li>
<li><span style="font-family: 'Helvetica Neue', Arial, Helvetica, sans-serif;">Skills<br /></span><span style="font-family: 'Helvetica Neue', Arial, Helvetica, sans-serif;">The existing team members are a key to success due to expertise of the</span><span style="font-family: 'Helvetica Neue', Arial, Helvetica, sans-serif;"> system, customers, and industry. Your commitment to their education, skills, and to be blunt - employment, is the supportive aspect. Show them how they will participate in the transition itself, as well as their contribution in the new world after the change. Provide them a picture of their role after the new technology is in place to assure them that they aren't helping the "new folks" build the system that is putting them out of a job.</span></li>
</ul>
</div>
<div>
<span style="font-family: Helvetica Neue, Arial, Helvetica, sans-serif;">These principles provide you a start at identifying the core issues you will face regardless of technology or industry. For example, iteration is simple in theory. In practice you have to address factors such as, "What is the least meaningful value I can ship to the market?", "How can I deliver 'less than everything' alongside existing software?", and "How long do I really have in the market with the existing product?"</span></div>
<div>
<span style="font-family: Helvetica Neue, Arial, Helvetica, sans-serif;"><br /></span></div>
<div>
<span style="font-family: Helvetica Neue, Arial, Helvetica, sans-serif;">The questions that follow from the principles are the real power. Conversations surrounding the questions and their answers will do more to increase project success than all the project management during the project itself. After all, if you don't have the right skills, your team is demoralized, and the project is a multi-year science project, your project status reports are going to be the least of your worries.</span></div>
<div>
<span style="font-family: 'Helvetica Neue', Arial, Helvetica, sans-serif;"><br /></span></div>
<div>
<span style="font-family: 'Helvetica Neue', Arial, Helvetica, sans-serif;"><br /></span></div>
<div>
<br /></div>
Neal Reizerhttp://www.blogger.com/profile/05525404065315976171noreply@blogger.com0tag:blogger.com,1999:blog-1210147194078337603.post-73913145004500410382013-05-03T14:32:00.000-05:002013-06-09T19:10:31.979-05:00System migration and people: Part 2<span style="font-family: Helvetica Neue, Arial, Helvetica, sans-serif;">Technologists often align themselves to the skills they possess. You see it in job titles: Senior .NET developer; Java architect, and so on. In the midst of a migration to a new technology stack, you are changing more than a person's business card. You are changing who they perceive themselves to be.</span><br />
<br />
<span style="font-family: Helvetica Neue, Arial, Helvetica, sans-serif;">This presents a fundamental challenge to large-scale technology migration. And one of the greatest ironies. </span><br />
<span style="font-family: Helvetica Neue, Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Helvetica Neue, Arial, Helvetica, sans-serif;">Possession of the required new skills is the least important contribution from your existing team. Yes - you read that right. During this transition, what makes your existing team so valuable is not their technical skills. So what does?</span><br />
<br />
<ul>
<li><span style="font-family: 'Helvetica Neue', Arial, Helvetica, sans-serif;">Domain knowledge<br />No matter your business, there is specialized domain knowledge. Mine is healthcare. That means deep understanding of patient registration, ordering medications, patient care documentation, and scores of other complex workflows. These don't change with new technology. Your team has spent years learning these and the interplay among them.</span></li>
<li><span style="font-family: 'Helvetica Neue', Arial, Helvetica, sans-serif;">Customer understanding<br />Your team understands how your customers operate at the intersection of the current product and the domain. You can't do a migration without some consideration for your customer base. Your team has customer relationships and trust (hopefully) to increase the chances of the transition going smoothly.</span></li>
<li><span style="font-family: 'Helvetica Neue', Arial, Helvetica, sans-serif;">Organizational knowledge<br />As I <a href="http://nealreizer.blogspot.com/2013/04/system-migration-and-people-part-1.html">wrote last time</a>, you may supplement your team with expertise in the new technology. These folks aren't going to have a clue about anything related to the items above. Your team can help them navigate the challenges of finding information about the existing system and processes - or even who knows the answer in the first place.</span></li>
</ul>
<div>
<span style="font-family: 'Helvetica Neue', Arial, Helvetica, sans-serif;">Returning to the challenge - changing who a person perceives themselves to be. Your goal is to shift that perception. You have to state (and restate) that technology is fleeting - and that it can be learned. The emphasis for the existing team is on their knowledge of domain, customer, and organization. That can't be extinguished</span><span style="font-family: 'Helvetica Neue', Arial, Helvetica, sans-serif;"> by Java 8, HTML 5, or any other technology.</span></div>
Neal Reizerhttp://www.blogger.com/profile/05525404065315976171noreply@blogger.com0tag:blogger.com,1999:blog-1210147194078337603.post-69186752873280669052013-04-29T11:52:00.001-05:002013-06-09T19:10:39.667-05:00System migration and people: Part 1<br />
<span style="font-family: Helvetica Neue, Arial, Helvetica, sans-serif;">My <a href="http://nealreizer.blogspot.com/2013/02/migrating-technology.html">last post discussed migrating to a new technology stack</a> as part of extending the life of a software system. Next, I'll explore people considerations. The first topic is skills related to the technology stack. My next post will discuss the role of domain experience. Finally, I'll attempt to tie it all together with a summary post.</span><br />
<span style="font-family: Helvetica Neue, Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Helvetica Neue, Arial, Helvetica, sans-serif;">Chances are your current team possesses skills to evolve and maintain the existing system. Unfortunately, these may not be the technical skills needed by the new technology stack. This may be a source of fear among the team. While there are no easy solutions, here are some thoughts:</span><br />
<br />
<ul>
<li><span style="font-family: 'Helvetica Neue', Arial, Helvetica, sans-serif;">Get expertise in the new technology stack<br />The most effective way I've seen this done is to hire additional people to supplement the team. Find people who know the new technology well and have demonstrated its use in bringing to market solutions that have some matching characteristics to your product.<br /><br />You need people with experience, otherwise you will end up with the old solution implemented in new technology - not at all what you intend.</span><span style="font-family: 'Helvetica Neue', Arial, Helvetica, sans-serif;">Your goal is to quickly apply best practices with the new technology. Consultants have their place, but in this situation I find that nothing beats employees who are fully dedicated to the project.</span></li>
</ul>
<ul>
<li><span style="font-family: 'Helvetica Neue', Arial, Helvetica, sans-serif;">Commit to training</span><span style="font-family: 'Helvetica Neue', Arial, Helvetica, sans-serif;">For those who want to, provide training in the new technology. It's OK if some want to stay with the older stack. it will be around for a while and you will need to maintain it. However, show people that you are willing to invest in their future and they will be more likely to stay with you through the transition.</span><span style="font-family: 'Helvetica Neue', Arial, Helvetica, sans-serif;"><br />In addition to training, integrate new employees with existing teams to increase the pace of learning. This will create one team, demonstrate by example how to apply the new tech stack, and allow new employees exposure to existing rationale, business rules, and architecture.</span></li>
</ul>
<br />
<span style="font-family: 'Helvetica Neue', Arial, Helvetica, sans-serif;">Understand that for some, they will equate their value to their existing skills. My next post will address this directly.</span><br />
<br />Neal Reizerhttp://www.blogger.com/profile/05525404065315976171noreply@blogger.com0tag:blogger.com,1999:blog-1210147194078337603.post-25674862386528869682013-02-16T17:54:00.001-06:002013-06-09T19:10:51.829-05:00Migrating technology<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif;">
I've been
thinking a lot about extending the life of a software system.<span style="mso-spacerun: yes;"> </span>There are several hard problems to
solve.<span style="mso-spacerun: yes;"> </span>The first problem I want to
discuss is migrating to a new technology stack.<span style="mso-spacerun: yes;">
</span>I'm skipping the discussions that take place before the decision to
transition to a different technical stack are made.<span style="mso-spacerun: yes;"> </span>Whether that decision is good or bad, if it
has been made it is your job to get it done. </span><br />
<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif;">
</span><br />
<h3 style="font-family: "Segoe UI"; margin: 0in;">
<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif; font-size: small;">Consideration #0
- Don't do it all at once</span></h3>
<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif;">
Big rewrites are
very likely to fail. So don't try them.<span style="mso-spacerun: yes;">
</span>Learn from our collective Agile experience and establish a backlog for
your migration.<span style="mso-spacerun: yes;"> </span>You will learn a lot
from planning the backlog, such as business and sales pain points, architecture
dependencies, and areas that don't require immediate attention.<span style="mso-spacerun: yes;"> </span>This gives you the advantage of putting new
technology into the market faster, further accelerating your learning feedback
cycle.</span><br />
<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif;">
</span><br />
<h3 style="font-family: "Segoe UI"; margin: 0in;">
<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif; font-size: small;">Consideration #1
- Build new features in the new technical stack</span></h3>
<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif;">
While
straightforward to understand, this is perhaps the most difficult to
implement.<span style="mso-spacerun: yes;"> </span>Your end user work flows have
to be (relatively) seamless.<span style="mso-spacerun: yes;"> </span>The
existing system was designed to support a collection of end user goals and
workflows.<span style="mso-spacerun: yes;"> </span>If the new feature is
presented is a jarring manner, you risk putting your users off.</span><br />
<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif;">
</span><br />
<div style="font-family: "Segoe UI"; margin: 0in;">
<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif;">A few years back,
my team was challenged to move from Delphi to .NET.<span style="mso-spacerun: yes;"> </span>We found ways to render .NET screens inside
Delphi containers.<span style="mso-spacerun: yes;"> </span>Although we used
different component libraries, an end user had to be extremely astute to notice
subtle control rendering variations.<span style="mso-spacerun: yes;"> </span>A
more recent experience involving more disparate technologies has required some
visual redesign of the existing application to reduce the perception gap.</span></div>
<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif;">
</span><br />
<div style="font-family: "Segoe UI"; font-size: 11pt; margin: 0in;">
<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif;"><span style="font-size: small;">Regardless of
your technologies, you have to make the user experience transition as seamless
as possible.</span><span style="mso-spacerun: yes;"> </span></span></div>
<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif;">
</span><br />
<h3 style="font-family: "Segoe UI"; margin: 0in;">
<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif; font-size: small;">Consideration #2
- Rewrite parts of the existing system when appropriate</span></h3>
<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif;">
As your existing
system requires modifications, determine if the feature to modify is a good
candidate for being rewritten.<span style="mso-spacerun: yes;"> </span>Again
going back a few years, we were faced with a major overhaul to government
reimbursement for Home Health services.</span><br />
<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif;">
</span><br />
<div style="font-family: "Segoe UI"; margin: 0in;">
<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif;">Instead of
modifying the existing (tried and true Delphi) payment system, we left it
alone.<span style="mso-spacerun: yes;"> </span>We wrote the new billing engine
in .NET.<span style="mso-spacerun: yes;"> </span>This allowed us to guarantee no
regression to existing billing and to add significant capability in the new
system.</span></div>
<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif;">
</span><br />
<h3 style="font-family: "Segoe UI"; margin: 0in;">
<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif; font-size: small;">Consideration #3
- Accept that some stuff will remain around for a very long time, maybe forever</span></h3>
<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif;">
This can be hard
to accept.<span style="mso-spacerun: yes;"> </span>Engineering, and I suppose
business, is about choices.<span style="mso-spacerun: yes;"> </span>Those
choices involve what you do and what you don't do.<span style="mso-spacerun: yes;"> </span>There are parts of your system that work, are
reliable, and aren't causing you lost sales.<span style="mso-spacerun: yes;">
</span>Before you rewrite those pieces, have a compelling reason to do so.</span><br />
<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif;">
</span><br />
<div style="font-family: "Segoe UI"; margin: 0in;">
<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif;">In general, your
goal is to devise a scheme to migrate to the new technology over a reasonable
period of time, incrementally, with little impact to your end users.<span style="mso-spacerun: yes;"> </span>I know this is hard.<span style="mso-spacerun: yes;"> </span>But it is possible.<span style="mso-spacerun: yes;"> </span>The alternative - a massive all-or-nothing
rewrite - has proven again and again to lead to failure.</span></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi3jeGiYwglMIZYuUySlnpYTLdiBoj6ewMmfH7KZpwFrvGwG7Aa6FXvvsBsovfJOLe2t649HWbJGYMXmWFRIV3qfSjpfvF557FpQpV-6XNhLHdBZjOCLMjS3U9OYXc4-wrWp8tK7bOW5msR/s1600/Signature.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"></a><br />
<div style="text-align: left;">
</div>
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi3jeGiYwglMIZYuUySlnpYTLdiBoj6ewMmfH7KZpwFrvGwG7Aa6FXvvsBsovfJOLe2t649HWbJGYMXmWFRIV3qfSjpfvF557FpQpV-6XNhLHdBZjOCLMjS3U9OYXc4-wrWp8tK7bOW5msR/s1600/Signature.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;">
</a><span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif;"></span><br />
<div style="font-family: "Segoe UI"; font-size: 11pt; margin: 0in;">
</div>
Neal Reizerhttp://www.blogger.com/profile/05525404065315976171noreply@blogger.com1tag:blogger.com,1999:blog-1210147194078337603.post-23334057036596063042012-07-25T06:32:00.000-05:002012-07-25T06:32:21.439-05:00Understand old solutions to solve new problems<br />
In my last post, I ended with a comment about the importance of understanding solutions in order to solve a broader range of problems. Problems have an essence. If you understand the essence of a problem, you can draw from solutions for that class of problems.<br />
<br />
Consider the problem of managing vaccination history for a patient. Take a moment to enumerate the essential characteristics of this problem. Can you think of systems you have seen or used that address problems with similar characteristics?<br />
<br />
What would you say if I told you that tracking vaccinations is a very similar problem to your vehicle’s recommended maintenance schedule? If you don’t believe me, next time you get your oil changed, ask to take a look at the screen the service manager uses to upsell you on a new air filter. Replace each recommended service with a vaccination and you should see what I mean.<br />
<br />
Experience with and exposure to varied solutions is important. However, it is not enough. You must internalize the relationship to the problems they solve and the essence of those problems.<br />
<br />
Here is an approach that may help:<br />
<br />
<ol>
<li><span style="background-color: white;">When you use tools (physical or software), identify the problem the tool solves. Ignore the features – focus on the problems. For example, don’t think of a hammer as something to “Drive a nail into a wall.” Think “Deliver force to an object.” </span></li>
<li><span style="background-color: white;">When solving a problem, tease out its essence. Find solutions that solve problems sharing essential characteristics. For example, replacing the lid on a paint can requires the use of directed force to seal the canister.</span></li>
</ol>
<br />
<span style="background-color: white;">Go out and build an inventory of solutions and the problems they solve. The larger your solution inventory, the broader the range of problems you will be able to solve.</span><br />
<div>
<br /></div>Neal Reizerhttp://www.blogger.com/profile/05525404065315976171noreply@blogger.com0tag:blogger.com,1999:blog-1210147194078337603.post-38432518742822837522012-03-15T08:47:00.001-05:002012-03-15T08:47:53.626-05:00Drive<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif;">I recently received an e-mail relating how certain programming constructs look elegant, but turn out to be grossly inefficient. That got thinking about abstraction frameworks and how they increase perceived development speed, yet can have unintended consequences (performance being a big one). That, in turn, got me thinking about why the guys on the thread could immediately spot the underlying inefficiency through visual inspection.</span><br />
<br />
<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif;">Are they inherently smarter? Maybe. </span><br />
<br />
<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif;">Did they screw up a similar project and learn? Possibly.</span><br />
<br />
<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif;">Are they driven to understand how things work at a fundamental level? Check.</span><br />
<br />
<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif;">What separates these guys from the huddled masses is an innate drive to understand their world (in this case, software engineering) down to the ones and zeros. I’ve sat next to both of them while they code. They have debuggers, output windows, browsers inspectors, and SQL execution plans running well after typical developers would have committed the code.</span><br />
<br />
<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif;">They have a drive to know their code is correct, fast, and readable. They dissect it, improve it, and test it. If someone is going to break their code, it will damn sure be them, not someone else.</span><br />
<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif;">But you protest. Surely, they must not understand deadlines! Clearly, they take longer! </span><br />
<br />
<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif;">You protest in vain. These guys are among the most productive guys I’ve worked with. Their code is clean before they release it. There is rarely rework. Because they have spent so much time understanding their tools, they avoid mistakes made by developers who focus on getting it done and checked-in.</span><br />
<br />
<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif;">Their breadth of understanding allows them to quickly select appropriate constructs and patterns based on the problem. Contrast this with developers forced to solve problems based on what they know versus the nature of the problem itself. More importantly, their depth of knowledge allows them to know why their solution will work and what its limitations are. Most developers won’t fully understand why their solution works. Or what problems it can’t solve.</span><br />
<br />
<span style="font-family: "Helvetica Neue", Arial, Helvetica, sans-serif;">I’ll leave things here. I plan to return to this last paragraph in a future post.</span>Neal Reizerhttp://www.blogger.com/profile/05525404065315976171noreply@blogger.com0tag:blogger.com,1999:blog-1210147194078337603.post-63942027890743984142011-12-23T08:51:00.010-06:002011-12-23T09:01:10.239-06:00Free to be crazy<span>I’ve been thinking about why I am comfortable throwing out crazy ideas to my team. I don’t think it is solely my lack of concern about appearing foolish (although there is an element of that).</span><div><span><br />I’ve repeatedly told my team – everyone, not just managers – that one of their most important jobs is to keep me from making bad decisions. I need to know that I am going to get honest feedback from everyone. This gives me freedom to come up with crazy ideas without fear they will be accepted simply because they came from me.<br /><br /></span></div><div><span>How do you get the team to a point where everyone believes they can safely share feedback with you?</span></div><div><span><ul><li>Reinforce the need to know the truth from your staff. Encourage people to challenge you. They may not do this initially. After all, you are the boss.</li><li>When you propose an idea, actively solicit input in public settings: “What do you think?” “Is there something I am missing?” “What would you do?” It will take time. If you keep asking, people will start to use their voice.</li><li>Once people find their voice, listen. The ensuing dialogue is the reinforcement needed to move your team into a positive feedback cycle. Use this time to explore your idea, tear it apart, defend it (without being defensive), and find viable alternatives.</li></ul>I have found that most of the time there are only a few outcomes (in descending order of occurrence):<br /><ul><li>I realize I am crazy and I’m grateful that we didn’t act on my idea.</li><li>A kernel of goodness is contained in my idea and the interaction results in a much better idea.</li><li>I actually had a pretty good idea after all.</li></ul>Remember, you aren’t trying to be right. You are trying to get to the best decision for the situation. Your job isn’t to be right – it is to make sure the right decisions are made by the team.<br /><br /></span></div><div><span>One last consideration. If you never accept the feedback, then you have two problems. Number one, your team will stop offering it. And two, you aren’t really interested in hearing it – which is why number one happens.</span></div><div><span><br />So go out and be crazy. Something good is sure to happen.</span><br /></div>Neal Reizerhttp://www.blogger.com/profile/05525404065315976171noreply@blogger.com0tag:blogger.com,1999:blog-1210147194078337603.post-5164880000213084252011-11-22T21:41:00.008-06:002011-11-22T22:32:42.927-06:00Argue your way to good decisions<span class="Apple-style-span" >If you observed my Friday afternoon leadership team meetings, you might think we are the most argumentative bunch of folks on the planet. And with good reason.<br /><br />We are.<br /><br />You might further think we constantly fight, back stab, and never agree to anything.<br /><br />You'd be wrong.<br /><br /><span style="font-weight:bold;">Respectful disagreements</span><br />From the time I interviewed and recruited the team, we've interacted with respect. During interviews, I challenged their beliefs. I wanted to know how they handle a differing opinion by someone "in authority." Could they defend their position without becoming defensive? Could they acknowledge a counterpoint even if they didn't agree?<br /><br />I didn't ask the "Tell me about a time when you disagreed with your boss" question. I wanted to disagree with them and see how they reacted. If you are going to do behavioral interviews, then you might as well elicit behaviors.<br /><br />One important point. Even in heated discussions involving critical decisions, we maintain respect. We don't throw things; we don't shout; we don't name call.<br /><br /><span style="font-weight:bold;">High Standards</span><br />Every member of my leadership team is excellent at what they do. They have selected each other as much as they've selected me. We expect the best from each other and push each other. We don't want to let each other down.</span><div><span class="Apple-style-span" ><br /></span></div><div><span class="Apple-style-span" >Keep this in mind when you recruit. I've found that if you hire wrong, the team descends to the lowest common denominator. Hire well and your team rises to levels of achievement unreachable individually.<br /><br /><span style="font-weight:bold;">Confidence</span><br />What type of person is better equipped to be wrong and make a change? One with low self-esteem or one with high self-esteem?</span></div><div><span class="Apple-style-span" ><br /></span></div><div><span class="Apple-style-span" >Correct - high self-esteem. If we felt that our self-worth was tied to being correct, we would never get to problem resolution. We would be too busy defending our self-esteem.<br /><br />So what does all this lead to (other than ending a sentence with a preposition)?</span></div><div><span class="Apple-style-span" ><br />Freedom.</span></div><div><span class="Apple-style-span" ><br /></span></div><div><span class="Apple-style-span" >Freedom to acknowledge a better idea. Freedom to ask for help. Freedom to admit a mistake. Freedom to learn from each other.<br /><br />What matters is that we arrive at a good decision. Equally important, it is a decision that has been argued, ripped apart, challenged, and extensively reviewed. When I walk out of the room, I'm confident a good decision has been made.<br /><br />That is why I love leading this group of argumentative folks.</span></div>Neal Reizerhttp://www.blogger.com/profile/05525404065315976171noreply@blogger.com0tag:blogger.com,1999:blog-1210147194078337603.post-30038627761692997402011-09-02T09:18:00.006-05:002011-09-02T09:26:23.633-05:00Risk versus perfection<div><font color="#000000" face="arial">I was recently asked how I can encourage my team to take risks, while simultaneously driving them to perfection. “After all”, the questioner posed, “doesn’t the drive for perfection inhibit risk taking?”</font></div><font face="arial"><div>
<br /><font color="#000000">It was a terrific question. I was not able to answer immediately. With the benefit of a few weeks of thought, here goes.</font></div><p><font color="#000000">First, I don’t ask for perfection. I ask for excellence. This is an important, subtle difference. Excellence is the attitude for approaching a task. Excellence is:</font></p><ul><li><font color="#000000">Driven by personal investment to deliver a quality outcome</font></li><li><font color="#000000">Attention to details without losing sight of key principles</font></li><li><font color="#000000">A commitment to deliver what one agrees to deliver, when promised</font></li><li><font color="#000000">A passion for delighting the recipient of the deliverable</font></li><li><font color="#000000">An understanding that every part matters, from the highest detail (functionality, visual design) to the lowest detail (alignment, colors).</font></li></ul><p><font color="#000000">Taking risks, on the other hand, is trying something with an uncertain outcome. Risk taking is:</font></p><ul><li><font color="#000000">A willingness to explore options, even if the result is failure (it never is, by the way)</font></li><li><font color="#000000">An ability to judge potential gain versus potential loss</font></li><li><font color="#000000">Trusting one’s intuition</font></li></ul><p><font color="#000000">Taking risks and excellence are not mutually exclusive. Taking risks is about choices we make. Excellence is the attitude we have when executing those choices. That is, once I choose to take a risk (change partners or technology, for example), the decision must be executed with excellence.</font></p><p><font color="#000000">Sending a human to the moon was a risk; it was performed with excellence.</font></p><p><font color="#000000">Encourage your teams to take risks. And expect excellence in all they do.</font></p></font><p></p>Neal Reizerhttp://www.blogger.com/profile/05525404065315976171noreply@blogger.com0tag:blogger.com,1999:blog-1210147194078337603.post-78963056450094739322011-08-02T10:48:00.017-05:002011-08-02T11:03:04.728-05:00Resumes: Views from a hiring manager<span style="font-family: verdana; color: rgb(0, 0, 0);">I’ve been fortunate to grow a team significantly in the last year. To achieve this, I’ve had many screenings and interviews. This process led to the following observations.</span><br /><br /><span style="font-family: verdana; font-size:22px; color: rgb(0,0,0);">Focus your skills list</span><br /><span style="font-family: verdana; color: rgb(0, 0, 0);">Just because you programmed in Prolog twenty years ago doesn’t mean it belongs on your resume. I am put off by a resume that list dozens of languages, operating systems, and tools. It leaves the impression you can’t self-assess your strengths. Secondly, it doesn’t allow me to determine the technologies you actually know well.</span><br /><br /><span style="font-family: verdana; color: rgb(0, 0, 0);">You might say, “I list my skill level for each technology!”</span><br /><br /><span style="font-family: verdana; color: rgb(0, 0, 0);">Strike two.</span><br /><br /><span style="font-family: verdana; color: rgb(0, 0, 0);">Can you really say that you are 4 out of top level of 5 in C#, C++, Java, Perl, Ruby, PHP, SQL, OOP, MVVM, MVC, M-I-C-K-E-Y M-O-U-S-E, Agile, and Waterfall? Yes, I’ve seen this type of listing repeatedly. No they didn’t get a call.</span><br /><br /><span style="font-family: verdana; color: rgb(0, 0, 0);">Anything you put on your resume is fair game. If you haven’t used something for years or you have only dabbled, you won’t discuss it well. That can only hurt you. If you list something in this category, acknowledge it was a while ago. And rehearse why you still mention it.</span><br /><br /><span style="font-family: verdana; font-size:22px; color: rgb(0,0,0);">Highlight strengths</span><br /><span style="font-family: verdana; color: rgb(0, 0, 0);">List your strong skills that match the job for which you are applying. Eliminate everything not relevant to the job description. If I’m looking for .NET C# with Visual Studio, then Java with Eclipse isn’t necessarily going to help. There is an exception.</span><br /><br /><span style="font-family: verdana; color: rgb(0, 0, 0);">If you have substantial domain experience (e.g., Healthcare), then highlight it. Domain experience is often more valuable than technical skills. In this scenario, drive home the domain experience while acknowledging that you used different technology.</span><br /><br /><span style="font-family: verdana; color: rgb(0, 0, 0);">Demonstrate that you understand the external environment and are self-aware regarding your technology skills. Then highlight (through examples) your ability to acquire new skills and obtain a level of excellence with them.</span><br /><br /><span style="font-family: verdana; font-size:22px; color: rgb(0,0,0);">Closing thoughts</span><br /><span style="font-family: verdana; color: rgb(0, 0, 0);">Tune your skills list to the job description. It is better to identify a few skills you know well than to dilute precious interview time on average or weak ones. And remember, knowledge of languages and tools isn’t the only deciding factor for hiring someone. Your <a href="http://nealreizer.blogspot.com/2009/10/hire-for-attitude.html">attitude about learning and passion</a> for software are as much a factor as experience and skills.</span><br /><br /><br /><span style="font-family: verdana; color: rgb(0, 0, 0);">Be ruthless with what you put on your resume. If you don’t, I will.</span>Neal Reizerhttp://www.blogger.com/profile/05525404065315976171noreply@blogger.com0tag:blogger.com,1999:blog-1210147194078337603.post-74676808862305328592011-06-16T22:56:00.017-05:002011-06-16T23:52:17.593-05:00Giving Feedback<span style="font-family:arial;">One management skill I have found essential is giving feedback. Here are a few tips I have learned about giving feedback.</span><br /><span style="font-family:arial;"></span><br /><span style="font-family:arial;font-size:130%;">Don't be afraid</span><br /><span style="font-family:arial;">OK, this may seem obvious. Lets face it - giving feedback is awkward and hard. I think this stems from an innate desire to be liked. If you have to give corrective feedback, you run the risk of making the other person mad at you. Or hurt.</span><br /><span style="font-family:arial;"></span><br /><span style="font-family:arial;">There aren't many things I can tell you about this. Well, actually there are *tons* of things I can tell you about, but that's not the point of this post... I will say this - don't own your employee's response. If you follow these guidelines you've done your part. If they are angry, hurt, or anything else - that is their feeling to own. Wow - I feel like I should be asking you for a therapy co-pay...</span><br /><span style="font-family:arial;"></span><br /><span style="font-family:arial;font-size:130%;">Give feedback as close to the event as possible</span><br /><span style="font-family:arial;">If someone is out of line at a meeting, call them out in front of their peers (if it is warranted) or pull them aside privately after the meeting. This is a delicate balance. The general rule is criticize in private. However, if someone crosses a line <span id="SPELLING_ERROR_0" class="blsp-spelling-corrected">publicly</span>, address it immediately.</span><br /><span style="font-family:arial;"></span><br /><span style="font-family:arial;">It is important your team knows you won't tolerate this behavior and that you are addressing it. Of course, if someone is so out of line <span id="SPELLING_ERROR_1" class="blsp-spelling-corrected">publicly</span>, you probably have another issue...</span><br /><span style="font-family:arial;"></span><br /><span style="font-family:arial;font-size:130%;">Give feedback <span id="SPELLING_ERROR_2" class="blsp-spelling-error">from</span> the heart</span><br /><span style="font-family:arial;">Wow - can I get more touchy <span id="SPELLING_ERROR_3" class="blsp-spelling-error">feely</span>? Maybe not.</span><br /><span style="font-family:arial;"></span><br /><span style="font-family:arial;">The point is to have your employee's best interest foremost in your mind. You have to care about your employee. Show her you are concerned for her professional growth and relationships.</span><br /><span style="font-family:arial;"></span><br /><span style="font-family:arial;">There is a saying that "feedback from the heart penetrates the heart." I believe this. Your employee will sense if you are jumping on them to make a problem go away or if you are sincerely trying to improve their character.</span><br /><span style="font-family:arial;"></span><br /><span style="font-family:arial;">Make sure you aren't angry when you give feedback. Think through why you are giving feedback.</span><br /><span style="font-family:arial;"></span><br /><span style="font-family:arial;">Is it to show someone you have authority? Is it to feel better because you felt wronged?</span><br /><span style="font-family:arial;"></span><br /><span style="font-family:arial;">Or is to help someone who is struggling to get better?</span><br /><span style="font-family:arial;"></span><br /><span style="font-family:arial;font-size:130%;">Be direct</span><br /><span style="font-family:arial;">Early in my career, I found all kinds of reasons to delay getting to the point. That doesn't work. I've found it best to be direct, factual, and <strong>brief</strong>. That last point is important.</span><br /><span style="font-family:arial;"></span><br /><span style="font-family:arial;">When you are nervous, you may tend to keep talking. That dilutes the message. Your job is to provide feedback, not debate. If your employee makes excuses, listen but redirect him. Let him know you understand his point but see things differently. In other words, don't buy into the drama.</span><br /><span style="font-family:arial;"></span><br /><span style="font-family:arial;font-size:130%;">Offer alternatives</span><br /><span style="font-family:arial;">Mature employees may ask you what you would recommend they do differently when confronting similar situations. Be prepared to offer alternatives. Help them role play alternatives so they can build new coping skills.</span><br /><span style="font-family:arial;"></span><br /><span style="font-family:arial;">If you prepare in advance, you will have empathy with their situation. You <span id="SPELLING_ERROR_5" class="blsp-spelling-corrected">will</span> be forced to consider their position. I've often found myself softening my position when I realized my employee's actions were not malicious.</span><br /><span style="font-family:arial;"></span><br /><span style="font-family:arial;">Giving feedback can be daunting. If you approach it with the intent to improve your employee, you'll be fine. </span><br /><span style="font-family:arial;"></span><br /><span style="font-family:arial;">Don't avoid giving advice. It will get easier over time.</span>Neal Reizerhttp://www.blogger.com/profile/05525404065315976171noreply@blogger.com0tag:blogger.com,1999:blog-1210147194078337603.post-18528788397310687032011-05-04T21:11:00.016-05:002011-05-04T22:29:36.043-05:00So you want to be an architectOver the last year or two, I’ve spoken with a handful of developers about their career. Several of them desire to become software architects. I’ve never really been satisfied with my guidance to them.<br /><br />With apologies to them for my poor initial responses, here are attributes I look for in an architect.<br /><br /><strong>Be a coach and mentor</strong><br />You might think technical excellence should be the first item on my list. While it is a requirement, it is not sufficient to be an architect. What matters is one’s ability to coach and mentor others to higher levels of achievement. A highly technical individual who cannot coach and mentor is not an architect. She is a highly technical individual contributor.<br /><br />Architects build large systems through a team. So while the architect may be the most technical, he must maximize the output of the team as a whole. Some examples of coaching and mentoring:<br /><br /><ul><br /><li>While reviewing other’s work, look for opportunities to praise good practice and to demonstrate improvements in critical thinking skills. It’s not about showing a better way to implement a specific module. Use the opportunity to teach a better way to think about the problem and possible solutions.</li><br /><br /><br /><li>Share your knowledge with the team. Use every opportunity to share not only your technical decisions, but options you considered but eliminated. Help your team understand how you made the decision, not just what the decision was.</li><br /><br /><br /><li>Expect your team to have great ideas. You don’t have to be the smartest all the time. You cannot expect your team to be willing to learn from others if you won’t.</li></ul><br /><strong>Desire to learn</strong><br />The best architects learn constantly. One monitor has Visual Studio open and the other has a blog about some piece of technology.<br /><br />Take time to read, study, and practice.<br /><br />I’ve known architects who spent personal time developing programs to exercise one or two language features. They may not need it immediately, but at some point they encountered a problem that feature was suited for.<br /><br />Architects learn from everyone. That includes business folks, QA, developers, and their leadership team.<br /><br /><br /><p></p><strong>Experience</strong><br />There is no substitute for experience in architecture. I’ve run into twenty-something developers with architect titles. I find that laughable. Experience brings diversity of challenges, solutions, technologies, and business contexts. It also brings time to have studied under other architects and senior mentors.<br /><br />You don’t have to have had many jobs and worked on dozens of systems. An architect must be exposed to a multitude of problems to solve. Each challenge faced and solved adds a tool to be used for the next problem. It provides maturity and confidence required to push through hard problems and solve them.<br /><br />A senior developer may master many software engineering technologies. An architect combines this basic requirement with coaching, personal desire to learn, and experience.<br /><br />An architect brings these elements together to solve new challenges. In this process, the seeds are sowed for new architects to be developed.<br /><br /><br /><p></p><i>On a personal note, I want to thank architects Mary Holstege, Andreas Guenther, Derik Whittaker, and Roger Larson. This article is merely a summary of what separates these folks from the rest of the bunch.</i>Neal Reizerhttp://www.blogger.com/profile/05525404065315976171noreply@blogger.com2tag:blogger.com,1999:blog-1210147194078337603.post-49133329439077612862011-02-23T20:31:00.005-06:002011-02-23T20:35:41.339-06:00People over technology<span style="font-family:verdana;">I just returned from the largest healthcare technology conference in the world, HIMSS 2011. There are hundreds of vendor booths ranging from a 10 foot table to city block sized two story complexes. It seemed everywhere I turned I was told that if only my doctor had an iPhone or tablet, patients would be healed faster, medical mistakes would plummet, and hospitals would recoup more money.<br /><br />There was so much technology that I found myself forgetting a basic fact. Healthcare is about healing people. And those that do the healing are people.<br /><br />I didn’t recognize how little I thought about patients until I put my girls to bed tonight and began reflecting on the show. Then it hit me.<br /><br />Every good and rewarding memory from the show involved people, not technology. It was the joy of being greeted with genuine fondness by former executive leaders. It was the smiles and embraces I received from past colleagues. And it was the tears when I ran into a prior customer as she turned a corner and I received the biggest hug of the entire event – and her kind and exaggerated words of thanks for the years of being a trusted partner to her organization.<br /><br />We are here to apply technology so our customer’s lives may be people-centered, not gadget centered.<br /><br />Regardless of your industry, remember that there is a person on the other end of your solution. Start with them and let their needs, their goals, and their hopes drive you – not the technology.<br /><br />One final story.<br /><br />I visited a hospice customer several years ago. After a day of IT, finance, and CIO type discussions, they asked if I’d like to tour their inpatient hospice unit. If you aren’t familiar an inpatient hospice unit, it is a place where people come to spend their last days. The average stay is measured in days, not weeks.<br /><br />It was sobering to be shown a typical patient room. By itself, that would have altered my view of my product and my role in leading the team developing it.<br />Then I saw the computer screens at the nursing stations with my application running. At that point I could trace a path to the choices I made daily directly to the patients who were in this unit dying. It ceased to be about technology. It became a quest to build something that would allow my users (nurses) to do their job better (help people die with dignity).<br /><br />Don’t lead with technology. Listen, observe, and seek to understand. Next time you find yourself getting enamored with new technology, don’t forget to ask yourself what difference it is going to make in the lives of your users.</span>Neal Reizerhttp://www.blogger.com/profile/05525404065315976171noreply@blogger.com1