Quantcast
Subscribe!

 

Enter your email address:

Delivered by FeedBurner

 

E-mail Steve
This form does not yet contain any fields.

    free counters

    Twitter Feed

    Entries in development (19)

    Friday
    Dec022016

    Learn a new word: The Feature Factory

    Quick shout-out to John Cutler writing at the Hackernoon site for this outstanding piece (and the source for today's 'Learn a new word' submission - The Feature Factory.

    What is a 'Feature Factory' in the context of a software development function?'

    From the piece on Hackernoon, '12 Signs You're Working in a Feature Factory' to get an idea -

    I’ve used the term Feature Factory at a couple conference talks over the past two years. I started using the term when a software developer friend complained that he was “just sitting in the factory, cranking out features, and sending them down the line.”

    How do you know if you’re working in a feature factory? (SMB Note: there are 12 signs in the post, I am just going to grab two of them here, but you really should read the entire piece)

    3. 'Success theater' around "shipping", with little discussion about impact. You can tell a great deal about an organizations by what it celebrates.

    7. Obsessing about prioritization. Mismatch between prioritization rigor (deciding what gets worked on) and validation rigor (deciding if it was, in fact, the right thing to work on). Prioritization rigor is designed exclusively to temper internal agendas so that people “feel confident”. Lots of work goes into determining which ideas to work on, leaving little leeway for adjustments and improvisation based on data. Roadmaps show a list of features, not areas of focus and/or outcomes 

    Really, really good stuff for project managers and development teams to think about.

    Why should this matter for readers of Steve's HR Tech?

    I can think of two reasons straight up.

    One, it is worthwhile to think about your current and potentially future providers of HR technology solutions in this context. Does your provider talk about their product roadmap for the next year or two in the same way you run down your holiday shopping or grocery list? Do they talk about the future as simply the container in which they will 'ship' more features and gadgets? Or do they discuss their plans and directions using your challenges and your desired outcomes as the context in which they are organizing and planning to deliver new solutions? I know I have written about this before, but it is worth repeating - almost any provider can build the capability you need if they think they have to. What is much more important for your long term success with a tech provider is if yours and their visions of the future are in alignment, and the methods, pace, and you feel confident in the manner in which you will both grow and evolve to be better prepared to succeed in that future. That is what is really important. Not just "shipping."

    And the other reason that this idea of the 'Feature factory' is important? Because in late 2016 it is pretty likely that all but the very smallest organizations have in-house IT and development teams themselves, and these teams are comprised of folks that both do not want to work in an environment that could be described as a feature factory, and at the same time have lots of career options that don't include your organization. As HR leaders, it is probably worthwhile from time to time to check in with some of your really important, hard to find, and harder to replace tech talent types and see how they really think and feel about the organization's development climate. If you are treating these talented and in-demand folks too much like cogs in the machine, chances are they won't want to stay in that machine for too long. They will see your shop as a skills and resume builder stepping stone to somewhere more interesting, more fun, and more challenging.

    Ok, that's it from me. Tip your servers.

    Have a great weekend!

    Monday
    Feb082016

    PODCAST: #HRHappyHour 233 - Knowing Your HR Potential

    HR Happy Hour 233 - Knowing Your HR Potential

    Recorded Thursday February 4, 2016

    Hosts: Steve BoeseTrish McFarlane

    This week on the HR Happy Hour Show, Steve Boese and Trish McFarlane recorded a podcast of a rehearsal on the day before a webinar that actually happened last Friday. I know that might be a little confusing, but just think of the show as the audio track for a webinar for the Cleveland SMA called 'Know Your Potential', (slides have been loaded up to Slideshare and are embedded below), that Steve and Trish delivered last week.

    The webinar (and this podcast), covered a range of topics, trends, and tips for HR, recruiting, and talent professionals - all aimed towards getting the most out of your potential for excellence in 2016.  So on the show we talk about some of the important trends for 2016, why they matter for HR and Talent pros, and how to leverage these trends in your professional life. Additionally, we shared some advice and tips on maximizing the value from online, social, and professional networks - an always interesting and rapidly changing space. Finally, while the webinar, (and attached sldes), covered some emerging HR and recruiting technologies, we cut the podcast short before this topic, as we will revisit it on its own show soon.

     

    You can listen to the show on the show page HERE, or using the widget player below (email and RSS subscribers will need to click through).

    The slides we used for the webinar and podcast can be found on Slideshare here, as well as embedded below.

     

     

    This was a really fun show to do, and many thanks for checking it out, and to the Cleveland SMA for having us on the webinar.

    Reminder: you can subscribe to the HR Happy Hour Show on iTunes or using your favorite podcast app for Android or iOS. Just search for 'HR Happy Hour' to add the show to your subscriptions and you'll never miss a show.

    Wednesday
    Dec092015

    What should we be working on?

    My favorite things to do on Winter weeknights are to watch NBA basketball, (thank you NBA League Pass), and plow though the seemingly thousands of unread items that accumulate each day in my Feedly feed reader. So in case you really care, and I am pretty sure you don't, this piece is being drafted (who am I kidding, on the blog there are no 'drafts', it is ship or don't bother writing around here), while watching LeBron and company take on Lance Haun's Portland Trail Blazers.

    But I digress.This is not Lance Haun

    While grinding through my Feedly looking for some inspiration for the blog, I came across this excellent compendium of product development prioritization techniques and approaches called 20 Product Prioritization Techniques: A Map and Guided Tour. The piece is a fantastic collection of strategies and methods that are employed by product managers and developers when faced with the fundamental and critical questions of 'What product features should we build?' and 'In what priority order should we build these features?'

    Both questions seem kind of easy on the surface, but for product managers and leaders they are not only very often quite complex, but how successful product leaders are at answering these questions plays a significant role in how successful (or not), their product will be. Build the 'wrong' features and current customers may defect and acquiring new ones may prove impossible. Build the 'right' features but in the 'wrong' order and risk making customers wait too long for features they need and end up losing 'bake-offs' for new customers when needed product features are not yet available.

    Like I said, simple sounding questions that are often really hard to answer. And really, really important to get right. 

    That's where the list of the 20 product prioritization techniques makes for a really useful starting point not just for 'product' people, but anyone that needs to assess and prioritize work efforts from a range of options, or what always seems to be an impossibly long 'to-do' list. Let's pull one example from the piece and see how it can be relevant and useful for both product and non-product, (I suppose that is just 'service') leaders. This is one I liked a lot and I think also can be pretty easily applied to say any internal HR or talent function.

    Technique: Feature Buckets

    The Feature Buckets technique by Adam Nash is also very popular on Quora.

    Adam believes that feature prioritization varies a lot across different product types and industries and that’s why he emphasizes that this technique was thought specifically for consumer internet products.

    Feature concepts should be placed in one of four buckets:

    • Metrics Movers — Features that will move the target business and product metrics significantly. There should be specific goals and strategies behind the decision to invest in a product or feature (things like AARRR metrics come in handy here);
    • Customer Requests —  These are features that have been requested directly by customers. They are usually incremental enhancements, but it’s important to consider them or else risk alienating users or miss important feedback coming from their usage of the product;
    • Delight —  Innovative features that are internally generated based on insights in design or technology. Working on surprising and exciting features is important to delight customers and create a differentiated position in the market (c.f. Kano Model for more on this);
    • Strategic – Features that are included for strategic reasons related to learning or future goals (e.g. experimentation and data gathering.)

    A well balanced product release should typically include features from all of these buckets. The framework is not explicit as to the appropriate distributions among these buckets and to how to prioritize internally within each. These implementation details are left up to the Product Manager to define.

    Breaking down the four components or buckets helps us see how if you could consistently deliver across all four that you would have an increased likelihood of customer (both internal and external customer) satisfaction.

    In this technique you address your fundamental, internal goals, (the Metrics Movers), as well as direct customer feedback, (Customer Requests). But you also showcase your innovation, and give your team opportunity to work on exciting stuff that your customers will be surprised by, (Delight). Finally, you continue to strengthen your position as market, product, and service leaders by building towards the future, (Strategic). 

    And I think you could just as easily apply the Four Buckets approach to any HR or Talent or Recruiting organization's quarterly plan as you can to a product development organization's list of potential features for the next product release. 

    If you are in product management, or just have the important, (and tough), job of figuring out what the organization should be working on today, tomorrow, next week, next month, etc., take a look at some of the prioritization techniques in the above-linked piece.

    No one can do everything we are asked to do. The most successful organizations know this, and they get really good at deciding what to do and what not to do.

    Ok, I am out. 

    Back to basketball.

    Have a great day!

    Wednesday
    Dec022015

    You can learn plenty from a simple employee tenure chart

    Count of employees by years of tenure. Quite possibly the simplest workforce metric, (can we even call it a 'metric?'. I guess), that exists. And since it is so simple, really it is just counting up the number of employees at different levels of tenure like 1 year, 2 years, more than 10 years, etc., it probably can't tell us all that much about the conditions or capabilities of a large workforce right?

    Well maybe this simple metric can tell us a little more than we think. Take a look at the data below, and before you skip ahead to the rest of the post to see where the data is drawn from, ask yourself what this simple data set might say or at least suggest about the organization in question:

    EXPERIENCE

    NUMBER

    First year

              10

    Second year

              13

    Third year

                1

    Fourth year

                0

    Fifth year

                1

    6-9 years

             21

    10-15 years

             38

    16-20 years

             27

    21-27 years

            10

    Source: (see below)

     

    So what can we discern from the data above, on the tenure counts of a group of employees that do pretty much the same job inside a mid-sized organization?

     

    Obviously there is a visible 'gap' in experience levels across this group - there is a huge cluster of the total of 121 employees in the group (about 61%) having more than 10 years experience and another smaller, but not insignificant grouping having between 1 and 2 years experience, (about 20%). But in between these clusters at the extremes of experience? Not many employees at all. In fact there are only 2 out of 121 employees having between 3 and 5 years experience on the job - often the 'sweet spot' for proficiency in many roles, but more on that in a second.

     

    What might we then deduce about the potential issues that might face any organization, (and again, we will get to which specific organization data set represents soon), with this kind of 'hollowed-out' tenure distribution?

     

    I can think of at least three things, and I promise I am not trying to allow my knowledge of who this organization is to reach these observations:

     

    1. Something in this organization's recruiting/onboarding/mentoring/early development for new employees is not working. To have effectively about zero staff in the 3 - 5 years of experience cohort says you either are bringing the wrong type of people into the role, or are failing to get them up to speed to the point where they are succeeding within 3 years. The chart, simple as it is, can't tell us what exactly is wrong, but that certainly something is wrong.

     

    2. Although this is just a tenure chart, and not an 'age' chart, it doesn't require too much of a stretch to conclude that this organization is going to face a pretty serious issue with older workers either retiring or with them simply unable to perform in the role at a high level once they hit a certain age. There are pretty significant physical and fitness requirements for this role, making it not the kind of job that most people can continue in much past say 60 or so. This lack of balance in experience with the heavy skew towards 10 and 15 year plus employees is going to present acute issues in the next 3 - 5 years (and possibly beyond).

     

    3. An organization with this kind of tenure distribution probably has not kept up from a talent management and recruiting perspective with the increasing demands of the role. Like most jobs, the one held by the folks in this chart has become more complex in the last few years, has more scrutiny and pressure placed upon the people in the role, and the employees have more at stake in terms of money and prestige for the organization that employs them. In a nutshell, this job, while being around for about 100 years or so, has in the last 10 or so gotten much, much harder. And the 'gap' in the talent pipeline shows us that recruiting, development, and mentoring efforts have not kept up. Entire new classes of new hires are gone inside if 5 years.

     

    Ok, so who is this organization/group of employees who are reflected in the above chart?

     

    No one but the National Football League's on-field officials - the 'Zebras' that officiate and adjudicate the action on the fields of America's most popular professional sports league, the NFL.

     

    And increasingly, these on-field officials are in the news for all the wrong reasons - missed calls, bad calls, failure to recognize clearly concussed and barely vertical players after they are smashed in the head, and so on. This group of employees, as a group, have been performing poorly for some time now. And the talent pipeline as we see above does not indicate that things are about to get any better anytime soon.

     

    The big lessons for the rest of us?

     

    Pay attention to tenure. Sure, it is not the only or even the most important simple metric to think about. But if it takes 3 or 4 or 5 years for someone to really become expert at the job, and you have hardly any employees in those buckets, then you are going to have organizational performance issues. You will have too many folks on the downslope of their capability and too many who have not yet figured out what the heck is going on. And not enough folks heading up towards their peak.

     

    You are not always recruiting, developing, mentoring, and retaining to ensure high performance this week - sometimes you are doing all of those things to ensure high performance four years from now.

     

    And football is still dumb.

     

    Friday
    Mar202015

    The half-life of technical knowledge

    That thing you just learned about or acquired mastery of - it could be a piece of electronics or a programming language or a new HR or Talent Management system, or anything really - about how long would you estimate is the useful life of that newly acquired knowledge or expertise?

    One estimate,published in 1997, from the mathematician and engineer Richard Hamming suggests the half-life of technical knowledge is about 15 years. Since Hamming's conclusion was reached more than 15 years ago, the theory itself, as well as our own practical experience with the modern world, seems to indicate the 15 year useful life of specific technical knowledge is probably even shorter. It could be 10 years, it could be even fewer. You still (mostly) remember things, but as time passes the value of what you remember continues to diminish.

    Think about the device that passed for what you called a smartphone in 2005. Remember how that thing worked? And even if you do, does that specific knowledge help you much today? Or how about the expertise you developed to help you navigate through that archaic HR and Payroll system your company used a decade ago. Any of that training and learning paying off these days?

    While it is no great bit of insight to conclude that technology is progressing more rapidly than even in the recent past, the question that results from that conclusion, just how can you attempt to stay relevant and knowledgeable in such a fast-moving environment is the important matter. How can or should you go about becoming more accustomed to learning all of the time, since as much as half of the knowledge we have already acquired becomes obsolete, in a kind of continuous cycle of degradation?

    Well, our pal Hamming had some really good ideas about that, and they have been synthesized and summarized in this excellent piece Ten Simple Rules for Lifelong Learning, According to Hamming, on the PLOS Computational Biology site. (Please don't ask me what I was doing on a Computational Biology site).

    You should really read the entire piece, it is not that long, you have time, but since I know you won't I will highlight the one 'rule' that stood out for me the most, especially since it sort of contradicts a currently popular idea that we should be open to and embrace failure.

    Take a look at an excerpt Rule 6, Learn From the Successes of Others:

    As Hamming says, because “there are so many ways of being wrong and so few of being right, studying successes is more efficient, and furthermore, when your turn comes you will know how to succeed rather than how to fail.” In addition, he notes that “vicarious learning from the experiences of others saves making errors yourself.

    The best part of that observation is just recognizing the almost infinite number of ways to fail and the extremely rare ways to succeed or to be 'right'. Maybe we have gotten too caught up in the 'embrace failure' cult since it is just easier to spot and experience failure in ourselves and in others than it is to attain success. Learning from success, even other's success, might get you where you want to be faster than always trying to extrude the value from your own failures.

    There are plenty of other great nuggets in the piece, (especially Rule 8. No Matter How Much Advice You Get and How Much Talent You Possess, It Is Still You Who Must Do the Learning and Put in the Time), so like I mentioned above if you are someone that needs to be concerned and able to keep current and proficient in today's complex world of technology the entire article is worth your time.

    Have a great weekend - try to learn something new!

    Errors occurred while processing template[pageRendered/journal.st]:
    StringTemplate Error: Can't parse chunk: {settingHomePageKBArticle}" target="_blank">Learn how.</a></li>
    <li>If you have already selected a front page, make sure it is enabled. Click on the Cubes icon (top right) and then click the "enable page" button.</li>
    </ol>
    </div>

    : expecting '"', found '<EOF>'
    StringTemplate Error: problem parsing template 'pageRendered/noDefaultModule': null
    StringTemplate Error: problem parsing template 'pageRendered/noDefaultModule': null